跨国深谈← 返回←智能体上线后总出问题？先学会「看见」它在干什么

智能体上线后总出问题？先学会「看见」它在干什么

关联

人物 Doug Guthrie

公司 Braintrust

概念 追踪 · 可观测性 · 评估 · LLM 裁判 · Topics · 飞轮 · 编码智能体 · Brainstore

做智能体（agent）的人都会撞上同一堵墙：东西做出来了，也上线了，但它到底哪里做得好、哪里在悄悄出错，没人说得清。

在这场工作坊里，Braintrust 的解决方案工程师 Doug Guthrie 把他们从 Cloudflare、Dropbox、Netflix 这些客户身上学到的经验掰开讲了一遍：

怎么追踪智能体的每一步，怎么从海量数据里淘出有意义的信号，又怎么让生产线上的发现反过来推动开发。

哪怕你不用 Braintrust，这套思路也值得借鉴。

为什么追踪是一切的基础

Guthrie 说得很直接：如果你的技术栈里没有类似追踪（trace）的东西，那你的智能体就是个黑盒。

追踪的意思是记录智能体走到最终输出前的每一个步骤——调用了哪些工具、每次的输入输出是什么。

步骤一多，数据量会爆炸，这正是难点所在。

但反过来，没有这些数据，你连「质量在哪 deteriorating」都找不到，更别提让 Codex 或 Claude Code 这类编程工具帮你定位问题了。

评分怎么设计才不流于形式

他把信号拆成两类。第一类是评分（score），也就是给智能体的输出打分。

最简单的是基于代码的评分：验证格式对不对、工具 A 是不是在工具 B 之前被调用，跑得快、花钱少。

更主观的问题就要靠大模型当裁判，你给它一套标准，它给对话打分。

如果裁判在给线上流量打分，还应该配上人工抽检来校准——这不是设一次就不管的事，智能体会变，评分标准也得跟着变。

几个实战建议：起步阶段用二元评分（过/不过），而且标准要狠。

如果你的评估全拿满分，「你的评分大概不够严苛」，测试用例也不够强。

另外，在提示词里给裁判举几个例子，评分用的模型可以比生成用的更强一些。

光知道已知问题还不够

第二类信号是 Braintrust 的 Topics 功能，专门对付未知的未知——你已经设好的评分，只能覆盖你认识到的那些失败模式，但用户实际会拿各种你没测过的场景去试探你的智能体。

Topics 的做法是：

把冗长的追踪预处理成一段摘要，让大模型按维度（比如用户意图、情绪、问题类型）归类，再对摘要做向量嵌入、聚类，最后生成一张散点图，把每条追踪打上标签。

这样你就能看到哪些模式出现得最频繁。

这个流水线用的是 Braintrust 自家的托管模型，成本是输入每百万 token 6 美分、输出 40 美分，目标是能在 100% 的追踪上跑。

有个意外收获：有客户发现用户在拿智能体做团队压根没想到的事——这与其说是发现故障，不如说是免费的产品需求调研。

真正的目标是转起来的飞轮

Guthrie 全场反复讲一个词：飞轮（flywheel）。核心主张是「生产应该反过来指导开发」。具体闭环是：

从线上日志里发现一个问题，把这条真实交互加回测试数据集，改代码、跑评估、对比上一次的结果确认没有退步，再部署上线。

他还现场演示了更进一步的自动化：

给 Codex 这类编程智能体装上 Braintrust 的 CLI 工具和相关技能，它就能自己写 SQL 查询线上数据、钻进出错的追踪、创建新评分、补充数据集、跑评估，最后开一个拉取请求，附上改动理由和评估数据，交给人审核。

他说首页上有一家客户靠这个每天多产出 5 到 10 个拉取请求。

几个值得记住的细节

被问到凭什么选 Braintrust 而不是竞品时，他举了两点：一是对语言、框架、模型供应商都很中立；

二是他们在 2024 年底就自研了数据库 BrainStore，因为接下 Netflix、Microsoft 这样的客户后，原本用的 ClickHouse 在大规模数据下很快撑不住了。

他认为竞品后来也纷纷自建数据库，Braintrust 在这件事上领先了大约一年。

部署方式上，除了标准 SaaS，还有数据留在客户自己基础设施里的方案，他估计首页那些大客户 90% 都是自托管。

问答环节还有个实用提醒：新上线的智能体采样率应该高一些，成熟之后可以逐步调低。

本集带走

• 没有追踪就是黑盒：先记录智能体每一步的工具调用和输入输出，才谈得上发现质量问题。
• 评分起步用二元制、标准从严；评估拿满分往往说明测试用例太弱，而不是智能体完美。
• 已设好的评分只覆盖已知问题，Topics 这类聚类分析能暴露你没料到的使用方式和故障。
• 核心是把生产反哺开发做成飞轮：线上发现的问题要变成测试用例，改完跑评估对比，确认改进再部署。
• 把这套飞轮交给编程智能体自动跑——查数据、改代码、开拉取请求——已经有客户每天因此多产出 5 到 10 个拉取请求。

我认为二元评分，尤其是在起步阶段、当我们有一个正要投入生产的智能体时，比 A、B、C、D 之类要好。而且你应该极其严苛。
Binary scoring, I think, especially at the outset, when we have sort of an agent that we are putting out into production, binary scoring, I think, is better than, you know, A, B, C, D, or so on. And you should be incredibly harsh.
—— Doug Guthrie · [12:46]

但如果你在你的 eval 上拿到 100%，其一，你的数据集中可能没有足够强的测试用例，你的评分可能不够严苛，所以你应该审视一下并相应地进行校准。
But if you get 100% on your evals, one, you probably don’t have strong enough test cases in your data set, your scores probably aren’t harsh enough, so you should sort of look at that and sort of calibrate accordingly.
—— Doug Guthrie · [13:09]

你的评估应该随着你的智能体一起演进。
Your evals should evolve with your agent.
—— Doug Guthrie · [78:32]

我可以基于所有那些洞察生成一个 PR，但我并不给他们访问底层 trace 的权限。我给他们的是对这些 trace 的分析的访问权限。
I can generate a PR based off of all of those insights, but I don’t give them access to the underlying traces. I give them access to the analysis.
—— Doug Guthrie · [98:38]