Warp 到底构建了什么
Warp 是一个基于 Claude 平台构建的 AI 驱动终端和 Agent 开发环境。规模数据：融资 7300 万美元，月活开发者 80 万，覆盖 56% 的《财富》500 强企业，4000 万次 Warp Agent 对话，以及一个惊人的数字——“迄今为止在 Warp 内部运行了 1000 万次 Claude Code 会话，每周超过 40 万次”。
问题在于一个不受欢迎的内部 Agent
Warp 的代码审查 Agent 让自己的工程师感到恼火。他们“抱怨说他们的 Agent 发表了无用的评论，并产生了低质量的输出”。文章清晰地阐述了这种普遍现象：“一个能正确完成 80% 任务的首版提示词，可能会给用户带来嘈杂且令人恼火的体验。”
首先尝试了两种权宜之计，这也是大多数团队都会尝试的方法。在每次观察到失败后手动重写提示词“使输出更可用，但无法扩展”。改进诸如 AGENTS.md 之类的上下文文件“也有所帮助，但远非完整的解决方案”。关于这种瓶颈的普遍版本，在为什么 Agent 会忽略你编写的指令文件中有所讨论。
内部技能保存知识
基础技能“保存了功能性的领域知识和指令”。当一个 PR（拉取请求）开启时，Warp 的代码 Agent 会针对该技能运行并生成其审查意见。
Warp 的创始人 Zach Lloyd 描述了为什么文件形式如此重要：“基于文件的技能是一种为 Agent 编码知识的方法，而无需将这些知识直接放入提示词中，作为 Agent 在执行任务过程中可以简单查找的内容。”
改进者技能是观察者，而非参与者
这是让循环发挥作用的部分，而调度细节很容易被忽略。外部技能“充当观察者 Agent，按计划运行，而不是按任务运行。它拉取累积的人类反馈，将 Agent 的建议与人类的反应进行对比，并对基础技能提出一个微小、专注的修改建议。”
不是按任务运行。而是按计划运行。这是一个查看语料库的独立作业，而不是附加在每次运行上的反思步骤。
它需要人类提供具体的信息。Lloyd 的例子：“人类可以肯定，‘这是一个很好、很有用的评论’。但人类也可以给出为什么代码审查不好的详细原因。诸如‘你建议重命名这个变量，但我们的代码库约定是这种类型的全局变量使用这个特定的命名上下文’之类的细节，会告诉 Agent 下次如何做对。”
循环通过代码审查闭环
正是这个特性让它不仅仅是一个聪明的小把戏：“因为技能是纯文本文件，所以 Agent 非常擅长更新它们。这些可审查、可批准和可合并的更新可以通过正常的 PR/代码审查工作流进行；一旦合并，内部技能的下一次运行就会继承这一改进。”
Warp 的问题分类 Agent 完整地展示了这一过程。一个 GitHub Action 触发一个 Agent，该 Agent 分析新问题的复杂性和可行性，分配标签并建议方向。在某一个问题上，它漏掉了 ready to spec 标签。一位维护者在问题本身上留下了反馈——“正是工作发生的地方”——解释了他期望什么以及为什么。
然后，改进者在 Warp 的 Agent 编排平台 Oz 中作为计划好的“更新分类”Agent 运行。它向 GitHub 进行身份验证，运行与技能绑定的 Python 脚本以拉取最近带有反馈的问题，将它们总结为一个 JSON 文件，并将其读回上下文。然后，它“开启了一个编辑内部技能的 PR，以便在问题描述了真实问题但具体的 UI 或 UX 形式尚未定义时，应用 ‘ready to spec’ 标签。”
然后由人来合并它。Anthropic 对这一步骤的定义是：“最后的人类步骤闭合了循环，并让人们控制实际发生的变化。”
Warp 现在在其整个开源仓库中运行这一机制，独立的规格编写、审查和分类 Agent 各自携带自己的循环——“数百人参与贡献，我们正在进行数千次代码审查。”
这确立了什么，又没有确立什么
这种模式令人信服。但其证据是一个厂商案例研究，因此有必要精确区分其差异。
未提供对比数据。 文章没有报告在审查质量、分类准确性或投诉量方面有任何可衡量的改进。令人印象深刻的数据——80 万开发者、1000 万次 Claude Code 会话——描述的是 Warp 的业务，而不是该循环的效果大小。这里没有任何内容可以量化 Agent 变得有多好。
Warp 对此装备异常精良。 一个拥有数百名贡献者且已经留下 PR 评论的公共仓库，是大多数团队所不具备的反馈语料库。Oz 是一个用于计划 Agent 的内部编排平台。去掉其中任何一个，该循环都需要用你构建的东西来替换。
选择的领域是友好的。 代码审查和问题分类具有现有的审查仪式和大致可检查的输出。Warp 自己的指南直接承认了困难的情况，建议你询问“你的领域是否可验证？”，如果不可验证，则“在存在黄金输出的地方，依赖确定性的评估”。
这不是自主的自我改进。 每一次更改都是由人类合并的 PR。“自我改进”描述的是建议的来源，而不是由谁来决定。
Warp 假设反馈有时会是错的。 他们的回答（完整引用，因为这是文章中最有用的一行）：“假设它会是错的。不要让 Agent 盲目接受反馈——给它上下文进行安全检查，过滤谁的输入有效，并在过滤或最终审查阶段保留人类参与。”
这是一个程序性循环，而不是记忆系统。 这一点非常重要，以至于 Anthropic 将其放在了文章自身 FAQ 的第一条，标题为“你是否将技能与记忆混为一谈？”。其回答是：“技能是程序性的且稳定的——‘如何做 X’，与运行无关，是刻意更改的。记忆是 Agent 在推理时自动写入的，并且永远不会停止变化。”
这就是我们在为什么 Agent 技能不是记忆中所论证的相同区别，由厂商亲自阐明。这在这里很重要，因为它告诉了你循环改进了什么：Agent 如何执行任务。而不是它对你的项目了解多少。
人们会从中吸取什么，以及不应该吸取什么
“技能现在就是记忆了。” 文章在标题中说了相反的话。技能是你有意更改的稳定程序；记忆是在推理时写入的，永远不会停止变化。Warp 的循环使程序得以改进——通过审查，刻意为之。
“Agent 会自我改进。” 人类合并每一次更改。去掉这一步，你就会得到一个在无人监管的情况下编辑自己指令的 Agent，这是一个不同且更糟糕的系统。
“只需两个文件。” 你还需要一个反馈落地的场所、一个调度器，以及将语料库拉入上下文的工具——在 Warp 的案例中是一个 GitHub Action、Oz 和一个绑定的 Python 脚本。
“反馈越多越好。” Warp 的立场是质量第一：“即使样本量相对较小，如果它是来自人类关于领域特定知识的非常详细的反馈，你也能获得非常好信号，否则 Agent 将无法获得这些知识。”对于不可验证的领域，“将其限制在领域专家范围内——不要打开闸门。”
“这取代了记录。” 它使记录工业化。改进者的全部工作就是将反馈转化为持久的文件。
解决方案：给循环提供除评论线程之外的可读内容
当你尝试在 Warp 的设置之外复制这一点时，会出现两个差距，而且这两个差距都与语料库有关，而不是与技能有关。
第一点是，改进者只能根据它能触及的反馈进行工作。Warp 的反馈存在于 PR 评论中，因为那是他们工作发生的地方。如果你的纠正意见落在 Slack 线程、审查会议和某人的脑海中，那么计划好的作业就无处可拉取。
第二点是厂商自身区别所指向的。技能保存程序。对于纠正通常包含的事实——为什么存在该约定、你已经尝试过什么、哪种约束使得显而易见的答案出错——它们是错误的容器。Warp 的纠正示例包含了这三者：命名约定、它适用的类别以及原因。程序进入技能。原因却无处可去。
这就是 MemoryLake 所保存的内容：你项目的持久事实存在于你的 Agent 查询的层中，因此程序性知识和事实性知识不再为同一个文件而竞争。设置分为三个步骤。
步骤 1：创建 API 密钥
登录并创建 API 密钥。一个凭据即可跨越你连接的所有工具。
步骤 2：上传你的第一批记忆
简短的条目，每条包含一个断言。你已经给出的纠正是最好的源材料：
约定加上原因。 “全局配置值使用 CFG_ 前缀，因为加载器在启动时会对其进行 grep。”规则可以存在于技能中。原因可以防止规则被还原。
在此处已被拒绝的方法。 未出现在任何技能文件和提交消息中，但在每个新会话中都会被重新提出的类别。
你给出过不止一次的纠正。 如果你已经说过两次，它就是关于你项目的事实，而不是关于该任务的偏好。
没有任何声明的环境约束。 仅在 CI 中失败的测试、未记录的速率限制、两个作业之间的顺序依赖关系。
步骤 3：连接你的 AI 和 Agent
MemoryLake 可通过 MCP 和 API 访问，因此 MCP 原生 Agent（包括 Claude、Claude Code、Codex 和 OpenClaw）通过指向 MCP 服务器进行连接，而其他助手则通过 API 读取相同的记忆。改进者风格的作业可以在提出更改建议之前查询它以获取上下文，这正是 Warp 推荐的安全检查。
三个诚实的限制，其中第一个在这里最重要。这不是循环的替代品。 Anthropic 的区别是双向的：记忆层不保存程序，而技能不保存事实。如果你想让你的 Agent 在任务上表现得更好，请构建循环——Warp 的设计很好，PR 审查步骤是记忆层所不具备的真正优势。MemoryLake 不会编写你的技能文件，也无法查看你的 Agent 运行情况。而且它只保存你或你的 Agent 放入其中的内容，因此步骤 2 是刻意为之的。
这在实践中改变了什么
反馈不再是一次性的。 评论变成了文件编辑，而不是某人滚屏忽略的消息。
改进以拉取请求（PR）的形式呈现。 可审查、可还原、可追溯——这比大多数 Agent 微调提供的内容都要多。
“解释原因”成为一种工作习惯。 Warp 关于编写原则而非规则的建议，只有在记录了原因的情况下才能发挥作用。
改进者变得可重用。 用 Lloyd 的话说，“代码审查 Agent 的改进者技能与任何其他 Agent 的改进者技能没有太大区别。”
技能刻意保持精简。 渐进式披露和绑定的资源文件，而不是一个不断增长的文档——这与编码 Agent 实际上在阅读什么中所描述的压力相同。
事实与程序不再冲突。 技能说明如何做；其他东西保存为什么。
构建此类反馈循环的最佳实践
选择一个具有现有审查仪式的领域。 代码审查和分类之所以有效，是因为本来就会有人去查看。
在工作发生的地方捕获反馈。 Warp 的规则：“低摩擦是保持信号流动的关键。”
坚持探究原因，而不仅仅是结论。 点踩并不能说明要改变什么。Warp 自己的纠正示例只有一句话，却包含了一条规则、一个类别和一个原因。
计划运行改进者，而不是按任务运行。 它需要一个语料库来进行对比，而不是单次交互。
保留人类进行合并。 这是让整个过程安全运行的步骤。
假设某些反馈是错的。 过滤谁的输入有效，并给 Agent 上下文进行安全检查。
编写原则，而非规则。 “构建技能时，就像你在指导一个聪明的人，而不是在给计算机编程。”
如果你的领域允许，先构建验证套件。 然后让 Agent 针对它进行调整。
不要将事实放入技能文件中。 程序是稳定且刻意的；事实会累积和变化——保持低价值事实处于活跃状态的成本在保留评分记忆树所展示的内容中有所衡量。
结论
Warp 的模式是近来发布的关于自我改进 Agent 最实用的东西，主要是因为它在合适的地方显得“枯燥”。内部技能保存领域知识。外部技能按计划运行，读取累积的人类反馈，将 Agent 的建议与人类的实际需求进行对比，并开启一个编辑内部技能的拉取请求（PR）。由人来合并它。下一次运行就会继承这一更改。
让它具有可信度的是，没有任何东西依赖于模型的改进。技能是纯文本文件，Agent 擅长编辑纯文本文件，而拉取请求已经围绕它们建立了审查文化。让你保持清醒的是，没有公布对比数据，Warp 为该问题带来了庞大的反馈语料库和内部调度器，并且他们自己的指南告诉你，要假设反馈有时会是错的。
并记住文章在其 FAQ 开头所作的区别。技能是程序性的、稳定的，且是刻意更改的；记忆是在推理时写入的，永远不会停止变化。反馈循环让你的 Agent 更好地完成工作。它不会让它记住你的项目。你两者都需要，但要放在不同的容器中——而最快的开始方式是让你下一次的纠正包含原因，这样以后无论什么读取它，都有值得保留的东西。