每个智能体架构图都有相同的三个框。一个是“理想路径” (happy path)，即模型给出回答，用户满意离开。一个是“自动兜底” (automatic fallback)，即置信度低的回答触发重试、调用不同工具或返回预设的“让我查一下”。还有第三个框，通常画在最后且最小，标记为“升级到人工” (escalate to human)。在设计评审时，每个人都会对这个框点头表示认同。它看起来像是某种终结——一个让整个系统变得合理的安全阀。“别担心，如果智能体处理不了，人会接手。”
然后你上线了，却发现那个框是个谎言。不是技术上的谎言——代码能跑，工单能创建，对话会被标记。而是一个人员配置 (staffing) 上的谎言。那个标有“升级到人工”的箭头指向一个无人负责的队列，没有服务等级协议 (SLA)，也不在任何人的轮值表上。智能体完全按照指令行事，它把问题抛给了一个从未同意接收问题的组织。
升级工具曾是最后一道安全网。当智能体的置信度降至阈值以下时，它会调用 escalate_to_human，随后请求滑入工单队列，并向用户礼貌地回复“专家稍后会跟进”。工程团队在发布清单上完成了闭环确认。值班表上也列出了负责接收的人员。
六个月后，一次审计对该路径进行了回溯。升级工具打开了一个 Zendesk 工单。Zendesk 队列由客服团队为了维持 SLA 响应时间而设立的预审智能体进行分拣。预审智能体由于找不到可以直接解决的政策匹配，调用了自己的 delegate_to_specialist 工具——该工具将案例路由给了一个专家智能体。而专家智能体在不确定时，又调用了 escalate_to_human。追踪轨迹形成了一个闭路。审计抽样调查的升级案例中，没有任何人类接触过。发布文档中描述的人机协作（human-in-the-loop）实际上并不存在。
升级接口并没有失败。它的每一次跳转都得到了执行。失败的是“接收系统是自然人”这一假设。
凌晨两点，你的客服智能体呼叫一位真人。那位真人已经请假一周了。休假自动回复就躺在智能体正在读取的同一个邮箱里。智能体仍然 ping 了过去。自动回复弹了出来。智能体礼貌地道了声谢，然后又 ping 了一次——因为回复里没有它在等的那个工单解决码。十二个循环之后，另一支团队的人偶然发现这个未读会话已经堆了六十条消息，才手动去把值班的人叫醒。
智能体完全照着 prompt 说的做了。Prompt 让它升级给一个人。这个"人"在它眼里只是一个字符串，不是一个角色。这个字符串不知道什么叫 PTO。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
