2025 年中，一个构建多智能体（multi-agent）财务助手的团队发现其 API 开支从每周 127 美元飙升至 4.7 万美元。一个智能体循环——智能体 A 向智能体 B 寻求澄清，智能体 B 反过来询问智能体 A，以此类推——已经递归运行了 11 天。没有熔断机制（circuit breaker）拦截它，也没有及时触发预算报警。重试逻辑尽职地在每次超时后不断重试，使每一环节的失控成本不断叠加。
这不是一个关于模型质量的故事。这是一个关于分布式系统工程的故事——特别是关于大多数 LLM 应用开发者跳过的那部分，因为他们假设供应商会处理好这些。
事实上，他们并不会。
大多数基于 LLM 的应用中都潜伏着一个隐形 Bug。它不会出现在单元测试中。在前一千次请求中也不会触发。它会一直潜伏，直到用户输入了带有引号的内容，或者模型出于某种莫名其妙的原因决定将其 JSON 响应包裹在 Markdown 代码块中，再或者将 "count" 字段作为字符串 "three" 而非整数 3 返回。这时，你的生产流水线就会崩溃。
“LLM 是文本生成器”与“我的应用需要结构化数据”之间的鸿沟，是大多数可靠性问题产生的原因。弥补这一鸿沟并非 Prompt 工程问题，而是一个基础设施问题。在 2026 年，我们终于拥有了能够正确解决这一问题的工具。
大多数智能体系统在生产环境中失败，并不是因为底层模型能力不足。它们失败是因为围绕模型构建的工程设计过于草率。模型在第三步偏离了方向，但没人注意到，直到第八步，最终答案虽然言之凿凿却是错误的，而且没有任何护栏来拦截它。这不是模型问题，而是架构问题。
智能体工程在三年内至少经历了两个完整的炒作周期。AutoGPT 和 BabyAGI 在 2023 年春季引发了巨大的狂热，随后在 GPT-4 不可靠的工具调用现实面前折戟。第二波浪潮随 2024 年的多智能体框架和智能体 RAG 而来。现在，到了 2026 年，超过半数的受访工程团队报告已有智能体在生产环境中运行——其中大多数团队也发现，部署一个智能体与维持一个可靠的智能体是完全不同的问题。成功的团队将智能体工程视为一门严谨的学科，而挣扎中的团队仍将其视为一种“感觉”（vibe）。
大多数 AI Agent 演示（demo）运行得都非常完美。
它们在 30 秒内运行完毕，调用三个工具，并返回整洁的结果。然后，有人要求 Agent 执行一些真正重要的事情——交叉引用代码库、运行多阶段数据流水线、处理批量文档——于是整个过程在超时、部分状态和重复副作用的级联反应中土崩瓦解。
问题不在于模型，而在于基础设施。运行几分钟或几小时的 Agent 与在几秒钟内完成的 Agent 相比，面临着完全不同的一类系统问题。大多数团队在最糟糕的时间点撞上了这堵墙：在他们已经发布了用户依赖的产品之后。
大多数智能体故障不会自行报告。没有崩溃，没有警报，没有堆栈跟踪。你的智能体只是默默地返回错误答案，跳过工具调用，或在任务中途停滞——而你直到三小时后用户投诉时才发现。从“在开发环境中正常运行”到“在生产环境中可靠”的差距，并非仅仅增加重试次数就能弥补。它关乎构建一个能够检测自身故障、对故障进行分类并在不半夜两点把你吵醒的情况下恢复的系统。
以下是自修复智能体管道在实践中的实际面貌。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
