尧图网页设计 
拆 Multi-Agent 之前先算这四本账之前写了最小 ReAct Agent结尾埋了一句“多 Agent 协作再上框架”。收藏榜上 Multi-Agent 决策帖双榜出现说明这个纠结很普遍职责打架就想拆 Multi-Agent几乎人人冒过这个念头。这篇把这笔账算全再给一个真拆时的最小实现。一、拆之前算四本账账拆的代价Token每个 Agent 各自维护完整上下文直接翻倍甚至三倍LatencyAgent 之间要串行/协调编排延迟上升Complexity从“一个 loop”变成“多个 Agent 的消息协议”复杂度暴涨Failure Surface失败面 ×N任何一个 Agent 出错都拖垮整体收益也真实职责清晰prompt 短而专、单点好调出错只调对应 Agent、可并行。一句话铁律Multi-Agent 不是为了看起来先进是职责冲突大到“拆开的收益超过四本账”的那一刻才做的决定。二、先试轻的节点不是 Agent多数“职责打架”用不着真拆 Agent。同一个执行流程里抽一个独立步骤节点共享上下文成本几乎为零。典型场景调研者舍不得否定自己刚找到的线索——把“审查”抽成独立节点冲突就没了Token 成本不变。节点和 Agent 的区别一句话节点是流程里的一步共享上下文Agent 是独立智能体有自己的上下文和工具。节点解决不了再拆 Agent。三、真要拆最小实现协调者 工种# multi_agent.py — 最小 Multi-Agent协调者 工种 Agent # 依赖pip install openai export OPENAI_API_KEYsk-xxx import json from openai import OpenAI client OpenAI() AGENTS { researcher: 你是调研员只输出事实要点每条一句话不写套话不下结论。, writer: 你是撰稿人把拿到的要点写成一段连贯结论不超过 150 字。, } JSON \n只输出 JSON: {result: 你的输出} def run_plan(task): 协调者拆任务每步指派一个工种最后一步必须是 writer resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是协调者把任务拆成不超过 3 步每步指派给一个工种。 可用工种: researcher(查要点) / writer(写结论)。 只输出 JSON: {plan: [{agent: 工种, task: 做什么}]} 最后一步必须是 writer。}, {role: user, content: task}, ], response_format{type: json_object}, ) return json.loads(resp.choices[0].message.content)[plan] def validate_plan(plan, max_hops3): plan 校验工种存在、最后一步收尾、步数封顶 assert plan and plan[-1][agent] writer, 最后一步必须是 writer assert all(s[agent] in AGENTS for s in plan), 指派了不存在的工种 return plan[:max_hops] def run_agent(name, task, context): 单个工种独立上下文只看自己的任务 上一步要点 resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: AGENTS[name] JSON}, {role: user, content: f{task}\n\n已知要点:\n{context}.strip()}, ], response_format{type: json_object}, ) return json.loads(resp.choices[0].message.content)[result] def run_multi(task): results [] for step in validate_plan(run_plan(task)): results.append(run_agent(step[agent], step[task], context\n.join(results))) return results[-1] # 最后一步writer的输出 if __name__ __main__: # 离线自检plan 校验逻辑不花 API ok [{agent: researcher, task: 查要点}, {agent: writer, task: 写结论}] assert validate_plan(ok) ok for bad in ([{agent: ghost, task: ?}], # 不存在的工种 [{agent: researcher, task: ?}]): # 缺 writer 收尾 try: validate_plan(bad) assert False, 校验没拦住 except AssertionError: pass print(self-check ok)设计要点三条每个工种独立上下文只看到自己的任务 上一步的要点。全量历史传下去等于没拆上下文互相踩就是拆之前的老问题协调者的 plan 必须校验工种存在、最后一步收尾、步数封顶——协调者幻觉出不存在工种整个流程直接崩工种职责必须互斥调研员只出要点不下结论撰稿人只写结论不查——职责重叠比不拆还糟四、三个踩坑协调者无限递归协调者反复改 plan 不收敛。validate_plan 步数封顶双保险超了直接返回当前最好结果上下文全量传递把前面所有 Agent 的完整输出都塞给下一个Token 翻倍的账就是这么来的。只传要点宁缺勿全输出格式抖动多 Agent 之间传 JSON格式不稳一处崩全链。JSON mode 入口校验别靠 prompt 喊五、总结铁律压成三句拆之前算四本账Token / Latency / Complexity / Failure Surface先试节点共享上下文的独立步骤再试 Agent拆出来的职责必须互斥协调必须封顶 拆 Multi-Agent 之前，先算这四本账
拆 Multi-Agent 之前先算这四本账之前写了最小 ReAct Agent结尾埋了一句“多 Agent 协作再上框架”。收藏榜上 Multi-Agent 决策帖双榜出现说明这个纠结很普遍职责打架就想拆 Multi-Agent几乎人人冒过这个念头。这篇把这笔账算全再给一个真拆时的最小实现。一、拆之前算四本账账拆的代价Token每个 Agent 各自维护完整上下文直接翻倍甚至三倍LatencyAgent 之间要串行/协调编排延迟上升Complexity从“一个 loop”变成“多个 Agent 的消息协议”复杂度暴涨Failure Surface失败面 ×N任何一个 Agent 出错都拖垮整体收益也真实职责清晰prompt 短而专、单点好调出错只调对应 Agent、可并行。一句话铁律Multi-Agent 不是为了看起来先进是职责冲突大到“拆开的收益超过四本账”的那一刻才做的决定。二、先试轻的节点不是 Agent多数“职责打架”用不着真拆 Agent。同一个执行流程里抽一个独立步骤节点共享上下文成本几乎为零。典型场景调研者舍不得否定自己刚找到的线索——把“审查”抽成独立节点冲突就没了Token 成本不变。节点和 Agent 的区别一句话节点是流程里的一步共享上下文Agent 是独立智能体有自己的上下文和工具。节点解决不了再拆 Agent。三、真要拆最小实现协调者 工种# multi_agent.py — 最小 Multi-Agent协调者 工种 Agent # 依赖pip install openai export OPENAI_API_KEYsk-xxx import json from openai import OpenAI client OpenAI() AGENTS { researcher: 你是调研员只输出事实要点每条一句话不写套话不下结论。, writer: 你是撰稿人把拿到的要点写成一段连贯结论不超过 150 字。, } JSON \n只输出 JSON: {result: 你的输出} def run_plan(task): 协调者拆任务每步指派一个工种最后一步必须是 writer resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是协调者把任务拆成不超过 3 步每步指派给一个工种。 可用工种: researcher(查要点) / writer(写结论)。 只输出 JSON: {plan: [{agent: 工种, task: 做什么}]} 最后一步必须是 writer。}, {role: user, content: task}, ], response_format{type: json_object}, ) return json.loads(resp.choices[0].message.content)[plan] def validate_plan(plan, max_hops3): plan 校验工种存在、最后一步收尾、步数封顶 assert plan and plan[-1][agent] writer, 最后一步必须是 writer assert all(s[agent] in AGENTS for s in plan), 指派了不存在的工种 return plan[:max_hops] def run_agent(name, task, context): 单个工种独立上下文只看自己的任务 上一步要点 resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: AGENTS[name] JSON}, {role: user, content: f{task}\n\n已知要点:\n{context}.strip()}, ], response_format{type: json_object}, ) return json.loads(resp.choices[0].message.content)[result] def run_multi(task): results [] for step in validate_plan(run_plan(task)): results.append(run_agent(step[agent], step[task], context\n.join(results))) return results[-1] # 最后一步writer的输出 if __name__ __main__: # 离线自检plan 校验逻辑不花 API ok [{agent: researcher, task: 查要点}, {agent: writer, task: 写结论}] assert validate_plan(ok) ok for bad in ([{agent: ghost, task: ?}], # 不存在的工种 [{agent: researcher, task: ?}]): # 缺 writer 收尾 try: validate_plan(bad) assert False, 校验没拦住 except AssertionError: pass print(self-check ok)设计要点三条每个工种独立上下文只看到自己的任务 上一步的要点。全量历史传下去等于没拆上下文互相踩就是拆之前的老问题协调者的 plan 必须校验工种存在、最后一步收尾、步数封顶——协调者幻觉出不存在工种整个流程直接崩工种职责必须互斥调研员只出要点不下结论撰稿人只写结论不查——职责重叠比不拆还糟四、三个踩坑协调者无限递归协调者反复改 plan 不收敛。validate_plan 步数封顶双保险超了直接返回当前最好结果上下文全量传递把前面所有 Agent 的完整输出都塞给下一个Token 翻倍的账就是这么来的。只传要点宁缺勿全输出格式抖动多 Agent 之间传 JSON格式不稳一处崩全链。JSON mode 入口校验别靠 prompt 喊五、总结铁律压成三句拆之前算四本账Token / Latency / Complexity / Failure Surface先试节点共享上下文的独立步骤再试 Agent拆出来的职责必须互斥协调必须封顶