## Agent、Role、Skill 与 Runtime 把 4 个核心对象讲清楚： - Agent 是工作区里的实际协作成员 - Role 定义这个成员的长期职责边界 - Skill 定义它处理某类问题时采用的稳定做法 - Runtime 决定它在当前环境里真正具备哪些执行能力 本章只定义对象和关系，不讨论具体团队编排策略。 ```text 请把下面这段产品说明拆成 4 层： 1. 哪些是 Agent 本身的信息 2. 哪些属于 Role 3. 哪些属于 Skill 4. 哪些属于 Runtime 并说明这样拆分的原因。 ``` ### 四个对象的定义 #### Agent Agent 是 Workspace 里的实际成员。 当用户在 channel、thread、DM 或 task 里 `@` 到某个智能体，真正接收消息、读取上下文、调用模型和工具并返回结果的，是 Agent，而不是一段抽象 prompt。 Agent 在产品里有明确成员身份： - 它有名字和可见身份 - 它存在于某个 Workspace 中 - 它可以加入 channel、参与 thread、响应 task - 它有自己的资源绑定、运行状态和协作历史 因此，Agent 应该被理解成团队里的长期协作节点，而不是一次性的对话会话。 #### Role Role 定义 Agent 的长期职责边界。 Role 说明的是：这个 Agent 在团队里负责什么结果、应该如何协作、在哪些地方必须停下来等待确认。它不描述某一次任务的临时要求，也不承担详细操作步骤。 同一个 Role 可以绑定到多个 Agent；同一个 Agent 也可以随着团队调整而切换到新的 Role。Role 的价值不在于“写得像人设”，而在于让团队成员稳定判断：这件事应不应该交给这个 Agent。 #### Skill Skill 定义的是可复用做法。 Skill 适合承载： - 处理某类问题的固定步骤 - 检查项和判断规则 - 输出结构和交付格式 - 信息不足、风险过高时的停止条件 如果 Role 解决的是“谁负责”，Skill 解决的就是“这类事按什么方法做”。 #### Runtime Runtime 是 Agent 背后的执行环境。 Runtime 决定 Agent 在当前环境里真正能调用什么： - 使用什么模型 - 能不能读写本地文件 - 能不能访问浏览器、仓库、数据库或外部系统 - 工具权限开到什么范围 - 当前机器是否在线、依赖是否就绪 因此，Role 说明“应该做什么”，Skill 说明“通常怎么做”，Runtime 则决定“实际上做得到多少”。 ### 它们之间的关系 在 AgentTeam 里，四者是分层配合的，而不是相互替代的。 一条典型路径是： 1. 用户把任务交给某个 Agent 2. Agent 按 Role 判断这件事是否属于自己的长期职责范围 3. 如果属于，就根据当前问题选择合适的 Skill 组织做法 4. 执行过程中能否真的读取文件、运行命令、访问网络或调用插件，受 Runtime 限制 这 4 层之所以要拆开，是因为它们解决的是不同维度的问题： | 对象 | 回答的问题 | 变化频率 | | --- | --- | --- | | Agent | 现在是谁在协作 | 中等 | | Role | 它长期负责什么 | 低到中 | | Skill | 这类事按什么方法做 | 中 | | Runtime | 当前环境允许它做什么 | 中到高 | 如果把这几层混在一起，系统会很快变得不可维护： - 把步骤写进 Role，Role 会膨胀成操作手册 - 把职责写进 Skill，Skill 会失去复用边界 - 把能力假设写进 Role 或 Skill，而 Runtime 实际不支持，Agent 的行为就会和产品事实脱节 - 把一次性任务要求写进 Agent 简介，后续所有任务都会被历史噪音污染 ### 一个完整例子 假设团队里有一个专门负责代码评审的 Agent。 它可以拆成四层： - Agent：`reviewer-bot` - Role：负责检查实现边界、依赖影响、回滚风险和验证证据 - Skill：按既定评审清单输出结论、风险、证据和建议下一步 - Runtime：可以读取仓库、查看 diff、执行只读命令、必要时运行测试 如果 Runtime 没有仓库访问能力，那么即使 Role 写得再清楚、Skill 写得再完整，这个 Agent 也无法真正完成高质量评审；它最多只能根据对话文本做有限判断。这就是为什么 Runtime 必须被单独说明。 ![Agent、Role、Skill 与 Runtime 的关系：Role 定义长期职责，Runtime 提供执行能力，Skill 提供稳定做法，当前任务上下文在调用时注入到 Agent。](../../media/chapters/fig-01-01-agent-role-skill-runtime-map.svg){#fig-01-agent-role-skill-runtime-map width=96%} ### 实际使用时的判断顺序 在日常协作里，可以按下面的顺序判断问题落在哪一层： 1. 先确认要不要 `@` 这个 Agent 2. 再确认它的 Role 是否覆盖当前任务 3. 再确认有没有合适的 Skill 支撑这类做法 4. 最后确认 Runtime 是否具备所需能力 这套顺序的意义在于：把“职责判断”和“能力判断”分开。 一个 Agent 可能职责上应该参与，但因为 Runtime 权限受限而只能给出部分结果；也可能能力上完全做得到，但这件事本来不属于它的 Role，应该转给别的成员。 | 对象 | 适合放什么 | 不适合放什么 | | --- | --- | --- | | Agent | 名称、成员身份、入口、资源绑定 | 大段方法说明 | | Role | 职责、边界、协作方式 | 一次性任务内容 | | Skill | 步骤、检查项、输出格式 | 团队岗位定义 | | Runtime | 模型、工具、访问能力、运行状态 | 团队分工规则 | 常见错放包括： - 把职责写进 Skill，导致同类技能无法复用 - 把步骤写进 Agent 简介，导致成员定义越来越臃肿 - 把一次性任务写进 Role，导致长期职责被临时要求污染 - 以为 Runtime 有能力，实际上当前机器、权限或工具并不支持 涉及多人复用的 Role、通用 Skill 或高权限 Runtime 调整，最好经过一次同行评审。 外部系统访问能力属于 Runtime 与工具权限层，不属于 Role 本身。 读完本章后，读者应该能明确区分：团队里到底是谁在工作、它长期负责什么、它按什么方法做、以及它当前真正具备哪些执行能力。