Workflow 系列（04）：Multi-Agent 协调——编排器边界、并发控制与上下文隔离
编排器的职责边界Orchestrator（主 Agent）和 Subagent（子 Agent）的分工不清楚，是 Multi-Agent 工作流最常见的设计问题。Orchestrator 做三件事：1. 决策：读取状态，判断下一步 2. 分派：spawn 子 Agent，传递 task prompt 3. 收集：读取子 Agent 的输出文件，更新状态Orchestrator 不做的事：× 不直接执行业务逻辑（分析 Bug、写代码、查日志） × 不读取原始日志文件或长文本（会让上下文膨胀） × 不修改业务数据（只有子 Agent 有操作权限）主 Agent 只接收结构化结论（JSON），不接收原始输出。子 Agent 用output.json向主 Agent 汇报，不用消息流。# ✅ 正确：主 Agent 读结构化结论result=json.loads(Path("phase3/analysis_final.json").read_text())ifresult["confidence"]=95:proceed_to_phase4()# ❌ 错误：主 Agent 读原始日志log_content=Path("crash.log").read_text()# 10万行日志进了主 Agent 的上下文decision=llm.analyze(log_content)# 主 Agent 不该做这个这个边界带来两个好处：主 Agent 的上下文保持可控（只有状态和结论，没有原始数据）；子 Agent 的业务逻辑可以独立测试，不依赖主 Agent 的会话历史。子 Agent 的设计原则原则 1：输入完备性子 Agent 的 task prompt 必须包含它完成任务所需的一切。# ❌ 不完备的 task prompt 分析这个 Bug 的根因，参考之前的分析结果。 # ✅ 完备的 task prompt ## 任务 分析以下 Bug 的根因。 ## 输入 Bug 信息： { { bug_info.summary }} { { bug_info.stack_trace }} 日志目录：{ { log_dir }} ## 输出要求 写入 analysis_final.json，格式： {"confidence": float, "root_cause": str, "evidence": [str]}"参考之前的分析结果"依赖子 Agent 能访问主 Agent 的上下文历史，在隔离会话里这不成立。每个子 Agent 只知道 task prompt 里给它的内容。原则 2：输出契约严格性子 Agent 必须按约定的 JSON Schema 写输出文件。主 Agent 依赖这个 Schema 做路由决策，字段缺失或类型错误会导致主 Agent 的判断逻辑失败。# 子 Agent 输出 Schema（在 templates/ 里定义）OUTPUT_SCHEMA={"passed":bool,# 必填，主 Agent 路由决策
 – 热辐射)
![[智能体-614]：OpenClaw构建智能体的过程，本质是围绕大模型，在智能体框架引擎的驱动下，用自然语言构建数字化公司的过程](http://pic.xiahunao.cn/yaotu/[智能体-614]：OpenClaw构建智能体的过程，本质是围绕大模型，在智能体框架引擎的驱动下，用自然语言构建数字化公司的过程)