Agents 编排与 Loop Engineering
本页由 [[wiki/concepts/Skills、Agents 与工具设计]] 拆分而来（2026-07-03），内容原样搬移。
Agents 正在从角色模板升级为协作单元
.claude/agents更像可复用角色模板，但 Agent Teams 已经把这种角色化推进成显式的”团队操作界面”，使委派、审批、显示模式和模型选择都更清楚。 [[raw/2026-04-02/方圆yo/claude code 中 .claude 文件夹详解.md|来源: .claude 文件夹详解]] [[raw/2026-04-27/DracoVibeCoding/Claude Code开启团战模式！你必须要用起来的Agent teams！.md|来源: Agent teams]]- 图像 Skill 与 GPT-image-2 的结合进一步证明：Skill 不只是文本工具，也能把外部模型 API 包成稳定工作流。 [[raw/2026-04-26/爱海贼的无处不在/我做了2个GPT-image-2生图Skills，帮助Agent实现生图，安装简单.md|来源: GPT-image-2 Skills]] [[raw/2026-04-25/袋鼠帝/GPT-Image-2 Skill + Hermes多Agent，才是画图的神～.md|来源: GPT-Image-2 + Hermes]]
Skills + SubAgent 的协同效应
- 多位作者独立验证同一结论：Skill 的渐进式披露与 SubAgent 的上下文隔离结合，产生 1+1>2 的效果。“Skills 的最佳使用场景其实是 Subagent。” [[raw/2026-05-09/潦草学者/用Kimi-K2+ClaudeCode做了条Agent流水线，节省90%的时间 - Subagent+Skills的最佳实践.md|来源: Subagent+Skills最佳实践]] [[raw/2026-05-09/宝玉/SubAgent 与 Skills：AI Agent 的两种扩展方式.md|来源: 两种扩展方式]]
- 宝玉给出精辟比喻：Skills = 安装进主系统的 app，按需加载；SubAgent = 独立运行的 VM，跑完返回干净结果。两者职责不同但互补。 [[raw/2026-05-09/宝玉/SubAgent 与 Skills：AI Agent 的两种扩展方式.md|来源: 两种扩展方式]]
- Subagents 支持 Async Agents（异步智能体）：Ctrl+B 后台运行，完成后回来查看——这是 Subagent 从不阻塞主流程的关键 UX 设计。[[raw/2026-06-16/扶苏/Claude Code 深度定制指南：CLAUDE.md、Commands、Skills 与 Subagents.md|来源: 扶苏 Async Agents]]
- 冒烟测试 Skill（subagent-smoke-test）可验证 Subagents 端到端工作流是否正常——在依赖 Subagent 的系统中，这是基础设施级的验证手段。[[raw/2026-06-16/扶苏/Claude Code 深度定制指南：CLAUDE.md、Commands、Skills 与 Subagents.md|来源: 扶苏 冒烟测试]]
三器合一：OpenSpec + Superpowers + gstack
- OpenSpec 管”做什么”（规范驱动）
- Superpowers 管”做得好”（流程治理）
- gstack 管”怎么做怎么发”（工具链与部署）
7 步完整流程只需 7 个命令，从需求到上线形成闭环。与上文 [[wiki/concepts/Skill 治理、进化与安全#Skills 已经进入流程治理层|Superpowers 流程治理]] 互补：三器合一把 OpenSpec 和 gstack 也纳入统一视图。
[[raw/2026-05-18/AgentBuff/三器合一：gstack + Superpowers + OpenSpec 工程化 AI 编程实战.md|来源: 三器合一]]
子代理 vs Agent Teams 选型
核心区分：
- 子代理（SubAgent）：fire-and-forget，隔离上下文、结束销毁、不互相通信
- Agent Teams：持续协作，长生命周期、对等通信、共享任务列表
核心原则：围绕上下文边界拆分，非角色拆分——按角色拆会导致”电话游戏”效应，信息在传递中逐层失真。这与上文 [[#Skills + SubAgent 的协同效应|Skills + SubAgent 协同]] 的结论一致：SubAgent 的价值在上下文隔离。
五种编排模式：prompt chaining / routing / parallelization / orchestrator-worker / evaluator-optimizer。
三种典型失败模式：任务描述不清、验证 agent 虚假通过、token 成本失控。
[[raw/2026-05-16/基咯咯/Claude 子代理 vs. Agent Teams：一文讲透.md|来源: 子代理vs Teams]]
Dynamic Workflows 与 Skill 的关系
Dynamic Workflows 的出现，重新定义了 Claude Code 编排体系中四个能力的定位：
| 形态 | 控制权 | 适合场景 | |
|---|---|---|---|
| Skill | SOP（确定性经验） | 模型自动触发 | 重复出现的固定流程 |
| Subagent | 跑腿（派完不管） | 主Agent委派 | 探索/验证/隔离任务 |
| Agent Teams | 打团战（涌现式） | 模型间自协调 | 多视角协作/互相校验 |
| Workflows | 自动化工厂（代码驱动） | 开发者写死流程 | 大规模并行/机械性任务 |
核心关系：Skill/Suagent/Agent Teams 都依赖模型做决策；Workflows 是代码做决策。这对 Skill 设计的影响是：当一个 Skill 的核心流程足够稳定，可以考虑将其沉淀为 Workflow 脚本——从概率经验升级为确定性流水线。 详见 [[Claude Code#Dynamic Workflows]]
六种编排模式（2026-06 新增）
Dynamic Workflows 提供的六种编排模式解决 Agent 编程中的三个核心问题：Agentic laziness（偷懒）、Self-preferential bias（自我偏好）、Goal drift（目标漂移）。[[raw/2026-06-14/金色传说大聪明/深入理解 Claude Code：从 CLAUDE.md 到 Hooks、Skills、Subagents.md|来源: 金色传说大聪明 编排模式]]
| 模式 | 适用场景 | 核心机制 |
|---|---|---|
| Classify-and-act | 路由式任务 | 先分类再执行 |
| Fan-out-and-synthesize | 多渠道研究 | 并行探索后综合 |
| Adversarial verification | 质量敏感任务 | 一个做、一个查 |
| Tournament | 多方案选优 | 多路并进，选最优 |
| Generate-and-filter | 内容生产型 | 先宽松生成再严格过滤 |
| Loop until done | 持续改进型 | 循环直到验收通过 |
反向用法：从历史 session 挖掘规则候选，对抗验证后写进 CLAUDE.md——这是 Dynamic Workflows 的新颖用法，把编排能力用于知识提炼而非执行力。[[raw/2026-06-14/金色传说大聪明/深入理解 Claude Code：从 CLAUDE.md 到 Hooks、Skills、Subagents.md|来源: 金色传说大聪明 反向用法]]
[[raw/2026-05-30/Claude Dynamic Workflows解析,迎接全新的AI编程生态.md|来源: Workflows 四象限]]
Loop Engineering：第四次抽象跃迁及其对 Skill/工具设计的启示
梦朝思夕在 6 月发表的《万字长文 - 带你由浅入深了解 Loop Engineering》中提出：Agent 编程经历了 Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering 四次抽象跃迁。Loop Engineering 不是 Harness 的子集——Harness 是脚本思维（“你设定规则，AI 照着执行”），Loop 是系统思维（“你设计环境，AI 在其中自主循环”）。[[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md|来源: 梦朝思夕 Loop Engineering]]
矛盾：Harness Engineering 是 Agent 编程的最终范式（现有 wiki 将 Harness 定位为第三次跃迁的终点） vs Loop Engineering 是 Harness 之后的第四次跃迁——Harness 是脚本思维，Loop 是系统思维 来自 [[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md|来源: 梦朝思夕 Harness vs Loop]]
五要素（+1）模型
Loop 系统由五个核心要素外加第六要素 Memory 构成：[[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md|来源: 梦朝思夕 五要素]]
| 要素 | 角色 | 对 Skill/工具设计的启示 |
|---|---|---|
| Automations | 启动触发器 | Skill 的激活不应只靠 description 匹配，还应能通过外部事件（定时、Git 事件、文件变化）触发 |
| Worktrees | 执行隔离 | Worktree 不仅是并行工具，更是 Loop 的基础隔离原语——每个循环在隔离环境中运行 |
| Skills | 知识固化 | Skills 是 Loop 中的”能力单元”，Loop 是在 Skills 之上编排执行周期 |
| Connectors | 行动能力 | MCP/CLI/API 是 Loop 的对外接口，决定 Agent 能做什么而不是会做什么 |
| Sub-agents | 质检 | Sub-agents 是 Loop 中的独立验证节点——从独立视角校验结果而非替主 Agent 干活 |
| Memory | 跨循环持久化 | Skills 的 config.json 跨会话记忆、边车文件统计、复盘日志——Memory 是 Loop 区别于单次执行的根本 |
六组件解剖
每个 Loop 系统从技术组件角度由六部分组成，对应 Skill/工具设计的核心维度：[[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md|来源: 梦朝思夕 六组件]]
- Goal（目标定义）：目标 + 范围 + 禁止 + 验证 + 停止条件。Wise Wong 验证的 Goal 四要素与 Anthropic 的 /goal 三要素互补。
- Tools（工具集）：Agent 可调用的全部工具。工具设计决定 Loop 的行动边界——给错工具等于设计错 Loop。
- Context（上下文管理）：上下文窗口是 Loop 的通用瓶颈——Sub-agent 隔离、Dev Docs 交接、结构化压缩、15% 阈值管理都在不同层面管理同一个约束。
- Termination（终止逻辑）：Loop 必须知道什么时候停。stop 条件（验证通过）、max 次数（预算上限）、timeout（超时兜底）三层终止机制。
- Error Recovery（错误恢复）：Loop 中错误的处理策略——重试（Retry）、降级（Degrade）、上报（Escalate）。扶苏的 <=5 错误自动修复 vs >=5 升级正是这一组件的工程实现。
- Guardrails（护栏）：资源类焊死 + 认知类可插拔。护栏不是限制 Loop，而是定义 Loop 的安全运行边界。
四种 Loop 模式与陷阱
| 模式 | 适用场景 | 核心陷阱 |
|---|---|---|
| Retry Loop | 不稳定网络/API 调用 | 无限重试耗尽成本，Loop 应设 max retries |
| Plan-Execute-Verify | 长任务执行 | Plan drift（计划漂移），需支持计划版本化和差异比较 |
| Explore-Narrow | 探索型任务 | 搜索空间爆炸，需设搜索深度限制和边界割草 |
| Human-in-the-Loop | 高风险决策 | 人类疲劳导致假确认，关键决策点应阻塞等待而非异步确认 |
所有 Loop 陷阱的共同根源：Loop 在没有人类判断的情况下做了不该做的事。 工程化的核心不是消除人工介入，而是在正确环节设计正确的人工介入点。[[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md|来源: 梦朝思夕 四种模式]]
三大风险框架
梦朝思夕提出的三大风险是对 Skill 设计中”验证信任危机”的理论扩展：[[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md|来源: 梦朝思夕 三大风险]]
- Comprehension Debt（理解债务）：Agent 输出超出人类理解能力，无法 review 或维护。对应设计：每次迭代都产出可审查的中间产物，而非一次性大黑盒输出。
- Cognitive Surrender（认知投降）：团队放弃理解 Agent 运行逻辑，完全信任自动输出。对应设计：关键决策点应强制人工确认（HITL），阻止”自动驾驶”惯性。
- Verification Gap（验证缺口）：没有与输出质量匹配的验证手段。对应设计：每个 Skill 应自带验证步骤——没有验证的 Skill 只是半成品。
辩论对抗拓扑的失效模式
多 Agent 协作中辩论对抗被广泛认为是提升质量的方案，但梦朝思夕揭示了一个关键失效模式：两个 Agent 互相说服对方接受错误结论——即”双重确认偏误”。当双方持有相似的认知偏差，辩论不仅不会纠正错误，反而会强化错误。这意味着多 Agent 协作需要独立的”真理源”（事实性知识库、确定性校验工具）作为仲裁者，而非单纯依赖 Agent 间的辩论。[[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md|来源: 梦朝思夕 辩论失效]]
Loop 成本公式
实际月成本 = 基础成本 × Thrashing 系数。Thrashing 系数（循环反复、推倒重来）是成本最大变量——一个 Thrashing 严重的 Loop 可能比无 Loop 更昂贵。试点阶段应聚焦降低 Thrashing，规模化阶段再优化基础成本。[[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md|来源: 梦朝思夕 成本公式]]
Claude Code / Codex / OpenCode 三款工具的 Loop 维度对比
梦朝思夕提供了三款主流 Agent CLI 工具在 Loop 维度上的横向对比：[[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md|来源: 梦朝思夕 工具对比]]
| 维度 | Claude Code | Codex | OpenCode |
|---|---|---|---|
| Automations | /loop 命令 | /goal 命令 | —agent 参数 |
| Worktrees | 原生支持 | 原生支持 | 不直接支持 |
| Skills | 官方生态 | OpenAI MCP | tool 配置 |
| Connectors | MCP 协议 | MCP 协议 | Google ADK |
| Sub-agents | 原生 Subagent | Agent Teams | agent 嵌套 |
| Memory | config.json | —resume | 文件持久化 |
| Loop 开箱度 | 最高 | 中 | 低 |