多智能体编排：让多个 Agent 协作完成任务

背景

单个 Agent 再强，也有两条硬上限：上下文窗口装不下所有信息，长期盯一个任务容易“跑偏”。当任务复杂到要兼顾研究、编码、测试多个环节时，更自然的做法是把任务拆给多个专职 Agent，由一个协调者统筹。

2025 年以来，多智能体（Multi-Agent）成为 Agent 系统的主流形态：LangGraph、AutoGen 等框架提供了编排原语，Anthropic 也公开过“Swarm（群）”式的协作思路。关键不是“越多越好”，而是怎么分工、怎么通信。

三种常见模式

A Supervisor（主管）：一个中枢 Agent 负责拆解任务、把子任务派给专职 Agent，再汇总结果。灵活，适合开放式任务。
B Workflow（工作流）：按固定 DAG 串起多个步骤，每步一个 Agent。可预测、易调试，适合流程明确的场景。
C Swarm（群）：Agent 之间互相“交接”控制权，谁擅长谁接手。去中心、变化多，但更难点可控。

示例

一个“调研 → 编码 → 评审”的主管式流水线：

orchestrator = Supervisor()

research = Agent(role="researcher", tools=[web, rag])
coder   = Agent(role="coder",     tools=[fs, shell])
reviewer= Agent(role="reviewer",   tools=[diff, test])

plan  = orchestrator.plan(task)
facts = research.run(plan.queries)        # 先调研
code  = coder.run(plan.spec, context=facts)  # 再编码
report= reviewer.run(code)                # 最后评审

协作通常靠消息传递 + 共享状态实现：Agent 之间可以交换消息，也可以读写一块共享“黑板”（blackboard）来同步进度。我们 Agent 工作台的 Workflow 模块，本质上就是把这种模式可视化、可拖拽地编排出来。

总结

多 Agent 能处理更复杂的任务，但代价是更长的延迟、更高的成本，以及调试难度的上升。我的建议是：先用单个 Agent 把任务跑通，确实触到上下文或专注度上限时，再拆出第二个专职 Agent。

下一步想把“上下文工程”笔记里提到的可视化面板，扩展成多 Agent 的“执行轨迹”视图，方便看清每个 Agent 在每一步看到了什么、做了什么。