自改进 Agent 回路
Warp 在 Claude Platform 上跑通并开源的 agent 改进模式（Warp - Self-Improving Agents on Claude）：把本会随 session 消失的人类反馈，变成经人工审核、随时间复利的知识更新。结构是两个 skill 夹着人类反馈：
inner/base skill（领域知识，随任务执行）
↓ 产出
agent 输出（code review / triage …）
↓ 就地反馈（what + why，零摩擦）
人类反馈累积
↓ 定时运行
outer/improver skill（观察者 agent）
↓ 提出"最小编辑"，开 PR
人审 → 合并 → 下次执行继承改进
为什么是 skill 文件
- 知识在文件里，不在 prompt 里：agent 干活时按需查阅——“encoding knowledge for agents without putting that knowledge directly in the prompt”。
- 纯文件所以 agent 极擅长改：更新是 reviewable / approvable / mergeable 的，走正常 PR / code-review 流程；人握着终审闸门。
- skill ≠ memory（Anthropic/Warp 判据）：skill 程序性、稳定、run 无关、刻意修改；memory 由 agent 推理时自动写、永不停歇。回路是把 memory 式的”越用越好”赋予程序性知识的机制。
写作心法
- 写原则不写规则：像教聪明人，不像编程——“look for repeated code” 好过穷举变量命名规则。
- 解释 why：给出理由让 agent 能推理和泛化，而非死板执行。
- 反馈零摩擦：就地给（PR / issue 评论），无额外提交步骤——“Low friction is what keeps signal flowing”。
- skill 保持小 + progressive disclosure：引用资源文件和脚本，不把一切倒进 context；skill 自带 Python 脚本拉反馈也是最佳实践。
- 反馈质量 > 数量，但数量有用：少量专家的详细反馈（讲清 what + why）胜过大量 👍/👎；优质语料库越大越好。
- improver skill 值得重投入：剥掉领域知识后跨场景高度可复用——code review 的 improver 和任何 agent 的 improver 差别不大。
Improver skill 怎么写
原文未给逐字模板，以下按 triage 实例 + 写作心法拼装。六步骨架：
- 拉反馈（确定性，不用模型）：运行 skill 自带的 Python 脚本认证 GitHub、拉取近期带人类评论的 issue/PR，汇总成 JSON——采集交给脚本，不靠模型每次现写。
- 读回上下文：JSON + 当前 base skill 文件一起读。
- 提取信号：对比”agent 当时建议了什么 vs 人类怎么回应”，抽出 what + why。
- 提出最小编辑：一次一批信号、一个小改动，不重写。
- 开 PR，描述即审计日志：写明哪些信号触发了什么改动——可追溯性内建在流程里。
- 停手：不合并，人审。
四个关键决策：
- 机制与领域知识分离（复用性的来源）：拉反馈 → 筛选 → 最小编辑 → 开 PR 这套流程写死成模板；仓库、标签语义、专家名单做成可替换的领域配置。几个 agent 各配一个 improver，一百个共享模板 + 领域权重。
- 内置防呆（反馈会错）：skill 写明筛选标准——反馈者在可信名单？与 base skill 既有原则冲突？与其他反馈矛盾？个案还是反复出现？矛盾/存疑的不编辑，列入 PR 请人裁决。
- 有 harness 就优先吃它：可验证领域先”参考语料 / 对比 / 修复 / 重复”，人类反馈退居次位；不可验证才用确定性 evals 对 golden outputs + 人类反馈只收专家。
- 全局指标回喂：time to merge / 贡献者数 / 成本也喂给 improver，防止回路只优化局部而系统整体变差。
伪模板：
# 目标
你是观察者，不干活；只改进 <base skill>。
# 步骤
1. 运行 ./collect_feedback.py → feedback.json（近 N 天带人类评论的 issue/PR）
2. 读 feedback.json + 当前 base skill
3. 每条反馈：提取 what+why → 筛选（可信名单？与既有原则冲突？
重复出现？）——矛盾/存疑的单独列出，不据此编辑
4. 通过筛选的信号 → 对 base skill 提出最小编辑（写原则不写规则，解释 why）
5. 开 PR：描述写明"信号 X → 改动 Y"；不合并运营要点
- 回路规模化的中间路线：模板化基础回路 + 领域权重叠加；几个 agent 各配一个 improver，一百个应共享。
- 假定反馈会错：不让 agent 盲收——给它上下文做 sanity-check、过滤谁的反馈算数、人工闸门设在过滤或终审环节。
- 验证优先于调优：领域可验证 → 先建 verification harness（参考语料 / 对比 / 修复 / 重复）再让 agent 对着调；不可验证 → 确定性 evals 对 golden outputs + 人类反馈只收领域专家。
- 全局指标回喂：用人类本来就在看的指标（time to merge、贡献者数、成本）判断整个系统是否在变好；部署走 crawl-walk-run。
- Warp 实例：GitHub issue 触发 triage agent（GitHub Action），漏打 “ready to spec” 标签 → 维护者在 issue 上就地反馈 → improver 定时跑在 Oz（Warp 编排平台）拉反馈、开最小 PR → 人审合并。spec / review / triage 三类 agent 各带回路，全开源仓库规模运行。
与已有页面的对偶
- Agentic Memory：memory 是陈述性知识跨 session 复利，本回路是程序性知识跨 run 复利；都靠”外部化到文件 + 显式流程”。
- LLM Wiki：形状同构——知识编译进文件、增量维护、改动可 review；wiki 的 lint ≈ improver 的定时运行。
- Agent Fleet 管理：人工闸门（money/send → 过滤/终审）与 counting test（全局指标）在两处同时出现。
来源与相关页面
- Warp - Self-Improving Agents on Claude（Anthropic 博客，2026-08-26）
- Agentic Memory · LLM Wiki · Agent Fleet 管理 · AI