八月二十六日，Claude 博客写了一家终端公司怎么把“用户骂得对”变成可合并的代码。How Warp builds self-improving agents on Claude 给出的增长数字很响——融资 7300 万美元、月活开发者 80 万、财富 500 强渗透 56%、Warp 内 Claude Code 会话累计 1000 万且每周 40 万+、Warp Agent 对话总量 4000 万——但真正值钱的不是海报，而是那套两层 skill 循环。
问题很具体：一次性提示词做到 80 分，会给用户留下嘈杂体验。Warp 用“内层基座 skill + 外层改进 skill + 人在现场的反馈 → 对 skill 文件开 PR”来回答。
[1]两层 skill 怎么转起来
官方描述的基座 skill 装着领域知识与指令。例如开 PR 时，代码审查代理靠它产出评论。人的反馈可以是简单点赞，更好是写清“为什么这条重命名不符合我们的全局变量命名约定”。
外层 improver 不当场跟任务跑，而是按调度观察：拉取积累的人类反馈，对照代理当初建议与人类反应，提出对基座 skill 的小而聚焦的修改。因为 skill 是普通文件，代理极擅长改它；改动走正常 PR/代码审查，合并后下一次内层运行自动继承。
Issue triage 是样例：新 GitHub issue 触发 Action，代理分析复杂度与可行性、打标签、建议修复方向。内层 skill 定义每个标签含义与调研方式。一次样本里它漏了 ready to spec——表示可以开始写产品与技术规格。维护者直接在 issue 里写清期望与理由；Oz（Warp 编排平台）上的定时“update triage”代理鉴权 GitHub、跑 skill 附带的 Python 脚本拉反馈、汇总成 JSON 再读回上下文，最终把补丁提成对 skill 文件的 PR。Warp 说这套模式已铺到开源仓库的规格撰写、审查与分诊代理。
为什么“文件化 skill”比加长提示词狠
作者判断：关键不在 Claude 更聪明，而在把改进从会话内存里捞出来，落进可 diff、可回滚、可评审的工件。提示词再长，也难让组织形成共同记忆；skill 文件一旦进 Git，代理改进就与人类工程文化对齐。
捆绑脚本而不是每次现场写代码，也是实用细节——减少跑偏，提高可复现。对做 Agent 产品的团队，这几乎是在说：别只做聊天包装，去做“反馈→工件→合并”的闭环。
[1]对开发者工具战局意味着什么
Warp 把自己摆在 AI 终端 / agentic IDE 赛道，底座是 Claude Platform。数字证明分发已成；自我改进循环想证明的是留存与质量斜率。对 Anthropic，这是客户故事：Claude 不只写代码，还参与客户自己的 agent 操作系统。
对其他编程代理（Cursor、Cognition、OpenHands 等），可比的不是谁更能聊，而是谁先把用户纠正沉淀成可版本化策略。局限也清楚：博客是客户案例，缺少公开的前后对照准确率；反馈质量决定上限；PR 合并仍是人闸。
[1]评论员看法
我喜欢这篇，是因为它把“Agent 会学习”从神话拉回了工程：学习发生在 Git，而不是发生在玄学记忆里。ready to spec 这种漏标，恰恰说明第一版 skill 会错；有价值的是错能被写进下一版文件。
风险在于把所有产品改进都外包成“再跑一轮 improver”——若人类反馈稀疏或充满情绪，skill 会漂移。六个到十二个月，我会盯 Warp 是否公开前后指标，以及其他厂商是否抄这套“外层观察者 + skill PR”的骨架。
[1]