Warp的工程师一开始很烦自己的代码审查智能体。它能看懂代码,但给出的评论经常文不对题,甚至提一些团队根本不认可的修改建议。团队试过手动改prompt,试过写AGENTS.md,都只是缓解,治不了根。问题不在模型笨,而在一件更基础的事:智能体每完成一次任务,人类给的纠正就跟着会话一起清零了。下一次遇到同样的坑,它还会再踩一遍。
Anthropic把Warp后来解决这个问题的做法写成了官方案例,框架听起来干净利落:一个负责干活的skill,一个负责复盘改进的skill,中间夹一层人类反馈。这套东西现在跑在Warp的整个开源仓库里,代码审查、issue分诊、写spec的智能体各自带一条改进链路。Warp月活开发者80万,财富500强里56%在用,Claude Code在Warp里跑过1000万次会话——这套机制不是玩具项目,是真在生产环境里跑量的东西。
两层Skill怎么分工
Skill是Anthropic Agent Skills机制里的知识文件,把操作规范存成独立文件,而不是塞进每次调用的prompt里。Warp的架构分里外两层:
内层skill管干活。PR一开,代码审查智能体照着这个skill里的领域知识产出评论。人类看了给反馈,可以是一个赞,也可以是具体到"这个变量按我们的命名习惯该叫什么"的详细说明。创始人Zach Lloyd强调,反馈越具体,信号越值钱。
外层improver skill管复盘。它不按任务触发,按计划跑,定期把攒下来的人类反馈拉出来,对比智能体当初的建议和人的实际反应,提出一处小改动,打包成一个PR去改内层skill。这个PR照常走代码审查流程,人批准合并,下一次内层skill跑起来就带上了新知识。
Zach Lloyd给的经验也简单:写原则别写死规则,给出理由让模型能推理而不是死记,反馈要在人本来就干活的地方顺手给(比如直接评论在PR上),skill文件要小、靠引用外部资源文件而不是一次性塞满上下文。
- 结论.这套方法本质是把code review里的隐性经验显性化、文件化、可版本管理,任何团队理论上都能照搬。
官方故事之外,真实版本复杂得多
Anthropic的官方博客把这套架构讲成一次性设计出来的优雅方案。但Warp自己的技术博客留下了另一条时间线:6月16日先发了一篇通用的skill自我改进方法论,7月15日才落地成代码审查的具体实现,8月26日Anthropic官方案例发出来,第二天8月27日,Warp自己又发了一篇升级版——这次多了独立的scorer智能体、量化metrics和benchmark,整套流程被称为"self-improving software factory"。
这条时间线说明两件事。一是这套架构不是灵光一现,是Warp在生产环境里边跑边补,连续三次公开迭代,当前最新版本已经比官方案例里"两个skill"的描述复杂出一截。二是Anthropic和Warp的关系不是一次性报道,早在5月13日双方就联合办过同主题的技术分享,8月这篇官方博客更像是一场持续了三个多月的联合叙事的阶段性总结,而不是孤立的产品案例。
支撑这套系统运转的,是Warp自研的智能体编排平台Oz。它能在本地或云端跑skill、支持定时调度、暴露API、留审计记录,官方案例里完全没提这一层。换句话说,improver skill能定期跑起来、能自动开PR、能被审计追踪,靠的是Oz这套基础设施,不是靠Claude Platform本身自带的能力。这也是这篇官方文章最容易让人误读的地方:读者可能以为拿着Claude Platform和Agent Skills就能直接复现,但真正撑起"定时复盘、自动开PR、留痕可查"这条链路的,是Warp自己搭的编排层。
这事到底该信几分
代码审查智能体变听话了,这个结果大概率是真的——Warp的仓库、贡献者数量、审查量都摆在那,团队没有理由在这件事上撒谎。但官方博客里没有一个数字能回答最关键的问题:改进循环跑了多久之后,评论采纳率涨了多少,或者误报率降了多少。没有量化对照,"变好了"就只是一句创始人的主观陈述。
improver skill本身也是个隐患。它按最近的人类反馈调整规则,如果某段时间反馈来自个别话痨型审阅者,或者集中在某类边缘case,skill很可能被带偏,越改越窄。Warp给出的对策是"人保留最终审阅权",这确实是个闸门,但闸门挡不挡得住噪音,取决于审阅者本身是否有耐心和判断力去否决一条看起来合理、实际有偏的修改。
《左传》说"其兴也勃焉,其亡也忽焉",讲的是治理系统靠什么撑住:靠制度而不是靠某一次决策的运气。Warp这套自我改进循环像是在给智能体装一套"制度",让经验能沉淀、能审计、能回滚。这个方向是对的,而且是少见的、真把工程纪律用在agent产品上的做法。
- 提醒.这套架构目前最硬的依赖是Oz这个自研编排层,没有类似基础设施的团队,复现难度比官方文章暗示的要高。
闭环讲得越漂亮,越该问一句:数据在哪,防过拟合的栏杆在哪。
对做Agent产品的团队来说,真正该抄的不是"两个skill"这个概念,而是Warp踩出来的那条更笨的路:先解决反馈怎么低摩擦地收集,再解决怎么把反馈可审计地写回知识库,最后才是考虑要不要上scorer和benchmark做量化验证。跳过前两步直接抄最新的"软件工厂"框架,大概率只是把prompt工程的活儿换了个更复杂的壳。