## 写 Role 把 Role 写成可以长期复用的职责说明，而不是一次性 prompt。 本章讨论 Role 的产品定义和写法，不讨论模型参数或运行权限。 ```text 请按产品说明书口径重写这个 Role： 1. 角色定位 2. 核心职责 3. 协作原则 4. 边界与停止条件 并删除所有一次性任务要求。 ``` ### Role 的作用 Role 的职责不是把任务做完，而是稳定地定义这个 Agent 应该对什么结果负责。 它回答的是团队协作中的三个核心问题： 1. 什么时候应该把事情交给这个 Agent 2. 这个 Agent 接到任务后应该以什么立场参与 3. 它在什么情况下必须停下来，不继续替团队做决定 因此，Role 写得好不好，不取决于字数多少，而取决于它能否稳定约束协作行为。 ### 一个可用 Role 的基本结构 在 AgentTeam 里，一个可操作的 Role 通常至少要包含 4 段： - 角色定位 - 核心职责 - 协作原则 - 边界与停止条件 #### 角色定位 角色定位说明它在团队里的岗位。 例如：需求拆解者、代码评审者、发布协调者、故障排查者。这里要写清“它站在哪个位置”，而不是抽象地写“帮助团队提高效率”。 #### 核心职责 核心职责描述它长期负责推进的结果。 好的写法强调结果责任，例如： - 把需求拆成可执行任务 - 识别依赖和风险 - 输出可供团队继续使用的结构化结论 差的写法通常只有空泛愿景，例如“协助研发”“提供专业支持”“帮助提升质量”。 #### 协作原则 协作原则定义它如何和人、和其他 Agent 配合。 这里应当说明： - 是先给结论，还是先给过程 - 信息不足时是继续猜，还是先提问 - 需要升级风险时是否主动提醒 - 输出是直接执行，还是供人确认后再执行 #### 边界与停止条件 边界与停止条件保证 Role 不越权。 一个长期可用的 Role，必须明确写出： - 哪些决定不由它直接做 - 遇到哪些情况必须停下来等待确认 - 哪些任务本来就不属于它的职责范围 没有这一层，Agent 往往会表现成“什么都接一点，但每件都只做到一半”。 ### Role 为什么不能写成 prompt 拼贴 很多 Role 失效，不是因为模型不够强，而是因为写法把长期职责和一次性要求混在了一起。 典型问题包括： - 今天像 PM，明天像工程师 - 把当前项目背景整段粘进 Role - 把输出格式、检查步骤、工具调用顺序都塞进 Role - 遇到信息不足时继续编，而不是停下来提问 这类写法的共同问题是：Role 不再是长期岗位定义，而变成了某次任务的临时工作单。这样一来，后续复用时几乎一定失真。 ### 官方模板与客户定制 从当前产品形态看，官方角色模板只是起点，不是最终限制。 更合适的做法是：先从官方模板或已有角色出发，快速落一个可用版本；再根据客户团队自己的协作方式、审批边界、输出习惯和术语体系，持续把它改成自己的角色版本，按客户自己的协作方式做长期定制。对客户来说，角色模板本身就是可以长期演进和按需定制的资产。 这意味着模板的价值主要有两点： 1. 提供一个结构正确的起始版本 2. 帮团队更快建立可复用的命名和分工规范 但真正决定质量的，仍然是后续是否把模板改成适合本团队的长期职责说明。 ### 一个对比例子 下面两种写法，只有后一种更像可长期使用的 Role。 不够好的写法： - 你是一个很强的研发助手 - 帮我处理技术问题 - 尽量高效、主动、全面 更好的写法： - 负责把需求拆成可执行任务，并识别依赖、风险和待确认项 - 默认先输出结构化拆解结果，再提示缺失信息 - 对超出信息边界的部分不做臆断，改为列出待澄清问题 - 不直接替代产品、研发负责人或审批人做最终决定 前者是形容词堆叠，后者才是在定义岗位责任。 多人复用的 Role，最好保持统一结构：角色定位、核心职责、协作原则、边界与停止条件。 Role 不好用时，常见表现是： - 职责过宽，导致什么都接 - 没有停止条件，导致信息不足时继续编造 - 把项目临时背景塞进去，导致复用时失真 多人复用的 Role，发布前最好经过一次同行评审。 Role 可以约束是否需要调用外部系统，但外部系统的真实可访问性仍由 Runtime 决定。 读完本章后，读者应该能写出一个长期可复用的 Role，并明确它和一次性 prompt、Skill、Runtime 的边界。