多智能体编排 (Multi-Agent Orchestration)
多智能体这件事很容易被讲得很热闹，好像只要把一个任务拆给几个 Agent，效果就一定更强。真正做起来以后，大多数团队都会很快碰到另一个现实：Agent 一多，延迟、成本、上下文同步和责任边界也一起上来了。
所以 Multi-Agent 不是默认更高级，而是只在某些任务结构里更合适。
[PROMPT_LAB_BANNER]
1. 为什么有人会选择多智能体
单个 Agent 的问题通常不是完全做不了，而是它要同时扮演太多角色。
比如一个任务看起来只是“做一篇技术内容”，实际里面可能同时包含：
- 调研资料
- 组织结构
- 产出正文
- 做事实核对
- 最后润色
如果都压给一个 Agent，它经常会在这些角色之间来回切，最后每一块都能做一点，但都不够稳。
Multi-Agent 的价值就在这里：不同 Agent 负责不同职责，甚至可以用不同 prompt、不同工具、不同模型。
拿一个更贴近业务的例子来说，如果你要做“行业研究报告”：
- researcher 负责搜信息和筛来源
- analyst 负责提炼趋势
- writer 负责写成稿
这种拆法通常是合理的，因为每一步的成功标准都不一样。反过来，如果你的任务只是“查一下文档里某个字段”，硬拆三个 Agent，收益通常很差。
2. 常见编排模式
A. 顺序流水线 (Sequential)
最容易理解，也最容易落地。
User -> [Agent A] -> [Agent B] -> [Agent C] -> Output
graph LR
User --> A[Agent A<br>选题]
A --> B[Agent B<br>撰稿]
B --> C[Agent C<br>润色]
C --> Output[成稿]
- 适合固定流程，比如资料整理、内容生产、报告生成。
- 好处是简单清楚，坏处是前一步做错了，错误会一路传下去。
B. 层级式 (Hierarchical)
这一种更像真实团队。
User -> [Manager Agent] -> [Worker A] / [Worker B]
graph TD
User --> Manager[经理 Agent]
Manager -->|指派任务| A[员工 A<br>调研]
Manager -->|指派任务| B[员工 B<br>写作]
A -->|汇报结果| Manager
B -->|汇报结果| Manager
- 适合复杂任务，因为 manager 可以动态分派和回收任务。
- 难点是 manager 自己必须足够稳，不然整个系统只是多了一层噪音。
C. 网状/对话式 (Conversational)
这一类最有“多智能体味道”，Agent 之间可以互相讨论、互相质疑，甚至模拟不同立场。
graph TD
User --> A[Agent A]
A <--> B[Agent B]
B <--> C[Agent C]
C <--> A
- 更适合创意探索、复杂讨论、研究型实验。
- 但它也是最容易失控的一类，因为对话一旦放开，成本和时延都可能迅速上升。
如果你真的打算上线这类系统，我会非常谨慎。它很容易出现一种表面上很热闹、实际上产出质量并不稳定的情况。
3. 两个常被拿来举例的方向
CrewAI
这类思路更强调“角色分工”，很适合顺序型或者轻量协作型流程。
代码风格：
researcher = Agent(
role='Researcher',
goal='Discover new AI trends',
tools=[search_tool]
)
writer = Agent(
role='Writer',
goal='Write a blog post',
)
crew = Crew(agents=[researcher, writer], process=Process.sequential)
result = crew.kickoff()
AutoGen
这类思路更偏“对话协作”，适合研究和复杂交互场景。
代码风格：
user_proxy = UserProxyAgent("user_proxy", code_execution_config={"work_dir": "coding"})
coder = AssistantAgent("coder", llm_config=llm_config)
# 发起对话
user_proxy.initiate_chat(coder, message="Plot a chart of NVDA stock price.")
它的优势是灵活，但灵活的另一面通常就是更难控。
一个现实经验是，越灵活的多 Agent 编排，越依赖你把状态、角色边界和终止条件讲清楚。否则系统看起来像在“协作”，实际更像在重复对话。
4. 实战建议
- 不要为了“高级”而上多 Agent：一个 Agent 能做好的，就别拆两个。
- 先定义接口，再定义角色：Agent A 输出什么，Agent B 接什么，必须结构化。
- 让 manager 真正负责收口：没有统一决策层，多 Agent 很容易各说各话。
- 把共享状态想清楚：每个 Agent 是否看到同一份上下文，决定了系统稳定性。
- 先从两角色开始：researcher + writer、planner + executor 这种轻组合，通常比一上来五六个 Agent 更靠谱。
- 给每个角色定义失败条件：什么时候该停，什么时候该交回 manager，最好提前写死。
还有一个很容易被低估的问题：多 Agent 系统里的“责任漂移”。
单 Agent 失败时，你至少知道是哪条链路没做好。多 Agent 失败时，常见情况是：
- researcher 说 writer 理解错了
- writer 说 researcher 资料不完整
- manager 说是工具结果不稳定
所以只要做多 Agent，我会默认要求每个交接点都尽量结构化，最好能追溯是谁产出的什么内容。
小结
Multi-Agent 不是银弹，它只是把“一个模型做所有事”的问题，换成了“多个角色怎么协作”的问题。
真正适合上多智能体的场景，通常满足至少一条：
- 任务天然可以拆角色
- 不同阶段需要不同工具或不同模型
- 你愿意为更高可控性付出更高编排成本
如果只是普通任务链路，先把单 Agent 做稳，通常收益更高。
我自己的判断一直很简单：
- 任务天然分角色，再上多 Agent
- 任务本来就短平快，就别为了“看起来先进”硬拆
多智能体最有价值的时候，不是在 demo 里，而是在你已经知道任务该怎么拆、为什么拆的时候。
