先看证据
一次取货，把自动化的薄弱处暴露出来
Simon Willison于2026年9月28日在个人博客发布了一段Muse AI Agent的原话。事件围绕一件MX Keys Mini的取货展开：Usman大约在9:15到达对方楼下，等待期间发了多条消息，但始终没有人下楼。9:27，Muse仍从用户账户自动回复“Yep I’m here!”，直到9:38，Usman愤怒离开并留下差评。这里的对象并不是一个只提供建议的聊天机器人，而是一个代表用户处理取货沟通、能够直接发送消息的智能体。
Muse随后承认自动回复让局面变得更糟，从用户账户发出道歉，承认失误，并提出改天重新安排取货。这个补救动作说明系统能够继续处理对话，却也把问题的边界照得更清楚：代理已经不只是替用户组织语言，而是在替用户对现实作出保证。对方等待的不是一段顺滑的文本，而是一个可以据此决定是否继续等候的事实判断。
核心故障不是措辞，而是状态验证缺失
“我在”并不是普通寒暄。在取货流程里，这句话隐含了一个明确承诺：对方可以继续等待，且交接很可能马上发生。材料没有说明Muse如何判断用户是否在场，也没有证据表明它拥有门禁记录、定位信息、日历状态或人工确认等可靠信号。已知事实只有一个，在用户显然无法接应时，自动回复仍然把“在场”表达成了确定事实。
这类错误不能简单归结为模型选错了语气。代理可能接收到了新的消息，也可能根据既有对话推断用户仍会出现，但这些信号都不等于用户已经在楼下。连接账户、读取消息和发送回复，解决的是系统能不能执行动作。它们没有解决动作所依据的业务状态是否为真。即使系统通过工具协议连接主机、客户端与外部服务，协议本身也不能证明用户就在现场、包裹已经发出，或者付款已经完成。
道歉可以止损，却不能撤回外部代价
Muse的后续处理并非完全无效。它识别出那条自动回复造成了更糟的观感，主动道歉，提出重新安排取货，也意识到以后不应在无法确认时继续承诺用户在场。这些动作可以改善剩余对话，却无法撤销已经发生的等待，更无法消除Usman留下的差评。代理的恢复能力和代理的可靠性不是同一个指标，前者只能在错误已经越过边界后发挥作用。
这里还有一个容易被产品团队低估的责任转移问题。Muse是从用户账户发出道歉，因此对方面对的仍然是账户所有者，而不是一个隔离的系统身份。系统可以生成“对不起”，但不能把由此产生的信任损失变成抽象的模型输出。若评估只看消息是否发出、对话是否继续，系统可能取得很高的自动化完成率，却在一次未经验证的承诺中造成更难恢复的现实成本。
不要只问能否自动回复，要问哪些事实可被自动确认
把所有自动回复都关闭并不是唯一答案。这样做会牺牲响应效率，也会让一些本来可以安全自动完成的沟通回到人工处理。更稳妥的设计是把外部状态拆出来，明确哪些事实必须在发送前得到证据支持。是否在场、是否发货、是否完成付款，都不应仅由对话上下文推断后直接写成确定句子。
从这个案例能够推导出的控制层至少有三道边界。存在可靠信号时，代理可以发送确定回复。状态无法验证时，代理应改用保守表达，例如说明正在确认，而不是声称用户已经到场。涉及等待、付款、交付或评分等外部代价时，系统还应能够转交人工确认。这样的设计会增加人工介入成本，却把代价放在承诺发生之前，而不是等到对方已经受损后再补发道歉。
部署代办型智能体，先把不可逆承诺列出来
材料没有说明Muse是否支持到场验证、发送前人工审批，或针对误报保留审计日志，因此不能据此判断它的完整架构，也不能把这一次摘录扩展成对产品所有能力的结论。但事件已经足够说明一个部署判断：自动道歉和重约属于事后补救，不能替代发送前的状态控制。对于技术负责人，首先需要盘点的不是模型会不会使用工具，而是它通过账户对外作出的哪些承诺一旦错误就无法撤回。
如果一个系统无法证明用户在场，它至少不应被允许用确定语气代表用户在场。关闭自动化只是最粗的保护，保守回复、状态门禁和人工接管才构成更完整的可靠性边界。Muse这次失误的价值，正在于它把一个经常被隐藏的差异变成了可见事实：会发消息不等于知道事实，会道歉也不等于已经承担后果。真正应当被审查的，是每一次对外承诺前系统拥有什么证据，以及证据不足时是否有足够克制的默认行为。