之前聊过一个问题：agent workflow 中，节点之间的 artifact 应该怎么设计？两条路。一条是 self-describing——上游把自己的产出写清楚，下游自己提取。另一条是 requirement-driven——下游声明期望，上游按要求产出。
这两条路不是对立的。一个好的 workflow 应该同时要求两者：每个节点既要对自己的产出负责，也要对自己的输入来源负责。类比人类团队——你希望每个人既能把活干清楚、让接手的人不用猜，也能在收到模糊需求时主动追问而不是自己瞎猜。两个方向都有，信息传递才不至于散架。
agent 系统比人类团队多一个优势：它可以强制保证对称性。人类组织里，资深工程师可以对下属要求精确的输入，同时交付模糊的产出让下属自己琢磨——权力结构允许这种不对称。agent 系统里没有层级，只有节点，每个节点既是上游也是下游。如果你把所有节点配置成同时做到 self-describing 和 requirement-driven，这份对称性是机器保证的——不会有人偷懒。
但对称性再完美，有一个天花板是节点自己永远突破不了的：每个节点只能看到自己周围的东西。
上游知道自己的产出格式，知道直接下游的需求，但它不知道整个 workflow 里还有哪些边、哪些边的合约冲突在反复消耗 tokens、哪些工作其实在两个节点里被重复做了。下游也一样——它能适应一份不够理想的输入，但它不知道这次适应推断是不是和 workflow 里另一个节点的推断产生了矛盾。每个节点的局部优化都是合理的、尽责的、不该被指责的。局部合理加起来不等于全局和谐。这不是任何人的错——是视野的物理限制。
回到人类团队的类比：你组里每个人都靠谱、主动、自驱力强。但如果没有一个人能看到所有人的工作状态——谁和谁的信息传递存在系统性摩擦、哪里的工作被两个人各自独立做了一遍、哪条链路的成本增长正在失去控制——这个团队就跑不远。你需要的不只是每个人做好自己，而是在这之上加一层全局视野。
编排器就是这个全局视野的承载者。
编排器不是做什么的，是能看到什么
先把一个常见的误解说清楚。编排器的工作不是"管着节点"——不是在替节点做它们该做的事，不是在监督节点的工作质量，不是在给节点打分。如果上游产出不够 self-describing，那是上游该修的。如果下游没有声明自己的输入要求，那是下游该修的。编排器不是来替它们善后的。
编排器提供的，是节点无论多努力都无法自己获得的东西：同时看到所有节点、所有边、所有 artifact 的完整图景。
有了这个视野，编排器能做几件节点自己做不到的事。
第一，发现跨节点的合约 gap。 上游的产出格式声明和下游的输入需求声明之间有没有缺口？这个缺口在单个节点看来是"上游做得不够"或者"下游要求太多"，但编排器能看到两边的完整上下文——上游为什么没有包含这个信息（因为它觉得不属于这个步骤），下游为什么需要这个信息（因为后续节点依赖它）。编排器的判断不是"谁对谁错"，而是"这个 gap 对整个 workflow 的影响有多大，值不值得现在填"。
第二，发现跨节点的重复工作。 前端团队的 sub-workflow 里有一个"代码结构分析"步骤，后端团队的 sub-workflow 里也有一个。两个步骤分析的是同一个 repo，做的是同一件事。独立创作时完全合理——前端不知道后端的 sub-workflow 内容，后端也不知道前端的。但编排器能看到两者，能识别出冗余，能把两个步骤合并成一个，输出同时路由给前后端各自的后续节点。
这种去重，不是任何一个节点能做的。它需要全局视野。这就像编译器的 link-time optimization——每个 .o 文件独立编译时只做本地优化，链接时再做跨模块的全局优化。编排器是 LTO for workflows。
第三，发现系统性的成本异常。 编排器能看到 workflow 里每条边的 token 消耗。GitHub 的 ET 模型对 output token 的定价是 input token 的 4 倍——合约不对齐导致的浪费，大头在 output 侧。下游 agent 反复读上游产出、自己推断缺失字段、在 prompt 里自我纠正、产出后标记不确定内容——每一步都在烧 output tokens。单个节点不知道自己的 token 消耗是否合理，因为它没有参照系。编排器能看到所有边，能告诉你：这条边的 token 消耗是 workflow 平均值的 3 倍，可能有问题。
第四，提供一份系统级的健康报告。 当编排器完成了合约比对、去重检查、成本分析之后，这些信息本身就构成了一份 workflow 健康报告。哪些边被标记为高风险、需要动态介入？哪些边的 token 消耗异常？哪些重复工作分布在哪些 sub-workflow 之间？这不是代码 review，不是功能测试——而是合约结构的健康检查，是节点自己想做但做不了的事。
你会发现这四件事有一个共同特点：它们都需要看到全局。 不是需要更强的 agent、更好的 prompt、更多的 skill——那些都是节点层面的事。需要的是一双能看到所有节点、所有边、所有 artifact 的眼睛。
合约协调是一个很好的例子
在上面的四件事里，合约协调——静态协调和动态协调——值得展开讲一讲，因为它很好地说明了"全局视野下的决策"和"节点内部的决策"有什么不同。
当编排器发现上游 A 的产出格式和下游 B 的输入需求之间存在 gap，它面临的选择不是"让 A 多写还是让 B 多读"——那是节点内部的选择。编排器的选择是：这个 gap，是在 compile time 一次性处理，还是在 runtime 根据实际情况动态处理？
静态协调（orchestration time）。 在 workflow 跑起来之前，编排器完成合约比对，把处理方案 baked 进 node prompt——"上游可能不包含 X，如果缺失你自己推断并标记"——然后 runtime 不再管。这笔协调成本付一次，后续所有 run 都复用。成本低，确定性高。适合产出格式相对稳定的边。
动态协调（execution time）。 在 workflow 跑起来之后，编排器监控边的实际执行。当发现某次产出和 compile time 的预期不一致，编排器在 runtime 介入：暂停下游，收集上下文，判断是触发上游重跑还是让下游适配，还是标注异常让人工介入。灵活，但每次介入消耗 tokens。适合产出格式本身就不稳定的边。
关键的设计决策是：这个选择以边为单位，而不是以 workflow 为单位。 稳定边用静态，不稳定边用动态。同一个 workflow 混合两种策略。编排器做的是给每条边分配最合适的策略——这个决定，单个节点做不了，因为节点不知道其他边的稳定性是什么样的。
这和一个好的 tech lead 做的事差不多。不会每件事都盯——有些协作链路已经很稳定了，不需要管。有些关键接口每次都有摩擦，多花点精力盯一下。全局视野意味着你知道该把注意力放在哪里。
编排器是补全，不是替代
回到主题。self-describing 和 requirement-driven 是每个节点该有的基本素养，就像团队里每个人应该靠谱和主动。编排器不是取代这些素养，而是在它们之上补一层系统能力：看到全局，做节点看不到的优化，在效果和成本之间找最合适的平衡点。
一个健康的工作流，是节点努力做好自己，编排器努力让它们在一起的时候比各自为战更好。
我现在还没搞明白的一些事
静态协调需要在 compile time 判断合约是否匹配，但 compile time 拿不到实际产出——agent 还没跑。让节点声明自己的输出 schema 是一个方向，但 agent 在设计阶段就准确描述"我将产出什么格式"这件事本身就不靠谱。也许不需要精确匹配——编排器只要能识别"这条边大概率需要动态介入"就够了。阈值怎么定？
编排器做全局判断时，context 开销集中在自己身上。如果 workflow 边的数量很多、动态边的比例高，编排器本身的 context 可能比任何一个节点都大。这时候编排器自己是不是也需要被编排？一个递归的编排器结构会是什么样子？
编排器的全局优化决策——给某条边分配静态还是动态、判断重复工作是否值得合并、识别某条边的 token 消耗是否异常——本质上是在替人类做 tradeoff。人是应该审阅这些决策，还是信任编排器的判断？审阅粒度得多细？
参考文献
- 本文的核心论点源于 firsthand practice，在设计和运行 agent workflow 编排系统时的直接观察。
- Zylos Research (2025). Production Agent Workflow Patterns. arxiv:2603.22386. 生产环境中 agent 部署采用 DAG 边类型化合约 + 节点内部自主推理的混合模式。
- GitHub (2026). ET Model Pricing. GitHub Copilot 的 ET 模型 output token 定价为 input token 的 4 倍。
- Pact Foundation. Consumer-Driven Contracts. docs.pact.io. CDC 模式是编排器合约比对的参考之一，区别在于编排器做柔性判断而非硬性 schema 校验。
- Anthropic (2026). Claude Code Hooks Reference. code.claude.com/docs/en/hooks.
- OpenAI (2026). Codex CLI Configuration Reference. developers.openai.com/codex.