Anthropic 在 2026 年 8 月 26 日发布了一篇客户案例 How Warp builds self-improving agents on Claude，作者 Michael Segner。Warp 是一家做 AI 驱动终端与 agentic 开发环境的公司，成立于 2020 年，累计融资 7300 万美元。规模数据先摆在这里：全球近 100 万开发者中约 80 万月活，56% 的财富 500 强企业在用，Warp 内累计跑过 1000 万次 Claude Code 会话（每周超 40 万次），agent 对话总量 4000 万次。
但真正值得读的不是规模，而是这篇文章回答的问题——它比"我们如何用 Claude"要尖锐得多：
agent 收到的反馈，通常在会话结束后就丢失了。下一次运行，它还是从零开始。
Warp 把这称为反馈消失问题。你调试 agent 的方式再精细，只要改进沉淀不下来，它就永远是一个"每天失忆的助手"。这篇文章给出的解法是一套基于 Agent Skills 的双层技能架构，简单到几乎没有框架感——而按 Warp CEO Zach Lloyd 的说法，“这种简单性正是此方法的魅力所在”。
一、核心架构：双层技能闭环
技能即文件
先明确一个前提：这里的技能（skill）是文件形式的知识编码——Markdown 写就的领域知识与指令，任务执行时按需载入，不直接占用 prompt。Warp 的关键判断是：agent 极擅长更新文件。所以与其给 agent 外挂一套记忆系统，不如把知识放进它最擅长操作的对象里。
两层分工
架构只有两个角色：
- 内层基础技能：存放领域知识与指令，比如"代码审查应该检查什么"。它是干活的——agent 每次执行任务时读取并遵循。
- 外层改进技能（improver）：一个定时运行的"观察者 agent"。它不执行业务任务，只做一件事——拉取近期的人类反馈，对比内层技能的当前内容，提出小幅修改，然后自动开 PR。
中间的原料是人类反馈：不需要任何专门的表单或工具，就在工作现场——issue 评论区、PR 评论区——顺手给出。可以是简单确认"这是一条有用评论"，也可以是详细解释。Zach Lloyd 举的例子很具体：
“你建议重命名这个变量，但我们代码库中这类全局变量遵循这种命名规范”——这能让 agent 下次做对。
闭环的最后一步是 PR 审查工作流：improver 的修改走标准 code review 流程，由人类审核、批准、合并。合并之后，内层技能的下一轮运行自动继承改进。
为什么这个设计站得住
（以下为作者观点。）这套架构的可信度来自三个朴素的工程事实：
第一，文件是 agent 最擅长操作的对象。 读写 Markdown 文件是任何 coding agent 的基本能力，不需要新的基础设施。改进 agent 的过程本身就是一次普通的 agent 任务——读反馈、改文件、提 PR。
第二，PR 是组织已有的信任机制。 知识更新不发明新流程，而是复用人类已经建立了几十年审查习惯的通道。agent 提的每个修改都可追溯、可回滚，“谁改了规则、为什么改"全部沉淀在 git history 里。
第三，闭环由人类合并完成。 这意味着改进的速度上限由人类的审查带宽决定——看起来是限制，实际上是安全设计：知识库永远不会在无人知晓的情况下发生漂移。
二、实战案例：issue 分诊 agent
架构讲完容易觉得抽象，Warp 用一个公开演示仓库（warpdotdev/warp-agents-demo-github-issue-triage）把闭环完整走了一遍。
触发与执行。 有人提交 GitHub issue，GitHub Action 触发分诊 agent。内层技能指导它分析 issue 的复杂度与可行性、打标签、建议修复方向。
首跑失误。 第一次运行漏掉了 ready to spec 标签——这个标签的含义是"issue 描述了一个真实问题，但 UI/UX 形态还没定型，值得先写成规格”。维护者发现后，直接在 issue 上留了一条评论，解释了期望行为以及原因。注意这里没有任何"提交反馈"的额外动作。
improver 接手。 运行在内部编排平台 Oz 上的 update triage agent 定时触发：认证 GitHub → 运行技能内置的 Python 脚本拉取近期带反馈的 issue → 汇总为 JSON 读入上下文 → 识别反馈信号，提出最小编辑——“当 issue 描述了真实问题但 UI/UX 形态未定时，应打上 ready to spec 标签”——然后自动开 PR 修改内层技能。
闭环完成。 PR 附带修改说明，人类审核合并。下一次分诊运行，新的知识已经在内层技能里生效。
（作者观点：这个案例里有两个容易被忽略的细节。其一，improver 输出的是最小编辑而非整段重写——这让 PR 的 diff 足够小，人类审查成本接近于零，闭环才转得快。其二，反馈发生在工作现场而非专门的反馈系统——维护者本来就要在 issue 上写评论，反馈只是顺路完成的。）
Warp 现在已经在整个开源仓库运行这个模式：规格撰写 agent、审查 agent、分诊 agent，各自携带独立的自我改进循环。
三、编写自我改进技能的六个实践
架构是骨架，技能的写法决定血肉。文章给出了六条实践建议：
1. 写原则而非规则。 像给聪明人下指令，而非给计算机编程。例如"寻找重复代码"远优于穷举每种命名规则——前者可以推理，后者只能背诵。Zach Lloyd 的原话是：
“构建技能时，要像在指导一个聪明人，而不是在给计算机编程。”
2. 解释为什么。 提供规则背后的理由，agent 才能推理泛化，而不是机械执行。一条有理由的规则在新场景下的表现，远好于十条没有理由的规则。
3. 让反馈零门槛。 在人们已有的工作流中捕获反馈——issue / PR 评论处就地给出，自动触发，无额外提交步骤。Zach Lloyd 对此的定性很直接：
“低摩擦是信号持续流动的关键。如果反馈太难给，你既收不到反馈，也无法改进技能。”
4. 保持技能小巧 + 渐进披露。 好的技能文件不大，需要时引用资源文件和脚本，而不是一次性把所有内容塞进上下文。技能是索引，不是百科全书。
5. 反馈质量 > 数量，但数量也有帮助。 资深工程师少量详细反馈的价值，远超大量"点赞"。但同时：
“即使样本量相对较小，只要是非常详细的、来自领域专家的反馈，就能获得极好的信号——这些知识 agent 本来无从获取。”
6. 在 improver 技能上多下功夫。 improver 是跨用例高度可复用的组件——写好一次，每个 agent 的自我改进循环都能用。它的投入回报超越任何单一 agent 的优化。
四、评测与安全网：假设反馈会出错
如果文章到案例为止，它只是一篇不错的教程。真正体现 Warp 工程成熟度的是后面的最佳实践问答——这一节回答的全是"闭环转起来之后会出什么问题"。
技能与记忆的区别？ 技能是程序性、稳定的——“如何做 X”，跨运行一致，任何变更都经过刻意的 PR 流程；记忆是推理时自动写入、持续变化的。这个区分决定了：需要长期稳定生效的知识进技能，临时性上下文进记忆，不能混。
一个 improver 还是多个？ Warp 的答案是折中：模板化的基础循环 + 领域定制层。一个 improver 管所有 agent 会失去领域精度，每个 agent 配一个又太重；少数 improver 各管一个领域，上百个 agent 则共享同一套 improver。
反馈是错的怎么办？ Warp 的态度是假设反馈会出错。不让 agent 盲目接受任何反馈，而是给它足够的上下文做合理性检查，过滤反馈来源，并在过滤或终审环节保留人类。这条原则是整个闭环不会"学坏"的根基。
领域能验证吗？ 能验证的领域（如代码任务），先建验证工具链：生成参考语料 → 对比输出与参考 → 修复 → 循环，让 agent 对着它调优——评测先行，改进才有标尺。
领域不可验证怎么办？ 尽可能用确定性评测对齐黄金输出；必须依赖人类反馈时，仅限领域专家，不开放全员。宁可信号少，不要噪声多。
如何确认整体在进步？ 不发明新指标，追踪人类本来就在看的全局指标——合并耗时、贡献者数量、成本——并把它们回灌给 improver agent，让系统自己感知自己是否在变好。部署上采用 crawl-walk-run（爬-走-跑） 渐进策略：小范围试点，扩大覆盖，再全面运行。
（作者观点：这一节比架构本身更值得抄走。架构只适用于"文件式技能"这个特定形态，但这组问答回答的是所有自我改进系统都会遇到的问题——反馈质量、评测可行性、全局可观测性。换任何一种 agent 改进机制，这五个问题的答案都直接可用。）
五、总结：从一次性助手到能力复利系统
回到文章的核心结论：任何 agent，无论任务是什么，只要从设计之初就内置这个循环——捕获人类反馈信号 → 转化为技能更新 → 经人工审核合并——就能随时间持续变好。
这个判断的分量在于它把 agent 的价值模型换掉了。没有自我改进循环的 agent 是一次性资产：上线即巅峰，之后随场景漂移缓慢贬值。有了闭环的 agent 是复利资产：每一次人类反馈都变成永久性的能力增量，而且这些增量以文件形式存在、以 PR 形式审查、以 git history 形式可审计——组织里最稀缺的专家经验，第一次有了一条不依赖"口口相传"的沉淀通道。
Warp 的实践还揭示了一个容易忽视的事实：这套机制的成本出奇地低。一个 Markdown 技能文件、一个定时 improver、一条人类已经走了几十年的 PR 流程，没有向量数据库，没有微调，没有新的基础设施。简单性不是妥协，而是这套方案能真正运转起来的原因。
（作者观点，也给读者一个行动建议：如果你已经在用 Claude Code 或类似的 agent 工作流，不必照搬 Warp 的全套架构。最小起步只需要两步——把你的 agent 规则整理成一个技能文件；再给它配一个定时 improver，拉取你对它的批评并转化为技能的 PR。闭环哪怕每周只转一圈，一年之后你的 agent 和今天也不会是同一个东西。）
「真诚赞赏，手留余香」
爱折腾的工程师
真诚赞赏，手留余香
使用微信扫描二维码完成支付
