49 篇博文 含有标签「system-design」

设计文档写着“人机回环”。发布演示稿写着“默认安全”。六个月后的事故回顾则写道，由于审批人在吃午饭，智能体（Agent）花了 90 分钟才给客户发送发票。这些文档都没有撒谎。它们只是在描述同一个组件在负载曲线不同位置的表现——而其中只有一份准确抓住了全貌。

当你在智能体与不可逆操作之间加入人工干预时，你并没有增加一个安全原语（safety primitive）。你实际上是增加了一个服务，它带有队列、吞吐量限制、质量负载曲线以及可用性概况。如果一个团队在发布智能体时没有命名那个服务，那么他们交付的产品的关键路径将取决于一段他们拒绝去运维的基础设施。

这一切始于一个 cron 作业。每晚凌晨 2 点，一个脚本会被唤醒，拉取当天的记录，通过模型运行，将结果写入表中，然后继续休眠。这是解决该问题的最简单形态，而且在整整一年的时间里，它确实是最合适的形态。没有人去考虑它，因为没有人需要去考虑。

接着有人问结果能否在早上 8 点而不是中午准备好。然后有人问用户是否可以按需触发单条记录的运行。接着一位产品经理问是否可以让应用内的体验“感觉像是即时的”。每个请求都是合理的。每一次改动都很小。而且从始至终，没有人打开过一份名为“重新架构推理流水线”的文档，因为没有任何一次单一的改动让人觉得像是在重写。

18 个月后，你拥有了一个披着批处理作业外壳的延迟敏感型在线服务。它的 p99 无人衡量，队列无人清理，且存在一种失效模式：由于流水线被构建为重试整个批次，一条错误记录就会导致面向用户的请求停滞。这是 AI 系统中最常见的架构失效之一，而且它几乎从未作为一项决策出现，而是作为对一系列合理请求不断说“是”而产生的缓慢累积。

当一个智能体（agent）给出的回答比上周差时，第一直觉往往是归咎于提示词（prompt）。有人会重新编写系统指令，删减几句话，增加一个示例，然后发布。有时这会有所帮助。但通常这毫无作用，因为提示词从来就不是问题所在。问题在于，一个冗长的工具调用结果静默地消耗了 18,000 个 token，将实际的任务指令推到了上下文窗口中关注度较低的中部位置，让模型在一个 70% 都是噪音的记录上进行推理。

这不仅是措辞问题，更是资源分配问题。资源分配在系统工程中有一个专属名称：调度（scheduling）。上下文窗口是一种固定大小的资源，多个消费者在其中竞争，而目前大多数智能体技术栈“调度”它的方式就像 1960 年代的批处理系统调度内存一样——先到先得，直到用完为止。

观察一个 Agent 思考多步任务的过程，你会注意到一些熟悉的东西：它的规划方式就像你调试代码一样。尝试一种方法，观察结果，如果错了，就撤回并尝试另一种。Agent 将其计划描述为一棵选项树，它可以探索、剪枝和重新访问。这种心智模型在代码沙箱中是正确的，因为在那里的每个操作都有隐式的撤销功能。但在 Agent 接触到现实世界的那一刻，这种模型就错得离谱且危险。

发出的邮件无法撤回。扣款的银行卡在没有退款流程、手续费以及已经看到通知的客户的情况下，是无法撤销扣款的。除非有人设置了软删除，否则被删除的数据行就彻底消失了。一条发布的 Slack 消息可能已经被阅读了。Agent 的规划模型没有原生的“单向门”概念——即一旦采取行动，就再也无法假装它从未发生过。

这不是一个模型智能问题。即使是更聪明的模型仍然不知道你的哪些工具是可逆的，因为可逆性不是操作本身的属性。它是操作所落地系统的属性。你必须明确告诉它。

每个智能体 (Agent) 架构图中都有一个标记为“上报给人类 (escalate to human)”的方框。它用一条整洁的箭头画出，既能让评审人员满意，又能让系统显得安全。然而，架构图从未展示过箭头另一端的人——他们是否存在、是否醒着，以及是否能在智能体耗尽耐心之前给出答复。

人机回环 (Human-in-the-loop) 被当作一种设计模式来推销。但在生产环境中，它的表现更像是一个人员配置问题。这种模式假设有人在随时待命；而人员配置的现实是，上报请求并不会在人类刚好有空时出现——它们有自己的“时间表”。比如凌晨 2 点，当夜间批处理任务触发护栏 (guardrail) 时出现的爆发式请求。或者是午餐时间，当一半评审员都不在座位上时产生的长尾延迟。又或者是细水长流般的请求量，在不知不觉中超出了那支在演示阶段看起来绰绰有余的双人团队——毕竟在演示阶段，智能体每天只处理 10 个请求，而不是 1 万个。

“我们有上报路径”与“上报得到响应”之间的鸿沟，正是智能体系统发生故障且评估 (eval) 无法捕捉的地方。评估衡量的是智能体是否正确地发起了上报，而从未衡量过是否真的有人在那里。

当一个 AI 驱动的客服智能体无法解决问题并将工单升级给人工时，接下来会发生什么？在大多数系统中：客户被冷转接，没有任何上下文，不得不从头开始重新解释所有情况。人工客服完全不知道 AI 尝试了什么、收集了哪些信息，以及为什么发生了交接。

这是人工接管失败最常见的形式——不是戏剧性的 AI 崩溃，而是自动化与人工处理衔接处悄然发生的 UX 崩塌。究其根本，是工程师精心设计了 AI 处理路径，却将人工接管作为事后补丁——一个出问题时的回退方案。结果是，接管体验像系统报错，而非经过设计的操作模式。

那些做得好的工程团队，从第一天起就将人工接管视为一等功能。以下是其在实践中的具体体现。

你的 AI 功能在上线时运行良好。六个月后，它有时给出简短的一两句话，有时写出五段长文，偶尔还会拒绝回答上个季度毫无障碍地处理过的问题。代码库中没有任何变化——至少你是这么认为的。实际上，系统提示在悄然改变，经过四名工程师跨两个团队提交的十一个拉取请求，逐步演变。每次改动单独来看都合情合理，但合在一起，却将你的提示变成了一台矛盾制造机。

这就是指令冲突问题。它不会抛出异常，不会出现在错误日志中，而是以行为漂移的形式表现出来——模型在细微不同的情境下做出细微不同的事，难以复现，更难溯源。等到用户提交 bug 报告时，提示可能已经被再次打过两个补丁了。

你的 REST API 运行良好。文档齐全，错误码一致，每一个经过测试的人工编写客户端都能正常使用。然后你的团队接入了一个 AI 智能体，不到一小时，它就通过不断重试一个不存在的端点的各种变体生成了 2,000 次失败请求——bulk_search_users、search_all_users、bulk_user_search——每次尝试都触发了真实的下游处理。

这不是提示词工程的失败，而是 API 设计的失败。

REST API 是为能够解析文档、遵守契约、严格调用规范的客户端而构建的。AI 智能体则不同：它们根据名称和描述推断端点可能做什么，在不追踪状态的情况下重试，并将错误信息视为指令而非诊断代码。为智能体调用方设计 API，需要重新审视大多数后端工程师从未质疑过的基本假设。

大多数团队在 AI 系统中加入人工在环 (human-in-the-loop) 审核后，就认为安全问题解决了。六到十二个月后，他们发现了真正的问题：人工审核员现在成了阻碍系统规模化的瓶颈，质量在无人察觉的情况下下降，而移除监督层又显得过于冒险。他们陷入了困境。

这就是 HITL 吞吐量失效。它不同于广为人知的 HITL “橡皮图章”失效（即人类不经真正审查就批准决策）。吞吐量失效更隐蔽且危害更大：审核员在尽职尽责地工作，但队列增长速度超过了团队的处理速度，延迟承诺变得无法兑现，人工层从独立验证变成了整个系统的速度限制器。

当你编写系统提示时，脑海中有一个预设的用户形象。也许是一位用简洁英语提出有针对性问题的专业人士，也许是发送简短、范围明确、完全符合提示假设的请求的人。你针对看似具有代表性的示例进行测试，调整直到输出效果令人满意，然后上线。

然后你看到了生产流量。

你的系统提示必须处理的真实查询群体，并非你所设计的中位情形，而是一个分布——有些查询范围狭窄，更多的漫无边际——还有一条长尾，暴露出你指令中每一个隐藏假设。对大多数生产系统而言，15%到30%的真实查询落入提示处理欠佳的类别。令人不安的是：这些失败大多是静默的。系统返回200状态码，用户得到一个看似合理的答案，失败永远不会浮现在你的日志中。

当麦当劳在三年运营后关停其 AI 得来速系统时，失败的原因并不是模型识别订单能力不足。失败的根源在于架构：没有明确的升级路径交给人工收银员，没有触发重试的置信度阈值，也没有定义系统困惑时该如何处理。AI 只是不停地尝试。顾客不断地抓狂。顺利路径设计得很好，其他一切都没有。

几乎每一个失败的 AI 部署都重复着这个模式。模型在演示中运行良好，在生产中出现故障。而事后分析揭示了同样的根本原因：降级设计从来不是架构的一部分，而是某人打算"之后再加"的东西。

一个三人团队花了整整一个季度，为一个日活跃用户仅 200 人的应用实现了事件溯源架构。这套架构技术上无懈可击，运维上却是一场噩梦。设计方案来自 AI 的推荐，团队之所以接受，是因为推理听起来流畅、权衡分析看似严谨，而最终构建出来的系统也完全符合高级工程师架构图上的样子。

这个故事如今已成为一种警示性范式，而非孤例。AI 在特定的、可识别的场景下能够提供真正有价值的架构输入——而在从外部看起来几乎相同的情况下，它也会给出自信满满却大错特错的建议。这两者之间的差距，如果你把 AI 当成答案机器，就几乎无从察觉；但如果你把它当成思维伙伴，则完全可以驾驭。