大多数将生成式 AI 技术栈视为模型集成项目的团队，最终都会发现他们实际上构建了——或需要构建——一个平台。模型是最简单的部分。难点在于它周围的一切：将查询路由到正确的模型、可靠地检索上下文、过滤不安全的输出、缓存冗余调用、在由五个 LLM 调用组成的链条中追踪出错原因，以及随着使用规模扩大，防止成本逐月翻倍。
本文讨论的就是这个平台层。不是模型权重，也不是提示词——而是将一个可行的原型与一个你可以放心交付给百万用户的系统区分开来的基础设施。
你的监控栈能告诉你关于请求率、CPU 和数据库延迟的一切。但它几乎无法告诉你你的 LLM 是否刚刚幻觉出了一个退款政策，为什么一个面向客户的智能体在回答一个简单问题时循环调用了三次工具，或者你的产品中哪个功能正每天悄悄烧掉 800 美元的 Token。
传统的可观测性是围绕确定性系统构建的。LLM 在结构上完全不同 —— 每次都是相同的输入，不同的输出。故障模式不再是 500 错误或超时；而是一个听起来自信且合理、但恰好错误的答案。成本也不再稳定可预测；当一个配置错误的 Prompt 遇到流量高峰时，成本会激增。调试也不再是“在堆栈跟踪中查找异常”；而是“重建为什么智能体在周二凌晨 2 点选择了这条工具路径”。
这正是 LLM 可观测性（Observability）所要解决的问题 —— 而这一领域在过去 18 个月里已经显著成熟。
大多数智能体故障不会自行报告。没有崩溃，没有警报，没有堆栈跟踪。你的智能体只是默默地返回错误答案，跳过工具调用，或在任务中途停滞——而你直到三小时后用户投诉时才发现。从“在开发环境中正常运行”到“在生产环境中可靠”的差距，并非仅仅增加重试次数就能弥补。它关乎构建一个能够检测自身故障、对故障进行分类并在不半夜两点把你吵醒的情况下恢复的系统。
以下是自修复智能体管道在实践中的实际面貌。
大多数构建 AI Agent 的团队花费数周时间进行部署前评估，却几乎不测量 Agent 在生产环境中实际的行为。这正好本末倒置了。真正重要的指标——Agent 无监督运行的时长、寻求帮助的频率、承担的风险程度——只有在运行时，跨越数千个真实会话之后才能浮现。不去衡量这些，等于盲目飞行。
一项针对数千次生产部署和软件工程会话的大规模研究，揭示了一些真正令人意想不到的发现。呈现出来的图景，与大多数构建者的预期大相径庭。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
