# 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”可以模拟团队分工：需求澄清 → 方案设计 → 编码实现 → 测试验收。

```bash
用户需求 → 产品经理(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)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET 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?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.