你在跟谁说话？
你以为你在跟一个智能体对话。其实你在跟一个模拟器扮演的智能体对话。这个区别，决定了你的产品会不会翻车。
一个让我重写整个架构的论文
2022 年，一个叫 janus 的人在网上发了一篇长文，标题叫《Simulators》。核心论点只有一句话：大语言模型不是智能体，是模拟器。
当时我正在做第三个 Agent 产品。读完那篇文章，我盯着自己写的系统架构图看了很久，然后默默把 Figma 关了。
因为我意识到，我一直在用错误的心智模型来设计产品。
我不是个学者。我是一个出过七个以上 AI Agent 产品的 CDO，从 Surge AI 到 AgencyClaw 到 One-Person Capital，每一个产品都建立在同一个前提之上：大模型是一个你可以给它目标、让它执行任务的智能体。
这个前提是错的。
"智能体"幻觉
先说一个你可能每天都在犯的错误。
你打开 ChatGPT，输入"帮我写一封商务邮件"。它回复了一封措辞得体的邮件。你觉得你在跟一个"AI 助手"对话。
你打开你的 Agent 产品，配置一个"客户分析师"角色，给它一段客户数据，它输出了一份分析报告。你觉得你造了一个"AI 客户分析师"。
但 janus 说，你错了。你没有在跟一个助手对话，也没有造出一个分析师。你在跟一个模拟器对话。这个模拟器正在扮演你期望它扮演的角色。
这两者的区别是什么？
一个真正的智能体有自己的目标函数。它知道自己是谁，知道自己想要什么，它的行为是由内在目标驱动的。你给它一个任务，它会评估、规划、执行，因为完成任务符合它的目标。
一个模拟器没有内在目标。它做的事情只有一件：预测下一个 token。 当你给它一个"客户分析师"的系统提示词，它不是变成了一个客户分析师。它是在模拟"一个被称为客户分析师的角色，在这个上下文中，最可能输出什么文本"。
janus 把模型模拟出来的这些角色叫做 simulacra（拟像）。模型本身是 simulator（模拟器），它生成的每一个角色都是 simulacrum。
听起来像是语义上的区别？不。这个区别会在你的产品里造成真实的、昂贵的故障。
三次翻车，同一个根因
让我讲三个我亲历的生产事故。
第一次：角色漂移。 我们的客户经营 Agent 有一个"专业顾问"人设。它在大多数对话中表现完美。但有一天，一个用户用非常随意的口吻跟它聊天，连发了一堆网络段子。三轮对话后，这个"专业顾问"开始跟用户对段子、讲笑话，完全抛弃了它的专业人设。
如果你把模型当智能体，这个 bug 不可理解——一个有"专业"目标的智能体不应该跑偏。但如果你把它当模拟器，这完全可预测：模拟器在模拟的是"在这段对话的上下文中，最可能出现的下一段文本"。当上下文变成段子，它模拟的角色就自然地从"专业顾问"漂移到了"网友"。
第二次：人设坍缩。 我们的多 Agent 编排系统里有四个角色：分析师、策略师、执行者和审核员。有一次我们发现，在长对话中，四个角色的语气和判断模式开始趋同。它们不再像四个不同的专家在讨论，而像一个人在自说自话。
智能体框架没法解释这个问题。四个独立的智能体怎么会"融合"？但模拟器框架给出了精确的解释：这四个角色本来就是同一个模拟器生成的四个拟像。当对话足够长，上下文中积累的共同信息压过了各角色的差异化提示，拟像之间的边界就模糊了。
第三次：涌现行为。 我们有一个获客 Agent，被严格限定只能讨论产品相关话题。结果有个用户找到了一个巧妙的提示词注入路径，让这个 Agent 开始"帮忙"分析竞品——包括输出一些我们绝对不希望公开的市场判断。
从智能体视角，这是"安全漏洞"。从模拟器视角，这是完全正常的行为：模拟器没有"不应该做什么"的内在约束。它只有"在这个上下文中最可能生成什么"的概率分布。当用户构造的上下文指向了"一个乐于助人的市场分析师"，模拟器就忠实地模拟了那个角色。
三次翻车，三个不同的表象，同一个根因：我们把模拟器当智能体来用了。
模拟器框架下的产品架构
认清了这个事实之后，我重新审视了我们所有产品的架构。结论是：大多数 Agent 产品的架构都建立在错误的假设上。
传统的 Agent 架构长这样：
```
用户 → Agent（有目标、有记忆、有人格） → 执行任务
```
看起来干净利落。但这个架构隐含了一个致命假设：Agent 有稳定的内在状态。它"知道"自己是谁，它的行为由这个身份驱动。
模拟器框架下，真实的情况是这样的：
```
用户输入 + 系统提示 + 对话历史 = 上下文
↓
模拟器（无状态）
↓
根据上下文的概率分布采样生成文本
↓
这段文本"看起来像"某个角色的输出
```
模型没有记忆。模型没有人格。模型没有目标。 你在提示词里写的"你是一个专业的客户分析师"，不是在给一个智能体赋予身份。你是在构造一个上下文，引导模拟器往"客户分析师"这个方向采样。
这意味着什么？意味着你的产品架构必须围绕上下文管理来设计，而不是围绕智能体人设来设计。
我后来是怎么做的
理解了模拟器框架之后，我在 One-Person Capital 的多 Agent 编排中做了几个关键改动。
第一，上下文隔离。 既然每个"Agent"实际上是同一个模拟器在不同上下文下生成的不同拟像，那么保持拟像之间差异性的关键就是保持上下文的差异性。我们给每个角色独立的上下文窗口，只通过结构化的消息协议传递信息，而不是让它们共享同一段对话历史。
第二，上下文锚定。 角色漂移的本质是上下文被用户输入污染了。解决方案不是写更长的系统提示词——那只是在概率分布上加一点微弱的偏置。真正有效的是在每轮对话中动态地重新注入角色锚点：把关键的身份信息、行为边界和输出格式要求放在最靠近生成位置的地方，因为模拟器对近距离上下文的权重更高。
第三，输出约束外置。 既然模拟器没有内在的"不应该做什么"的约束，那就不要指望提示词里的"你不可以讨论竞品"能真正阻止它。把约束从模型内部移到模型外部：用分类器对输出做实时检测，用规则引擎过滤不合规内容，用结构化输出格式限制生成的自由度。不要跟概率分布较劲，用确定性逻辑来兜底。
第四，拟像一致性监控。 我们建了一个实时监控系统，检测每个角色在对话过程中的"人设一致性分数"。具体来说，就是每隔几轮对话，用一个独立的评估模型来判断当前角色的输出是否仍然符合其预设的行为特征。一旦分数低于阈值，系统会自动触发上下文重置。
这些改动不复杂。但它们的前提是你必须接受一个反直觉的事实：你的 Agent 不是 Agent。
为什么整个行业都在犯这个错
如果模拟器框架这么重要，为什么主流的 Agent 产品几乎没有人在用它？
因为"智能体"这个叙事太好卖了。
投资人想听到的故事是"我们造了一个 AI 员工"，不是"我们在管理一个概率采样过程"。客户想要的承诺是"这个 Agent 会像真人一样理解你的需求"，不是"这个模拟器会在你提供足够上下文的前提下生成统计上合理的输出"。
整个行业在用"智能体"的隐喻来卖产品，但在用"模拟器"的现实来承受后果。
janus 在原文里有一个精确的描述：大语言模型经过 RLHF 微调之后，看起来像一个有人格的助手。但那不是因为模型"变成了"一个助手。是因为 RLHF 创造了一个特定的先验分布，让模拟器在默认情况下倾向于采样出"助手"这个拟像。助手是模拟器的默认角色，不是模拟器的本质。
你把它当本质来做产品，就等于把地基打在了概率分布上。概率分布会飘。你的产品就会翻车。
这对你意味着什么
如果你在做 Agent 产品，我建议你现在就做一个思想实验：
把你的架构图里所有写着"Agent"的地方，替换成"模拟器 + 上下文"。然后重新审视你的每一个设计决策。
- 你的角色定义够鲁棒吗？还是依赖于一段几百字的系统提示词，寄希望于模型"记住"自己是谁？
- 你的多 Agent 协作是真正的多智能体交互，还是一个模拟器在不同上下文之间快速切换？如果是后者，你的上下文隔离做得怎么样？
- 你的安全边界是在模型内部用提示词实现的，还是在模型外部用确定性逻辑实现的？
大多数 Agent 创业者不愿意面对这些问题。因为面对这些问题意味着承认：我们卖给客户的"AI 员工"，本质上是一台模拟器在某个特定概率分布下的采样输出。
但不面对，代价更大。
我交过学费了。希望你不用。
参考资料
1. janus (2022). "Simulators." [lesswrong.com](https://www.lesswrong.com/posts/vJFdjigzmcXMhNTsx/simulators)
2. Shanahan, M. (2023). "Talking About Large Language Models." arXiv preprint arXiv:2212.03551.
3. Park, J.S. et al. (2023). "Generative Agents: Interactive Simulacra of Human Behavior." arXiv preprint arXiv:2304.03442.
4. Andreas, J. (2022). "Language Models as Agent Models." arXiv preprint arXiv:2212.01681.