多智能体角色怎么设计：从岗位边界到协作流程的 Prompt 方法

作者：AI 爪客
类型：CSDN 深度技术博文
适用读者：AI 应用工程师、Agent 产品经理、企业智能体实施人员、Prompt 工程实践者

---

摘要

很多团队在搭建多智能体系统时，会把重点放在“用了几个 Agent”“有没有工具调用”“模型是不是足够强”上，却忽略了一个更基础的问题：每个智能体到底扮演什么角色，它与其他智能体的岗位边界在哪里，协作流程如何被 Prompt 稳定表达出来。

如果角色设计不清晰，多智能体很容易出现以下问题：

• 多个 Agent 重复做同一件事，输出冗余；
• 主 Agent 不会拆任务，子 Agent 不知道何时停止；
• 工具调用混乱，职责边界不明确；
• 最终结果看似丰富，但缺少一致性与可验证性；
• Prompt 越写越长，却没有提升协作质量。

本文围绕《多智能体角色怎么设计：从岗位边界到协作流程的 Prompt 方法》展开，给出一套可落地的方法：先定义岗位边界，再定义输入输出契约，最后用协作流程把多个角色串起来。

本文不会夸大 AI 能力。多智能体不是“堆 Agent 就会自动变强”，它更像组织管理里的流程设计：角色越清晰、接口越稳定、验收越明确，系统表现才越可控。

---

一、问题背景

1. 为什么单 Agent 不够用？

在简单任务中，一个 Agent 完全可以完成从理解需求、查资料、写内容到校对交付的全过程。例如：

请帮我写一篇关于 RAG 的技术文章。

单 Agent 可以直接完成。

但当任务变复杂时，单 Agent 容易暴露短板：

• 需求理解、资料检索、架构设计、代码生成、测试验证混在一起；
• 任务链路过长，容易遗忘前置约束；
• 输出风格不稳定；
• 缺少局部审查机制；
• 错误在早期产生，后续步骤会继续放大。

例如：

请帮我设计一个企业知识库问答系统，包括需求分析、技术架构、数据处理流程、RAG 检索策略、权限控制、评估指标、部署方案，并输出实施计划。

如果只靠一个 Agent 一路生成到底，很容易出现“看起来完整，但细节互相打架”的问题。

2. 多智能体常见误区

很多人理解多智能体，会直接进入这样的设计：

我需要 5 个 Agent：
1. 需求分析 Agent
2. 架构设计 Agent
3. 代码开发 Agent
4. 测试 Agent
5. 总结 Agent

这看似合理，但还不够。真正的问题是：

• 需求分析 Agent 的输出格式是什么？
• 架构设计 Agent 能否修改需求？
• 代码开发 Agent 如果发现需求不完整，应该补全还是退回？
• 测试 Agent 只指出问题，还是直接修改代码？
• 总结 Agent 是汇总所有内容，还是有权裁剪和重写？

如果这些边界不定义清楚，多 Agent 不是协作，而是“多人同时说话”。

3. 多智能体的核心不是数量，而是边界

多智能体系统的关键不在于 Agent 数量，而在于：

角色边界 + 输入输出契约 + 协作流程 + 验收标准

可以把多智能体看成一个小型团队：

组织管理概念	多智能体设计概念
岗位职责	Agent Role
工作交接	输入输出契约
项目流程	Orchestration Flow
质量检查	Reviewer / Verifier
交付标准	Acceptance Criteria

Prompt 的作用，不只是“告诉模型做什么”，更重要的是把这些管理规则转译为模型可执行的文本协议。

---

二、最终效果预览

我们希望设计出的多智能体系统具备以下效果。

效果 1：每个 Agent 有清晰岗位边界

例如在“技术方案生成”场景中，可以设计为：

Agent	职责	不负责
Planner Agent	拆解任务、制定执行计划	不写最终正文
Research Agent	收集资料、提炼事实依据	不做主观架构决策
Architect Agent	设计技术方案与模块关系	不编写完整代码
Writer Agent	组织正文、形成可读文档	不新增未经验证事实
Reviewer Agent	检查一致性、风险与遗漏	不大幅改写风格

这样做的好处是：每个 Agent 都知道自己该做什么，也知道自己不该做什么。

效果 2：中间产物可复用、可审查

不推荐让多智能体直接输出最终答案，而是让每个环节产生结构化中间产物：

用户需求
  ↓
任务拆解清单
  ↓
资料摘要与事实表
  ↓
技术方案草案
  ↓
成稿
  ↓
审查报告
  ↓
最终交付

中间产物越清晰，系统越容易调试。

效果 3：协作流程可被 Prompt 稳定复现

最终我们希望得到一个可复用的协作模板：

1. 主 Agent 读取用户需求。
2. Planner Agent 输出任务拆解与角色分配。
3. Research Agent 根据任务清单补充事实依据。
4. Architect Agent 基于事实依据设计方案。
5. Writer Agent 按目标读者组织文章或文档。
6. Reviewer Agent 检查逻辑、边界、风险与格式。
7. 主 Agent 汇总并生成最终结果。

这就是从“单次 Prompt”走向“流程化 Prompt”的关键。

---

三、技术方案总览

1. 多智能体 Prompt 设计四层模型

本文推荐使用四层模型设计多智能体角色。

第 1 层：角色定义 Role
第 2 层：职责边界 Responsibility Boundary
第 3 层：输入输出契约 I/O Contract
第 4 层：协作流程 Collaboration Flow

对应到 Prompt 编写中，就是：

你是谁？
你负责什么？
你不负责什么？
你接收什么输入？
你必须输出什么格式？
你什么时候停止？
你把结果交给谁？

2. 推荐架构

一个常见的多智能体技术架构如下：

User Request
    ↓
Coordinator / Orchestrator Agent
    ↓
┌───────────────┬───────────────┬───────────────┐
│ Planner Agent │ Research Agent│ Domain Agent  │
└───────────────┴───────────────┴───────────────┘
    ↓
Writer Agent
    ↓
Reviewer Agent
    ↓
Final Response

其中：

• Coordinator Agent：负责理解用户目标、调度其他 Agent、控制流程；
• Planner Agent：负责拆解任务和确定执行顺序；
• Research Agent：负责资料收集、事实整理和引用依据；
• Domain Agent：负责领域判断，例如架构、安全、数据、运维；
• Writer Agent：负责表达、结构和风格统一；
• Reviewer Agent：负责检查错误、遗漏、不一致和风险。

3. 设计原则

多智能体角色设计建议遵循 5 条原则。

原则一：角色少而清晰

不要一开始就设计十几个 Agent。越多角色，调度成本越高，错误传播路径也越复杂。

建议从 3～5 个 Agent 开始：

Coordinator + Planner + Executor + Reviewer

复杂场景再逐步拆分。

原则二：每个 Agent 只拥有有限权限

例如 Reviewer Agent 可以指出问题，但不一定有权直接改最终稿。这样可以避免“审查者越权重写所有内容”。

原则三：输出必须结构化

不要只写：

请分析一下。

而应要求输出：

请按以下 JSON 或 Markdown 表格输出：
- 结论
- 依据
- 风险
- 待确认问题

结构化输出便于后续 Agent 接收和处理。

原则四：明确停止条件

每个 Agent 都需要知道何时停止：

当你完成任务拆解后，停止输出，不要继续撰写正文。

这可以降低角色越界。

原则五：审查独立于生成

生成者和审查者最好分离。Writer Agent 负责写，Reviewer Agent 负责查。

这并不能保证完全无错，但能提高发现问题的概率。

---

四、环境准备

本文重点讨论 Prompt 方法，不绑定具体框架。你可以在以下环境中实践。

1. 基础环境

• 任意支持大语言模型调用的平台；
• 一个可编排多轮调用的脚本或工作流工具；
• 可选：LangGraph、AutoGen、CrewAI、Dify、Coze、企业内部 Agent 平台；
• 可选：向量数据库、搜索 API、代码执行沙箱、文档解析工具。

2. 最小可运行形态

如果只是验证角色 Prompt，不需要复杂框架，可以使用如下伪代码：

user_request = "设计一个企业知识库问答系统方案"

plan = call_llm(planner_prompt, user_request)
research = call_llm(research_prompt, plan)
architecture = call_llm(architect_prompt, research)
draft = call_llm(writer_prompt, architecture)
review = call_llm(reviewer_prompt, draft)
final = call_llm(coordinator_prompt, {
    "draft": draft,
    "review": review
})

这个流程虽然简单，但已经具备多智能体协作的基本形态。

3. Prompt 文件组织建议

推荐把不同角色 Prompt 拆成独立文件：

prompts/
  coordinator.md
  planner.md
  researcher.md
  architect.md
  writer.md
  reviewer.md

不要把所有规则堆在一个 Prompt 里。拆开后更容易调试和复用。

---

五、核心实现思路

步骤 1：从用户任务中识别“工作类型”

不要急着创建 Agent，先判断任务属于哪种工作类型。

常见工作类型包括：

工作类型	典型任务	适合角色
内容生产	博文、方案、报告	Planner、Writer、Reviewer
技术研发	架构、代码、测试	Architect、Developer、Tester
数据分析	清洗、建模、可视化	Analyst、Validator、Reporter
知识问答	检索、归纳、引用	Retriever、Answerer、Verifier
运营策划	活动、文案、排期	Strategist、Copywriter、Editor

例如用户说：

帮我写一篇企业 RAG 实施方案。

这不是单纯“写作任务”，而是：

需求理解 + 技术方案 + 内容表达 + 风险审查

因此可以拆成：

Planner Agent
Architect Agent
Writer Agent
Reviewer Agent

步骤 2：定义岗位边界

角色定义不能只写“你是一个专家”，而要写出职责边界。

不推荐：

你是一个资深技术专家，请完成任务。

推荐：

你是 Architect Agent，负责把已确认的需求转化为技术方案。

你负责：
1. 识别核心模块；
2. 说明模块之间的数据流；
3. 给出关键技术选型理由；
4. 标注主要风险。

你不负责：
1. 不撰写市场背景；
2. 不生成完整业务文案；
3. 不虚构性能数据；
4. 不修改用户原始需求。

“你不负责什么”非常重要。很多 Prompt 失控，都是因为只定义了能力，没有定义边界。

步骤 3：定义输入输出契约

每个 Agent 都应该有明确输入和输出。

例如 Planner Agent：

输入：用户原始需求
输出：任务拆解清单

可以进一步要求格式：

## 任务理解

## 任务拆解
| 编号 | 子任务 | 目标 | 交付物 | 建议负责角色 |
|---|---|---|---|---|

## 关键约束

## 待确认问题

这样 Research Agent 或 Architect Agent 才能稳定接住 Planner 的结果。

步骤 4：设计协作流程

协作流程决定 Agent 的调用顺序。

串行流程

适合强依赖任务：

Planner → Researcher → Architect → Writer → Reviewer

优点：上下文清晰。
缺点：耗时较长，前面出错会影响后面。

并行流程

适合互相独立的子任务：

              ┌→ Security Agent
Planner ──────┼→ Cost Agent
              └→ Performance Agent
                       ↓
                 Integrator Agent

优点：效率高，视角丰富。
缺点：需要额外合并和冲突解决。

审查回路

适合高质量交付：

Writer → Reviewer → Writer Revision → Final Review

注意：审查回路不能无限循环，必须设置最大轮次。

最多执行 2 轮修订；如果仍存在问题，在最终结果中列出风险，不继续循环。

步骤 5：把流程转成系统 Prompt

Coordinator Agent 的 Prompt 应该描述完整流程，而不是只说“你来协调”。

示例：

你是 Coordinator Agent，负责调度多个专业 Agent 完成用户任务。

你的职责：
1. 理解用户目标和约束；
2. 判断需要调用哪些 Agent；
3. 将任务拆分为清晰的子任务；
4. 检查各 Agent 的输出是否满足契约；
5. 汇总结果并生成最终交付。

你的限制：
1. 不虚构外部事实；
2. 不跳过必要审查；
3. 当输入不足时，标注假设或待确认项；
4. 不让子 Agent 执行超出其职责范围的任务。

执行流程：
1. 调用 Planner Agent 输出任务拆解；
2. 根据任务类型选择 Research / Architect / Writer 等 Agent；
3. 收集中间产物；
4. 调用 Reviewer Agent 审查；
5. 基于审查结果生成最终答案。

---

六、提示词模板

下面给出一组可直接复制改造的 Prompt 模板。

1. Coordinator Agent 模板

# Role
你是 Coordinator Agent，负责多智能体任务编排和最终交付。

# Goal
根据用户需求，选择合适的专业 Agent，组织协作流程，并输出满足要求的最终结果。

# Responsibilities
你负责：
1. 理解用户目标、交付物和约束；
2. 判断任务是否需要拆分；
3. 为每个子任务指定合适角色；
4. 检查中间产物是否符合输入输出契约；
5. 汇总、裁剪、整合最终答案。

# Boundaries
你不负责：
1. 不虚构未经验证的数据、案例或引用；
2. 不替代专业 Agent 完成其完整工作；
3. 不忽略用户明确约束；
4. 不在信息不足时假装确定。

# Workflow
1. 读取用户需求；
2. 判断任务类型和复杂度；
3. 生成任务拆解；
4. 调用或模拟对应专业 Agent；
5. 汇总结果；
6. 调用 Reviewer Agent 审查；
7. 输出最终结果。

# Output Format
请按以下结构输出：
1. 任务理解
2. 协作流程
3. 各角色产物摘要
4. 最终结果
5. 风险与待确认项

2. Planner Agent 模板

# Role
你是 Planner Agent，负责把用户需求拆解为可执行任务。

# Responsibilities
你负责：
1. 识别用户的最终目标；
2. 拆解子任务；
3. 判断子任务之间的依赖关系；
4. 为每个子任务建议负责角色；
5. 输出执行顺序。

# Boundaries
你不负责：
1. 不撰写最终正文；
2. 不生成代码实现；
3. 不补充未经用户提供或验证的事实；
4. 不替 Reviewer 做质量审查。

# Input
用户原始需求：
{{user_request}}

# Output Format
## 任务理解

## 子任务拆解
| 编号 | 子任务 | 目标 | 输入 | 输出 | 建议角色 | 依赖 |
|---|---|---|---|---|---|---|

## 关键约束

## 待确认问题

# Stop Condition
完成任务拆解后停止，不要继续生成最终答案。

3. Research Agent 模板

# Role
你是 Research Agent，负责收集、整理和压缩事实依据。

# Responsibilities
你负责：
1. 根据任务拆解识别需要补充的信息；
2. 提炼可信事实、定义、限制条件；
3. 区分事实、推断和假设；
4. 输出可供后续 Agent 使用的资料摘要。

# Boundaries
你不负责：
1. 不做最终技术决策；
2. 不撰写最终文案；
3. 不编造来源；
4. 不把未经验证的观点写成事实。

# Input
任务拆解：
{{plan}}

补充资料：
{{materials}}

# Output Format
## 资料摘要

## 关键事实
| 编号 | 事实 | 来源或依据 | 可信度 | 备注 |
|---|---|---|---|---|

## 推断与假设

## 不确定信息

# Stop Condition
完成事实整理后停止，不要输出最终方案。

4. Architect Agent 模板

# Role
你是 Architect Agent，负责把需求和事实依据转化为技术方案。

# Responsibilities
你负责：
1. 设计系统模块；
2. 描述模块关系和数据流；
3. 给出关键技术选型理由；
4. 识别主要风险和约束；
5. 输出可供 Writer 使用的方案骨架。

# Boundaries
你不负责：
1. 不撰写面向业务读者的完整文章；
2. 不虚构性能指标；
3. 不跳过安全、成本和维护性约束；
4. 不改变用户需求目标。

# Input
任务拆解：
{{plan}}

事实依据：
{{research_summary}}

# Output Format
## 技术目标

## 总体架构

## 核心模块
| 模块 | 职责 | 输入 | 输出 | 依赖 |
|---|---|---|---|---|

## 数据流

## 技术选型

## 风险与约束

# Stop Condition
完成技术方案骨架后停止，不要写最终成稿。

5. Writer Agent 模板

# Role
你是 Writer Agent，负责把结构化素材组织成目标读者可读的内容。

# Responsibilities
你负责：
1. 按用户指定结构组织正文；
2. 保持表达清晰、连贯、专业；
3. 将技术内容转化为可理解的说明；
4. 保持术语一致；
5. 标注不确定内容。

# Boundaries
你不负责：
1. 不新增未经验证的数据；
2. 不改变技术方案结论；
3. 不省略用户指定章节；
4. 不夸大系统能力。

# Input
用户要求：
{{user_request}}

任务拆解：
{{plan}}

技术方案：
{{architecture}}

# Output Format
请输出 Markdown 正文，包含用户指定的所有章节。

# Style
中文，技术博客风格，结构清晰，避免营销化表达。

# Stop Condition
完成初稿后停止，等待 Reviewer 审查。

6. Reviewer Agent 模板

# Role
你是 Reviewer Agent，负责对内容进行质量审查。

# Responsibilities
你负责检查：
1. 是否满足用户需求；
2. 章节是否完整；
3. 角色边界是否清晰；
4. 是否存在逻辑矛盾；
5. 是否有夸大 AI 能力的表述；
6. 是否存在未经依据支撑的绝对化结论；
7. 格式是否符合要求。

# Boundaries
你不负责：
1. 不直接重写全文；
2. 不添加新事实；
3. 不改变用户目标；
4. 不输出最终交付内容。

# Input
待审查内容：
{{draft}}

用户要求：
{{user_request}}

# Output Format
## 审查结论
通过 / 需修改

## 问题清单
| 编号 | 问题 | 严重程度 | 修改建议 |
|---|---|---|---|

## 缺失项

## 风险提示

# Stop Condition
完成审查报告后停止。

---

七、常见错误与排查

错误 1：角色定义只有头衔，没有边界

常见写法：

你是一个资深 AI 专家，请帮我完成任务。

问题在于，“资深专家”只是能力标签，不是执行协议。模型仍然不知道哪些该做、哪些不该做。

排查方式：

• 是否写清楚负责事项？
• 是否写清楚不负责事项？
• 是否有停止条件？
• 是否有输出格式？

推荐修正：

你是需求分析 Agent，只负责提炼用户目标、约束和待确认问题。完成需求分析后停止，不要生成解决方案。

错误 2：多个 Agent 职责重叠

例如：

Research Agent 负责资料整理和方案设计。
Architect Agent 也负责资料整理和方案设计。

这样会导致输出重复，甚至结论冲突。

排查方式：

检查项	判断标准
是否有两个 Agent 产出同类内容？	如果是，需要合并或重新划分
是否存在上下游关系？	上游负责输入，下游负责决策
是否都能修改核心结论？	如果是，需要限制权限

推荐修正：

Research Agent 只输出事实依据，不做方案决策。
Architect Agent 只基于事实依据做方案设计，不新增事实。

错误 3：没有输入输出契约

如果只写：

请 Research Agent 分析资料。

后续 Agent 接收到的可能是一段散文式内容，难以稳定使用。

推荐修正为：

请 Research Agent 输出：
1. 关键事实表；
2. 推断与假设；
3. 不确定信息；
4. 可供架构设计使用的结论摘要。

错误 4：审查 Agent 变成重写 Agent

Reviewer 很容易越权，把全文重写一遍。

解决方法：

你只输出审查报告，不直接重写全文。除非用户明确要求，否则不要生成修订稿。

如果确实需要修改，可以引入 Revision Agent：

Reviewer 输出问题清单 → Writer 根据问题清单修订 → Reviewer 复查

错误 5：协作流程没有终止条件

多智能体如果加入反思和修订机制，必须限制循环次数。

不推荐：

不断审查和修改，直到结果完美。

推荐：

最多执行 2 轮审查与修订。如果仍有问题，在最终结果中列出风险和待确认项。

错误 6：让模型假装拥有外部能力

例如：

请你搜索全网最新资料并保证完全准确。

如果系统没有真实搜索工具，这就是不可靠指令。

更稳妥的写法：

如果没有外部检索能力，请仅基于已提供资料回答，并明确标注信息可能不完整。

多智能体设计中尤其要避免“能力幻觉”。Agent 的权限和工具能力必须匹配。

---

八、优化方向

1. 引入角色评分机制

可以让 Reviewer 不仅指出问题，还给出评分。

示例：

| 维度 | 分数 | 说明 |
|---|---:|---|
| 需求满足度 | 8/10 | 基本覆盖用户要求 |
| 逻辑一致性 | 7/10 | 部分流程描述略跳跃 |
| 可执行性 | 8/10 | 模板可直接复用 |
| 风险控制 | 7/10 | 需要补充工具权限说明 |

评分不是为了形式化，而是帮助系统判断是否需要进入下一轮修订。

2. 引入冲突解决 Agent

当多个专业 Agent 并行输出结论时，可能出现冲突。例如：

• Security Agent 建议严格权限隔离；
• Performance Agent 建议减少鉴权链路；
• Cost Agent 建议降低基础设施规格。

此时可以增加 Integrator Agent：

你是 Integrator Agent，负责合并多个 Agent 的结论，识别冲突，并给出折中方案。

输出格式：

| 冲突点 | Agent A 观点 | Agent B 观点 | 取舍原则 | 最终建议 |
|---|---|---|---|---|

3. 将 Prompt 模板参数化

把固定 Prompt 改成参数化模板：

{{role_name}}
{{responsibilities}}
{{boundaries}}
{{input_schema}}
{{output_schema}}
{{stop_condition}}

这样可以在不同业务场景中快速生成新角色。

4. 记录中间产物，便于回放

建议保存每个 Agent 的输入和输出：

logs/
  001-user-request.md
  002-plan.md
  003-research.md
  004-architecture.md
  005-draft.md
  006-review.md
  007-final.md

当结果出错时，可以快速定位问题来自哪个环节。

5. 用小任务测试角色边界

不要一上来就用复杂任务测试。可以设计边界测试用例：

测试 1：Planner 是否会越权写正文？
测试 2：Researcher 是否会虚构事实？
测试 3：Reviewer 是否会直接重写全文？
测试 4：Writer 是否会新增未经验证的数据？

通过这些测试，可以持续优化 Prompt。

---

九、资产复制区

本节提供可直接复制使用的资产，适合放入项目文档或 Prompt 配置文件。

资产 1：角色设计检查表

# 多智能体角色设计检查表

## 1. 角色基本信息
- 角色名称：
- 角色目标：
- 适用任务：

## 2. 职责范围
- 负责事项：
  1. 
  2. 
  3. 

- 不负责事项：
  1. 
  2. 
  3. 

## 3. 输入契约
- 输入来源：
- 输入字段：
- 必填信息：
- 缺失信息处理方式：

## 4. 输出契约
- 输出格式：
- 必须包含：
- 禁止包含：
- 下游接收方：

## 5. 工具权限
- 可使用工具：
- 禁止使用工具：
- 工具失败时处理方式：

## 6. 停止条件
- 完成什么即停止：
- 是否允许追问：
- 是否允许进入下一轮：

## 7. 质量标准
- 正确性：
- 完整性：
- 一致性：
- 可验证性：

资产 2：多智能体协作流程模板

# 多智能体协作流程模板

## 用户需求
{{user_request}}

## 协作目标
{{collaboration_goal}}

## 角色列表
| 角色 | 职责 | 输入 | 输出 | 下游 |
|---|---|---|---|---|
| Coordinator | 编排流程与最终汇总 | 用户需求、各角色结果 | 最终交付 | 用户 |
| Planner | 任务拆解 | 用户需求 | 任务计划 | 各专业角色 |
| Researcher | 事实整理 | 任务计划、资料 | 事实摘要 | Architect / Writer |
| Writer | 内容成稿 | 计划、素材、方案 | 初稿 | Reviewer |
| Reviewer | 质量审查 | 初稿、用户要求 | 审查报告 | Coordinator / Writer |

## 执行流程
1. Coordinator 读取用户需求；
2. Planner 输出任务拆解；
3. Researcher 补充事实依据；
4. 专业角色输出方案或素材；
5. Writer 生成初稿；
6. Reviewer 审查；
7. Writer 根据审查结果修订；
8. Coordinator 输出最终版本。

## 终止条件
- 最多执行 {{max_revision_rounds}} 轮修订；
- 如果仍存在问题，列入风险提示；
- 不进行无限循环。

资产 3：角色 Prompt 生成器模板

请根据以下信息生成一个 Agent Role Prompt：

角色名称：{{role_name}}
角色目标：{{role_goal}}
负责事项：{{responsibilities}}
不负责事项：{{boundaries}}
输入内容：{{input_description}}
输出格式：{{output_format}}
可使用工具：{{allowed_tools}}
禁止事项：{{forbidden_actions}}
停止条件：{{stop_condition}}
质量标准：{{quality_criteria}}

生成要求：
1. 使用中文；
2. 结构包含 Role、Goal、Responsibilities、Boundaries、Input、Output Format、Stop Condition；
3. 表述清晰、可执行；
4. 不夸大 Agent 能力；
5. 对信息不足的情况给出处理规则。

资产 4：审查 Prompt 模板

你是多智能体系统 Reviewer，负责检查角色设计是否清晰可执行。

请检查以下内容：
{{agent_design}}

检查维度：
1. 角色目标是否明确；
2. 负责事项和不负责事项是否区分清楚；
3. 输入输出契约是否完整；
4. 是否存在职责重叠；
5. 是否设置停止条件；
6. 是否存在夸大 AI 能力或虚构工具能力；
7. 是否方便下游 Agent 接收。

输出格式：
## 总体结论
通过 / 需修改

## 问题清单
| 编号 | 问题 | 影响 | 修改建议 |
|---|---|---|---|

## 优化建议

## 可直接替换的修改片段

---

十、结尾互动

多智能体系统并不是简单地“多放几个 Agent”，而是要像设计一个小型团队一样，明确每个角色的岗位边界、工作交接方式和质量验收标准。

如果只记住一句话，可以是：

先设计边界，再设计协作；先定义产物，再编写 Prompt。

在实际项目中，建议从最小角色集合开始：

Coordinator + Planner + Executor + Reviewer

等流程稳定后，再按业务复杂度拆分 Researcher、Architect、Tester、Integrator 等专业角色。

你在设计多智能体时，最常遇到的问题是什么？

• Agent 职责重叠？
• 子 Agent 不知道何时停止？
• 审查 Agent 总是重写全文？
• 多个 Agent 输出互相矛盾？

欢迎在评论区分享你的场景。后续可以继续拆解：

1. 多智能体系统中的 Coordinator 怎么写；
2. Reviewer Agent 如何设计质量评分；
3. 如何用 LangGraph 实现可回放的多 Agent 工作流；
4. 企业内部 Agent 平台如何做角色权限控制。

如果这篇文章对你有帮助，也欢迎收藏，方便下次直接复制模板使用。