图工程多智能体编排

为什么线性 Agent 流程会拖垮复杂任务

当你把任务拆成“做 A → 然后 B → 然后 C”的线性脚本时，整个流程跑得又慢又脆。只要其中一个节点卡住，下游全部等待，单点故障会级联成全局阻塞。更糟的是，很多开发者习惯性地把所有步骤串成链，甚至把简单的列表展平、字段重命名或去空值交给 Agent 处理，白白消耗昂贵的 token，还引入不稳定性。同时，不加区分地使用同步屏障（barrier）会让不需要等待全集结果的步骤无谓挂起。

用图工程重塑工作流

Graph Engineering 将任务建模为一张图：节点是有界且职责单一的工作单元（如搜索、审查、生成），边则是真实存在的数据依赖。该技能的核心原则是：只有下游节点读取了上游节点的输出时，两者之间才建立边。

落地时遵循一套标准操作流程：

• 契约定义：为每个节点显式定义 input、output schema 和失败策略。
• 拓扑选择：默认使用 pipeline，让独立 item 各自流过多个阶段；只有需要跨来源去重、统一排序或冲突裁决时，才引入 parallel barrier。
• Reduce 逻辑下沉：把 flatten、dedupe 和 filter 这类确定性逻辑交给代码执行，不要让 Agent 干脏活累活。
• 质量保障：在边上插入对抗式验证器尝试推翻发现，并让扇入节点容忍部分分支失败为 null。

适用边界与避坑指南

并非所有任务都值得引入图编排。如果是单点事实问答或简单的文本润色，直接线性执行即可。当子任务之间共享状态极其复杂且难以隔离时，强行并行反而会放大错误风险。

此外，严禁让多个 sub-agent 并行写入同一个文件，必须分配独立路径并由主 Agent 统一合并。对于包含发布、删除或生产系统变更等外部副作用的操作，必须保持高度可审计，并在执行前获得用户的明确确认。