从 trace 到 eval:trace 设计、agent eval 方法论、一个 eval harness 的实现,和它抓到的上游并发 bug
我开始做 AI 相关 App,从 chatbot 到 agent 已经有一年多了.积攒了不少相关的经验,这次我分享一下关于 trace 和 eval 的一些做法和观点.
我开始做 AI 相关 App,从 chatbot 到 agent 已经有一年多了.积攒了不少相关的经验,这次我分享一下关于 trace 和 eval 的一些做法和观点.
2025 年 4 月,得物技术团队发了一篇文章得物 iOS 启动优化之 Building Closure,讲他们排查到 iOS 启动耗时中 BuildingClosure 阶段的一次诡异暴增。根因不是动态库、不是编译选项、不是打包脚本,而是新增的几个 ObjC 方法名,跟已有符号在 dyld 的完美哈希构造算法里...
我在维护两个项目,一个是 Swift 写的 macOS CLI 工具(ForgeLoop),另一个是 Rust 写的微信 Bot(AMClaw)。开发阶段每次 push 都跑全量测试太费时间,而且有些测试在本地 commit 之前已经跑过了,CI 再跑一次完全重复。
在 iOS 开发里,没有哪个基础控件能像 UITextField 这样—-表面上代码只有一行,背地里却牵扯到半个操作系统的子模块。它泄漏、它卡顿、它生命周期诡异、它让内存检测工具集体失语。更麻烦的是,这些问题往往不是你代码写错了,而是系统层面组合出的结果。
把 Agent 的上下文理解成“聊天记录”,很自然,也很容易把问题看浅。
我最早把 Thought 看得很重。
前两篇写 Planning 和 ReAct 的时候,我其实一直没把问题说到底。
我最早搭 Planning 模式的时候,觉得它比 ReAct 优雅很多。先花一点时间把任务想清楚,拆成步骤,排好依赖,再一条条往下走。不像 ReAct 那样边想边做,每一步都临场拍脑袋。Planning 看起来更有条理,也更可控。