vault: add ECC v2.0 orch-* family + team orchestration notes
This commit is contained in:
Yaojia Wang
134
1 - Inbox/Agentic Design Patterns：一本让我重新理解"Agent 到底是什么"的书.md
Normal file
134
1 - Inbox/Agentic Design Patterns：一本让我重新理解"Agent 到底是什么"的书.md
Normal file
@@ -0,0 +1,134 @@
|
||||
---
|
||||
title: "Agentic Design Patterns：一本让我重新理解\"Agent 到底是什么\"的书"
|
||||
source: "https://x.com/yanhua1010/article/2058552177912947044"
|
||||
author:
|
||||
- "[[Yanhua (@yanhua1010)]]"
|
||||
published: 2026-05-24
|
||||
created: 2026-05-25
|
||||
description: "Antonio Gullí 是 Google 的工程总监。他写了本 453 页的书，把 AI Agent 开发拆成了 21 种设计模式。但这不是一篇书评。我读这本书的动机很具体：我写过 Harness Engineering，写过 Clawdbot 的踩坑经验，写过\"AI 智能体..."
|
||||
tags:
|
||||
- "clippings"
|
||||
---
|
||||
|
||||
|
||||
Antonio Gullí 是 Google 的工程总监。他写了本 453 页的书，把 AI Agent 开发拆成了 21 种设计模式。
|
||||
|
||||
但这不是一篇书评。我读这本书的动机很具体：我写过 Harness Engineering，写过 Clawdbot 的踩坑经验，写过"AI 智能体不是魔法"那篇从烧 Token 到真正好用的七个转折，每次写完之后都有一个没完全想透的问题：**这些东西背后有没有一套可以复用的底层逻辑？**
|
||||
|
||||
这本书给了我答案，而且比我想的更深。
|
||||
|
||||
## 你写的可能根本不是 Agent
|
||||
|
||||
书里最狠的判断藏在 prologue 里。
|
||||
|
||||
大多数人在用的"AI"，只是 Level 0：裸 LLM，没有工具、没有记忆、不会行动。你问它 2025 年奥斯卡最佳影片是哪部，它猜。书里说得很直白：Level 0 的东西，不是 Agent。
|
||||
|
||||
往上走才是真 Agent。
|
||||
|
||||
**Level 1：工具使用者。** Agent 开始用工具了：搜索、API、数据库。但它不光是"能调接口"，更要自己判断什么时候该调、调什么、结果怎么用。书里给了一个很具体的例子：用户问"最近有什么新剧"，Agent 自己意识到这条信息不在训练数据里，主动调搜索工具去找，然后合成结果。关键一步在"自己意识到"。不是人类告诉它"你去搜一下"，是它自己判断需要搜。这个判断能力，是 Level 1 的门槛。
|
||||
|
||||
**Level 2：战略思考者。** 多了两样东西：规划和 Context Engineering。书里定义了 Context Engineering：不做信息堆砌，做的是精心筛选、裁剪、打包上下文。例子很妙：用户要在两个地点中间找咖啡店。Agent 先调地图工具拿到一堆数据，然后自己判断"下一步只需要街道名称"，把地图输出裁剪成一个短列表，再喂给本地搜索工具。每一步都在做信息降噪。书里有一句话我反复看了几遍："要让 AI 达到最高准确率，必须给它短小、聚焦、有力的上下文。" Context Engineering 就是干这件事的。
|
||||
|
||||
到了这个级别，Agent 还能自我反思。干完活后自己审一遍，发现问题自己改。我后面会细讲。
|
||||
|
||||
**Level 3：多 Agent 协作。** 书的立场很明确：别老想着造一个全能 super agent。真正靠谱的做法是像搭团队一样，项目经理 Agent + 研究员 Agent + 设计师 Agent + 文案 Agent。书里举的例子是新产品发布：一个"项目经理 Agent"做总调度，下发任务给"市场研究 Agent"、"产品设计 Agent"、"营销 Agent"。关键是通信：Agent 之间怎么传数据、怎么同步状态、怎么处理冲突。这章画了六种通信拓扑结构，从最简单的单 Agent 到最灵活的自定义混合，每种适合什么场景都有说明。
|
||||
|
||||
看完这四个等级，我突然明白为什么很多人说"我的 Agent 不好用"。模型没问题，问题是你在把它当聊天机器人用，它可能连 Level 1 都没到。
|
||||
|
||||
|
||||
|
||||
## Context Engineering：书里最被低估的概念
|
||||
|
||||
我写过一篇 Harness Engineering，讲的是赛道的设计比引擎的马力更重要。看完这本书我发现，Context Engineering 就是 Harness Engineering 在 prompt 层面的映射。
|
||||
|
||||
传统的 Prompt Engineering 只管"你怎么问"。书里的 Context Engineering 管的是"问之前，Agent 的眼前摆着什么"。它包括四层信息：
|
||||
|
||||
第一层，system prompt。定义 Agent 是谁、什么语气、什么边界。大多数人只写了这一层。
|
||||
|
||||
第二层，外部数据。RAG 检索到的文档、工具调用的返回值、实时 API 数据。这是大部分人卡住的地方：知道要喂数据，但不知道怎么喂才不会把模型淹没。
|
||||
|
||||
第三层，隐式数据。用户身份、交互历史、环境状态。你没明说但 Agent 应该知道的东西。比如你跟 Agent 说"帮我给 John 发邮件确认明天的会议"，它应该知道你日历里明天的会议是什么、你和 John 是什么关系。
|
||||
|
||||
第四层，反馈回路。Agent 每次输出之后，自动评估质量、调整下次的上下文策略。书里把这叫"自动化的 context 优化"，Google 的 Vertex AI Prompt Optimizer 就是这个思路的工程化实现。
|
||||
|
||||
我读到这里的时候想起之前写那篇"AI 智能体不是魔法"，里面有一条经验是"你的智能体需要规则，而且是很多规则"。现在回头看，那些规则本质上就是 Context Engineering 的手工版，书里把它系统化了。
|
||||
|
||||
|
||||
|
||||
## Reflection：两个 Agent 真的比一个好
|
||||
|
||||
这是全书对我最有实战价值的一个 Pattern。
|
||||
|
||||
Reflection 的核心很简单：Agent 干完活后自己审一遍，发现问题自己改。但实现方式有讲究。书里明确说了：**Producer 和 Critic 必须用两个不同的 Agent，给不同的 system prompt。** 同一个 persona 审自己的东西，一定有盲区。你让同一个 LLM 先写代码再审查自己写的代码，它大概率会说"挺好的"。
|
||||
|
||||
书里给了一个完整的代码示例。Producer 的 prompt 是"你是一个 Python 开发者，写一个计算阶乘的函数，处理边界条件和异常"。Critic 的 prompt 是"你是一个吹毛求疵的高级工程师，逐行审查代码，检查 Bug、风格、遗漏的边界条件、可改进的地方。如果完美就输出 CODE\_IS\_PERFECT，否则列出所有问题"。然后是一个 for 循环：Producer 写代码 → Critic 审 → Producer 根据意见改 → Critic 再审 → 直到 Critic 说 CODE\_IS\_PERFECT 或者达到最大迭代次数。
|
||||
|
||||
就这么简单。但书里提醒了一个容易被忽略的成本问题：每次反射循环都是一次新的 LLM 调用，迭代次数越多越贵。而且随着对话历史膨胀，上下文窗口被前期版本和批评意见占满，实际可用的推理空间在缩小。所以 Reflection 的最佳实践是：设一个合理的最大迭代次数（书里用的是 3），一旦 Critic 满意就停，不要追求完美。
|
||||
|
||||
用途远不止写代码。写文章、做计划、总结文档、解决逻辑题，Producer-Critic 模型全都能套。书里列了七种应用场景，核心逻辑一样：先产出，后审查，再修正。
|
||||
|
||||
|
||||
|
||||
## Multi-Agent 不是越复杂越好
|
||||
|
||||
Multi-Agent Collaboration 这章我最喜欢的是那六种通信拓扑图。很多人一上来就搞复杂的，但其实大部分场景三种就够了：
|
||||
|
||||
**单 Agent（独立执行）：** 任务能拆成互不依赖的子问题，每个 Agent 自己搞定自己的。简单，好维护。
|
||||
|
||||
**对等网络（Peer-to-Peer）：** Agent 之间直接通信，没有中心控制节点。去中心化，容错性好，一个 Agent 挂了不影响全局。但协调成本高，容易乱。
|
||||
|
||||
**Supervisor（中心调度）：** 一个 Supervisor Agent 管一群 Worker Agent。分配任务、收集结果、解决冲突。层级清晰，好管理。但 Supervisor 是单点故障，也是性能瓶颈。
|
||||
|
||||
另外三种（Supervisor-as-Tool、层级式、自定义混合）是前三者的变体和组合。书里说得很实在：**你需要的拓扑结构取决于你的任务复杂度。** 任务越拆越碎，通信成本越高，到一定程度 Supervisor 模式反而比层级式更有效率。
|
||||
|
||||
我的体会是，很多人搭 Multi-Agent 的时候花了 80% 的时间在通信协议上，忘了问一个更基本的问题：**这个任务真的需要多个 Agent 吗？** 书里写得很清楚，Level 2 的单 Agent + Reflection 往往已经够用了。Level 3 是给那些单 Agent 确实搞不定的场景准备的。
|
||||
|
||||
|
||||
|
||||
## Memory 三层模型，我之前隐约感觉到了但没命名
|
||||
|
||||
Memory 这章我最有共鸣，因为我写 Obsidian + Claude 那两篇文章的时候，一直在琢磨一个问题：Agent 的记忆该怎么分层？
|
||||
|
||||
书里给了答案。
|
||||
|
||||
**Session（会话层）：** 当前对话的上下文窗口，这是最短的记忆，对话结束就没了。长上下文模型只是把这个窗口放大了，但本质上还是临时的，而且每次推理都要处理整个窗口，又贵又慢。
|
||||
|
||||
**State（状态层）：** 当前任务进行中的临时数据。比如"正在做的任务是什么"，"已经完成到哪一步""中间产生了哪些数据"。比 Session 长，但任务结束就清理，书里用 Google ADK 的 State 机制做了完整示例。
|
||||
|
||||
**Memory（持久层）：** 跨会话、跨任务的长期记忆。用户偏好、学到的经验、重要的历史决策，存数据库或向量库里，语义检索。书里强调了一个很重要的点：Memory 不只是存下来，还要设计"存什么、什么时候存、怎么检索"的一整套策略。存太多了噪声大，存少了不够用。
|
||||
|
||||
我之前写 Clawdbot 那篇文章里提到"状态文件"和"工作区文档"，本质上就是在手搓 State 层和 Memory 层，书里把这件事框架化了。
|
||||
|
||||
|
||||
|
||||
## 五种假设，第五个最离谱
|
||||
|
||||
书末提了五个关于 Agent 未来的假设，前四个还在合理推演范围内：
|
||||
|
||||
通用型 Agent 从写代码到管项目、深度个性化主动发现你的需求、具身智能走出屏幕进物理世界、Agent 成为独立经济实体。
|
||||
|
||||
**第五个把我震住了：变形 Multi-Agent。** 你只声明目标，比如"做一个卖精品咖啡的电商生意"。系统自动决定：先创建"市场研究 Agent"和"品牌 Agent"。跑了一轮数据后，自己判断品牌 Agent 不需要了，拆成三个新的："Logo 设计 Agent"、"建站 Agent"、"供应链 Agent"。如果建站 Agent 成了瓶颈，系统会自动复制出三个并行 Agent 同时干不同的页面。整个过程中，系统持续自动调优每个 Agent 的 prompt，不断重组团队架构。
|
||||
|
||||
书里管这叫"目标驱动的、自我变形的多 Agent 系统"。它不是在执行你写的计划，是在自己生成计划、自己调整计划、自己重组执行团队。
|
||||
|
||||
这让我想起 Karpathy 的 AutoResearch：写一个 program.md，定义目标、指标、边界，按"启动"。人类在循环外面。但这本书推得更远：连 Agent 团队怎么组建、怎么重组，都交给系统自己决定。人类只声明"要什么"。
|
||||
|
||||
|
||||
|
||||
## 三件可以马上做的事
|
||||
|
||||
读完这本书，我有三个立刻可以落地的动作：
|
||||
|
||||
**第一，给你现在的 Agent 加一个 Critic。** 不管你是用 Claude Code、CrewAI 还是自己搭的框架，在你现有的 workflow 末尾加一步：让另一个 Agent（用不同的 system prompt）审查上一步的输出。代码生成加代码审查，文章撰写加事实核查，计划制定加可行性评审。多一次 LLM 调用，但质量提升往往翻倍。书里的 Producer-Critic 模式是即插即用的。
|
||||
|
||||
**第二，开始做 Context Engineering，不只是 Prompt Engineering。** 回头看你写给 Agent 的指令文件。如果全是"你要怎么做"的规则，缺少"你现在面对什么环境"的上下文，补上。告诉 Agent 它现在在哪个项目里、之前做过什么决定、用户偏好是什么。书里的 Context Engineering 那章和你的 AGENTS.md 是同一件事的两个表述。
|
||||
|
||||
**第三，先别急着上 Multi-Agent。** 把你的单 Agent 做到 Level 2：有工具、有 Reflection、有 Memory。书里反复强调，Level 2 的单 Agent 加上 Producer-Critic 和 Context Engineering，能覆盖绝大多数实际场景。Level 3 是给真正跨领域、多阶段、需要并行分工的任务准备的。大多数人的问题不是 Agent 不够多，是一个 Agent 都没调好。
|
||||
|
||||
这本书 453 页，Springer 2025 年出版。代码示例覆盖LangChain/LangGraph、Google ADK、CrewAI、OpenAI API。前言是 Google Cloud AI VP 写的，还有个 Goldman Sachs CIO 的推荐序，意外地好看。
|
||||
|
||||
但我推荐它的理由不是"全面"。是你读完会意识到一件事：你过去半年在 Agent 上踩的坑，都有人整理成模式了。你不需要再去发明 Reflection，不需要再去猜 Memory 该怎么分层，不需要再去试 Multi-Agent 该用哪种通信拓扑。
|
||||
|
||||
有人替你画了地图，剩下的就是走。
|
||||
|
||||
**你在用 AI Agent 做开发吗？你现在的 Agent 到了 Level 几？评论区聊聊。**
|
||||
457
1 - Inbox/Claude Code Dynamic Workflows：把编排逻辑搬进代码的新原语.md
Normal file
457
1 - Inbox/Claude Code Dynamic Workflows：把编排逻辑搬进代码的新原语.md
Normal file
@@ -0,0 +1,457 @@
|
||||
---
|
||||
title: "Claude Code Dynamic Workflows：把编排逻辑搬进代码的新原语"
|
||||
source: "https://x.com/riba2534/article/2060102236676792711"
|
||||
author:
|
||||
- "[[riba2534 (@riba2534)]]"
|
||||
published: 2026-05-28
|
||||
created: 2026-05-30
|
||||
description: "当任务大到一次对话装不下时，让 Claude 把编排过程写成一段脚本5 月 28 日，Anthropic 发布了 Claude Opus 4.8，随之而来还带来了一个新功能——Dynamic Workflows（动态工作流）。先看一个数字：11 天、约 75 万行 Rust 代码..."
|
||||
tags:
|
||||
- "clippings"
|
||||
---
|
||||
|
||||
|
||||
> 当任务大到一次对话装不下时，让 Claude 把编排过程写成一段脚本
|
||||
|
||||
5 月 28 日，Anthropic 发布了 Claude Opus 4.8，随之而来还带来了一个新功能——Dynamic Workflows（动态工作流）。
|
||||
|
||||
先看一个数字：**11 天**、**约 75 万行 Rust 代码**、**99.8% 的原有测试通过**。这是 Bun 作者 Jarred Sumner 把整个 Bun 运行时[从 Zig 迁移到 Rust](https://github.com/oven-sh/bun/pull/30412) 交出的成绩单，而扛起这场迁移的主力，正是这个 Dynamic Workflows。
|
||||
|
||||
它作为研究预览（research preview）放出，瞄准的是那一类单个 Agent 一次跑不完的活，官方博客的原话是这样描述的：
|
||||
|
||||
> Some problems are too big for one pass by a single agent, especially in complex, legacy codebases: a bug hunt across an entire service, a migration that touches hundreds of files, a plan you want stress-tested from every angle before you commit to it.
|
||||
|
||||
整个服务范围的 bug 排查、动辄上百个文件的迁移、一个需要从各个角度反复推敲才敢拍板的方案——这些任务的共同点是规模超出了一轮对话能协调的范围。Dynamic Workflows 给出的答案，是让 Claude 把这套编排过程写成一段可执行的脚本。
|
||||
|
||||
## 从 Subagent 到 Workflow
|
||||
|
||||
要理解 Workflow 的位置，得先把 Claude Code 已有的几层协作能力捋一遍。
|
||||
|
||||
最底层是单个 session，一个 Agent 实例从头干到尾，串行处理。往上一层是 subagent——主 Agent 派生出若干小弟去搜文件、读代码、跑命令，干完把结果汇报回来。再往上是今年早些时候推出的 [Agent Teams](https://code.claude.com/docs/en/agent-teams)，多个独立的 Claude Code 实例像团队一样并行协作，队员之间还能互相通信。
|
||||
|
||||
这几层有一个共同的瓶颈：**编排者始终是 Claude 本身**。它逐轮决策下一步派谁去干什么，而每一个 subagent 的返回结果，都要先回到 Claude 的上下文窗口里，它读完才能决定接下来怎么走。这套机制在任务规模不大时很灵活，可一旦要协调几十上百个并行任务，问题就来了：上下文窗口装不下那么多中间结果，Claude 的注意力也会被海量的过程信息稀释。
|
||||
|
||||
Workflow 换了个思路。这一次 Claude 不再亲自逐轮调度，它先把整个编排过程**写成一段 JavaScript 脚本**——循环、分支、中间结果的收集全都固化在代码里——再交给一个独立的运行时去执行。官方文档把这个转变概括得很精炼：
|
||||
|
||||
> A workflow moves the plan into code. With subagents and skills, Claude is the orchestrator: it decides turn by turn what to spawn next, and every result lands in Claude's context. A workflow script holds the loop, the branching, and the intermediate results itself, so Claude's context holds only the final answer.
|
||||
|
||||
计划被搬进了代码。脚本自己持有循环、分支和中间结果，Claude 的上下文里只剩下最后那个答案。这跟"把大型代码库塞进有限上下文窗口"的思路是同一条路线上的延续——前者解决的是"上下文怎么省着用"，Workflow 解决的是"当工作量大到上下文根本装不下时怎么办"。
|
||||
|
||||
把 Agent Teams 和 Dynamic Workflows 摆在一起看：
|
||||
|
||||
|
||||
|
||||
> 图片出自 Anthropic 产品经理 Cat Wu 发布 Dynamic Workflows 的推文。左边 Agent Teams 是网状协作，右边 Dynamic Workflows 则是"一个 claude 扇出上百个 task，每个 task 走 implementer → 两个 verifier → fixer 三层，最后扇入返回"的树状结构——后面 Bun 案例里"每个文件配两个 reviewer"的设计，在这张图上已经能看到雏形。
|
||||
|
||||
## Workflow 到底在哪运行
|
||||
|
||||
开始拆架构之前，得先破除一个最常见的误解：很多人以为 Workflow 是某个跑在 Anthropic 服务端的编排引擎，于是去找它的 API 协议、担心第三方中转兼容性。
|
||||
|
||||
实际情况是：**Workflow 工具本身不请求任何服务端**。它是 Claude Code 在你本机跑的一段 JavaScript 编排脚本——agent()、parallel()、pipeline() 这些都是在你电脑上执行的控制流。真正去"请求服务端"的，是脚本里 agent() 调用 spawn 出来的每个 subagent，而**subagent 调用模型的方式，和你主对话窗口完全一样**。
|
||||
|
||||
这件事有个直接推论：如果你用第三方 API 中转，Workflow 跑挂了，那跟 Workflow 没关系——它用的就是 Claude Code 平时调模型一直在用的那套接口，即 Anthropic 原生的 Messages API（不是 OpenAI 的 /v1/chat/completions）：
|
||||
|
||||
```text
|
||||
POST {ANTHROPIC_BASE_URL}/v1/messages
|
||||
|
||||
Headers:
|
||||
x-api-key: <key> # 或第三方常用的 Authorization: Bearer <key>
|
||||
anthropic-version: 2023-06-01
|
||||
anthropic-beta: context-1m-2025-08-07 # 1M context 会带这个 beta flag
|
||||
content-type: application/json
|
||||
|
||||
Body:
|
||||
{
|
||||
"model": "claude-opus-4-8", # 裸 model id，[1m] 只是本地标识，不会进 body
|
||||
"system": [ {... cache_control ...} ], # system 是数组，带 prompt caching
|
||||
"messages": [...],
|
||||
"tools": [...], # Claude Code 会塞几十个 tool 定义
|
||||
"stream": true # 默认流式
|
||||
}
|
||||
```
|
||||
|
||||
把这层关系理清之后，Workflow 的运行模型就清晰了：一个**无脑的、确定性的 JavaScript 运行时**当指挥，它只会循环、拼字符串、await，本身不含任何 LLM；只有当脚本执行到 agent(...) 那一行，运行时才去临时雇一个 LLM subagent 干活。而"真正的 Agent"——也就是你正在对话的主 Claude——在脚本执行期间**根本没在运行**：它在发出 Workflow 调用后那一回合就结束了，脚本在后台独立跑，跑完用一条通知把它叫醒，让它去读最后的结果。
|
||||
|
||||
|
||||
|
||||
一句话概括这个分工：**JavaScript 运行时当指挥（无脑、确定性），在 \`agent()\` 点临时雇 LLM 干活，主 Agent 全程在睡觉，只在最后被叫醒读结果。** 记住这条，后面所有的特性都好理解了。
|
||||
|
||||
## Workflow 的核心架构
|
||||
|
||||
一个 Workflow 跑起来，背后是四个部件在配合：
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
这张图里最关键的一条线，是 subagent 的结果先流进**脚本变量**，在运行时内部完成循环和校验，最后只有汇总过的答案才回到 Claude。这跟 subagent 那种"每个结果都要经过 Claude 大脑"的模式有本质区别。
|
||||
|
||||
官方文档给了一张三者对照表，把 Workflow 和 Subagents、Skills 的定位差异讲得很清楚：
|
||||
|
||||
|
||||
|
||||
读这张表的时候，注意"可复用的是什么"这一行。subagent 和 skill 复用的是"一个工作者"或"一条指令"，而 Workflow 复用的是**整套编排逻辑**——这意味着一个调度数百个 agent 做交叉验证的复杂流程，写好一次就能存下来反复运行。这是 Workflow 区别于其它原语的地方。
|
||||
|
||||
## 脚本长什么样：meta、原语和那个最容易踩的坑
|
||||
|
||||
既然 Workflow 是一段 JS 脚本，那它到底长什么样？这一节把骨架拆开看。
|
||||
|
||||
每个脚本**必须**以 export const meta = {...} 开头，而且 meta 必须是**纯字面量**——不能有变量、函数调用、模板插值。它定义了脚本的名字、一行描述（会显示在权限弹窗上）和阶段划分：
|
||||
|
||||
```javascript
|
||||
export const meta = {
|
||||
name: 'find-flaky-tests',
|
||||
description: 'Find flaky tests and propose fixes', // 一行，显示在权限弹窗
|
||||
phases: [ // 每个 phase() 调用对应一条
|
||||
{ title: 'Scan', detail: 'grep test logs for retries' },
|
||||
{ title: 'Fix', detail: 'one agent per flaky test' },
|
||||
],
|
||||
}
|
||||
// 脚本体从这里开始
|
||||
phase('Scan')
|
||||
const flaky = await agent('grep CI logs for retry markers', { schema: FLAKY_SCHEMA })
|
||||
phase('Fix')
|
||||
// ...
|
||||
```
|
||||
|
||||
meta 之后就是脚本体。能用的核心原语不多，一张表就能记住：
|
||||
|
||||
|
||||
|
||||
每个 agent() 的提示词，就写在脚本里，是普通的 JS 字符串。要给不同 agent 喂不同的输入，常见写法是把 prompt 写成一个"返回字符串的函数"，调用时用 .map() 把循环变量插进去。数据就是这样在 agent 之间流动的——靠的就是普通的字符串拼接，没有什么消息总线：逐项数据用 .map() 插进每个 agent 的 prompt，跨阶段数据则把上一阶段的返回值 JSON.stringify 后拼进下一阶段的 prompt。
|
||||
|
||||
整段脚本里最容易踩的坑，是 pipeline 和 parallel 分不清。两者的本质分界是**有没有屏障（barrier）**：parallel 会等这一批全部跑完才往下走，pipeline 则让每个 item 各自独立地流过所有 stage，互不等待。下面这种写法就是典型的浪费：
|
||||
|
||||
```javascript
|
||||
const a = await parallel(...) // ❌ 屏障：等全部跑完
|
||||
const b = transform(a) // 只是 flatten / map / filter，没有跨 item 依赖
|
||||
const c = await parallel(b.map(...))
|
||||
```
|
||||
|
||||
如果 5 个任务快慢不一，中间这个屏障会让快的干等慢的。正确的做法是把中间的 transform 塞进 pipeline 的一个 stage，让每条数据一旦就绪就立刻流向下一步：
|
||||
|
||||
```javascript
|
||||
// ✅ 维度 'bugs' 的发现可以在 'perf' 还在 review 时就开始 verify
|
||||
const results = await pipeline(
|
||||
DIMENSIONS,
|
||||
d => agent(d.prompt, { label: \`review:${d.key}\`, phase: 'Review', schema: FINDINGS }),
|
||||
review => parallel(review.findings.map(f => () =>
|
||||
agent(\`对抗性验证: ${f.title}\`, { phase: 'Verify', schema: VERDICT })
|
||||
.then(v => ({ ...f, verdict: v }))
|
||||
))
|
||||
)
|
||||
```
|
||||
|
||||
|
||||
|
||||
只有三种情况才真正需要屏障：下一阶段前要对**全集**去重或合并；要根据总数提前退出（比如"0 个 bug 就跳过整个验证阶段"）；下阶段的 prompt 要引用"其他所有发现"做横向比较。除此之外，**有疑问就用 pipeline**。
|
||||
|
||||
## 三种触发方式
|
||||
|
||||
让 Claude 起一个 Workflow，有三条路子。
|
||||
|
||||
第一条是在 prompt 里直接出现 workflow 这个词。Claude Code 会把它高亮出来，提示你这句话可能触发一个工作流：
|
||||
|
||||
```text
|
||||
Run a workflow to audit every API endpoint under src/routes/ for missing auth checks
|
||||
```
|
||||
|
||||
如果你只是顺口提了一句 workflow、并不想真的触发，按 alt+w 就能忽略这个高亮。
|
||||
|
||||
第二条是开启 ultracode 模式，让 Claude 自己判断要不要起 Workflow：
|
||||
|
||||
```text
|
||||
/effort ultracode
|
||||
```
|
||||
|
||||
第三条是运行一个已经保存好的 Workflow，它会以斜杠命令的形式出现：
|
||||
|
||||
```text
|
||||
/deep-research What changed in the Node.js permission model between v20 and v22?
|
||||
```
|
||||
|
||||
保存下来的 Workflow 放在两个位置，决定了它的可见范围：
|
||||
|
||||
```text
|
||||
.claude/workflows/ # 项目级，克隆仓库的人都能用，跟团队共享
|
||||
~/.claude/workflows/ # 个人级，只有你能看到，但在每个项目里都能用
|
||||
```
|
||||
|
||||
保存时按 Tab 在这两个位置之间切换。如果项目级和个人级有同名 Workflow，**项目级优先**。存好之后它就成了一个 /<name> 命令，出现在斜杠自动补全菜单里，跟普通的 slash command 混在一起。
|
||||
|
||||
|
||||
|
||||
脚本生成之后、真正跑起来之前，你有机会审一眼它要干什么。运行中按 Ctrl+G 还能在编辑器里打开脚本，看 Claude 到底写了段什么样的代码。这种"代码可见、可审"的特性，是 Workflow 相比黑盒式自动化更让人放心的地方。
|
||||
|
||||
## 执行模型与那些硬约束
|
||||
|
||||
Workflow 的运行时跟你的对话是隔离的——脚本在独立环境里执行，跑的过程中你的会话依然能响应。这套隔离机制也带来一组必须了解的硬约束。
|
||||
|
||||
并发是有上限的：**最多 16 个 subagent 同时跑**（实际是 min(16, CPU 核数 − 2)，核心少的机器会更低），**单次运行最多 1000 个 agent**。后面这个数字是防止脚本陷入死循环失控烧钱的保险丝。
|
||||
|
||||
权限上，Workflow 内部派生的所有 subagent **自动以 \`acceptEdits\` 模式运行**，文件编辑不再逐个弹窗确认，并且继承你当前会话的工具允许列表（tool allowlist）。但有一类情况仍然会打断运行——不在允许列表里的 shell 命令、网络抓取和 MCP 工具，跑到一半还是会向你弹确认框。所以官方的建议是：**大规模运行之前，先把 agent 们需要用到的命令加进允许列表**，免得跑了一半被一个权限弹窗卡住。
|
||||
|
||||
还有一点容易被忽略：脚本本身没有直接的文件系统或 shell 访问权限，所有的读写和执行都得通过 subagent 来完成。脚本是纯粹的"调度大脑"，手脚都长在 subagent 身上。
|
||||
|
||||
可恢复是 Workflow 相比 subagent、Agent Teams 独有的能力。每次运行都会留一份 journal，改完脚本后用 resumeFromRunId 重跑，**没改动的 \`agent()\` 调用直接命中缓存，只有改动及其之后的部分才重新跑**。这一点对调试编排逻辑很省事——改一行 prompt 重跑，前面已经跑对的那些 agent 直接命中缓存，不用再花一遍钱和时间。但要注意一条界线：**恢复只在同一个会话内有效**。运行中途暂停了可以接着跑，已完成的工作不会丢；可一旦你退出了 Claude Code，下次进来这个 Workflow 只能从头再跑一遍。
|
||||
|
||||
## 内置的 deep-research 长什么样
|
||||
|
||||
光说概念有点抽象，Anthropic 直接内置了一个现成的 Workflow 让你上手体验——/deep-research。
|
||||
|
||||
它的用法就是后面跟一个问题：
|
||||
|
||||
```text
|
||||
/deep-research <question>
|
||||
```
|
||||
|
||||
跑起来之后，它干的事情分三段：先从多个角度扇出（fan out）一批 Web 搜索，然后抓取并交叉核对这些来源，接着对每一条声明（claim）投票表决，最后产出一份带出处的报告，**没通过交叉验证的声明会被直接剔除**。
|
||||
|
||||
|
||||
|
||||
它依赖 WebSearch 工具可用。这个内置 Workflow 的价值在于，它把"对抗幻觉"这件事用编排的方式做了进去——单个 Agent 搜索容易被某个来源带偏，而多路搜索加交叉投票，本质上是在用结构化的流程逼近事实。想感受 Workflow 是什么体验，跑一个 /deep-research 是成本最低的入口。
|
||||
|
||||
## Ultracode：让 Claude 自己决定要不要起 Workflow
|
||||
|
||||
如果你不想每次都手动判断"这个任务值不值得起 Workflow"，可以把这个决定权交给 Claude——开启 ultracode。
|
||||
|
||||
```text
|
||||
/effort ultracode
|
||||
```
|
||||
|
||||
这条命令同时做两件事：把推理努力（effort）拉到 xhigh，同时允许 Claude 自动判断什么时候该用 Workflow 来处理你的任务。开启之后，**一个请求可能被拆成连续好几个 Workflow**——比如先跑一个理解代码，再跑一个做修改，最后跑一个验证。这个设置对当前会话里的每个任务都生效，新会话则会重置。
|
||||
|
||||
代价也很直白：官方文档说得很清楚，ultracode 模式下每个请求消耗的 token 和耗时都明显高于较低的努力档位。想退回日常工作模式，降回去就行：
|
||||
|
||||
```text
|
||||
/effort high
|
||||
```
|
||||
|
||||
这种"让模型自己决定调度规模"的设计，跟 Codex 那套 Goals（持久目标）走的是不同的方向，这点最后再细说。
|
||||
|
||||
## Workflow 是一张 DAG 吗
|
||||
|
||||
聊到编排，很多人脑子里第一反应是 DAG（有向无环图）——Airflow、Argo、GitHub Actions 的 needs:，都是先把一张静态的依赖图画死，再按图执行。Workflow 是不是也是这样？
|
||||
|
||||
答案要看你问的是哪张图：**作为程序，它不一定是 DAG；但任何一次执行的轨迹，一定是 DAG。**
|
||||
|
||||
先说程序层面。Claude Code 的 Workflow 是一段**图灵完备的命令式 JavaScript**，不像传统编排器那样跑之前就把依赖图定死。它能写出 DAG 表达不了的东西，最典型的就是循环——比如"一直找 bug，直到连续两轮都没有新增"：
|
||||
|
||||
```javascript
|
||||
let dry = 0
|
||||
while (dry < 2) { // ← 这是一条回边，控制流图里的环
|
||||
const fresh = (await parallel(FINDERS.map(...))).filter(isNew)
|
||||
if (!fresh.length) { dry++; continue }
|
||||
dry = 0
|
||||
confirmed.push(...await verify(fresh))
|
||||
}
|
||||
```
|
||||
|
||||
除了循环，它还能写运行时才决定的分支（if (bugs.length === 0) return，走哪条路取决于上一步 LLM 的输出），以及动态扇出（下一阶段起几个 agent，取决于上一阶段返回了多少条结果）——图的形状事先并不知道。在"程序结构"这个层面，它有环、有数据决定的分支，比 DAG 严格更强。
|
||||
|
||||
但只要你盯住"某一次具体执行"，它又一定是 DAG。原因有两个：数据只往时间前方流，一个值不可能依赖它之后才产生的值；循环会被展开，while 第 N+1 轮的那些 agent，和第 N 轮是不同的节点——环在"程序"里，展开成"轨迹"后就被拉直成一条链了。
|
||||
|
||||
|
||||
|
||||
一句话记住：**带 \`while\` 的程序不是 DAG，但它跑一次产生的执行轨迹，永远是 DAG。** 这正是它比传统 DAG 编排器更灵活的地方——传统工具的图在跑之前就定死了，而 Workflow 的拓扑是命令式脚本跑出来的，形状运行时才定。
|
||||
|
||||
## 真实案例一：Bun 从 Zig 移植到 Rust
|
||||
|
||||
前面所有的概念，都不如 Bun 这个案例有说服力。开头那组数字可以再看一眼：11 天、约 75 万行 Rust、99.8% 的原有测试通过，从第一个 commit 到合并。
|
||||
|
||||
Bun 是一个用 Zig 写的 JavaScript 运行时，性能是它的招牌。把这样一个庞大的运行时从 Zig 整体迁移到 Rust，是那种听起来就让人头皮发麻的工程——光是 Rust 借用检查器（borrow checker）对内存所有权的严格要求，就足以让人工迁移举步维艰。Jarred Sumner 用三个串联的 Workflow 把它啃了下来。
|
||||
|
||||
|
||||
|
||||
**阶段一是生命周期映射。** 第一个 Workflow 专门做一件事：给 Zig 代码库里每一个 struct field 算出它对应的、正确的 Rust lifetime。这一步单独拎出来做，是因为它是后面所有移植工作的地基——Rust 的内存安全建立在生命周期标注之上，这一层没算对，后面写出来的 .rs 文件根本过不了编译。
|
||||
|
||||
**阶段二是并行文件移植，也是最能体现 Workflow 规模优势的一段。** 下一个 Workflow 把每个 .zig 文件移植成一个行为等价的 .rs 文件，**数百个 agent 同时开工，每个文件还配两个 reviewer 做交叉审查**。把这个量级跟 Agent Teams 对比一下就能感受到差距——Agent Teams 同时跑三五个队员就到协调上限了，而 Workflow 在这里是几百个 agent 并行外加双重 review。
|
||||
|
||||
**阶段三是编译与测试的 fix loop。** 文件移植完只是半成品，真正的硬仗是让它们能编译、能通过测试。第三个 Workflow 驱动整个 build 和 test 套件，循环修复，直到两者都干净跑过。这正是上一节讲的 while 循环模式的典型场景——靠脚本里的循环逻辑反复迭代，而不靠 Claude 逐轮盯着。
|
||||
|
||||
三个阶段各自的特征可以列成一张表：
|
||||
|
||||
|
||||
|
||||
事情到这还没完。移植合并之后，又跑了一个 **overnight workflow**（过夜工作流）专门处理收尾——扫描代码里不必要的数据拷贝，每发现一处优化就单独开一个 PR 交给人做最终审查。这种"夜里挂着自己干长尾清理、产出一堆待 review 的 PR"的用法，是 Workflow 很有意思的一个侧面。
|
||||
|
||||
需要说清楚的是，官方明确标注了 Bun 的这个 Rust 版本**当时还没进入生产环境**——这整套流程跑通了、测试过了，但离上线还有距离。Jarred 自己也说，后续会专门写文章讲这件事的更多细节。
|
||||
|
||||
## 真实案例二：用 Workflow 盘点 133 个历史会话
|
||||
|
||||
Bun 是个极端案例，普通人未必有机会跑一次跨语言大迁移。我自己拿一个更接地气的任务试了一下：用 Workflow 给自己的 Claude Code 历史会话做一次"使用画像"。
|
||||
|
||||
任务是这样的：~/.claude 目录下攒了 **133 个会话、130MB 的 jsonl 记录**，想从里面提炼出使用模式、反复出现的痛点和可以自动化的点。这个活的特点是数据量大、维度多，正好适合 fan-out。
|
||||
|
||||
整个任务拆成了"**主 Agent 预处理 + Workflow 编排**"两段。主 Agent 先做侦察和清洗：jsonl 里塞满了工具调用的噪声，直接喂给 agent 会浪费上下文，于是先写个脚本把 133 个会话压缩成"标题 + 用户真实输入 + 元数据"，得到 601 条真实的人类输入，再切成 10 个批次。然后才是 Workflow 上场：**10 个分析 agent 并行各啃一个批次**（按统一的 schema 抽取领域分布、卡点、自动化候选），最后 1 个综合 agent 跨批汇总去重，产出一份带优先级的报告。
|
||||
|
||||
|
||||
|
||||
这次运行的执行体，去掉声明部分后大致是这样：
|
||||
|
||||
```javascript
|
||||
phase('分析')
|
||||
const batches = Array.from({ length: 10 }, (_, i) =>
|
||||
\`${DIR}/batch_${String(i + 1).padStart(2, '0')}.md\`)
|
||||
|
||||
const findings = await parallel(batches.map((path, i) => () =>
|
||||
agent(ANALYZE_PROMPT(path), { // ANALYZE_PROMPT 是返回字符串的函数
|
||||
label: \`分析:batch_${String(i + 1).padStart(2, '0')}\`,
|
||||
phase: '分析',
|
||||
schema: FINDING_SCHEMA, // 强制结构化输出，不匹配自动重试
|
||||
})
|
||||
))
|
||||
|
||||
const ok = findings.filter(Boolean) // 丢掉跑挂的（被跳过的 agent 返回 null）
|
||||
log(\`分析完成：${ok.length}/${batches.length} 批返回有效结果\`)
|
||||
|
||||
phase('综合')
|
||||
const corpus = JSON.stringify(ok, null, 1) // 把 10 份发现整个塞进综合 prompt
|
||||
const report = await agent(SYNTH_PROMPT, { label: '综合报告', phase: '综合' })
|
||||
return report // 这个返回值就是唯一回到主上下文的东西
|
||||
```
|
||||
|
||||
跑下来的账单：**11 个 agent、81.8 万 token、254 秒**。这中间我还踩了一个坑——第一次跑直接挂了，报 TypeError: undefined is not an object (evaluating '[batches.map](https://batches.map/)')，原因是 args 没正确传进去、被当成了字符串。修法很能体现 Workflow"脚本即文件、可迭代"的价值：我没有重发整段脚本，只是直接 Edit 那个落盘的脚本文件、把路径写死成自包含，再用 scriptPath 重跑。
|
||||
|
||||
这个案例还顺带回答了一个很多人会问的问题：**这事派几个 subagent 一样能做，区别在哪？** 确实能做——区别不在"能不能"，在"编排逻辑放哪、中间结果流到哪"。如果用 Agent 工具派 10 个 subagent，10 份结果会作为 tool result 全部回到主上下文，然后你得在下一个回合用自己的脑子读完、决定怎么合；编排逻辑是临场判断，每一步协调都烧主上下文的 token。而 Workflow 把编排写成了代码，10 份中间结果不进主上下文，只回最终那份报告，schema 自动校验、并发自动管控。
|
||||
|
||||
不过得诚实地补一句：就**这一次**这种"一把梭 map-reduce"而言，两者差距其实没那么大——10 路并行、合一次就完了，subagent 也够用。Workflow 真正赚到的是随复杂度放大的那部分：当阶段变多、需要循环（一直找到连续 N 轮无新增）、需要多轮对抗式验证、或者要 fan-out 到几十个单元时，用 subagent 手动协调会非常痛，用脚本写就很自然。
|
||||
|
||||
## 和 N8N、Coze、Dify 的本质区别
|
||||
|
||||
看到"用代码编排多步流程 + 步骤里塞 LLM"，很容易冒出一个念头：这不就是 n8n、Coze（扣子）、Dify 那套吗？无非是现在让模型自动来编排。
|
||||
|
||||
这个直觉**抓住了最关键的共性**，但"唯一区别是模型自动编排"这句话，得往回拉一拉。
|
||||
|
||||
先说共性，而且这个共性比想象的更硬。Anthropic 在《Building Effective Agents》里给过一个权威定义：**Workflows 是 LLM 和工具通过"预定义代码路径"（predefined code paths）被编排的系统**；与之相对的 Agents，才是 LLM 在运行时动态指挥自己流程的系统。按这个定义，Dynamic Workflow 和 n8n/Dify/Coze 是**同一类**——它们的控制流都是确定性的，LLM 不会在运行时决定"下一步走哪条边"，脚本一旦写好，执行它的就是个无脑运行时，LLM 只在节点内部干活。真正不在这个范畴里的，是主对话那个 ReAct 式 agent（那才是模型实时决定下一步）。这一点的判断完全成立。
|
||||
|
||||
但"唯一区别"这个说法漏掉了两个更硬的差异。把它们摊开看：
|
||||
|
||||
|
||||
|
||||
把这张表压成一句话：**Workflow ≈ 把 n8n 那张图，换成模型现场生成的一段代码。** 它换掉了两样东西——作者（人 → 模型）和载体（可视化 DAG → 命令式代码）。第一样带来即时性和定制性（不用人预先搭，针对当次任务量身生成），第二样带来表达力的提升（能写循环和动态扇出，这是可视化 DAG 做不到的）。
|
||||
|
||||
|
||||
|
||||
至于"AI 自动编排"这个最抢眼的差异，还得再精确一点：**AI 的介入发生在"写代码"那一刻，不在"跑流程"那一刻。** n8n 是人写编排、运行时确定性执行；Workflow 是模型写编排、运行时确定性执行——执行期间模型在睡觉。两者跑流程的方式是一样的，差别只在编排脚本的作者是谁。
|
||||
|
||||
值得一提的是，两边其实在互相靠拢：Coze、Dify 都在加 agent 节点（节点本身变自主）和 code 节点（可以写 JS / Python），往"代码 + 自主节点"挪；而 Workflow 的脚本也能存进 .claude/workflows/ 当可复用产品，往"建一次反复用"挪。所以更准确的结论是：你的本质判断成立——都是确定性流程编排、LLM 当步骤；但区别不止"AI 自动编排"一条，还有**载体是图灵完备代码而非可视化 DAG**，以及**每个节点是个自主 agent 而非固定连接器**。
|
||||
|
||||
## 官方之前，怎么手搓一个 Workflow
|
||||
|
||||
既然 Workflow 本质是"确定性脚本 + 在节点处调 LLM"，那在官方推出之前，自己手搓一个类似的东西，完全可行。核心拼图就一个：claude -p。
|
||||
|
||||
claude -p（即 --print，headless 模式）会非交互地跑完一整个 agent loop——思考、调工具、改文件——跑完即退出。它读 stdin、写 stdout，可以像普通命令行工具一样接进管道。把每一步当成一次 claude -p 调用，外面用 shell 或 Python 写编排循环，就是 DIY 版的 Workflow：
|
||||
|
||||
```bash
|
||||
# fan-out：10 个批次并行，每个起一个 claude -p
|
||||
for f in batch_*.md; do
|
||||
claude -p "分析这个批次：$(cat $f)" --output-format json > "out_$f.json" &
|
||||
done
|
||||
wait # ← 屏障，等全部跑完，对应 parallel()
|
||||
|
||||
# reduce：把 10 份结果拼起来，再起一个 claude -p 综合
|
||||
claude -p "综合这些发现：$(cat out_*.json)" > report.md
|
||||
```
|
||||
|
||||
对照一下就会发现，这跟前面那个 133 会话的 Workflow 是同构的：& 加 wait 就是 parallel() 的屏障，$(cat ...) 拼字符串就是 prompt 里的变量插值。社区里这类实践不少，futuresearch.ai 那篇就用 claude -p 加文件系统轮询搭了一套 18 路并行的扫描流水线——子 agent 把结果写盘（成功写 .json、失败写 .error），编排器只轮询文件名而不把输出收进上下文，把复杂度从 O(n × 输出大小) 压到 O(n × 文件名)。
|
||||
|
||||
那官方 Workflow 比手搓版多了什么？答案是：模型没变，省掉的全是工程脏活。
|
||||
|
||||
|
||||
|
||||
一句话：**Workflow 是把这套手搓 harness 产品化了，省的是工程脏活，不是改变模型。** 理解了这一层，你对它的能力边界也就有了底——它不是什么魔法，就是一个把"claude -p + 编排循环"打磨得足够顺手的运行时。
|
||||
|
||||
## 什么场景该用 Workflow
|
||||
|
||||
不是每个任务都需要起一个 Workflow。它本质上是用大量并行 agent 换效率，而并行 agent 是实打实烧 token 的。那什么时候这笔账划算？
|
||||
|
||||
官方文档给出的适用场景集中在四类。
|
||||
|
||||
一是代码库范围的批量排查，比如全仓库 bug 扫描、性能剖析引导的优化审计、安全审计。这类任务的共同点是"搜索加独立验证"——Claude 并行搜遍整个服务，再对每个发现单独验证，确保报告里浮现的都是真问题。授权检查、输入校验、危险模式的全库加固也是同一个形状。
|
||||
|
||||
二是大规模迁移与现代化，框架替换、API 弃用迁移、跨语言移植都算，Bun 是其中最极致的例子。
|
||||
|
||||
三是需要反复推敲的关键决策。当错误答案的代价很高时，让 Claude 从多个独立角度各做一遍，再派对抗性的 agent 试图推翻这些结果，迭代到答案收敛为止——这种对抗式验证能逼近单次跑达不到的质量。
|
||||
|
||||
四是长尾清理，像 Bun 那个 overnight workflow，挂着自动扫描问题、逐个开 PR。
|
||||
|
||||
反过来，这几类任务用 Workflow 就是杀鸡用牛刀：一两步就能搞定的小修补、需要你中途频繁拍板的探索性工作、以及碰安全和支付这类高风险代码的改动。
|
||||
|
||||
把 Claude Code 现有的几种协作原语放一起，选型逻辑大致是这样：
|
||||
|
||||
|
||||
|
||||
一句话区分：需要"跑腿"用 subagent，需要"开会讨论"用 Agent Teams，需要"流水线作业"用 Workflow。
|
||||
|
||||
## 可用范围与怎么开
|
||||
|
||||
Dynamic Workflows 目前是研究预览状态，对版本和计划都有要求。
|
||||
|
||||
版本上需要 **Claude Code v2.1.154 或更高**。平台覆盖得相当全：CLI、Desktop、VS Code 扩展、Claude API，以及 Amazon Bedrock、Google Cloud Vertex AI、Microsoft Foundry 三大云。
|
||||
|
||||
计划上的差异要留意：**Max、Team 以及通过 API 使用的场景，默认就开着**；Pro 计划默认关闭，需要去 /config 里的 Dynamic workflows 一行手动打开；Enterprise 计划发布时也默认关闭，得由管理员在设置里开启。第一次触发 Workflow 时，Claude Code 会把即将运行的内容摆给你看并要求确认，不会闷头就跑。
|
||||
|
||||
如果你想彻底关掉它，有几个层面的开关：
|
||||
|
||||
```json
|
||||
// ~/.claude/settings.json
|
||||
{
|
||||
"disableWorkflows": true
|
||||
}
|
||||
```
|
||||
|
||||
或者用环境变量，在启动时生效：
|
||||
|
||||
```bash
|
||||
export CLAUDE_CODE_DISABLE_WORKFLOWS=1
|
||||
```
|
||||
|
||||
个人也可以直接在 /config 里切换，组织层面则能通过 managed settings 或管理后台统一禁用。
|
||||
|
||||
## Token 成本：必须算的一笔账
|
||||
|
||||
这部分官方说得格外坦诚：**单次 Workflow 的 token 消耗，明显高于一次普通的 Claude Code 对话**。道理不复杂，几十上百个 subagent 同时跑，每个都在烧 token，再叠加交叉验证、对抗式 review 这些"额外冗余"的设计，账单自然往上走。前面那个 133 会话的案例，11 个 agent 就吃掉了 81.8 万 token——这还只是 10 路一把梭的轻量编排。这些消耗都计入你所在计划的用量和速率限制。
|
||||
|
||||
官方给的实用建议有几条可以记下来。一是**从一个范围明确的小任务开始**，先摸清楚它在你的工作里大概花多少，再决定要不要放手让它跑大活。二是大规模运行之前，先用 /model 确认自己在合适的模型上，并且可以要求 Claude 在那些不需要最强能力的阶段改用更小的模型——不是每一步都得动用最贵的脑子。三是前面提过的，提前把命令加进允许列表，避免中途被权限弹窗打断一个跑了几小时的任务。
|
||||
|
||||
好在 Workflow 随时可以叫停，已经完成的工作不会白费。
|
||||
|
||||
## 已知限制
|
||||
|
||||
研究预览阶段，几个边界先摆在这，省得踩到了再回来查：
|
||||
|
||||
- **运行中途不接受人工输入**：除了权限确认弹窗，Workflow 跑起来就不停下来等你拍板。需要分段签核的流程，得拆成多个独立的 Workflow。
|
||||
- **脚本本身没有文件和 shell 访问权限**：读写和执行全靠 subagent，脚本只负责调度。
|
||||
- **并发与总量都封顶**：最多 16 个并发 subagent，单次运行 1000 个 agent 上限。
|
||||
- **跨会话不可恢复**：退出 Claude Code 后，下次进来 Workflow 从头再跑。
|
||||
- **自定义 Workflow 怎么传参**：内置的 /deep-research 能接收一个问题参数，但你自己存的 Workflow 怎么传参，官方文档这块还语焉不详。
|
||||
- 整个功能仍在研究预览，行为和约束都可能随版本调整。
|
||||
|
||||
## 它在 Claude Code 体系里的位置
|
||||
|
||||
到这里，可以把 Claude Code 的几种扩展原语放在一张表里通盘看一遍：
|
||||
|
||||
|
||||
|
||||
这张表从上到下，编排权一步步从"你"转移到"Claude"，再转移到"代码"。Workflow 站在最右端——你只给一句任务描述，编排的活儿交给 Claude 写的脚本，规模冲到数百个 agent。
|
||||
|
||||
这里就要回到开头那个伏笔：为什么 Dynamic Workflows 和 Opus 4.8 同一天发布。当你让几百个 agent 并行干活、还要它们互相 review 彼此的结论时，每个节点的可靠性就被放大了——节点是概率性的 LLM，同一个问题换个角度问都可能给出不一致的答案，而多步流程里的不确定性会层层累积。Opus 4.8 这一代专门强化了这块：官方说它"**让代码缺陷悄悄溜过、不被发现的概率比前一代低了约四倍**"，更倾向于主动标记自己拿不准的地方。这种诚实性的提升，正是"数百 agent 交叉验证"这套打法能成立的前提——交叉验证要管用，前提是 reviewer 真的会指出问题，而不是一味点头。强模型不是 Workflow 的可选项，是它的承重墙。
|
||||
|
||||
最后把 Workflow 放进更大的图景里看。它把"编排逻辑代码化"作为一个明确的产品选择，这件事本身值得玩味：编排从模型每次现想现做的临时行为，变成了一段可以读、可以审、可以存、可以反复跑的代码资产。把它和 Codex 的 Goals 摆在一起看，会发现一个有趣的分野。两者都想解决"大任务怎么持续推进"，但路径相反：Codex Goals 押注的是**目标持久化**——把目标钉在那，让模型自己想办法一步步逼近；Claude Code Workflow 走的则是**编排代码化**这条路——把过程写成脚本，靠脚本保证流程不跑偏。一个管"往哪走"，一个管"怎么走"，是两套不同的工程哲学。哪条路最后跑得更远现在下结论还太早，但两家头部产品在"承载超大规模工作"这个问题上同时发力，本身就说明这是 AI Coding 下一阶段的主战场。
|
||||
|
||||
最后，说点我自己的判断。我觉得 dynamic workflow 这套东西相当强大，大概率代表了未来的方向。它能站住，靠的是两块拼图严丝合缝：一块是把"编排"从模型的临场发挥固化成可控的代码，另一块是一个足够诚实、足够强的前沿模型，撑得起几百个 agent 互相交叉验证——这也正是它要跟 Opus 4.8 同天登场的原因。前沿模型是地基，编排代码化则是让"几百个 agent 协作还不跑偏"成为可能的关键，两者缺一不可。
|
||||
|
||||
也正因为它对前沿模型的能力依赖得这么深，我的判断是：一年之内，这套"模型现写编排脚本、再调度一支 agent 舰队"的打法，会从某一家的研究预览，长成几乎所有 coding agent 的标配。
|
||||
|
||||
顺带一提，这篇文章背后的调研，本身就是一个 Workflow 跑出来的：**十五个 agent 并行**分头干活——精读一手对话记录、交叉比对业界资料——**27 万 token、169 秒**，最后汇成一份素材交回来。用 Workflow 把 Workflow 讲清楚，大概是对它最直接的一次试用。
|
||||
|
||||
## 参考资料
|
||||
|
||||
- [Dynamic workflows 官方文档](https://code.claude.com/docs/en/workflows)
|
||||
- [Introducing dynamic workflows in Claude Code（官方发布博客）](https://claude.com/blog/introducing-dynamic-workflows-in-claude-code)
|
||||
- [Claude Opus 4.8 发布说明](https://www.anthropic.com/news/claude-opus-4-8)
|
||||
- [Run agents in parallel（官方对比 subagent / agent teams / workflow）](https://code.claude.com/docs/en/agents)
|
||||
- [Building Effective Agents（Anthropic 对 workflow 与 agent 的定义）](https://www.anthropic.com/research/building-effective-agents)
|
||||
- [Headless / \`claude -p\` 官方文档](https://code.claude.com/docs/en/headless)
|
||||
- [Bun “Rewrite Bun in Rust” PR（oven-sh/bun #30412）](https://github.com/oven-sh/bun/pull/30412)
|
||||
203
4 - Resources/Claude-Code/ECC orch- 编排家族与 v2.0 团队编排.md
Normal file
203
4 - Resources/Claude-Code/ECC orch- 编排家族与 v2.0 团队编排.md
Normal file
@@ -0,0 +1,203 @@
|
||||
---
|
||||
created: "2026-06-18"
|
||||
type: resource
|
||||
tags: [resource, claude-code, ECC, orchestration, multi-agent, orch-pipeline, dynamic-workflow, team-orchestration]
|
||||
source: "https://github.com/affaan-m/ECC"
|
||||
---
|
||||
|
||||
# ECC orch-* 编排家族与 v2.0 团队编排
|
||||
|
||||
> 本笔记补的是 **ECC v2.0.0(2026-06-09)新增**的编排层。早期编排笔记停在 2026-04,覆盖的是 `/orchestrate`(已退役)、`/multi-*`、GSD、devfleet、自治循环。这一篇专门讲 **`orch-*` 家族、`plan-orchestrate`、团队编排(Kanban)、动态工作流**,以及 2.0 的"操作员系统"理念。
|
||||
>
|
||||
> 相关:[[ECC 编排实战手册]]、[[ECC 编排替代方案 (orchestrate 迁移)]]、[[Autonomous Loops 自主循环模式]]、[[Ralphinho RFC-DAG 编排模式]]、[[Everything Claude Code 完整指南]]、[[Everything Claude Code Agent 编排模式]]
|
||||
|
||||
---
|
||||
|
||||
## 1. `orch-*` 家族 —— 把单会话流程产品化
|
||||
|
||||
`/orchestrate` 退役后,ECC 2.0 用 **`orch-*` skill 家族**取而代之。这不是 5 个独立流程,而是 **5 个薄包装(thin wrapper)共用一个引擎 `orch-pipeline`**。包装层只做三件事:给任务**分级**、决定**跑哪几个阶段**、把每个阶段**委派**给现成的 ECC agent/命令。**它不重新实现任何东西**(`/feature-dev`、`/plan`、`/code-review`、`/build-fix`、`/refactor-clean`、`/gan-build`、`tdd-workflow` 都是被它编排的)。
|
||||
|
||||
### 五个操作 = 五种任务意图
|
||||
|
||||
| skill | 操作 | 触发条件 | 默认尺寸 | 第一步(关键) |
|
||||
|-------|------|---------|---------|--------------|
|
||||
| `orch-add-feature` | feature | 能力**还不存在** | standard | 先写**新**失败测试 → 实现 |
|
||||
| `orch-fix-defect` | fix | 行为**坏了** | small | 先写**回归**失败测试 → 修 |
|
||||
| `orch-change-feature` | tweak | 行为在但**不符合期望** | small | 先改**现有**测试到新规格 → 改实现 |
|
||||
| `orch-refine-code` | refactor | 行为不变、**结构**改善 | standard | 先确认测试绿 → 重构 |
|
||||
| `orch-build-mvp` | mvp | 从 design/spec **文档引导** | large | 读文档 → 切薄竖切片(vertical slices) |
|
||||
|
||||
> 选错入口没关系:引擎会先分级,small/trivial 的 feature 会自动塌缩成 `4→5→6`。
|
||||
|
||||
### 共用引擎 `orch-pipeline` —— 门控的 R-P-T-R-C 流水线
|
||||
|
||||
七个阶段(Phase 0 永远跑):
|
||||
|
||||
- **0 Intake** —— 复述请求;MVP 还要读 spec 抽 scope/锁定决策/功能清单
|
||||
- **1 Research & Reuse** —— `gh search repos/code` → Context7/官方文档 → 包仓库 → Exa;**优先采用现成实现**
|
||||
- **2 Plan** —— 委派 `planner`(结构性改动用 `architect`/`code-architect`),产出 `task_list`(薄竖切片排序)→ **GATE 1**
|
||||
- **3 Scaffold** —— 仅 MVP:立起第一个端到端切片
|
||||
- **4 Implement (TDD)** —— 走 `tdd-guide`/`tdd-workflow`:red→green→refactor,遵守该操作的"第一步"规则
|
||||
- **5 Review** —— `code-reviewer`/`/code-review`;碰安全触发器加 `security-reviewer`
|
||||
- **6 Commit** —— conventional commit,每个逻辑块一个 → **GATE 2**
|
||||
|
||||
### 核心设计:仪式随"爆炸半径"缩放(right-sizing)
|
||||
|
||||
Step 0 按三个信号(改动文件数 / 是否引入新依赖或契约 / 设计模糊度)取**最高**那一档:
|
||||
|
||||
| Tier | 文件 | 新依赖·契约 | 模糊度 | 跑哪些阶段 |
|
||||
|------|------|------------|--------|-----------|
|
||||
| trivial | 1、几行 | 无 | 改动显而易见 | 4 → 5 → 6 |
|
||||
| small | 1 文件/函数 | 无 | 读完代码就清楚 | (1 轻量) → 4 → 5 → 6 |
|
||||
| standard | 2–5 文件 | 可能新内部模块 | 一个真实选择 | 1 → 2 → 4 → 5 → 6 |
|
||||
| large | 多/横切 | 新外部依赖、公开 API、spec 文档 | 多个开放问题 | 1 → 2 → (3) → 4 → 5 → 6 |
|
||||
|
||||
> 平局打破:碰**安全触发器**或**公开 API/契约**的,无论文件多少,**至少 standard**。
|
||||
|
||||
### 两道人类门(gated, not autonomous)
|
||||
|
||||
1. **GATE 1(Plan 之后)** —— 先给 `task_list`,用户批准前**不写实现代码**
|
||||
2. **GATE 2(Commit 之前)** —— 先给 diff 摘要 + 提交信息,用户确认前**不提交**
|
||||
|
||||
两门之间一路不停。这正是 `orch-*` 与全自治循环([[Autonomous Loops 自主循环模式]])的根本区别:**有人在环**。
|
||||
|
||||
### 阶段→agent 映射
|
||||
|
||||
| 阶段 | 主用 | 兜底/升级 |
|
||||
|------|------|----------|
|
||||
| Intake/理解 | `code-explorer` | tweak/fix/refactor 前先 trace 现有路径 |
|
||||
| Plan | `planner` | `architect`、`code-architect`(结构性) |
|
||||
| Implement | `tdd-guide` / `tdd-workflow` | 构建炸了用 `build-error-resolver`/`/build-fix` |
|
||||
| Review | `code-reviewer` / `/code-review` | 语言专属 reviewer(python/typescript-reviewer…) |
|
||||
| Security | `security-reviewer` | — |
|
||||
| MVP 内循环 | `/gan-build "<brief>" --skip-planner` | 驱动 `gan-generator`→`gan-evaluator` |
|
||||
|
||||
安全触发器(任一即拉 `security-reviewer`):认证授权、用户输入、DB 查询、文件路径、外部 API、加密、密钥凭据。
|
||||
|
||||
> 与 `/feature-dev` 的区别:`/feature-dev` 是这套流程的**独立版**;`orch-add-feature` 通过共用 `orch-pipeline` 引擎(分级器 + 两门),让 trivial 功能能右尺寸到 `4→5→6`,并和家族其余操作保持一致。
|
||||
|
||||
---
|
||||
|
||||
## 2. `plan-orchestrate` —— 把计划文档翻译成 agent 链
|
||||
|
||||
**纯生成,不执行**。输入一份多步计划(PRD/RFC/implementation plan),输出**每步一条可直接粘贴**的 `/orchestrate custom` 调用。三件事:
|
||||
|
||||
1. **检测 ECC 安装模式** —— plugin 形态命令是 `/everything-claude-code:orchestrate`、agent 是 `everything-claude-code:<name>`;legacy 形态是 `/orchestrate`、`<name>`。**一份输出里不混用两种**。
|
||||
2. **拆步骤**(六级优先:显式编号 `## Step N` > 表格 Step 列 > `---` 分隔的动词块 > 否则每个 H2 一步)
|
||||
3. **打标签 + 选 agent 链**(12 个触发词 → 默认链):
|
||||
|
||||
| 标签 | 默认 agent 链 |
|
||||
|------|--------------|
|
||||
| `design` | `planner,architect` |
|
||||
| `impl` | `tdd-guide,<lang>-reviewer` |
|
||||
| `impl+security` | `tdd-guide,<lang>-reviewer,security-reviewer` |
|
||||
| `impl+db` | `tdd-guide,database-reviewer,<lang>-reviewer` |
|
||||
| `refactor` | `architect,refactor-cleaner,<lang>-reviewer` |
|
||||
| `migration` | `architect,tdd-guide,<lang>-reviewer` |
|
||||
| `build` | `<lang>-build-resolver` |
|
||||
| `security` | `security-reviewer,<lang>-reviewer` |
|
||||
| `test` | `tdd-guide,e2e-runner` |
|
||||
| `db` | `database-reviewer,<lang>-reviewer` |
|
||||
| `docs` | `doc-updater` |
|
||||
| `loop` | `loop-operator` |
|
||||
|
||||
输出含:全步骤总表、每步详情块(意图 + 选链理由 + 可粘贴命令)、批量执行块。
|
||||
|
||||
---
|
||||
|
||||
## 3. 团队编排 —— Agent Kanban
|
||||
|
||||
### `team-agent-orchestration`:把 agent 当队友
|
||||
|
||||
核心:agent 要有**显式 owner、scope、状态、合并门**。用 Agent Kanban 让并行工作可见。
|
||||
|
||||
**列(及退出标准)**:Backlog(写好验收) → Ready(分配 owner+分支/worktree) → Running(有 handoff 产物+改动文件) → Review(测试/diff/风险通过) → Merged。另有 Blocked(blocker 有 owner+下一步)、Archived。
|
||||
|
||||
**工作项 schema**(关键字段):`id / title / owner / state / branch / worktree / acceptance[] / merge_gate / handoff`。
|
||||
|
||||
**控制面板(control pane)应暴露**:活跃工作项及状态、owner/harness/分支/worktree/心跳、handoff/测试/PR 链接、按 owner 分组的 blocker、**按 gate 而非感觉判断的合并就绪度**、可复用工作流候选。
|
||||
|
||||
> 关键口号:**merge gate, not hope gate**(用门判断能否合并,而不是凭希望)。
|
||||
|
||||
### `team-builder`:按需组队
|
||||
|
||||
交互菜单从可用 agent 里拼并行团队。流程:`claude agents` 发现 agent → 按领域分组菜单 → 接受编号("1,3")或名字("security + seo") → **上限 5 个**(再多边际递减) → 用 Agent 工具 `subagent_type: general-purpose` 并行 spawn → 汇总(各 agent 输出 + 一致/冲突/建议)。
|
||||
|
||||
> 注意:用**并行 Agent 工具调用**(各自独立做事),不是 TeamCreate(那是给 agent 之间对话用的)。
|
||||
|
||||
---
|
||||
|
||||
## 4. `dynamic-workflow-mode` —— 为任务现造载体
|
||||
|
||||
让 agent 能**生成/改造工作流**,而不只执行静态命令。何时启用:任务需要自定义 loop/评估器/爬虫/fixture 生成器/watcher/dashboard;多个 agent 要同一可重复流程(但还没沉淀成 skill);需要持久 handoff 产物、eval 证据或操作员批准。
|
||||
|
||||
**决策树**:一次性 → 内联;输入会变的重复任务 → 建**任务局部载体(task-local harness)**;跨队友/跨仓库重复 → **抽成共享 skill**;有外部状态/排队/审批 → 先加控制面板可见性;有安全风险 → 加 eval 门 + 人类合并门。
|
||||
|
||||
**抽成共享 skill 的条件**(满足 ≥2):多会话/仓库/团队重复出现、需要特定语言/工具/安全顺序、失败反复发生、输入输出契约稳定、能受益于控制面板/状态板/团队 handoff。
|
||||
|
||||
**每类工作最便宜的可靠 eval 门**:代码 → 聚焦测试+lint+覆盖率+一条集成路径;UI → 浏览器冒烟+截图+溢出/报错检查;agent 工作流 → fixture transcript / 带预期路由的种子工作项;研究/内容 → 来源中立的 brief + claim 清单;集成 → dry-run 命令 + 配置校验 + 无密钥扫描。
|
||||
|
||||
---
|
||||
|
||||
## 5. v2.0 编排理念:操作员系统(operator system)
|
||||
|
||||
ECC 2.0 的论点:agent 工具正从"单人聊天窗"走向**团队编排系统**(看板、控制面板、动态工作流、eval 门、共享 skill)。三层架构:
|
||||
|
||||
1. **Meta-harness** —— 可移植的 skills/rules/hooks/MCP 约定/发布门/eval/安全证据
|
||||
2. **专属 ECC agent** —— 一个**操作** ECC 资产的 agent(不只把它们当静态指令读)
|
||||
3. **控制面板 / agentic IDE** —— 把 session/队列/skill/记忆/证据/发布/团队工作流变成**可观测**的操作员界面
|
||||
|
||||
提炼出的几条编排原则(可单独当 zettel 看,见 [[20260618073140 编排即排序门控与委派]]):
|
||||
|
||||
1. **编排 = 排序 + 门控 + 委派**(不是新 AI):价值在系统化排序、两道门、委派给被验证过的 agent。
|
||||
2. **仪式随爆炸半径缩放**:trivial 跳过 Research/Plan;large 才上全套 + 安全审查。(同样体现在 Ralphinho 的 tier 分层、`parallel-execution-optimizer` 的"只在写面不冲突处并行"。)
|
||||
3. **权威随领域走**:Codex=后端权威、Gemini=前端权威、Claude=代码主权(所有落盘);跨域意见仅供参考。(见 [[ECC 编排替代方案 (orchestrate 迁移)]] 路线 D)
|
||||
4. **并行必须有可观测的合并门**:每个并行单元都要有 owner、分支/worktree、验收、证据(测试/截图)、merge gate。
|
||||
5. **可复用的资产是工作流,不是答案**:一次性答案会扔;证明答案可用的任务局部载体有价值;多团队复用的共享 skill 才是制度资产。
|
||||
6. **控制面板胜过隐藏的聊天输出**:"谁拥有这张卡、改了什么、什么失败、什么通过、什么能合并"才是操作员真正需要的。
|
||||
|
||||
---
|
||||
|
||||
## 6. 这一层在整张编排图里的位置
|
||||
|
||||
| 你要的 | 用 | 出处 |
|
||||
|--------|-----|------|
|
||||
| 单任务全流程、要分级 + 两道人类门 | `orch-add-feature` / `orch-fix-defect` / `orch-change-feature` / `orch-refine-code` | skill |
|
||||
| 从 design/spec 文档起 MVP | `orch-build-mvp` | skill |
|
||||
| 把一份 PRD/RFC 翻成可粘贴的 agent 链 | `plan-orchestrate` | skill(纯生成) |
|
||||
| 多 agent 并行 + 看板可见性 + 合并门 | `team-agent-orchestration` | skill |
|
||||
| 按需从可用 agent 拼并行小队(≤5) | `team-builder` | skill |
|
||||
| 给任务现造 loop/评估器/dashboard | `dynamic-workflow-mode` | skill |
|
||||
| 全自治长跑循环 | 见 [[Autonomous Loops 自主循环模式]]、[[Ralphinho RFC-DAG 编排模式]] | — |
|
||||
| 跨 harness/tmux 并行 | 见 [[ECC 编排实战手册]]、[[dmux 多Agent并行编排]] | — |
|
||||
|
||||
---
|
||||
|
||||
## 来源(直接读取的仓库文件)
|
||||
|
||||
- `skills/orch-pipeline/SKILL.md`(共用引擎:5 操作、Step 0 分级表、7 阶段、两门、agent 映射、安全触发器)
|
||||
- `skills/orch-add-feature/SKILL.md` 及 `orch-fix-defect/`、`orch-change-feature/`、`orch-refine-code/`、`orch-build-mvp/`
|
||||
- `skills/plan-orchestrate/SKILL.md`(安装模式检测、拆步、12 标签链)
|
||||
- `skills/team-agent-orchestration/SKILL.md`(Kanban 列、work item schema、control pane)
|
||||
- `skills/team-builder/SKILL.md`、`skills/dynamic-workflow-mode/SKILL.md`
|
||||
- `skills/parallel-execution-optimizer/SKILL.md`
|
||||
- `docs/architecture/cross-harness.md`、`docs/architecture/platform-value-loop.md`、`docs/business/team-agent-orchestration-content-pack.md`
|
||||
- `CHANGELOG.md`(2.0.0 Added: "orch-* orchestrator skill family and dynamic workflow team orchestration")
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
### Resources
|
||||
- [[ECC 编排实战手册]]
|
||||
- [[ECC 编排替代方案 (orchestrate 迁移)]]
|
||||
- [[Autonomous Agent Harness 自主代理框架]]
|
||||
- [[Autonomous Loops 自主循环模式]]
|
||||
- [[Ralphinho RFC-DAG 编排模式]]
|
||||
- [[dmux 多Agent并行编排]]
|
||||
- [[Everything Claude Code 完整指南]]
|
||||
|
||||
### Zettelkasten
|
||||
- [[20260618073140 编排即排序门控与委派]]
|
||||
- [[Everything Claude Code Agent 编排模式]]
|
||||
- [[Everything Claude Code 多服务编排详解]]
|
||||
31
6 - Zettelkasten/20260618073140 编排即排序门控与委派.md
Normal file
31
6 - Zettelkasten/20260618073140 编排即排序门控与委派.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
created: "2026-06-18 07:31"
|
||||
type: zettel
|
||||
tags: [zettel, claude-code, orchestration, agent-orchestration, design-principle]
|
||||
source: "https://github.com/affaan-m/ECC"
|
||||
---
|
||||
|
||||
# 编排即排序门控与委派
|
||||
|
||||
好的 agent 编排不靠"更聪明的 AI",而是三件事的组合:**排序 + 门控 + 委派**。
|
||||
|
||||
ECC 的 `orch-pipeline` 是最干净的例证:它**不重新实现任何东西**。它的全部价值在于把现成 agent(planner、tdd-guide、code-reviewer…)按 Research→Plan→Implement→Review→Commit **排好序**,在两个关键点**设人类门**(Plan 后批准 task_list、Commit 前确认 diff),然后把每一步**委派**出去。包装层(`orch-add-feature` 等 5 个)只负责分类意图和选阶段。
|
||||
|
||||
配套的关键原则:**仪式随爆炸半径缩放(ceremony scales to blast radius)**。改一行的 trivial 改动直接 `Implement→Review→Commit`,跳过 Research/Plan;横切、引入新依赖或动公开 API 的 large 改动才上全套 + 安全审查。把全套流程套在小改动上,和让大改动裸奔,是同一种错误的两面。
|
||||
|
||||
> 推论:当你想"造一个更强的编排器"时,先问——我是不是只需要把已有的步骤**排好序、设好门、委派对人**?新增的往往应该是 sequencing 和 gate,而不是新实现。
|
||||
|
||||
这条原则在 ECC 各处复现:Ralphinho 的 tier 分层(trivial 只 implement→test,large 才加 final-review)、`parallel-execution-optimizer`(只在写面不冲突处并行)、Santa Loop(评审者≠作者的强制隔离)。
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- [[ECC orch- 编排家族与 v2.0 团队编排]]
|
||||
- [[Everything Claude Code Agent 编排模式]]
|
||||
- [[Ralphinho RFC-DAG 编排模式]]
|
||||
- [[上下文腐烂与全新窗口隔离]]
|
||||
|
||||
## Source
|
||||
|
||||
- `skills/orch-pipeline/SKILL.md`(ECC v2.0)— "The orch-* skills are thin wrappers. They do not re-implement any work." / "Ceremony scales to blast radius."
|
||||
Reference in New Issue
Block a user