2026 年 8 月 29 日,Anthropic 在 Hacker News 发布《Warp builds self-improving agents on Claude》,58 分上首页讨论,23 条评论。这是 Anthropic 官博首次详细披露一家 startup 如何用 Claude Platform 搭建会自己改进的 Agent——Warp(AI-powered terminal)CEO Zach Lloyd 和团队把 stateless 的用户反馈转化为 self-improvement loop,让 Agent 在每次任务后吸收人类反馈,通过 outer/improver skill 自动改写 inner/base skill 文件,改动走正常的 PR/code-review 流程 merge,下次跑任务时继承改进。结合 6 月 Anthropic 披露的《How we monitor internal coding agents for misalignment》以及同期 Decispher 的 LongMemEval 89% accuracy 数据,可以把 Harness 自进化机制在企业 Agent 落地的工程化新基线完整勾出来。Warp 的实践揭示了一个长期被忽视的事实——Agent 的能力不只来自模型,更来自 harness 里以 skill 文件形式存在的领域知识,而 skill 文件可以被设计成可演进的、可持续运营的产品形态。
一、Warp 的核心问题定义
Warp 团队在 Anthropic 博客里直接给出他们踩过的坑——Agent 处理 recurring 任务时,一个 first-pass prompt 即使 80% 正确,也会给用户制造 noisy and annoying 的体验。这种 noisy 不是模型问题,而是 Agent 系统设计问题:Agent 在每次 session 跑完就丢掉了反馈,不会从错误中学习,下次同一个任务会犯同样的错。
Warp 的具体例子是 internal code review agent。工程师反馈这个 agent 经常给出 unhelpful comments、产生低-quality 输出。Warp 团队最初尝试的解法都很局部——人工根据观察到的 code review 失败重写 prompt,提升 output usability 但不 scale;改进 AGENTS.md 之类的 context files 有帮助但远非 complete fix。最终他们意识到,核心问题在于 Agent 收到的反馈,无论用途如何,通常在 session 结束时消失,把 critical context 从 agentic loop 里拿走了。
这是企业 Agent 落地一个普遍而隐蔽的失败模式。Agent 在生产环境跑几周后,开发者会发现它的表现停留在初学水平,不会进步——因为每次任务结束,Agent 学到的经验、用户给的具体反馈、踩过的坑、修正过的行为,全部跟着 session 一起消失。下一个 session 的 Agent 是新的,没有上次经验,会犯同样的错。这条工程瓶颈在 LLM 时代被误以为是模型能力问题,实际上绝大多数情况下是 harness 设计问题——harness 没有持续吸收反馈的机制,模型再强也学不到任何东西。
二、Warp 的 inner/base + outer/improver 双 skill 架构
Warp 的解法是一个 file-based skills 框架,核心是两个 skill 加中间的人类反馈。
第一个 skill 是 inner/base skill,持有 functional domain knowledge 和 instructions。例如,当 PR 打开时,Warp 的 code agent 用 base skill 加 context 执行 code review,产出 review comments。这层 skill 是 procedural and stable——"如何做 X",run-agnostic,由人 deliberate change。base skill 文件不是很大,它引用 resource files 和 scripts 而不是把所有内容倒进 context——这是 progressive disclosure 的实践。
第二个 skill 是 outer/improver skill,作为 observer agent 在 schedule 上跑(而不是每个任务都跑),拉取 accumulated human feedback,对比 agent 建议和 human response,提出 small focused edit to base skill。因为 skill 是 plain files,agents 极擅长更新它们——这些更新是 reviewable, approvable, mergeable,可以走 normal PR/code-review workflow;一旦 merge,下次跑 inner skill 时继承改进。
这条架构的核心创新是把 skill 文件作为 Agent 能力的"可演化层",而不是静态 prompt。Agent 在每次任务执行完后,human feedback 通过 GitHub comment、issue 评论、PR 评论等低摩擦方式收集,outer improver agent 周期性把这些反馈转换成 base skill 的小改动,改动走 PR review,merge 后下次任务继承。整个 loop 是"feedback → skill update → PR → merge → inheritance",完全用企业现有的代码 review 基础设施,不引入新的 approval system。
Warp 把这个 pattern runs 在 spec-writing agents、review agents、triage agents 三个独立 Agent 上,每个都带自己的 self-improvement loop。每个 Agent 的 base skill 和 improver skill 是分开的,反馈信号是分开的,改进路径是独立的——一个 Agent 改进不会污染另一个。
三、Issue Triage Agent 的具体工作流
Warp 的 issue triage Agent 是 self-improving agent skills framework 的标准 demo。Pattern 在有人开新 GitHub issue 时触发:GitHub Action 触发一个 Agent,分析 issue 的复杂度和可行性,分配 label,推荐修复方向。Triage agent 用 base skill 加 context 跑。
真实例子——某个 issue 上,first-stage inner skill 做了一份 solid 工作但漏掉一个 label,ready to spec——这个 label 表明 contributor 可以开始写 product/technical specs。Warp 团队的 maintainer 在 issue 上直接 catch 了 gap 留 feedback——比如"You suggested renaming this variable, but our code base convention is this type of globbing"——这种具体反馈比 thumbs up/down 有用得多。
Outer improver skill 跑在 Oz(Warp 内部 agent orchestration platform)上,作为 scheduled "update triage" agent。Agent authenticate 到 GitHub,跑一个 Python script 拉取最近带 feedback 的 issues,总结成 JSON 读回 context。bundled script 本身是 best practice——skill 应该带 executable script 而不是依赖 Agent 自己写 code。
之后 Agent 识别 maintainer 评论里的具体反馈信号,提出能 capture 它们的最小 edit。它开 PR 编辑 inner skill,让 triage agent 在 issue 描述 real problem 时应用 "ready to spec" label,即使 issue 没有 explicit request。整次 update 是一个 skill file,它走 normal code-review workflow——PR 描述说明哪些 signals 触发了改动、改了什么,人 review、approve、merge,下次跑 triage skill 时继承改进。
这个工作流揭示了一个关键工程事实:Agent 的能力改进可以完全融入企业现有的软件工程流程,不需要专门的 Agent ops team、不需要新的 approval system、不需要新的监控工具。Skill 文件是普通代码文件,PR 是普通 PR,reviewer 是普通 reviewer,merge 触发 deployment 是普通 CI/CD。
四、Warp 提炼的 Best Practices
Warp 团队从自己的实践中提炼出六条 best practices,这些都对其他企业 Harness 自进化设计有借鉴价值。
第一条,write principles, not rules。"Construct the skill as though you're instructing a smart person, not like you're programming a computer," Zach Lloyd 解释,"Including direction in the skill like 'Look for repeated code' provides better direction than exhaustive variable naming rules."这条原则直指 LLM Agent 与传统程序员的根本差异——LLM 能做推理,可以用 high-level principle 引导;穷举 rule 反而限制 Agent 自主应对 edge case 的能力。
第二条,explain the why。给规则提供 rationale,让 Agent 能 reasoning about the problem 而不是 rigidly follow instructions。这条原则在 PR review 上是常识——给出 reasoning 比给命令更有效,迁移到 skill 文件同样成立。
第三条,make feedback effortless to give。在用户已经在工作的地方捕获反馈,比如直接在 PR 或 issue 上评论,还要自动捕获而不是额外步骤。"Low friction is what keeps signal flowing," Zach 强调,"If you make it too hard you're not going to get the feedback and your loop will be empty."这条原则是 self-improvement loop 成败的关键——feedback friction 太高,信号流就枯竭,improver skill 没东西可学。
第四条,keep skills small and use progressive disclosure。Skill 文件不要大,通过引用 resource files 和 scripts 保持 context 精简,而不是把所有内容倒进 context。这条原则与 Claude Prompt 工程的 best practice 一致——context 越精简,Agent 越聚焦核心任务。
第五条,feedback quality > volume, but volume helps。少量 domain-specific 反馈比大量 cursory 反馈更有价值,因为 binary thumbs up/down 没说 why。"You can get really good signal even from a relatively small sample size if it's very detailed feedback from a person around domain specific knowledge that the agent otherwise would have no way of getting," Zach 补充,"That said, the bigger the corpus of quality signal you have the better."这条原则给企业一个明确指引——不要追求反馈数量,要追求反馈深度。
第六条,put extra effort into the improver skill。Improver skill 写得好的回报远超单次 agent loop,因为 improver skill 在不同 use case 间非常 reusable。"Outside of the domain specific knowledge component, this is a fairly reusable mechanism," Zach 解释。把 engineering effort 集中在 improver skill 的设计、testing、verification 上,回报是跨所有 inner skill 复用的 infrastructure。
五、Skill 和 Memory 的本质区别
Warp 团队明确区分 skill 和 memory,这个区分对 Harness 自进化设计至关重要。
Skills 是 procedural and stable——"如何做 X",run-agnostic,被人 deliberate change。Skill 文件的改动是显式的、被审计的、走 PR review 的、merge 才生效。Skill 的演化是 deterministic 路径。
Memory 是 auto-written by the agent at inference time and never stops changing。Memory 在 Agent 每次推理时被写入,持续变化,没有 explicit review。Memory 的演化是非 deterministic 路径。
这个区分直接对应 OpenAI 内部 Coding Agent 监控实践——CoT 监控和 skill 监控是两类不同的工程。CoT 监控关注 Agent 在跑任务时的实时行为(类似 memory),skill 监控关注 Agent 用的知识是不是当前最优(类似 skill 的版本化和 PR 流程)。两者都不能少,但工程方法完全不同。
Anthropic 自己的内部 Coding Agent 监控是基于 CoT 和动作的实时审查,30 分钟内分类、评定严重等级。Warp 的 skill 改进是基于 PR review 的异步流程,改进周期可能是天或周。两个时间尺度的监控结合在一起,才是完整的 Harness 自进化体系——实时层面抓 alignment 异常,异步层面做 capability 持续提升。
六、企业 Harness 自进化的落地 checklist
把 Warp 的工程实践映射回企业落地,可以列出一份 Harness 自进化的具体 checklist。
第一条,任何 Agent 必须有 inner/base skill 文件,承载 domain knowledge 和 instructions。Skill 文件是 procedural and stable 的,不被 inference-time 修改。
第二条,任何 Agent 必须有 outer/improver skill,周期性拉 human feedback 转 small focused edit to base skill。Improver 走 schedule 而不是 per-task,避免增加 user latency。
第三条,human feedback 必须在用户已经在工作的地方捕获——PR 评论、issue 评论、task 评论——不允许额外的反馈提交步骤。Low friction 是 signal flowing 的前提。
第四条,skill update 必须走 PR/code-review workflow,reviewable、approvable、mergeable。Merged 之后下次跑 task 继承改进,不 merge 的改动不生效。
第五条,skill 文件必须 keep small,使用 progressive disclosure,引用 resource files 和 scripts 而不是把所有内容倒进 context。
第六条,improver skill 的工程 effort 必须 significant——设计、testing、verification 上花时间,因为 improver skill 跨多 inner skill reusable。
第七条,feedback quality 必须高于 feedback volume,鼓励 domain-specific 具体反馈,不要追求 binary thumbs up/down 的数量。
第八条,skill 写 principle 不写 rule,每条 principle 配 rationale,让 Agent 能 reasoning 而不是 rigidly follow。
第九条,skill 监控和 CoT 监控必须分开做。Skill 是文件级 PR review,CoT 是推理级实时审查,两者时间尺度不同,工程方法不同,不能合并到一个监控体系。
第十条,所有 skill 改动必须可回滚、可对比、可审计。Skill 是 Agent 能力的可演化层,改动记录是合规和调试的基础设施。
七、下一步:Harness 自进化成为标准能力
把这件事放到更大的图景里看,Harness 自进化正在从"创业公司的特殊实践"过渡到"标准能力"。早期 Agent 平台让用户写 prompt,prompt 不演化,Agent 表现永远停在初学水平;接下来一年内,主流 Harness 会把 skill + improver + PR workflow 作为出厂配置,任何不带自进化能力的 Agent 平台都会在企业市场被快速淘汰。
Anthropic 官博发 Warp 的故事不是偶然——这是 Anthropic 在告诉市场,Claude Platform 上的 Agent 自进化已经是 production-ready,任何客户都可以照搬 Warp 的架构。这种信号会让企业 IT 加速采纳自进化 Agent,因为 Anthropic 自己已经在 customer story 上证明了可行性。
回到一开始的问题——Warp 基于 Claude 搭建自进化 Agent,把"feedback → skill update → PR → merge → inheritance"这套 loop 第一次完整公开,加上 Decispher 的 LongMemEval 89% accuracy、Anthropic 自己的 internal monitor 实践,企业 Harness 自进化的工程化新基线已经被钉死。剩下的是企业 IT 在落地时把六条 best practices + 十条 checklist 都做对,把 Agent 从"一次性 helper"升级为"持续进化的系统"。这是 2026 年下半年 Harness 工程走向成熟的标志,也是企业 Agent 真正能承担关键业务的入场券。