Ben Holmes：用 Agent 追踪记录改进技能

Warp 开发者体验工程负责人 Ben Holmes 介绍一种 agent：回顾过去的工作，并提出配置改进建议。他关注的是软件工厂外围的改进循环，而不只是编写代码的 agent。

软件工厂将开发阶段自动化：从看板或消息接收任务，研究问题，与人编写规格，实现代码，收集证据并审阅拉取请求。监控结果再进入下一轮。

Holmes 将改进这一系统的工作称为工厂工程。团队可以改善技能、代码架构或静态分析；本次演讲专注于影响 agent 行为的技能与配置。

这一循环收集对话，按团队定义的评分标准打分，归纳失败案例，再让另一个 agent 提出修改。人工审阅这些修改后，团队可以继续衡量结果是否改善。

第一步是把 agent 对话集中起来。本地工具把历史保存在各自机器上；团队可以集中这些记录，也可以使用共享云运行器，让隔离任务在共同系统中生成追踪记录。

有用的追踪记录不只有消息：还应包含工具和文件系统调用、外部集成及其输出。也要保留最终代码差异或拉取请求，让审阅者把 agent 的行动与产物联系起来。

当团队发现 agent 添加的测试不符合覆盖策略时，Holmes 建议评估冗余测试。评分标准应反映团队对单元、集成和端到端测试的实际偏好。

另一个标准是冗长程度：过多注释或不清楚的摘要可能拖慢代码审阅。目标是帮助审阅者理解变更，同时减少不必要的噪声。

评估效率需要查看工具调用，而不只是最终回答。Holmes 说，agent 可能在过时指令下反复探测环境，最终成功，却没有报告浪费的工作。

他展示一个用 Markdown 编写的 LLM 评分标准，定义期望行为、分数标签和失败条件。他建议先从简洁标准开始，再在使用中改进。

对每个抽样对话，评分 agent 会评估选定标准。在他的例子中，过多单元测试和花时间摸索测试环境分别未通过对应标准，而清晰沟通通过了。

评分可在拉取请求合并后触发，并通过抽样控制 token 成本。每份报告都应解释通过或失败的原因，为下一个 agent 提供证据，而不仅是数字。

定时运行的改进 agent 可以检查近期失败，找出反复出现的原因，并提出技能或代码修改。Holmes 举例说明每天运行一次，向其提供失败报告和相关仓库访问权限。

对于个人环境，他演示了 Skill Doctor：一次性分析本地 agent 历史，分批给会话评分，并生成模式与配置修改建议报告。

一个例子发现 agent 反复遇到端口占用，建议改进测试环境指令。另一个记录了对更新日志语言的反复偏好，以减少重复沟通。

Holmes 认为，可见的评分历史有助于团队理解一次修改产生了什么效果。仪表盘可以展示效率随时间的变化并标记技能合并时间，不过相关性本身不能证明因果关系。

在 Warp 的环境中，agent 持续给对话评分，定时流程再提出供人工审阅的拉取请求。一个报告的修复更正了阻止分诊 agent 启动子 agent 的配置。

Holmes 最后邀请团队尝试这一流程或在本地运行 Skill Doctor。核心做法是揭示看似成功的运行中隐藏的模式，把反复出现的摩擦转化为可审阅的改进。