5.2 角色分工与 SOP 流程编排

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

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

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

角色

角色定义了智能体的职能边界。如同公司中的职位，角色决定了智能体应该做什么、不应该做什么。

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

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

目标

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

好的目标示例：

• "将用户需求转化为不超过 10 个的技术任务项"

• "确保代码覆盖率达到 80% 以上"

• "在 5 轮对话内解决用户问题"

差的目标示例：

• "做好工作"（太模糊）

• "成为最好的助手"（无法衡量）

背景故事

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

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

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

5.2.2 标准作业程序 设计

SOP 定义了多个智能体如何按照预定流程协作完成任务。

5.2.3 SOP 的核心要素

1. 触发条件：什么情况下启动这个流程？

2. 参与角色：哪些智能体参与？

3. 执行步骤：每一步做什么？谁来做？

4. 交接规则：步骤之间如何传递信息？

5. 终止条件：什么情况下流程结束？

5.2.4 SOP 的工程化实践

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

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

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

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

实现 SOP 的代码模式

具体示例如下：

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

5.2.5 工具权限分配

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

5.2.6 权限矩阵设计

具体示例如下：

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.7 角色设计的常见失败模式

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

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

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

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

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

优化建议：

1. 明确终止条件：在角色定义中显式说明"什么情况下任务完成"，避免 FM-1.5。

2. 防止步骤重复：设置最大迭代次数，并在 Prompt 中提醒智能体 "不要重复已完成的步骤"。

3. 职责边界清晰：使用 restrictions 字段明确禁止的行为，降低 FM-1.2 风险。

5.2.8 小结

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

• 让每个智能体专注于自己擅长的领域

• 减少角色冲突和职责模糊

• 提高复杂任务的完成质量

• 便于系统的调试和维护

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

---

下一节: 5.3 动态组队与自适应编排