在真实的生产级开源仓库里，新 Issue 每天涌入。Agent 被寄予厚望去做第一轮分类——ready-to-implement、duplicate、needs-info——可现实往往是：它把需要更多环境细节的 issue 直接标成了 ready-to-implement。维护者手动改标签、写评论解释原因。第二天类似 issue 再来，Agent 依然犯同样的错。技能文件没有记住这些修正，维护者陷入反复手动兜底的循环。

这不是 Agent “不够聪明”，而是执行与进化被混在同一个静态提示里。Warp 团队在管理自身开源仓库时，把这个问题拆成了两个可独立运行、可相互喂养的闭环：内循环负责当下执行，外循环负责基于真实反馈进化技能。他们把这个模式提取出来，让别人也能复用。

为什么把执行和进化拆开，才是可持续的解法

我起初以为，只要把 triage prompt 写得再详细、再加几条规则，就能覆盖所有边界。后来看到他们把核心契约（输出 schema、保留标签规则、安全约束）锁死在共享 skill 里，只允许本地 companion 文件被外循环修改，才明白：技能的进化必须像代码 Review 一样，有明确的修改边界和审计路径，否则一次坏的更新就会污染整个系统。

这就像一支职业球队。场上球员执行战术（内循环），教练组赛后复盘录像、更新战术手册（外循环）。球员再有天赋，没有复盘机制也只能靠个人经验慢慢试错；有了系统复盘，手册里的每一条调整都能被下一场比赛直接继承。Agent 的技能文件（.agents/skills/xxx/SKILL.md）就是那本可版本控制的战术手册。

另一个更贴近工程的类比是工厂 SOP。工人严格按最新 SOP 操作（内循环），质量部门收集异常报告后修订 SOP（外循环）。新员工入职直接用修订后的版本，而不是靠老员工口口相传。双循环把“个人经验”变成了“组织资产”。

内循环：把 triage 变成可重复、可观测的生产动作

内循环的核心是：每当新 Issue 出现，就用当前最新版本的技能去处理，并把完整交互记录下来。

典型实现（以 GitHub + Oz 云 Agent 为例）：

# .github/workflows/oz-issue-triage.yml（简化示意）
on:
  issues:
    types: [opened, reopened, edited]
jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      - name: Run Oz triage agent
        uses: warpdotdev/oz-agent-action@vX
        with:
          skill: triage-issue          # 核心共享技能（不可被外循环随意修改）
          local-skill: triage-issue-local  # 仓库专属可进化部分
          # 传入 issue 内容、仓库 config、历史上下文等

Agent 执行后会输出结构化结果（triage_result.json），包含：

• 标签集合（严格遵守保留标签规则）
• 可复现性评估
• 最可能根因（带证据）
• follow_up_questions（最多 5 个，且必须是只有 reporter 才能回答的）
• duplicate_of（与已有 issue 的关联）
• issue_body（要发在 issue 下的 Markdown 总结）

整个过程不直接修改仓库，只通过标签和评论与人类交互。所有运行轨迹都被记录（文件、agent trace 或外部系统），为外循环提供“训练数据”。

外循环：把人类修正变成可合并的 diff

外循环通常按日程（或事件触发）运行。它不执行 triage，而是观察内循环产生的所有反馈。

具体流程（基于 Warp 团队的 update-triage 模式重构）：

1. 聚合过去 7 天（或自定义窗口）被人类修正过的 issue（标签改动 + 评论中的明确理由）。
2. 识别可复用的模式：反复把某类 issue 从 ready-to-implement 改成 needs-info、特定 owner 分配规律、 recurring follow-up 问题等。
3. 只对可覆盖类别提出最小 diff：
   • 仓库专属的 triage-issue-local/SKILL.md（启发式、follow-up 模式、duplicate 聚类等）
   • .github/issue-triage/config.json（仅标签 taxonomy）
4. 严格禁止触碰核心 triage-issue/SKILL.md 的输出 schema、保留标签规则和安全约束。
5. 生成 PR，人类 review 后合并。合并即完成技能升级，下一次内循环自动使用新版本。

整个过程像一次“代码 Review + 最小变更原则”：只改该改的，只因为有重复信号才改，避免把一次性噪音固化成规则。

<!-- update-triage 技能的简化决策逻辑（中文注释） -->
- 读取 feedback.json（聚合脚本产出）
- 检测重复模式（同一类 mis-triage 出现 ≥2 次且有明确理由）
- 仅修改 overridable 部分：
  - label taxonomy 描述
  - repo-specific follow-up 模式
  - issue-shape 启发式
- 生成最小 patch，验证后开 PR
- 禁止：修改核心 schema、弱化保留标签、把 reporter 个人内容写成通用规则

双循环 vs 传统静态方案对比

为什么这个模式值得在更多场景复制

把技能当成“可 diff 的文件”而非“黑盒提示词”，是整个方法论的底层杠杆。它让 Agent 从“每次都要重新教”的工具，变成了“能记住教训并主动进化”的队友。

在 Warp 团队的实践中，这个双循环已经被用于管理他们自己的开源仓库，也被提取成可复用的框架（oz-for-oss 相关 workflows 与 skills）。当你有清晰的目标（比如“把 needs-info 比例降到 X% 以下”），甚至可以把外循环里的“人类 reviewer”替换成自动 grader，进一步降低人力依赖。

当然，这套系统也对基础设施有要求：可靠的反馈收集通道、版本控制的 skill 文件、以及最终的 eval 机制（Zach 本人在回复中也提到，下一步会补充 eval 部分）。没有 eval，就无法判断一次 skill 更新是真正进步还是引入了新问题。

在你的系统里，第一个外循环该从哪里开始？

如果你已经在用 Agent 处理 Issue、Code Review、Incident Response 等重复性任务，那么你手里其实已经积累了最宝贵的资源——人类修正的轨迹。把这些轨迹结构化、喂给外循环，让技能像代码一样被 Review、被合并、被版本化，这就是把一次性实验变成长期生产力的关键一步。

你目前在哪个具体场景里积累了可复用的反馈数据？第一个值得构建外循环的技能，会是 triage、review，还是其他？

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。