如何设计 Agent 的角色与职责边界？

简化版

Agent 角色边界要用“目标、允许输入、可用工具、数据范围、输出契约、禁止事项和升级条件”定义，不能只写一段人格 Prompt。角色应围绕稳定职责划分，而不是把规划、审批、执行和审计全塞给一个 Agent；权限由工具层按身份强制执行，高风险决策由规则或人承担。多 Agent 协作时通过结构化任务和产物交接，避免共享一整段可互相污染的对话。

详细版

先从业务责任倒推角色：谁产生候选、谁验证事实、谁有权执行、谁负责审批。每个角色建立能力清单和拒绝清单，并为工具配置最小权限。例如“研究 Agent”可读公开资料、生成带引用报告，但不能发邮件或写生产库；“发布 Agent”只接收已批准 artifact，并只能调用限定发布 API。

角色契约 = 目标 + 输入 Schema + 输出 Schema
         + 工具允许列表 + 数据作用域
         + 禁止动作 + 升级/交接条件

边界必须在运行时校验：调用者身份、工具、参数对象、租户和审批令牌都要匹配。Agent 之间传递产物 ID、来源和验证状态，而不是让下游盲信上游自然语言。评测需包含越权请求、职责冲突、循环转交和提示注入。

完整版教学

一、角色不是给模型起一个名字

“你是一位资深分析师”主要影响语言风格，不能限制模型访问什么数据或调用什么工具。真正的角色是系统中的责任与权限单元，必须能由代码判断一项动作是否属于它。

角色定义过宽会形成“上帝 Agent”，一次提示注入就可能同时读取秘密、修改数据并发布结果；定义过细又会产生大量交接和上下文成本。边界应围绕稳定的业务责任和风险域划分。

记忆钩子：Prompt 描述角色，工具网关执行边界；没有运行时权限的角色，只是一种说话口吻。

二、用角色契约替代模糊职责

角色契约明确它接收什么、交付什么、允许做什么和何时必须停下。输入输出使用 Schema，可以在交接时自动验证；工具与数据作用域使用允许列表，不能由模型临时扩张。

契约项	研究 Agent 示例
目标	收集并比较公开产品资料
输入	问题、时间范围、评价维度
输出	带来源的分析 artifact
工具	搜索、只读网页抓取
禁止	登录私有系统、对外发布
升级	证据冲突或缺少官方来源

契约还应版本化。角色能力改变后，旧任务恢复时要知道使用旧契约继续还是重新授权。

三、职责分离降低单点风险

高风险流程常把建议、验证、批准和执行分开。生成付款方案的 Agent 不应同时批准付款；读取候选简历的 Agent 不应自行修改招聘规则。职责分离让错误或攻击必须跨越多个独立边界才产生副作用。

Planner -> 计划草案
Verifier -> 事实与规则校验
Approver -> 人工/策略授权
Executor -> 按批准参数执行
Auditor -> 读取事件但不能修改

并非所有任务都需要五个 Agent。低风险文案可以单 Agent 加验证器；只有当职责具有不同权限、模型、数据或审计要求时，拆分才带来价值。

四、最小权限要落在工具和参数层

只允许调用 database 工具仍然过宽：它可能读所有表或执行写 SQL。权限应细到方法、资源和参数，例如只读某租户的订单、只允许更新草稿状态、金额不得超过审批上限。

执行网关根据不可伪造的角色身份校验，而不是读取模型输出里的 role=admin。租户 ID 从认证上下文注入，不能让模型自由填写。临时权限要有有效期，并绑定任务和审批版本。

如果研究角色尝试调用发送邮件工具，网关直接拒绝并记录越权事件；不能寄希望于 system prompt 让它“自觉不用”。

五、交接需要产物和证据

上游说“我已经核实价格”不是可靠交接。它应提交结构化产物，包括价格、币种、来源、抓取时间和验证状态；下游先校验 Schema 和权限，再决定是否接受。

{
  "artifact_id": "price-report-v4",
  "producer_role": "researcher",
  "evidence": ["source://official/123"],
  "validation": "passed",
  "content_hash": "..."
}

内容哈希防止批准后产物被替换。下游不必继承上游全部对话，只需要契约规定的产物和必要证据，这也减少提示污染传播。

六、避免职责重叠与空白

两个 Agent 都认为对方负责核验，会产生职责空白；两者都修改同一产物，会产生覆盖冲突。可以建立 RACI 类矩阵：每项能力只有一个最终负责者，协作者与审批者明确列出。

假设流程有 12 项关键责任，审计发现 2 项无人负责、3 项有多个最终负责人，则边界设计尚未闭合。修正时先补齐责任，再配置权限，不能只改 Prompt 名称。

共享资源写入要指定所有者或仲裁器。多个 Agent 可以提出补丁，但由一个合并角色处理冲突，比各自直接写同一文件更可控。

七、转交要有停止条件

角色无法完成时可以转交，但“交给更合适的 Agent”过于模糊，容易 A 转 B、B 又转 A。路由规则要基于能力标签、错误类型和已尝试路径，并限制最大跳数。

例如研究角色遇到登录墙，应转人工授权，而不是交给另一个同样无凭证的研究角色。验证角色发现证据冲突，应退回具体缺口；上游补充后使用新版本产物再次提交。

连续两次相同转交或达到三跳可触发协调器停止并报告。转交历史写入 Trace，但不必全部放进接收方 Prompt。

八、如何验证边界真的有效

测试要尝试诱导角色使用未授权工具、访问其他租户、修改输入中的角色字段、复用过期审批，以及通过上游 artifact 注入指令。期望结果是在执行层被确定性拒绝。

还要做正向任务测试，防止权限过窄导致合理工作无法完成。指标包括越权拦截率、误拦截率、交接验证失败率、循环转交率和每个角色的任务完成率。

若把角色拆成三个后，安全提升但平均交接增加 8 次、延迟翻倍，应检查是否拆得过细。边界设计要同时满足责任清晰、最小权限和可接受协作成本。

九、常见误区与追问

• 误区：System Prompt 写清禁止事项就等于权限隔离。 模型指令可被绕过，权限必须由工具层执行。
• 误区：Agent 越多，系统越专业。 过度拆分会增加通信、延迟、冲突和责任空白。
• 误区：把完整对话交给下游最省事。 会传播噪声、秘密和提示注入，应交付结构化产物。
• 误区：工具允许列表足够细。 还要限制方法、资源、租户、参数范围和有效期。
• 误区：验证 Agent 可以天然信任。 它也需要独立证据、有限权限和质量评测。
• 追问：什么时候应该拆成两个角色？ 当职责需要不同权限、数据、模型、审批责任或独立验证时。
• 追问：怎样处理多个 Agent 修改同一产物？ 使用版本、补丁和单一合并责任者，避免无序并发写。
• 追问：如何避免循环转交？ 记录路由历史、按错误类型选择接收者，并限制最大跳数。

十、加强记忆

Agent 角色边界记住“契约、分责、最小权限、产物交接”：每个角色写清目标、输入输出、允许和禁止；生成、验证、批准与执行按风险分开；工具网关按身份、租户和参数强制最小权限；角色间只传带来源、版本和验证状态的结构化产物。最后用越权攻击与循环转交测试证明边界有效，而不是相信角色 Prompt 写得足够严厉。