凌晨两点，你的客服智能体呼叫一位真人。那位真人已经请假一周了。休假自动回复就躺在智能体正在读取的同一个邮箱里。智能体仍然 ping 了过去。自动回复弹了出来。智能体礼貌地道了声谢，然后又 ping 了一次——因为回复里没有它在等的那个工单解决码。十二个循环之后，另一支团队的人偶然发现这个未读会话已经堆了六十条消息，才手动去把值班的人叫醒。
智能体完全照着 prompt 说的做了。Prompt 让它升级给一个人。这个"人"在它眼里只是一个字符串，不是一个角色。这个字符串不知道什么叫 PTO。
这是一个小 bug，但它揭示了一个大教训。人有边界——睡眠、周末、年假、出差开会、随便哪个周二请半天去看牙。除非有人把这些边界明确接进系统，否则智能体一概不知。而承载这些信息的天然位置——日历、休假自动回复、值班表——几乎总是在你的智能体没有去看的地方。
升级目标应当是一个角色，而不是一个人
第一个设计修正最便宜，可是多数智能体堆栈仍然搞错了：智能体的升级目标应该是一个角色，而不是一个用户名。
这在事件响应领域早已是老生常谈。PagerDuty 整个服务所有权（service ownership）模型的核心，就是把升级策略路由到值班表而不是个人。值班表会动态解析为当前正在值班的人。如果主值班无响应，策略会在超时后升级到二线。线上的智能体根本不需要知道这些人是谁——它只路由到一个角色，由角色在呼叫的那一刻去解析具体的人。
我见过的大多数 LLM 智能体却采用了相反的设计。某个人在 system prompt 里硬编码了一个 Slack handle。半年后那位工程师换了团队。智能体还在 ping 他。这些通知被静音了。真正的升级丢进了大家学会忽略的那个机器人频道。
这条规则虽小，但值得刻进石头里：永远不要让你的智能体直接持有对某个人的引用。让它持有对一个角色的引用，由角色自己去做解析。就像你的服务架构把用户当作 ID 再解析为名字一样，你的智能体架构应该把人当作角色，再解析为具体的人。
日历和休假状态是一等的上下文
更难的问题是，即使升级路由是基于角色的，当这个角色为空、或者持有这个角色的人本身就不在时，依然会失败。某人"理论上"在值班，但他在没有信号的婚礼现场，或者他在一个 Slack DM 不弹通知的会议上，又或者他今天早晨临时请了假但忘记更新值班表。
人的旁路信号——休假自动回复、设置成沙滩 emoji 的 Slack 状态、日历上那个叫 OOO 的事件、头像旁边的离线标识——是你的组织对"现在到底谁能干活"产生的最有上下文的信号。可几乎没有任何智能体堆栈把它当作输入。它被当作会话里的输出，智能体读一读，简单推理一下，然后就被 prompt 里写好的指令盖过去了。
修正办法是把休假和日历状态从会话表面提升到路由决策层。在智能体升级之前，它应该向路由层询问类似这样的问题：
- 解析出来的角色持有者现在可用吗？
- 他的日历里有 OOO 或者一整天的忙碌事件吗？
- 他的自动回复打开了吗？
- 他的 Slack 状态是不是属于那一小撮代表不可达的状态之一？
只要任何一个返回 false，智能体就不应该呼叫那个人。它应该按升级策略走到下一个人——正是 PagerDuty 处理 SEV-1 事件的方式。这不是什么新鲜事。这是已经在值班轮换里跑了十五年的逻辑。唯一新鲜的事是，你的智能体得参与到这套逻辑里，而不是绕过它。
循环为什么会发生
一旦你接受了智能体绝不应该呼叫一个正在休假的人这一前提，下一个问题就是：循环到底是怎么发生的？答案很机械，值得直说。
邮件系统从有 OOO 回复的那天起就知道 OOO 循环。传统的防御手段是限流：约定俗成的做法是对同一个目的地址的休假自动回复至少间隔七天，Gmail 著名的限制是对同一个发件人每四天只回一次。邮件循环是这一类 bug 的祖宗——两个自动回复器互相回信，把对方塞满，直到某位邮件管理员手动掐掉循环为止。
智能体把这一类 bug 复活了，并且经济性更糟糕。传统的 OOO 循环每次循环耗几 KB 磁盘。智能体的 OOO 循环每次循环耗 token。每一轮都是一整套 prompt、一整套工具、一整段推理轨迹和一次模型调用。代价是真实的，而循环要走到智能体内部的回合上限才会停——那个上限通常比你希望的要高。
机制上的根源是：智能体对"这条回复不是来自这个人，而是来自他的信箱"没有一个稳定的概念。它把 OOO 当成了一个部分的答案，试图去处理这个部分答案，结果又触发了一次 OOO。从模型的视角看，这只是一段稍微奇怪的对话，再多几轮就能收敛。
两个防御能起作用。第一，解析邮件头——Auto-Submitted: auto-replied 这个字段存在的本意就是处理这种场景，智能体所用的邮件集成应当在消息到达模型之前就把这些丢掉。第二，给智能体一条硬规则：在规定窗口内未被确认的呼叫，下一步不是"再发一次"，而是"按策略走下一级"。这就是一个从值班纪律里学到东西的智能体，与一个把这套东西重新发明得一团糟的智能体之间的区别。
组织图谱必须以组织自身的节奏更新
藏在这一切下面的更深问题是：智能体对你组织的认知模型几乎可以肯定是过时的。升级策略是一月写的。轮班里两个人离职了。一个在休产假。还有一个换了团队。值班表里仍然写着原来那五个人。因为最近没什么事件，没人去碰它。
这和文档面临的问题一模一样，修正办法也一模一样：智能体的组织图谱必须取自那些"组织变化时自己也会变"的系统，而不是某人半年前手写的 prompt。员工目录、HRIS、日历、值班工具——这些才是当一个人入职、离职、休假或轮换时会被更新的系统。智能体每次需要知道呼叫谁的时候，都应该去读这些系统。
具体来说，落地通常意味着以下几点：
- 值班的事实来源是 PagerDuty、Rootly 或者你用的同类工具，而不是某个 Slack 频道的描述。
- 休假的事实来源是日历，不是某次站会里凭印象记住的内容。
- 组织架构图来自 HRIS，不是 Slack 私信窗口的自动补全列表。
- 智能体的 prompt 里应该按名字引用角色和策略，并在调用时刻去解析，而不是在写 prompt 的那一刻就锁定。
这么搭出来，OOO 循环就在结构上不可能发生。智能体没法 ping 一个休假的人，因为路由层根本不会把那个人作为一个有效目标返回。自动回复永远不会到达，因为那条消息从一开始就没被发出去。这个 bug 的代价就从"十二个循环和一个一头雾水的值班"变成了"轮换里的下一个人被正确呼叫到了"。
这一周要审计什么
如果你运维任何会向人升级的智能体，在团队里下一个人去休假之前，有三件事值得检查：
- 智能体的升级目标是从哪里取的？ 如果答案是"从它的 prompt 里"，那就是一段硬编码的、指向一个具体人的字符串。把它换成一个角色加一个解析器。
- 解析器会查可用性吗？ 日历、休假、值班状态、Slack 在线状态——这其中至少有一个应当出现在链路里。一个都没有，智能体就会乐此不疲地呼叫休假的人。
- 被呼叫的人没有响应时会发生什么？ 如果答案是"智能体等一会儿，然后再 ping"，那么 OOO 循环已经在等着发生。答案应该是"智能体按策略走下一级"。
这些都不是什么新工作。事件响应团队十年前就把它解决了。唯一新鲜的事，是你现在拥有了一个系统：既有"主动升级"的执行力，又对人的边界毫无意识——这两个事实之间的缝隙，正是 bug 安家的地方。
智能体的组织图谱必须以组织自身的节奏更新。任何更慢的节奏，都意味着你的智能体正在一份"已经不存在的公司"的快照上工作。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
