跳到主要内容

角色分工

1. 定义与边界​

多 Agent 的角色分工是把任务中的认知职责、工具权限和工程责任拆成可管理单元。角色不是 prompt 人设，而是接口、权限、状态和质量指标的组合。

一个角色定义至少包含：

  • 输入：接收哪些任务、状态和 artifact。
  • 输出：产生什么结构化结果。
  • 工具：能调用哪些工具，是否只读或可写。
  • 预算：最大 token、模型调用、工具调用和时间。
  • 终止：什么时候完成、失败或 handoff。
  • 责任：哪个团队或模块维护。

2. 为什么重要​

角色分工的价值在于降低互相污染和权限混乱：

  • Planner 不应该直接执行高风险操作。
  • Researcher 不应该把未验证外部内容当事实写入最终答案。
  • Executor 不应该自行扩大任务目标。
  • Reviewer 不应该只做语言润色，而要检查证据、规则和风险。
  • Supervisor 不应该成为“万能大脑”，否则会退化为单 Agent 加多个工具。

3. 核心角色​

角色主要职责不应承担
Router识别任务类型和入口路径深度执行和最终裁决
Planner拆解目标、生成计划、定义依赖高权限工具执行
Researcher检索、抽取、核验来源未经核验写最终结论
Executor调用业务工具、执行步骤修改目标和策略
Critic / Reviewer检查错误、合规、安全和证据无边界重写全部内容
Supervisor调度、预算、汇总、恢复替代所有专业 Agent
Memory Agent读写长期记忆和偏好存储未授权敏感数据
Human Proxy向人类请求确认和输入伪造审批或代替人类授权

4. 架构/流程​

5. 工程实现​

角色注册表示例：

agents:
  planner:
    model: "reasoning"
    tools: []
    input_schema: "PlanningRequest"
    output_schema: "Plan"
    max_turns: 2
    permissions: ["read_task"]

  researcher:
    model: "fast"
    tools: ["web_search", "kb_query"]
    output_schema: "EvidenceBundle"
    permissions: ["read_public_web", "read_internal_kb"]
    must_label_sources: true

  executor:
    model: "tool_optimized"
    tools: ["crm_update", "ticket_create"]
    permissions: ["write_ticket"]
    requires_approval_for: ["refund", "delete", "external_send"]

  reviewer:
    model: "reasoning"
    tools: ["policy_check"]
    output_schema: "ReviewDecision"
    permissions: ["read_trace", "read_artifacts"]

角色输出要结构化：

{
  "role": "reviewer",
  "decision": "block",
  "reasons": [
    {
      "type": "unsupported_claim",
      "evidence": "最终报告第 4 段缺少来源",
      "required_fix": "补充来源或删除断言"
    }
  ],
  "risk_level": "medium",
  "next_agent": "researcher"
}

6. 生产实践​

  • 给每个角色设置最小工具集，优先只读再逐步开放写权限。
  • 高风险动作拆成“建议 Agent”和“执行 Agent”，中间加策略审批。
  • Reviewer 必须能访问 trace、来源和中间 artifact，而不是只看最终文本。
  • Supervisor 应保存每次角色决策的输入摘要和输出摘要。
  • 对角色能力做版本化：prompt、工具 schema、模型版本和策略版本都应可追溯。
  • 不同角色可以使用不同模型，但要记录模型差异对成本和质量的影响。

7. 常见反模式​

反模式问题修正
角色名很细，权限完全一样只是 prompt 分身按工具和状态边界重划
Planner 既规划又执行规划错误会直接造成副作用执行前增加审批或 Executor
Reviewer 只看最终答案看不到工具误用和来源污染Reviewer 读取 trace 和 artifact
Supervisor 汇总所有细节上下文膨胀汇总结构化摘要，保留 artifact 链接
每个 Agent 都能 handoff 给任何 Agent容易循环使用允许的转移图

8. 评测方法​

角色级指标：

角色指标
Router路由准确率、拒识率、误拒率
Planner计划可执行率、依赖完整率、步骤冗余率
Researcher来源覆盖率、引用准确率、无来源断言率
Executor工具调用准确率、参数正确率、副作用失败率
Reviewer缺陷发现率、误报率、漏报率
Supervisor任务成功率、恢复成功率、预算遵守率

评测数据应包含正常样本、边界样本、冲突样本和恶意样本。

9. 安全与治理​

  • 高权限角色不应直接消费低可信 Agent 的自由文本指令。
  • 角色之间传递敏感数据时必须标注数据分类和授权范围。
  • Human Proxy 必须接入真实审批机制，不允许模型生成“已批准”。
  • Reviewer 与 Executor 尽量分离，避免同一 Agent 自审自执。
  • 允许的 role transition 应显式声明，例如 planner -> supervisor -> executor。

10. 工程手册补充​

10.1 角色 contract 模板​

角色不是名字，而是可执行边界。

agent_contract:
  id: research_agent
  owner: knowledge-team
  purpose: "收集和结构化证据"
  accepts:
    - task_brief
    - source_constraints
  returns:
    - evidence_table
    - uncertainty_notes
  allowed_tools:
    - web_search
    - file_read
  forbidden:
    - "不得生成最终结论"
    - "不得调用写工具"
  escalation:
    - "证据冲突时交给 supervisor"
边界好的设计坏的设计
目标产出可验证 artifact“负责把事情做好”
工具只给角色必需工具所有 Agent 都有全部工具
状态局部 scratchpad + 共享 artifact复制完整上下文
责任owner 和失败码明确失败后互相推诿

上线清单：

  • 角色数量从最少开始，新增角色必须解释新增边界。
  • Reviewer 不应拥有被审对象的高风险写权限。
  • Planner 不直接执行副作用工具，Executor 不静默改计划。
  • 评测要看单角色准确率、跨角色交接损耗和职责越界率。

11. 权威资料​