角色建模与角色卡：职责边界与输出契约
前置知识
一句话定义
角色建模是把系统提示从「人格描述」升级为「岗位契约」的工程过程：每个智能体拥有一份角色卡，明确身份目标、职责边界、输入输出契约、工具白名单与协作规约，使多智能体的分工可预测、可验收。
直观类比
招人时你不会只说「你是个聪明的工程师」，而会写岗位说明书：负责什么、不负责什么、交付物长什么样、能用哪些系统、有问题找谁。角色卡就是智能体的岗位说明书。
为什么重要
多智能体的绝大多数协作故障（越权、漏做、格式错乱、无限礼貌性客套）根因都在角色卡含糊。角色也是五种协作模式（kp-006 至 kp-010）共同的原料：模式回答「智能体怎么连」，角色卡回答「每个智能体是什么」。MetaGPT 的核心洞察正是把人类组织的 SOP（标准作业程序）编码进角色定义。
前置知识
kp-002（角色过载问题）；系统提示的基本写法（前置技能，不在本库展开）。
核心概念
角色卡六要素：
- 身份与目标：你是谁、为哪个可度量的结果负责；
- 职责边界：明确「做」清单与「不做」清单——负面清单比正面描述更能防越权；
- 输入输出契约（Contract）：输入是什么结构、输出必须是可解析的格式（如 JSON Schema），含字段语义与示例；
- 工具白名单：只授予完成职责所需的最小工具集（最小权限原则）；
- 协作规约：何时交付、何时上报、何时请求澄清、消息发给谁；
- 约束与风格：长度、语言、禁用行为（如不得臆造数据）。
原理与机制
角色卡有效的机理有三层。注意力聚焦：职责边界缩小了每步决策空间，模型输出更稳定（呼应 kp-002 的角色过载）。可验证性：输出契约让下游可以用确定性断言检查产物（kp-022 的第一层防护栏），而不是靠感觉验收。职责不重叠：若两个角色都能「改需求」，系统会出现循环改写（kp-020 的循环失败）；判断标准是——任何一份产物恰好只有一个 owner。
设计顺序建议：先写输出契约，再倒推职责与工具，最后补人格与风格。契约先行能避免「写了三段人设却发现没法验收」的返工。跨智能体的契约还要约定交接信息的字段落点（与 kp-012 的交接包对接）。
实例或案例
「代码评审员」角色卡（节选）：
身份: 负责对提交的 diff 做安全与正确性评审的评审员。
职责: 输出问题清单；不负责修复代码；不负责风格偏好类意见。
输入: 结构化 diff 与变更说明。
输出: JSON 数组，每项含 severity(high|medium|low) / file / line / issue / suggestion。
工具: 只读代码库工具；禁止调用写操作。
上报: 发现高危问题时置 severity=high 并在 issue 中给出复现路径。下游因此可以写断言「severity=high 的条目必须含复现路径」自动验收——角色卡直接变成了测试用例。
图示
角色卡(契约层) 运行时(执行层)
┌──────────────┐ 系统提示 ┌──────────────┐
│ 身份/边界/契约 │ ──────────▶ │ LLM 内核 │ ──▶ 结构化输出
│ 工具/规约/约束 │ 注入 │ +工具白名单 │ (可被断言验收)
└──────────────┘ └──────────────┘常见误区
- 误区一：角色 = 人设。 「你是资深专家」不构成契约，模型仍会越界；真正约束行为的是负面清单与输出 schema；
- 误区二：万能智能体。 一个角色同时承担分析、写作、审查，等于退回单 Agent 的角色过载；
- 误区三：契约只约束不示例。 没有 few-shot 示例的 JSON 契约在长输出下极易跑偏，示例是契约的一部分。
与其他知识点的关系
角色卡是 kp-006 至 kp-010 五种模式的装配单元；输出契约是 kp-022 防护栏的第一道闸；工具白名单是 kp-026 最小权限治理的落点。
自测题
- 角色卡六要素是什么？为什么负面清单比正面描述更重要？
要点：身份目标/职责边界/输入输出契约/工具白名单/协作规约/约束风格；负面清单直接封死越权路径，正面描述留有解释空间。
- 为什么建议「契约先行」地写角色卡？
要点：输出契约决定能否自动验收；先写契约可倒推职责与工具，避免返工。
- 「任何产物恰好一个 owner」防止哪类失败？
要点：多角色都有权修改同一产物时引发的循环改写与责任不清（循环失败）。
延伸阅读
MetaGPT 论文展示了把 SOP 编码进角色的完整实例；单条角色的提示写法细节见 agent-development 站点。