4000个居民如果每秒都问一次大模型“你现在想干什么”，绝大部分答案会是“继续走路”，钱和时间都花在了没有信息的回答上。大发娱乐的思路是让NPC平时不思考，只在事情发生变化时被叫醒。
先算一笔账：每秒一次调用到底是多大的量
下面是一个假设的模拟示例，只用来说明数量级，不代表任何实测数据。设想一座有4000个居民Agent的城市，游戏内每分钟让每个居民“想一次”。一个游戏日有1440分钟，于是一天要调用大模型约576万次。如果按真实时间每秒问一次，则是每秒4000次请求；哪怕单次响应只要一秒，也意味着要同时维持4000路并发。
更糟的是，这些调用里绝大多数没有信息量。上午八点，一个居民正在从家走向公司，路线没变、天气没变、钱包没变，模型给出的答案与上一分钟完全相同。我们花了最贵的一种计算，换来一个“继续”。
公开研究里也能看到类似的判断。Xie等人于2024年在《AI Metropolis》一文中报告，在他们测试的生成式智能体工作负载里，约95%的模拟时间花在大模型推理上；他们还指出，全局同步推进会制造“假依赖”，让本来可以并行的智能体互相等待。这些数字只针对他们的实验设置，不能当作所有模拟的通用比例，但它说明了瓶颈在哪里：不是物理计算，是“什么时候、为谁调用模型”。
所以问题不是“怎样让每次调用更快”，而是“怎样让大部分时刻根本不需要调用”。几千个角色同时运行时的性能压力，在大型多Agent模拟的性能问题里有更宽的讨论；这篇只谈其中最靠前的一环，即决定谁该被调用。
再补一个常被忽略的成本：调用不只花钱，还改变游戏的节奏。玩家点下“加速三倍”，事件密度也跟着涨三倍，如果每个事件都要等一次模型响应，加速反而会让画面更卡。事件驱动把“思考”从时间轴的每一格，挪到了少数几个节点上，加速时只是节点更密，而不是每一格都更重。
NPC的一天被拆成三种状态
在大发娱乐AI大模型的设计方案里，一个Agent在任何时刻只处于三种状态之一。
- 惯性执行：按已有的日程和计划行动。起床、通勤、上班、吃饭，都是由规则和状态机推进，成本接近零。
- 事件唤醒：某个条件被触发，日程被打断，需要重新判断。这时才向大模型（或轻量的本地模型）提交一次带上下文的请求。
- 定时反思：每隔一段游戏时间，把最近的经历压缩成几条“印象”，写入长期记忆，用来修正之后的偏好。
Generative Agents（Park等人，2023年发表于arXiv）提出的“记忆—反思—规划”架构，用了25个智能体在沙盒里运行。这个规模下让每个智能体频繁调用模型还撑得住；当数量提高到几千，就必须把“规划”从每一步都做，改成只在计划失效时才重做。
关键在于第二种状态的入口：什么算“事件”。定得太宽，等于每秒调用；定得太窄，NPC就变成反应迟钝的木偶。
用一个居民的一天来说明。设想一位在城东上班的居民（模拟示例）：清晨闹钟响起，起床、洗漱、通勤，这些都是惯性执行，每一步只查一张日程表和一个状态机。途中手机收到公司通知，“今天全员居家办公”。这是一个“计划被打断”的事件，他被唤醒，模型收到的上下文只有几行：当前位置、原定计划、新通知、今天的心情与预算。他的选择可能是折返回家，也可能顺路去咖啡店坐一上午。选定以后，他又回到惯性执行，这个早晨总共只调用了一次模型。
五类唤醒条件，各自对应什么代价
| 触发类型 | 模拟示例 | 处理方式 |
|---|---|---|
| 状态越过阈值 | 居民存款低于两周开销 | 唤醒，重新评估工作、消费、搬家 |
| 计划被打断 | 通勤的地铁线路临时停运 | 先走规则寻路，寻不到合理替代再唤醒 |
| 意外信息 | 听说工厂要裁员 | 按相关度打分，超过分数线才唤醒 |
| 社交相遇 | 同事约周末聚会 | 只有同一场景、且双方都有空档时才触发 |
| 定时体检 | 每游戏周一次 | 批量反思，不做实时决策 |
这张表里有一条容易被忽略的规则：能用规则解决的，先用规则。地铁停运后，居民先在本地的路网上找一条不太绕的替代路线，找到了，就只是一次路径更新；只有找不到、或者代价超过承受范围时，才提交给模型去考虑“要不要请假、要不要换个交通方式”。这与批量推理并不冲突：事件驱动决定“谁需要想”，批量推理决定“想的时候怎样一起算”，两者是先后两道闸门。
预算与合并：事件太多时先放弃什么
即使有触发条件，一次突发事件也可能同时叫醒成千上万个Agent。大发娱乐的设计里给每个游戏小时设了一个调用预算，并规定超额时的取舍顺序。
- 先合并再调用：相似的居民面对相似的情境，先按“情境指纹”分组。指纹包括收入档位、住房状态、事件类型、所在区域。同组居民由一次调用产出一个决策模板，再加上每个人各自的个性参数做微调。
- 再按重要度排队：影响到基本生存的事件（失业、无房）优先，娱乐偏好类的推迟到下一个预算窗口。
- 最后降级：仍然排不上的，用上一次的决策加惯性延续，并把“延后了多少个事件”记在日志里，而不是悄悄丢掉。
相关研究里，MobileCity（Ye等人，2025年，arXiv）在约4000个模拟智能体的城市里，采用了在预先生成的动作空间内选择、并用本地模型生成记忆的做法来压低算力成本。这与上面的“合并”和“降级”是同一个方向：把开放式生成收窄成有限选项，把昂贵的调用留给真正开放的问题。
三种典型的失败，以及怎么发现它们
事件风暴
某条主干道突然堵死，沿线八百个居民在同一个游戏分钟内被同时唤醒，请求排成长队，延迟骤升，画面上的城市停顿了几秒。这类问题在压力测试里很容易复现：把一次大范围事件当作输入，观察唤醒峰值和排队时长。对策是唤醒时加入随机抖动，把同一批居民分散到几个游戏分钟内，符合“人对消息的反应本来就有先后”的常识。
企业Agent也遵守同一套逻辑。大发娱乐经营AI里的一家店铺Agent，不必每个游戏小时都重新定价，只有在库存跌破安全线、邻近对手改价、或者连续几天客流偏离预期时才被唤醒；其余时间沿用当前策略。
沉睡过深
一个居民的存款以极慢的速度下降，从来没有越过阈值，直到某天突然破产。事件驱动有一个天然盲区：缓慢变化的变量不产生事件。对策有两个，一是给慢变量设“趋势阈值”，不只看数值，也看斜率；二是保留定时体检，让每个Agent至少每游戏周被检查一次。
同步羊群
如果所有居民对同一条消息使用同一个模板、在同一刻作出同样的反应，城市会表现出整齐得不真实的行为：同一分钟全体涌向某家商店。合并决策模板是为了省钱，但若不加个体差异，就把省钱变成了失真。所以模板必须与个人参数（预算、偏好、习惯路线）结合，而不是直接复制。
怎样知道唤醒设计是不是合理
唤醒机制本身也需要被验证，而不是设定后就相信它。可以检查的指标有几个：
- 每个NPC每个游戏日的平均唤醒次数：远低于每分钟一次，但也不能长期为零。
- 决策来自缓存或模板的比例：比例过高，说明个体差异被抹平；过低，说明预算白白消耗。
- 唤醒延迟的高分位值：关注最慢的那批，而不是平均数。
- 漏报率：抽一小批居民，用“每步都唤醒”的慢速模式作为对照，对比事件驱动版本是否漏掉了本该发生的重大决策。
最后一项最重要，也最容易被省略。做法是在小规模城市里同时跑两套：一套逐步全量唤醒，一套事件驱动，然后比较两者在居民迁出率、失业率、通勤时长这类宏观结果上的差距。差距在可接受范围内，事件驱动才算没有丢掉东西。这类对照如何做成长期的检查流程，可以参考模拟的验证与校准。在大发娱乐的设计里，这套对照要在每次修改唤醒阈值之后重跑，而不是上线前做一次就算数。
大发娱乐的取舍很明确：让NPC显得聪明，靠的是在对的时刻想得深，而不是时时刻刻都在想。一个大部分时间安静、被事情叫醒时才认真作答的居民，比一个每秒都在自言自语的居民，更接近我们熟悉的人，也便宜得多。
