Anthropic 8 月 26 日放出一篇 Warp 的工程复盘，讲这家公司怎么让自家智能体持续修正行为，又不去动模型权重。
Warp 做的是 AI 终端和代理开发环境，2020 年成立，创始人 Zach Lloyd，累计融资 7300 万美元。公司给出的使用数据是月活开发者 80 万，财富 500 强企业里 56% 用过它的产品；Claude Code 在 Warp 内部累计跑过 1000 万次会话，当前每周超过 40 万次，平台上的智能体对话总量到了 4000 万。
三层结构
这套机制拆开只有三块。
最里面是基础技能，一份写着领域知识和操作规则的文件，比如代码审查该看哪些点、什么算阻塞性问题。中间是人类反馈，开发者对智能体输出的评价。最外面是一个改写代理，Warp 内部叫 improver skill，它的工作只有一件：定期把反馈收拢起来，对基础技能提出小幅修改。
Lloyd 对这个结构的说法是：
“There’s the base domain-specific skill and then there’s the improver skill that refines that domain-specific skill. This simplicity is the beauty of this approach.”
意译：一层基础的领域技能，一层负责打磨它的改写技能，简单本身就是这套做法的好处。
技能以文件形式存放，用的是 Claude 平台的 Agent Skills API。这个选择带来的连锁效果比听上去大。文件能被智能体直接编辑，也能进 Git，改写代理提出的每一次修改都以普通代码变更的形式走团队评审。人可以否决，可以回滚，可以在 diff 里看到智能体给自己新增了哪条规则。知识写进文件系统，不再堆在提示词里，这一步把”模型今天怎么又变了”变成一次能追溯的提交。
这里有个容易被跳过的前提：三层里最外面那层也是一份技能文件。改写代理自己怎么读反馈、怎么判断该不该改、一次能改多少，同样写在文件里，同样可以被人改。整套东西没有黑盒，出问题时能顺着两份文件查到底。
反馈质量决定上限
Warp 的代码审查代理刚上线时准确率大约 80%，剩下那两成靠这条回路往上补。Lloyd 强调的重点在反馈的形态，一句”这条审查不好”没有用，“detailed reasons why a code review wasn’t good” 才带得动学习。
难处在于，写详细理由要花时间，而开发者正在赶自己的活。Warp 的处理办法是把反馈入口做到极低摩擦，Lloyd 的原话是 “Low friction is what keeps signal flowing”，摩擦低，信号才流得动。这一条比三层架构本身更难落地：架构一周能搭好，让团队长期留下有信息量的评价，是个产品设计问题。
这套东西的边界
粗算一下这条回路的经济性。改写代理只在反馈攒够量时跑一次，每次读的是聚合后的反馈加一份几百到几千 token 的技能文件，提交的是几行 diff。跟微调比，成本低到可以忽略；代价是能改的只有写在文件里的显式规则，模型自身的判断偏好动不了。
所以它更像给智能体配了一本活的操作手册，而非把模型变聪明。适合的场景是规则明确、反馈密集、对错可判定的任务：代码审查、工单分类、格式转换。碰到需要模型改变底层判断的活，这条回路就到头了。
对多数团队来说，这个天花板算不上问题。绝大部分智能体在生产里出的错，都出在没写清楚的规则上，跟模型强弱关系不大。把规则写清楚这件事，过去靠人一遍遍改提示词，现在有了一个会自己动笔、且改动摆在评审台上的合作者。
参考来源：Anthropic 官方博客的 Warp 工程复盘、CocoLoop、Warp 公开的产品与融资信息；会话量、准确率与融资额均按其公开披露口径记录。