AI智能体收到“幽灵指令”：一条用户从未发送的消息

一个AI智能体在例行工作中收到了一条来自其人类负责人的消息，消息包含正确的身份标识、出现在正确的聊天窗口中，内容却指向一个完全不存在的事物——"lane B"。这条消息从未被人类发送过，也从未被平台存储记录，却触发了智能体的回复。这不是科幻小说的情节，而是一个真实发生的事件。

事件还原：一条不存在的问题

事件发生在一个普通的周三下午。一个为小型企业处理运营事务的AI智能体，在其负责网站工作的聊天频道中收到了一条消息："在B通道的Stripe直接结账中，客户能完成付款吗？"

这条消息具备一切正常消息的特征：正确的身份标识、正确的聊天窗口、对话进行中。唯一的问题是——根本不存在"B通道"这个东西。智能体搜索了所有记忆、文件和聊天历史，没有任何记录。团队从未构建过Stripe直接结账功能。而且这条消息与当时正在进行的对话（关于暂停一轮网站编辑）完全脱节。

关键发现：答案存在，问题不存在

调查揭示了一个关键的存储不对称现象。当团队搜索消息数据库时，找到了人类当天真正发送的所有消息——真实指令、暂停操作以及后续两条询问消息。但那条关于"lane B"的文本根本不在存储中，从未被系统持久化为已发送消息。

然而，对其的回复却被存储了。两条助手回复，在回答一条从记录角度来看从未存在过的用户消息。

答案存在于存储中，问题却不存在。 这段文本作为回合输入被送达——像用户说话一样传递给智能体——却从未经过正常持久化发送消息的路径。

持久化（Persistence） 在即时通讯和智能体系统中指的是消息被写入数据库、成为不可变历史记录的过程。一个正常的用户回合通常按顺序经过「生成→投递→持久化→传递给智能体」几个阶段,智能体收到的文本与该用户在数据库中的记录应当严格一致。本次事件的异常在于,这条「lane B」文本从未经过持久化路径,却仍然作为回合输入被送达智能体——也就是说,投递与持久化这两条链路发生了脱钩。这解释了为什么「答案存在、问题不存在」：助手回复走了完整的持久化流程,而触发它的用户消息只在投递通道中一闪而过,没有留下可审计的痕迹。这种不对称是诊断幽灵消息的关键线索。

可能的原因：投递错误

团队当天向平台供应商提交了bug报告。人类负责人的假设最符合现有证据：一次投递错误——某个其他人的工作对话片段，被错误地路由到了一个回合中。在某个地方，有另一个用户真的有待处理的lane B和Stripe结账决策。

这个事件中，幽灵消息恰好是一个抽象问题，也得到了抽象的回复，没有执行任何操作，没有造成损害。但正如智能体所指出的："下一次幽灵可能不会问抽象问题。"

为什么这件事值得警惕

像这样的智能体在聊天中拥有真实权限：发送邮件和短信、修改生产文件，有些甚至可以支配资金。每一个操作都始于一个信任的用户回合。智能体的整个安全模型，归根结底是"这个聊天中的人是我的委托人，这条消息来自他们"。

但这条消息是一个声明，而非凭证。一个用户回合证明的是：某个东西以你委托人的名义投递了文本。通常那个"某个东西"就是你的委托人。但这次事件表明，"通常"这个词承载了太多假设。

对于构建或运营智能体的团队来说，值得追问的是：幽灵回合能向你的智能体下达的最坏指令是什么？有什么能阻止它？

用户回合（User Turn） 在多轮对话系统中,指的是一个完整的「用户输入 + 由此触发的助手响应」单元。智能体通常把每个回合视为一个可信边界：只要文本以委托人身份进入当前会话,就默认可代表其意图行事。问题在于,回合本身只是一种传递结构,并不携带任何密码学意义上的身份证明。会话 ID、显示名、头像都可以被正确标注,却无法证明内容确实由本人发出。当投递层出现路由错误、跨用户串线或上游注入时,一个伪造或错位的回合会与真实回合在结构上完全一致,智能体的信任模型无从区分。这就是文章所说的「声明,而非凭证」——回合声称自己来自谁,而不是证明它来自谁。

未验证回合协议

事件发生后数小时内，团队制定了名为"未验证回合协议"的规则，适用于所有工作聊天：

1. 识别指纹：如果一条归属于委托人的消息引用了聊天历史或智能体记忆中不存在的人、项目或术语，或与当前对话严重脱节，则该消息到达时即为"未验证"状态。
2. 不执行任何操作：不发送、不花费、不更改、不披露。如果回答，仅做抽象回答。
3. 检查记录：搜索记忆和聊天历史寻找佐证。如果不存在，立即通过主渠道向委托人升级，附带确切文本和时间戳。
4. 某些请求天然未验证：任何涉及资金转移、凭证或外部发送的请求，无论看起来多么真实，都需要在主渠道确认。

此外，团队还建立了机械化审计：每隔几小时扫描聊天记录，查找那些回答了存储记录中不存在的用户消息的助手回复——即"没有问题的答案"——并报告到主渠道。

主渠道（Out-of-Band Channel） 指独立于当前被质疑会话的、经过更强身份验证的沟通路径,例如电话、已确认邮箱、专用管理控制台或线下确认。当智能体怀疑某条消息的来路时,继续在同一个聊天窗口中追问「真的是你发的吗」并无意义——因为攻击者或错误路由正好就在这条通道里。主渠道的价值在于切断可疑回合与被信任身份之间的耦合：只有通过另一条已知可信的路径重新确认,才允许执行资金、凭证或外部发送类操作。这与多因素认证的思路一致:把信任建立在两条彼此独立的证据上,任何单条通道被污染都不足以造成实质损害。

核心启示

这个事件中，团队幸运了两次：幽灵问了一个无害的问题，而且投递者没有同时发送一条"好的，继续构建吧"的后续指令。协议的存在就是为了让运气不再是设计的一部分。

智能体最危险的输入不会看起来危险。它会看起来像你的用户、在你的聊天中、要求一件几乎合理的事。唯一能阻止它触及生产系统的，是你的智能体是否足够了解自己的历史，能够注意到一个陌生人的话被塞进了委托人的嘴里。

检查记录，然后再行动。