19｜洞察黑盒：为 Agent 引入 Tracing 机制复盘失败决策路径
Tony Bai
你好，我是 Tony Bai。欢迎来到《从 0 开始构建 Agent Harness》专栏的第十九讲。
在上一讲中，我们为 go-tiny-claw 打造了成本追踪的“仪表盘（Cost Tracker）”，我们清楚地知道了 Agent 每次运行消耗了多少 Token 和人民币。这是企业级落地必不可少的第一步算账。但是，仅仅知道“花了多少钱”和“跑了多久”，并不能帮我们排查深层次的逻辑 Bug。
设想这样一个真实的生产事故：你的 Agent 在排查线上问题时，跑了整整 5 分钟，经历了 15 个 Turn（轮次）的 ReAct 循环，最终宣告：“对不起，我无法修复这个问题。”
作为它的主程序员，你面对满屏滚动的终端日志，完全是一头雾水：
它在哪一步开始跑偏的？
在第 8 个 Turn 时，它发给大模型的 System Prompt 和 Working Memory 到底长什么样？大模型返回的原始 JSON 是不是因为截断而导致了幻觉？
它并发调用的 3 个工具，究竟是哪一个导致了耗时飙升？
大模型本身是一个不可控的“黑盒（Black Box）”。如果在驾驭工程（Harness Engineering）中，我们不能提供透视这个黑盒的“X 光机”，一旦 Agent 发生智障行为，我们将陷入无法调试的境地。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《从 0 开始构建 Agent Harness》，新⼈⾸单¥59
《从 0 开始构建 Agent Harness》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论