> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/agentic_ai_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/agentic_ai_guide/di-er-bu-fen-qun-ti-zhi-neng-yu-jin-hua/05_collaboration/5.2_roles_sop.md).

# 5.2 角色分工与 SOP 流程编排

在多智能体系统中，明确的角色定义和标准化的工作流程是高效协作的基础。本节探讨如何为每个智能体设计独特的“人设”，以及如何通过 **标准作业程序 (SOP)** 来编排复杂的协作流程。

## 5.2.1 角色定义：智能体的身份证

每个智能体都应该拥有一张独特的“身份证”，包含以下核心要素：

### 角色

角色定义了智能体的职能边界。如同公司中的职位，角色决定了智能体应该做什么、不应该做什么。以下示例展示了如何定义一个智能体的角色：

```python
class AgentRole:
    def __init__(self):
        self.name = "首席架构师"
        self.department = "技术部"
        self.permissions = ["代码审查", "架构决策", "技术选型"]
        self.restrictions = ["不参与招聘", "不处理财务"]
```

**设计原则**：角色应该足够具体，避免“万能智能体”。一个好的角色定义应该能回答“这个智能体负责什么？不负责什么？”

### 高度专业化角色案例：CitationAgent

在 Anthropic Research 系统中，为了确保每项声明都能追溯到确切的来源，专门引入了 **CitationAgent** 这一高度专业化的角色。它的职责单一但关键：在海量研究文档与生成的研究报告之间建立精确的对应关系（《如何构建多智能体研究系统》，2025 年 6 月）。

**角色定义**：

```yaml
名称：CitationAgent
职责：文档解析与引文映射
输入：原始研究文档 + 编排者生成的研究报告
输出：带有精确源引用的最终报告（每项声明都含 source_id）
约束：
  - 只能使用提供的研究文档作为信息源
  - 严禁创造或推断未在文档中明确出现的事实
  - 优先级：准确性 > 完整性（宁可遗漏，不要错引）
```

**工程价值**：

* **责任清晰**：将“引文生成”从主研究流程中独立出来，使得主流程可以聚焦于信息发现与综合
* **质量保证**：由专用智能体处理所有引文逻辑，降低主研究智能体因上下文过长而出现遗漏的概率
* **可追溯性**：用户可以点击任何声明直接跳转到源文献，提高了整个系统的可信度

### 目标

目标是智能体的 KPI，驱动其行为方向。目标应该是可衡量的、具体的。

**好的目标示例**：

* “将用户需求转化为不超过 10 个的技术任务项”
* “确保代码覆盖率达到 80% 以上”
* “在 5 轮对话内解决用户问题”

**差的目标示例**：

* “做好工作”（太模糊）
* “成为最好的助手”（无法衡量）

### 背景故事

背景故事看似“软性”，但实际上能显著影响 LLM 的输出风格和决策倾向。这是利用模型“角色扮演”能力的关键技巧。

```python
backstory = """
你是一位长期从事大型系统开发的资深架构师。你崇尚简洁可维护的代码风格，
讨厌过度工程化。你总是先问"这真的有必要吗？"再动手实现。
在技术争论中，你习惯用数据和案例说话，而不是诉诸权威。
"""
```

实践中，详细的背景故事往往能让输出风格更一致：它为模型提供了决策时的参考框架。

## 5.2.2 标准作业程序设计

SOP（标准作业程序）定义了多个智能体如何按照预定流程协作完成任务。一个完整的 SOP 包含以下核心要素：

1. **触发条件**：什么情况下启动这个流程？
2. **参与角色**：哪些智能体参与？
3. **执行步骤**：每一步做什么？谁来做？
4. **交接规则**：步骤之间如何传递信息？
5. **终止条件**：什么情况下流程结束？

## 5.2.3 SOP 的工程化实践

### 角色分工与交接标准

在工程实践中，一个典型的“软件开发 SOP”可以模拟团队分工：需求澄清 → 方案设计 → 编码实现 → 测试验收。

```
用户需求 → 产品经理(PRD) → 架构师(设计文档) → 工程师(代码) → QA(测试)
```

每个角色都应有明确的输入、输出与质量标准：

| 角色   | 输入     | 输出           | 质量标准    |
| ---- | ------ | ------------ | ------- |
| 产品经理 | 用户原始需求 | 产品需求文档 (PRD) | 需求完整性   |
| 架构师  | PRD 文档 | 系统设计图        | 架构合理性   |
| 工程师  | 设计文档   | 可运行代码        | 代码质量    |
| QA   | 代码     | 测试报告         | 测试覆盖与回归 |

下面这个最小实现展示了如何把“角色分工 + 顺序交接”落成一个可执行的协作流程：

```python
# 注意：下面的 Agent 类（ProductManagerAgent, ArchitectAgent 等）需要先在项目中定义或导入

from agents import ProductManagerAgent, ArchitectAgent, DeveloperAgent, QAAgent

class SoftwareDevelopmentSOP:
    def __init__(self):
        self.agents = {
            "pm": ProductManagerAgent(),
            "architect": ArchitectAgent(),
            "developer": DeveloperAgent(),
            "qa": QAAgent(),
        }

    async def execute(self, user_requirement: str):
        prd = await self.agents["pm"].analyze(user_requirement)
        design = await self.agents["architect"].design(prd)
        code = await self.agents["developer"].implement(design)
        report = await self.agents["qa"].test(code)

        if not report.passed:
            code = await self.agents["developer"].fix(code, report.issues)

        return code, report
```

### SOP 的版本化与验收

把 SOP 当成“运行在智能体之上的流程代码”来管理，才能在迭代中保持稳定：

* **版本号与变更记录**：每次调整角色职责、交接格式或停止条件都应记录原因与影响范围。
* **验收标准前置**：为每个步骤定义可检查的产物（例如 PRD 字段齐全、测试通过、审查清单通过）。
* **失败兜底**：当任一节点无法收敛时，明确回退路径（回到上一步重写、切换策略、请求人工介入）。

## 5.2.4 工具权限分配

在多智能体系统中，工具权限的分配是角色设计的重要组成部分。不同角色应该只能访问与其职能相关的工具。

```python
PERMISSION_MATRIX = {
    "product_manager": ["search_web", "read_document", "create_prd"],
    "architect": ["search_code", "draw_diagram", "analyze_dependency"],
    "developer": ["write_code", "run_tests", "git_commit"],
    "qa": ["run_tests", "generate_report", "create_issue"],
    "hr": ["search_employee", "send_email", "schedule_meeting"]
}

def get_tools_for_agent(role: str) -> List[Tool]:
    allowed_tools = PERMISSION_MATRIX.get(role, [])
    return [tool for tool in ALL_TOOLS if tool.name in allowed_tools]
```

**安全原则**：最小权限原则。每个智能体只应该拥有完成其任务所必需的最少权限，避免越权操作带来的风险。

## 5.2.5 角色设计的常见失败模式

多智能体系统在落地中常见失败原因往往不是“模型不够聪明”，而是角色与流程设计不清晰：任务边界含糊、交接信息不完整、停止条件缺失、重复步骤无法收敛等。

### 系统设计问题的典型失败模式

下面表格总结了常见的系统设计类失败模式，便于在复盘时快速定位问题类型：

| 编号     | 失败模式       | 描述                |
| ------ | ---------- | ----------------- |
| FM-1.1 | **违反任务规范** | 未能遵循用户指定的任务要求     |
| FM-1.2 | **违反角色规范** | 行为超出定义的角色边界       |
| FM-1.3 | **步骤重复**   | 陷入重复执行相同步骤的循环     |
| FM-1.4 | **上下文丢失**  | 关键信息在执行过程中被遗漏或被覆盖 |
| FM-1.5 | **停止条件不清** | 无法判断任务何时完成或何时该停止  |

### 案例：角色规范优化的效果

实践中常见现象是：在不更换模型的前提下，仅通过改进角色规范（输入输出、约束、停止条件、交接模板），整体成功率就能显著提升。这说明系统设计往往比模型选择更重要。

**优化建议**：

1. **明确终止条件**：在角色定义中显式说明“什么情况下任务完成”，避免 FM-1.5（停止条件不清）。
2. **防止步骤重复**：设置最大迭代次数，并在 Prompt 中提醒智能体 “不要重复已完成的步骤”（FM-1.3）。
3. **职责边界清晰**：使用 `restrictions` 字段明确禁止的行为，降低 FM-1.2（违反角色规范）风险。

## 5.2.6 小结

角色分工和 SOP 是多智能体系统的“组织架构”。通过精心设计角色定义（Role + Goal + Backstory）和标准化流程（SOP），可以：

* 让每个智能体专注于自己擅长的领域
* 减少角色冲突和职责模糊
* 提高复杂任务的完成质量
* 便于系统的调试和维护

下一节将探讨如何让这些角色动态组队，应对更加复杂多变的任务场景。

***

**下一节**: [5.3 动态组队与自适应编排](/agentic_ai_guide/di-er-bu-fen-qun-ti-zhi-neng-yu-jin-hua/05_collaboration/5.3_dynamic_teaming.md)