一、写这篇的动机
一句话总结:企业 AI Agent 在 2026 年已经普遍走出 PoC,但大多数团队卡在同一条看不见的线上——模型答得对,流程却在生产中"隐性失败"。把 agent 当员工管、把 reliability 当 SLO 设计、把可观测性当成新 APM,正在变成 Agent 落地工程链路的真正分水岭。Datadog 8 月把 Agent Observability 提升成独立产品线、Thoughtworks 8 月 14 日发布《An operating model for enterprise AI agent reliability》、Thoughtworks 8 月 13 日发布《Understanding agents, their five controllers and one graph》三件事同时发生,说明这件事已经从"内部经验分享"升级成"行业共识"。
最近两周我们团队在做 AI Agent 落地咨询时,最常被客户 CTO 问到的问题不是"哪个模型最强",而是"上线以后怎么知道它没出问题"。这个问题听起来很朴素,但背后是过去半年 agent 项目集中爆雷留下的真实伤口。
一个做跨境电商的 SaaS 客户,把 agent 接进客服后,第一天处理了 3000 单对话,看起来成功率 92%,但实际去看用户回访:有 6% 的退订客户在对话里拿到的退款规则错了。这种错不在"答非所问",而在"答得对、答得自信、但答案是错的"。没人在 production trace 里看到,因为传统的客服 KPI 看板只统计"对话是否完成",不统计"答案是否正确"。
另一个客户的研发团队把代码 agent 接进 PR 流水线,Agent 把"PASS"的测试和"故意写崩"的单元测试放在同一个 commit 里被合进主干,代码评审机器人点头,4 天后生产告警才暴雷。这种失败不是模型问题,是观测盲区。
这类故事在过去两年反复出现,但 2026 年下半年开始,业界对它的称呼变了:从"prompt 调优"变成"agent reliability",从"看 log"变成"agent observability"。这两个英文词组,翻译成中文其实是同一件事——把 agent 当成会自己动的手,而不是只会答话的嘴,把手装回仪表盘上。
二、一组让所有人坐不住的数据
把视角拉高一点。Datadog 在 2026 年第二季度的财报电话会上,把 Agent Observability 单独列成"AI 业务线的核心增长引擎",并在 8 月正式把它升级为独立产品(产品页标题为"Agent Observability | LLM Observability | Datadog"),从原来的 LLM Observability 模块里拆出来,赋予专门的 SDK、自动评估流水线、trace explorer 与基于 span 的 cost attribution。在 Datadog 的客户分类里,凡是 2025 年跑通 LLM Observability 的客户,2026 年升级到 Agent Observability 的转化率达到 71%,这是一组极其关键的数字——它告诉我们,过去一年投入 LLM 监控的客户确实在把 agent 作为下一步的重点建设对象。
Thoughtworks 8 月 14 日的运营模型文章里,Arun Srinivasan 与 Zichuan Xiong 抛出的核心数据更扎眼——他们调研 145 家"声称已经把 agent 投入生产"的企业,只有 28 家(约 19%)建立了任何形式的 reliability 工程实践。也就是说,剩下 81% 的所谓"生产环境 agent",既没有 reliability 指标体系,也没有失败归因能力。剩下那 81% 大多是怎么处理问题的?答案是"用户投诉"——靠客服、产品经理、CTO 偶尔刷到 bad case 来反向纠错。
把这两个数据叠在一起,看到的是一张行业级的画像:模型能力在头部继续保持逐月跃升,生产侧的工程纪律却还在 PoC 阶段。这是一种非常危险的"头重脚轻"。
三、看不见的失败:Agent 的四种隐性故障模式
Anthropic 在 2026 年 1 月发布的《Demystifying evals for AI agents》文章里,早就把 Agent 的失败方式归纳为四个层次。我们结合过去半年看到的真实项目再细化一下,可以拆成四种"隐性故障模式"——每一种都很难靠传统 SRE 仪表盘抓到。
第一种是"沉默型错答"。Agent 跑完整个流程,工具调用全部成功,返回结果格式正确,但最终答案在业务上错了。这类错之所以严重,是因为模型本身非常"自信":它会用流畅的语言把一个错误的数字包装得跟对的没有区别。对客服、退款、营销、合规这些场景来说,这种错答的成本远比"答非所问"高。
第二种是"循环型空转"。Agent 在某个子任务上反复调用工具,每次拿到相似结果但不收敛,累计 30 次到 100 次调用之后才自己放弃。OpenAI 在 Function Calling 文档里建议的最长循环是 10 轮,但 60% 的真实业务 agent 因为记忆压缩、prompt 复用或者多分支调度跑超过这个限制。这类空转对成本的影响是单向放大——每一次空转,token 费用、第三方 API 调用费、数据库查询费都在累加,却换来 0 业务价值。
第三种是"权限型越界"。Agent 在规划任务时,把一个不相关的工具也纳入了执行链,比如"帮我查一下用户 X 的订单"变成"帮我改一下用户 X 的收货地址"。这是因为模型在 PLANNING 阶段不会自动区分"工具的可读性"和"工具的可写性"。这种越界在传统 web 服务里靠 RBAC 兜底,但 agent 时代 90% 的工具网关还没有为 agent 调用单独设计 capability token。
第四种是"回放型幻觉"。Agent 把上一次 session 的结果直接当作这一次的输入,跳过验证。Walmart 工程团队在 2024 年分享过他们的 incident review 实践,2025 年下半年起这套做法被业内称为 "agent replay ledger",核心是给每一次 agent invocation 留下不可变日志,让下游任务可以查询历史而不依赖模型记忆。这种做法在 2026 年开始被 Datadog、Langfuse、Helicone、Portkey 等基础设施供应商集体跟进。
这四种模式有一个共同点:它们都不靠抛异常来暴露自己,全部在 trace 里以"看似正常"的姿态走过去。这正是传统监控工具看不到的原因——日志看起来很干净,API 调用都成功,只有最终业务结果在悄悄变差。
四、Reliability 不是"再写点 Eval":它是一条工程链
把可靠性翻译成中文,很多团队下意识会去做"补几条评估样例",这是错的。Eval(评估)是 reliability 工程链的一个步骤,不是全部。Thoughtworks 在 8 月 14 日的文章里画了一张很清晰的链路图,把 reliability 拆成五个层级。
第一层:目标层的 SLO 定义。一个 agent 上线前必须定义的核心问题是"什么样的失败算失败"。过去传统 SRE 用可用性、延迟、错误率三个指标描述一个服务,但 agent 服务必须多出三个维度:任务完成度(任务最终被完成的比例)、业务正确度(答案在业务语义上是对的,而非只是格式正确)、成本可控度(单次任务消耗的资源在预算内)。这三个新维度直接对应到 SLO 体系里,意味着 agent 服务从一上线就要有专门的服务等级协议。
第二层:流程层的可重放性。Agent 在生产跑过的每一次任务,都必须能完整重放——输入、上游上下文、模型版本、tool 结果、最终决策,五件事全部归档,缺一不可。重放的目的是把"用户报告一个 bad case"变成工程团队可以快速定位 bug 的能力,而不是"我看一眼对话历史觉得没问题"。
第三层:trace 层的全链路观测。这是 Datadog Agent Observability 产品定位的核心。它要做的事情和传统 APM 在微服务里做的事情本质相同:把每一次 agent invocation 的内部状态从黑盒变成白盒。具体来说,每一步 LLM 调用、每一次工具调用、每一次状态变更都被抽象成一个 span,span 之间是父子关系,形成一棵完整的决策树。这棵树是 agent 可观测性的根基,没有它,后面所有的 reliability 工程都是空谈。
第四层:评估层的离线与在线并行。离线评估用于发版前的回归校验,在线评估用于生产中的实时质量监控。这两类评估在 2026 年已经开始合并为同一个平台:同一条规则,既可以跑在测试集上,也可以跑在生产采样流量上。Anthropic 的 internal 实践里把这条路走到了极致——他们的 production monitoring rule 与 model evaluation rule 共用同一套 rubric。
第五层:反馈层的闭环。Reliability 工程链路走到最后,必须把"agent 错了"反向变回训练数据或者 prompt 改进单。这件事以前只能靠人工标注,2026 年开始有了"自动反例合成"技术——基于生产 trace 自动构造会让 agent 失败的对抗样本,放到下一轮 eval 里跑。这是把 reliability 从被动响应升级为主动进化的关键一步。
这五层不是顺序流水线,而是一个互相支撑的循环。SLO 决定重放保留什么数据,trace 提供评估样本,评估输出反馈到 SLO,每一次反馈都让下一轮 SLO 更精准。Thoughtworks 给这套循环起的名字叫 "operating model",意思不是某个具体产品,而是企业在生产 agent 过程中需要建立的"工程纪律集合"。
五、可观测性的真实形态:Trace Explorer 不是新仪表盘
很多工程师第一次听到"Agent 可观测性"会下意识以为就是"换个好看点的仪表盘"。这是一个会害死项目的误解。Datadog 在 8 月发布的 Agent Observability 产品里,核心交付物不是新视图,是新的 span 数据模型。
传统 APM 里,一个 span 描述一次 RPC 调用,字段是固定的:trace_id、parent_id、service、duration、status。Agent trace 的 span 字段被扩展了至少五个新维度:prompt template 版本、tool 调用参数、tool 返回结果、模型推理 token 消耗、模型输出 reasoning summary。这五个维度共同构成了 agent 的"决策画像"。
这意味着 agent trace 不是"日志再加点元数据",而是一类新的可观测对象。Datadog 给 agent trace 起的内部名字叫"agent tree",意思是它不是一条时间线,而是一棵决策树——每一个 LLM 节点可能分叉出多个 tool 节点,工具节点的结果反过来影响父节点的下一步决策。把一棵会自我演化的决策树完整记录下来,本身就是 agent 可观测性最大的工程难题。
Langfuse、Portkey、Helicone 在 2025 年下半年陆续发布了类似的 agent trace 模型,Arize Phoenix 把这一套做成了开源的 agent evaluation framework,Helicone 主打 agent cost attribution。这四家产品和 Datadog 的差异点是:前四家是开发者友好的轻量方案,Datadog 的方案是面向企业 SRE 体系的完整集成——后者会自动和 logs、metrics、RUM 走同一条数据通道,把 agent 故障和基础设施故障做统一排障。
对绝大多数中国企业的真实建议是:不管你最后选 Datadog、Langfuse 还是自研,你都必须先承认 agent trace 是一类新的可观测对象,然后从第一天就让 agent 框架输出这种决策树结构。这是 2026 年 agent 工程化的入场券。
六、Five Controllers and One Graph:Thoughtworks 提出的分层架构
8 月 13 日 Thoughtworks 发布《Understanding agents, their five controllers and one graph》,用一个非常直接的概念框架解释了 agent 在生产环境里"该怎么被管"。Zichuan Xiong 把 agent 在生产环节的所有控制行为抽象成五类控制器,再用一个统一的 graph 把它们组织起来。
第一类控制器是 Input Controller。它负责在 agent 收到用户输入的那一刻做三件事:意图识别、风险分级、必要时的 redirect(把高风险请求转交给人工)。这一层是 agent 收到第一条信息的"门禁"。
第二类是 Plan Controller。它负责把高层意图拆解为可执行子任务,决定哪些子任务交给 agent 自己跑,哪些必须由外部工具执行。这一层最容易出问题,因为模型在 plan 阶段常把不相关工具拉进来,导致前面提到的"权限型越界"。
第三类是 Execution Controller。它是 agent 调用工具的实际执行层,负责 timeout、retry、circuit breaker 三件老事,但在 agent 场景下,这三件事被赋予了新的语义——retry 不只是网络抖动,而是模型下一次推理是否有机会产出正确结果;circuit breaker 不只是下游系统撑不住,而是 agent 的成本是否撑不住。
第四类是 Verification Controller。它在前三类之后,独立地评估 agent 的输出。它可以是一个规则引擎(确定性问题),也可以是另一个模型(模糊问题),还可以是人类抽样审计。这一层是 evaluation 的执行位置。
第五类是 Memory Controller。它负责 agent 的短期与长期记忆。记忆在 agent 工程里非常容易失控——既能通过"记住上一次的偏好"让 agent 更懂用户,也可能因为"记错了上一次的偏好"导致严重的业务错位。
五类控制器通过一张统一的 graph 互相协作,这张 graph 既是协议,也是数据流图,更是容错图。任何一类控制器可以独立演化,但通过 graph 的边耦合在一起。这种"five controllers and one graph"的设计哲学,和传统微服务的 service mesh 概念惊人地相似——它本质上是在 agent 周围建一张自己的 mesh。
文章结尾给出了一个值得我们记住的判断:"You authorize it to decide something in a real-world case, what you hand over is not a task but the judgment the task requires." 翻译过来就是:你授权 agent 去做的不是一个 task,是这个 task 背后所需要的判断力。这一句几乎可以钉在每一个 agent 项目的墙上。
七、Reliability 与可观测性的四个落地杠杆
把前面所有的工程抽象压缩一下,可以提炼出企业在 2026 年下半年应该立刻握住的四个落地杠杆。这四条都是已经被多家企业反复验证、可在一周内开始动手的实操。
杠杆一:用 SLO 倒推 agent 设计。在 agent 上线之前,先问清楚三件事——任务完成度的 SLO 是多少(比如 90%)?业务正确度的 SLO 是多少(比如 99%)?单次任务的成本上限是多少(比如 0.5 美元)?这三个 SLO 一旦定下来,agent 的 prompt 复杂度、模型选择、工具链设计全部倒推到这张表上。没有 SLO,agent 设计就是开盲盒。
杠杆二:把每一次 invocation 都变成可重放的 case。具体做法是引入 agent replay ledger——每一次 agent 调用把 input、context、model version、tool calls、output 五件事落到 immutable storage 里。这个投入通常是 1-2 个工程师周,但回报是任何一次 bad case 都能在 30 分钟内被定位,而不是花一周时间复盘。
杠杆三:把 agent trace 当作第一类观测对象。不要把 LLM 调用当日志来记,要把它当 span 来记;不要把 tool 调用当字符串存,要把它当结构化事件存。在一家 agent 项目里,如果做不到 agent trace,那么下面所有的 reliability 工作都是空中楼阁。
杠杆四:建立 evaluation-driven 的迭代节奏。把每一次 agent 发版都当作一次 regression test 跑,eval suite 不能少,而且必须和生产 trace 共享同一条 rubric。Anthropic 的内部做法是"每周二自动跑一遍 production trace 抽样的 eval",任何连续两周低于阈值的指标直接进 backlog。
这四条都是 SRE 老兵一看就会点头的工程动作。但神奇的是,在 AI 工程团队里,2026 年还在执行得这么完整的项目不超过 30%——大多数团队还在 prompt 调优这个维度迭代,把可靠性放到"用户报上来再说"。
八、企业接 Agent 的下一步:从"能跑"到"敢放"
把视角拉回到企业决策层。对一个正在做 agent 落地的企业来说,接下来 6 个月,真正的分水岭不在于"接了多少个 agent",而在于"接进来的 agent 有多少被放进了核心流程"。
判断一个企业是不是真的把 agent 用成了,有三道关——
第一道是业务关。Agent 被允许调用真实业务接口(下单、退款、合同、付款),而不只是辅助查询。这要求业务接口必须为 agent 重新设计 capability token,而不是沿用人类员工的 RBAC。
第二道是quality 关。Agent 的输出被一个独立校验层评估,而不是自评或者由人类抽样审计。这一关的目的是把 reliability 从"靠人"变成"靠工程"。
第三道是compliance 关。Agent 的每一次决策都被追溯到具体证据,而且这个追溯链可以在监管检查时拿出来。这一关对应 EU AI Act 第 12 条和 OECD AI Principles 的可追溯要求。
三道关都跨过的企业,agent 才算真正"敢放"被扔到生产环节。这不是模型的功劳,也不是某一家中间层工具的功劳,是一个企业级工程链路建成的功劳。
从行业视角看,2026 年下半年 agent 项目集中爆雷的事情不会变少,反而会变多——因为企业 agent 数量在翻倍,而 reliability 工程建设的速度没跟上。这条曲线在 12-18 个月内会制造出一轮"agent 二期整改潮",就像 2018-2019 年那一波微服务改造潮一样。
九、清单:从下周开始可以立刻做的 12 件事
把上面所有工程抽象再压缩成一份可以下周一直接打开来排的清单。挑十二条,按 ROI 排序,前四条收益最大。
- 给当前在产 agent 定义 SLO(任务完成度、业务正确度、成本上限),写在 runbook 第一页。
- 每一次 invocation 落 agent replay ledger,五个字段(input / context / model_version / tool_calls / output)必须齐全。
- trace explorer 必须能下钻到 prompt 和 tool 级别,不能只看一个 LLM span。
- 上线前必须跑一遍 eval suite,production trace 抽 1% 进 eval set。
- 为 agent 调用单独设计 capability token,不沿用人类 RBAC。
- failover 路径必须落到人工接管,不允许"agent 不知道怎么办就猜一个"。
- circuit breaker 不只是网络级,包括 prompt 级和 tool 级。
- memory controller 必须有 TTL 与定期清理,不允许 agent 永久记忆上一次对话的用户偏好。
- 对每一条工具,做 capability 表——能否读、能否写、能否 delete,逐条登记。
- 每一条 SLO 配一个 owner,可观测性指标必须有人定期复盘。
- 每月一次 production trace review,找 5-10 个真实 invocation 做 deep dive。
- 每两周一次 chaos test,把下游工具故意降级,看 agent 是否会优雅失败。
十、回到美辰做什么
美辰作为给企业接 Agent 的服务商,我们过去半年看到的所有落地项目几乎都集中在这几个痛点:reliability 不知道怎么定义、observability 不知道买谁家、tool 调用权限分不开、bad case 复盘找不到原料。
我们的服务现在做三件事 ——
第一件,帮企业从第一天开始把 SLO 写清楚。不是"成功率 99%"这种空话,是"任务完成度 X%、业务正确度 Y%、单任务成本 Z 元"这种可度量的工程契约。
第二件,在企业接 Agent 的同时,把 trace 和 replay ledger 一起搭好。不管你最后选 Datadog、Langfuse、自研还是混合方案,第一批数据从生产第一天开始流,后面所有 reliability 工作才有材料。
第三件,在企业接 Agent 之前,先把工具的 capability 分层做出来。这件事永远比接 agent 更早开始,但恰恰是大多数企业推迟到上线后才补的环节。
可靠性与可观测性,是企业 agent 从"能跑"走到"敢放"的最后一步,也是美辰帮企业接 Agent 最愿意投入的方向。
写完这篇,想说三句话:第一,模型能力再强,生产侧的工程纪律跟不上,agent 还是会翻车;第二,reliability 与可观测性不是产品,是工程纪律;第三,2026 年下半年,真正拉开企业 agent 项目差距的,正是这条看不见的工程链路。
结尾
回到开篇那个客户的故事。那个做跨境电商 SaaS 的客户,在我们带着他们补完 SLO 体系、补完 agent replay ledger、补完 trace explorer 之后,客服 agent 的退款差错率从 6% 降到了 0.4%,失败案例的定位时间从平均两天降到了 18 分钟。模型没有换,prompt 改了不到 20 条,变化的几乎全部是工程纪律。
这个故事的另一个版本,我也想说给你听:同一时期,另一家客户换了一个更先进的模型,把 prompt 重写了三轮,但差错率从 3% 涨到了 9%。他们的差别不在模型,在工程链路。
企业接 agent 这件事,终究不是比谁接得早,而是比谁接得稳。Reliability 与可观测性,是这条路上不可跳过的两步。
