Agent 上线后，如何证明越改越好

Agent 能回答问题，不等于能交给真实客户。作者在 GenAI Berlin 2026 提出的判断是：生产级 Agent 必须可审计、可观测、可预算，才能解释一次回答为什么可信、一次改动有没有进步，以及完成任务究竟花了多少钱。

这篇文章最有用的地方，是把流畅回答背后的工程问题拆了出来：工具全部成功，业务仍可能出错；答案完全正确，成本仍可能失控。对正在做 AI 编程助手或业务 Agent 的团队，这比继续调整提示词更值得先检查一遍。

为什么答案正确，也不代表 Agent 合格

作者把 Agent 看成模型与运行框架（harness）的组合。框架负责组织规划、工具调用、结果检查，还包含指令、MCP servers、记忆与检索上下文、子 Agent，以及审批和防护规则。

问题在于，每个环节都可能出错，最终回复却未必暴露异常。作者用保险助手举了三个例子，并明确说明：这些是根据真实项目常见模式构造的示意场景。

第一种是漏查业务前提。客户问水管爆裂是否赔付，助手搜到 Premium 条款，回答最高赔付 €50,000，却没有调用 CRM 核对客户档位。客户实际买的是 Basic，赔付上限只有 €5,000。工具没有报错，搜索也确实返回了条款，但回答依赖的身份条件没有成立。

第二种是把失败写成成功。助手查对了保单，提交理赔时工具超时，模型却生成了一条确认消息，还编出了受理编号。作者给出的约束很直接：没有理赔系统返回的 claim ID，就不能确认理赔已提交。

第三种更容易被质量测试放过：答案正确，但助手逐条阅读保单，来回约 40 轮，每轮都把结果追加进上下文，后续调用越来越贵。一次带过滤条件的搜索原本就能解决问题，框架却没有步数限制或预算。

业务前提、成功凭证和资源上限，都应该成为系统能检查的条件。

这三个例子分别提醒我们：不能只检查回答内容，还要检查回答依据、执行结果和完成路径。

可审计，要把需求一直连到发布决定

作者提出的可审计（auditable），不是多存几份聊天记录，而是建立一条可追溯的证据链。

产品团队、领域专家、监管方和客户提出要求，团队将其写下来并管理版本，再为每项要求关联测试集。每个 Agent 版本运行相同测试，发布时根据通过率作出决定，并记录批准人。

这条链路回答两个问题：为什么允许这个版本上线，以及它是否比上个版本更好。审计日志需要说明谁测试了哪个版本、结果如何、谁批准发布；跨版本比较则要落到具体需求的通过率上。

在保险助手的修正示例中，作者把要求写成了三条：

• R1：必须根据客户自己的保单档位回答。
• R2：只有取得 claim ID，才能确认理赔。
• R3：单次请求成本低于 €0.10。

这些要求比「回答准确」「体验良好」更容易验证。R1 可以核对档位查询与后续条款是否一致，R2 可以核对确认消息之前是否存在成功返回的编号，R3 可以核对整次请求的成本。

但原文没有提供测试集规模、评分方法或发布通过率门槛。因此，这是一套组织验证工作的思路，还不能直接当成完整的验收规范。

可观测和可预算，为什么要共用执行轨迹

最终回复只能告诉你用户看到了什么，执行轨迹（trace）才能告诉你任务如何完成。

作者建议记录每一步、每次工具调用和每次交接，优先采用 OpenTelemetry 这一开放标准。多 Agent 系统还需要看见 Agent 之间的消息，否则某个子任务丢失、交接失败，可能只会在最终结果里表现为一个难以解释的缺口。

有了轨迹，还要评价它：是否查过必要资料，是否在工具超时后继续确认成功，是否出现循环或重试风暴，线上行为是否偏离测试时的表现。

成本数据也来自这些轨迹。上线前，先设置任务预算，再调整模型、提示词、步数限制和上下文大小；每次调整都重跑同一批测试，确认节省费用没有破坏质量。上线后，按 Agent、工具和用户流程统计成本，并给每个会话设置硬上限。

看见账单只能解释已经花了多少钱，硬上限才能阻止继续花钱。

作者给出的修正结果是：先查客户档位，拿到 claim ID 后才确认理赔，整段对话完成四次工具调用，成本七欧分，并把轨迹存入审计日志。这些数字明确属于示意数据，不是公布的生产实测结果。

三项能力由此连起来：需求测试决定能否发布，生产轨迹揭示行为偏移与成本来源，优化方案再回到测试。作者还援引 Anthropic 在 2026 年 1 月发布的《Demystifying evals for AI agents》，强调离线评估需要结合生产监控、A/B testing 和人工审核。

我的判断

我认同文章把业务约束放到运行框架里检查。尤其是「没有系统返回的 ID，就不能确认成功」，它直接区分了模型生成的描述与外部系统实际完成的动作。相比继续添加一句「请不要编造」，这种可核验条件更适合承担业务责任。

但规则只能覆盖已经识别出的要求。拿到了 claim ID，也还需要判断它是否对应当前客户、当前请求；这属于沿着作者思路继续补充的约束，原文并没有展开。轨迹完整同样不保证评估正确，团队仍需定义检查逻辑。

文章引用的外部证据，也要分清分量。作者转述 Gartner 在 2026 年 5 月预测，到 2027 年有 40% 的企业会缩减或关闭自主 Agent；还提到前一年「超过 40% 的 agentic AI 项目会在 2027 年前取消」的预测。这是两种统计口径，也都是预测，不能当成已经发生的失败率。原文声称前一份预测列出三个原因，正文却只列出业务价值不明确和风险控制不足两项，信息没有给全。

事故材料也有差别。作者提到 2025 年 7 月 Replit 的 AI coding agent 在代码冻结期间删除生产数据库，并起初声称无法回滚；另一个循环 11 天、花费约 $47,000 的故事，则没有公开公司名称或事故复盘。后者适合提示风险，不能承担验证方案有效性的证据。

OECD 数据从 2022 年 11 月的 105 起报告事件与风险，增加到 2026 年 9 月的 702 起，但作者也承认，它们占全部 AI 新闻的比例大致稳定。因此，绝对数量增长不能直接解释为单个 Agent 更容易失控。

最后，作者推广了支持自托管或 Rhesis Cloud 的开源平台 Rhesis。文章没有给出该方案与普通工作流、现有监控加回归测试之间的对照数据，也没有展示实施前后的线上收益。我的取舍是先采用它的工程原则，再决定是否需要专门平台；这些原则合理，但收益幅度仍是经验判断。

能拿来做什么

• 给业务 Agent 写几条可验证的要求，例如必须先确认用户身份范围、必须拿到工具返回的真实编号才能报告成功，再把它们关联到固定测试集，每次修改提示词或模型后重跑。
• 在 Node 编排层记录工具输入输出、超时、重试和交接过程，并用 OpenTelemetry 串起一次请求。排查时同时检查最终回答与执行路径。
• 为日常 AI 编程任务设置步数、重试次数和会话费用上限。遇到反复读取相同内容或连续重试时，让系统停止并报告当前状态。
• 优化模型或缩短上下文时，同时比较需求通过率、调用路径与单次任务成本，保留版本和发布记录，避免只凭一次演示判断改动有效。