单个大模型Agent的能力总有上限：上下文窗口有限、角色定位容易漂移、长链路任务里出错后难以自我纠正。把一个复杂任务拆给多个Agent协作完成，是近来越来越主流的做法。但多Agent系统好不好用，八成取决于Prompt怎么写。角色定义模糊、任务边界不清、信息传递格式混乱，都会让协作变成几个模型互相扯皮。本文从分工结构、协作模式、实战细节三个层面，拆解多Agent协作推理的Prompt设计方法。
一、多Agent Prompt设计的三要素：角色、边界、协议
多Agent系统的Prompt不是简单地把一段指令复制几份，而是要为每个Agent构建独立的身份认知。一份合格的角色定义Prompt至少包含四个部分：角色身份、能力范围、禁止事项、输出格式。角色身份告诉模型它是谁，能力范围划定它能做什么，禁止事项防止角色越界（比如让研究员Agent直接给出最终结论），输出格式则决定了下游Agent能否准确解析它的产出。
任务边界比角色身份更重要。实践中最常见的失败案例是两个Agent的职责重叠，比如一个负责收集资料、一个负责分析资料，但收集Agent总是忍不住顺手给出分析结论，导致下游Agent被上游的观点锚定，失去独立判断。解决办法是在Prompt里显式声明禁止行为，例如明确写出不要给出评价性结论，只输出事实清单。
第三要素是通信协议，也就是Agent之间传递信息的格式约定。如果没有统一格式，每个Agent自由发挥，汇总模块解析起来会非常痛苦。建议在系统Prompt中强制要求JSON输出，并给出字段示例。下面是一个规划者Agent的Prompt模板：
你是任务规划专家。你的职责是把用户需求拆解成可执行的子任务。
规则：
1. 只做拆解，不执行任务，不给出答案
2. 每个子任务必须说明目标、所需输入、期望输出
3. 输出严格遵循以下JSON格式：
{
"tasks": [
{
"id": "T1",
"goal": "子任务目标",
"input": "依赖的上游任务id或用户输入",
"output_format": "期望输出的形式描述"
}
]
}
这个模板的要点在于第1条的禁止性约束。规划者一旦开始执行任务，整个分工体系就失去了意义，后续Agent拿到的不是待办清单，而是被预判过的答案。
二、串行流水线与并行讨论：两种协作模式的Prompt写法差异
串行流水线是最简单也最稳定的多Agent结构：需求分析Agent把任务拆解后，依次交给检索Agent、写作Agent、审校Agent处理，前一个的输出作为后一个的输入。这种模式下，每个Agent的Prompt里必须包含对上游输入的容错声明，因为上游输出可能不完整或格式异常。例如写作Agent的Prompt中应写明：如果输入的资料清单为空，不要编造内容，而是返回一个明确的缺料提示。
并行讨论模式则适合没有标准答案的开放性问题，比如方案评审、代码架构决策。典型结构是一个主持人Agent加多个专家Agent：主持人负责提出议题、汇总观点、控制轮次；每个专家Agent持有不同的立场设定。这种模式下Prompt的关键是给专家注入差异化视角，比如一个专家被设定为激进派关注性能，另一个被设定为保守派关注稳定性，避免所有Agent用同一套思维模式得出雷同结论。
主持人Agent提示词（节选）：
你是一场技术方案评审会的主持人。
每一轮你将收到各位专家的观点列表，你需要：
1. 提炼各方共识与分歧点
2. 针对分歧点向指定专家发起追问
3. 当分歧收敛或达到最大轮次（3轮）时，
输出最终决议，格式为：
{"decision": "...", "reason": "...", "dissent": "保留意见"}
专家A提示词（节选）：
你是性能专家，立场偏激进。你只从性能与成本角度评估方案，
其他维度（如可维护性）仅在直接损害性能时提及。
回应必须控制在200字以内，先给结论再给理由。
注意专家Prompt里的字数限制。多Agent讨论如果不控制单次发言长度，上下文会迅速膨胀，几轮之后早期观点就被截断，主持人会基于残缺信息做裁决，讨论质量急剧下降。
三、上下文传递与冲突处理：让协作真正落地的细节
多Agent系统最棘手的问题是上下文膨胀。假设五个Agent各自携带完整对话历史，总Token消耗会是单Agent的数倍。工程上有两种收敛手段：一是共享黑板模式，所有Agent读写同一个结构化状态区，每个Agent的Prompt中只注入黑板中与自身任务相关的字段；二是摘要压缩，即每个Agent输出后立刻由一个轻量级Agent压缩成要点再传给下游。前者适合结构清晰的任务，后者适合讨论型场景。
冲突处理也需要在Prompt层面预设规则。当两个Agent给出矛盾结论时，谁来裁决？常见做法是引入一个仲裁Agent，其Prompt要求它不重新执行任务，只基于双方给出的证据和理由做裁决，并输出置信度。这种设计把裁决和执行分离，避免仲裁者陷入重复劳动，也让裁决过程可追溯。
# 一个简单的多Agent调度骨架，展示Prompt与流程的关系
planner_prompt = "你是任务规划者，只输出任务JSON..."
researcher_prompt = "你是资料收集者，只输出事实清单..."
writer_prompt = "你是撰写者，基于事实清单写作，禁止引入清单外的结论..."
def run_pipeline(user需求):
tasks = call_llm(planner_prompt, user需求)
facts = call_llm(researcher_prompt, tasks)
# 对事实做压缩，控制传给写作Agent的上下文长度
facts_brief = compress(facts, max_tokens=800)
return call_llm(writer_prompt, facts_brief)
最后提醒一点：多Agent不是万能药。如果一个任务用单个精心设计的Prompt就能完成，强行拆成多Agent只会增加延迟和成本，还会放大不确定性。判断标准很简单——只有当任务确实存在角色天然分离（比如检索与写作、执行与审查）、或者需要多视角制衡时，多Agent结构才有价值。先用最简单的结构跑通，再逐步增加Agent数量和协作深度，这才是稳妥的演进路径。