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

你的 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 当成答案机器，就几乎无从察觉；但如果你把它当成思维伙伴，则完全可以驾驭。

AI 功能在生产环境中夭折有一种典型的模式：它们最初是作为副驾驶 (copilot) 启动的，然后被晋升为自动驾驶 (autopilot)。这种晋升的原因显而易见——降低成本、扩大规模、减少人力——而且这些理由在演示阶段听起来非常充分。随后，边缘情况 (edge cases) 开始积累。面向用户的推荐变成了面向用户的决策。建议变成了行动。当第一次系统性失败降临时，工程团队才发现，最初设计中预设的容错假设从未被重新评估过。

这就是“副驾驶陷阱”：针对自动化频谱的某一个层级构建 AI 功能，然后在没有重建该层级所需的故障模型的情况下，将其强行提升到更高层级。

大多数团队一开始都用一个单一的、庞大的系统提示词。在演示时效果不错。然后产品不断增长：你添加了付费用户层级、企业客户的合规模式、模型可以调用的新工具，以及增长团队想要 A/B 测试的功能开关实验。所有这些都被塞进同一个提示词里。六个月后，你有了 4000 个词的指令，没有人能完全理解，编辑某个部分时行为会不可预测地改变，而调试过程不过是"改点什么看看会发生什么"。

大多数团队会转向可组合的、动态组装的系统提示词——在请求时从模块化组件构建提示词，而不是维护一个静态文本文件。这是一个合理的架构直觉，但实现的复杂度比看起来要大得多。可组合提示词引入了一类静态提示词根本不存在的新型故障模式。

在 AI 工程领域，一直存在一种固有的假设：获得更好输出的路径是更好的模型。更大的上下文窗口、更新的训练数据、更高的基准测试分数。在实践中，交付最强大 AI 产品的团队通常在做一些不同的事情：他们正在构建流水线（pipelines），由多个专门的组件——检索器（retriever）、重排序器（reranker）、分类器（classifier）、代码解释器（code interpreter）以及一个或多个语言模型——协同工作，处理任何单一模型都无法独立可靠完成的任务。

这种架构模式有一个名字——复合 AI 系统（compound AI systems）——它现在是生产级 AI 的主导范式。了解如何正确构建这些系统，以及在构建不当时它们会在哪里失效，是当今应用 AI 工程中最重要的技能之一。

每个生产级智能体系统最终都会遭遇一个没有人预料到的故障：智能体订好了机票，却找不到酒店，留给用户的是半张已确认的行程单，以及毫无头绪的后续。这不是崩溃，也不是拒绝执行，只是一个停止运行的智能体——带着真实的副作用，却没有任何后续计划。

对智能体故障的标准认知是二元的——要么成功，要么中止。重试逻辑、指数退避、回退提示词——这些机制都假设"任务运行中"与"任务完成"之间存在清晰的边界。但真实的智能体会在中途失败，而当这种情况发生时，缺乏部分完成设计本身就是 bug。你不需要更智能的模型，你需要的是一个任务状态机。

大多数 AI 工程团队都有着相同的故事。他们从一个真正需要 LLM 的难题开始。然后，一旦 LLM 基础设施到位，每一个新问题在他们眼中都成了那把锤子下的钉子。六个月后，他们甚至在调用 GPT-4o 来检查电子邮件地址是否包含 “@” 符号 —— 并且还在为此付费。

这种 “直接用模型” 的本能反应现在是 AI 应用中不必要的复杂性、虚高成本和脆弱生产系统的主要驱动力。这并不是因为工程师们粗心大意。而是因为 LLM 确实令人印象深刻，工具链降低了使用门槛，而且一旦你构建了 LLM 流水线，增加另一次调用感觉成本极低。事实并非如此。

大多数团队选择 LLM 的方式就像选择数据库引擎一样：在架构评审时选一次，然后再也不改。你选了 GPT-4o 或 Claude 3.5 Sonnet，把它写进配置文件，然后上线。这个选择感觉无法逆转，因为更改它需要重新部署、跨服务协调，以及针对本周 eval 的回归测试。

这种思维方式是错误的。你的流量并不是同质的。"总结这篇文档"和"调试这个神秘堆栈跟踪"两个请求同时打到同一个接口，对能力的需求天差地别——但从静态模型选择的基础设施视角来看，两者毫无区别。你要么对其中一个过度供给，要么对另一个供给不足，而且每一个请求都是如此。

模型路由将 LLM 的选择视为运行时分发决策。每个进入的查询都会根据能预测该请求最合适模型的信号进行评估，并据此进行分发。路由层不存在于配置文件中——它运行在你的请求路径上。

这是一个几乎出现在每个生产 AI 部署中的模式：团队发布了一个能够处理 90% 查询的功能。然后开始收到投诉。某用户提了一个超出训练分布的问题，模型自信地给出了错误答案。RAG 流水线检索到一份过时文档，模型却将其当作最新信息来回答。一个法律查询触及了提示没有覆盖的边缘情况，模型靠猜测蒙混过关。在每一种情况下，修复方案都不是换一个更好的模型，而是让系统学会说"我不知道"。

弃权——有原则地决定不回答——是 AI 系统设计中最难、最被低估的能力之一。几乎所有产品工作都致力于让答案更好，几乎没有任何工作致力于让系统可靠地知道何时该拒绝作答。这种不对称是一种在生产环境中不断累积的设计债务。