AI智能体生产环境调试：从凭直觉到用Evals与Trace

很多团队上线AI智能体时，靠的是“感觉”——看一眼输入输出，觉得差不多就发布了。这种被演讲者Ankur称为“凭直觉裸奔”的做法，在演示环境也许行得通，一旦进入生产环境，你根本不知道智能体在哪一步悄悄跑偏。在B站分享的这场技术演讲中，Ankur系统性地展示了如何用追踪（Trace）、评估（Evals）和编码智能体（Coding Agent）构建一套可重复的调试闭环。

为什么凭直觉上线必然翻车

传统软件调试之所以简单，是因为执行路径是确定性的：一个handleSubmit方法，校验失败就报错，校验通过就进入下一步，堆栈信息一目了然。但智能体不同，你的代码里往往只有一行agent.run(query)，接下来它是调用工具、做内部分析还是继续思考，全由模型自己决定。

这意味着，如果没有追踪数据，你连“它做了什么”都说不清楚，更别提定位问题。Ankur在演讲中现场做了一个小调查：绝大多数人都在凭感觉验证智能体，配置了评估体系的人少一些，而敢说自己评估覆盖足够、能放心持续迭代的人更是寥寥无几。这不是能力问题，而是智能体的非确定性本质决定的——你很难预先知道该评估什么。

Trace：智能体调试的地基

Trace记录的是智能体执行过程中的每一步：LLM调用、检索到的文档、触发的工具、内部推理链路。Ankur举了一个典型例子：用户问“我的退款到哪了”，智能体却调用了getOrderStatus工具，然后回复“退款已发放”。从工具返回值看似乎没错，但用户真正想知道的是退款为什么还没到账。只看最终输出，你发现不了这个错误；看Trace，错误工具调用暴露无遗。

有了Trace，调试才从“猜”变成“查”。你可以定位失败发生的具体环节，抽取一批相似案例作为数据集，然后针对性地判断：是提示词需要改？是工具本身有问题？还是该加一层护栏（Guardrail）？

Trace（追踪）与可观测性：在智能体语境下，Trace指的是对一次请求完整生命周期的结构化记录，通常以树状或链式结构组织，每个节点是一个span，记录该步骤的输入、输出、耗时、模型参数、token用量和错误信息。与传统的日志（log）相比，Trace的核心优势在于保留了步骤之间的因果关系——你能明确看到是哪个工具返回引发了后续的LLM幻觉，而不是在一堆时间戳相近的日志里拼凑时序。业界常见的实现标准是OpenTelemetry的GenAI语义约定，LangSmith、Langfuse、Arize Phoenix等平台都兼容这一格式。Trace的粒度设计需要权衡：记录太少无法定位问题，记录全部原始prompt又会带来存储成本和隐私风险，因此生产环境通常对敏感字段做脱敏并设置采样率。

手动调试的八步循环，太慢了

标准的智能体改进流程大致是：发现生产问题→找到对应Trace→抽样形成数据集→分析根因→设计方案→构建评估→跑实验→上线，然后循环往复。这个过程有效，但极其耗时——几天时间可能就耗在翻Trace和手动比对上了。

Ankur的思路是把所有数据源汇聚到编码智能体面前：Trace数据、已有评估结果、人工标注、APM监控日志，甚至代码库本身。这样，Claude Code、Cursor、Codex这类工具就能自动完成大部分排查工作，把原本以天计的过程压缩到分钟级。

现场演示：一个金融智能体的“体检报告”

演讲中的案例是一个金融建议智能体，用户问“我该不该投资某公司”，它直接给出了“该投”的结论。这显然有问题——它既没有询问用户的风险偏好和财务状况，也没有任何合规护栏。现场观众给出的诊断包括：应该多反问用户、需要提示词调整、缺少基准验证。

配置好CLI和技能后，Ankur让Claude Code拉取该智能体的Trace并做分析。结果相当刺眼：约44%的交互产生了糟糕的总结，大量回答存在编造内容，工具冗余调用率偏高，还存在“工具静默失败但智能体假装成功”的情况。这些问题靠人工翻日志几乎不可能全面发现。

更关键的是，编码智能体不仅能诊断，还能动手修。它针对“工具静默失败”和“数值可溯源性”构建了评估器，并在导致失败的原始数据集上跑实验验证。

另一个历史案例更能说明迭代的价值：某次涉及韩国股票的查询全部失败，基线通过率为0%。第一轮修复尝试归一化国家名称，无效——因为底层工具版本也已过时。更新工具版本后，第三轮迭代通过率提升到约90%。仍不完美，但从“完全不知道哪里坏了”到“知道修了什么、还差什么”，这是质的区别。

评估不是一劳永逸，而是持续监控

现场有观众问：既然可以直接改提示词让总结变好，为什么还要评估？Ankur的回答点出了核心：评估的价值不在于某一次修复，而在于防止性能回退。提示词今天好用，两个月后模型更新、用户提问方式变化，效果可能悄悄下滑。没有评估，你根本感知不到这种退化。

关于成本，演讲者也给出了务实建议：评估调用LLM确实产生额外费用，但平台通常支持采样比例控制，不必对100%的Trace跑评估。另外，评估模型的选择应服务于你的场景——有人用便宜模型做初筛，有人坚持用最强模型保证评估质量，没有统一答案，也不存在通用的“最佳评估模型”榜单。

评估器（Evaluator）的常见类型：评估智能体输出时，通常组合使用三类评估器。第一类是确定性规则评估，如精确匹配、正则校验、JSON schema合法性、工具调用参数是否包含必需字段，成本低且可解释。第二类是LLM-as-a-Judge，让一个模型按评分标准（rubric）对回答打分，适合判断“总结是否忠实于检索文档”这类主观质量，但需要注意位置偏差、冗长偏好等已知问题，通常要求评分标准写得足够具体并给出few-shot示例。第三类是人工标注，作为校准前两类评估器可信度的金标准。实践中常采用分层策略：先用便宜规则评估过滤明显错误，再用LLM评审处理边界案例，定期抽样人工复核。评估结果还应与线上指标（如用户点赞率、任务完成率）做相关性验证，避免评估集与真实分布脱节。

这套方法适合谁

Ankur反复强调，编码智能体不是魔法，它们也会跑偏、会陷入修linting之类的小问题。技能（Skills）的作用是让它们聚焦在Trace暴露的真实故障上，而不是对着代码风格反复打磨。人类仍然要扮演最终审核的角色——确认修改方向正确，而不是让智能体自我感觉良好地“优化”了一轮却让效果倒退。

对于已经上线智能体、却还在靠肉眼抽查的团队，这套“Trace→诊断→建评估→跑实验→上线→持续监控”的闭环，是目前把生产环境不确定性压下去的最实际路径。

护栏（Guardrail）与编码智能体的分工：护栏是独立于智能体主流程之外的一道检查层，在输入侧可以拦截越狱提示、敏感话题，在输出侧可以校验事实一致性、合规措辞、是否包含必要免责声明。它与评估的区别在于运行时机：评估多在离线或抽样场景下运行，用于衡量质量趋势；护栏则在每次线上请求的路径上同步执行，要求低延迟且误杀率可控。文中的金融案例里，“未询问风险偏好就给出投资建议”这类问题，既可以靠提示词修复，也适合用护栏兜底——例如在输出前检测是否包含具体投资建议且缺少免责声明，命中则改写或转人工。护栏与编码智能体构成互补：智能体负责发现和修复系统性缺陷，护栏负责在修复上线前和上线后持续拦截高危输出。