9.7 边界、分发与过渡
面向经管学生、研究者与从业者的 AI 智能体设计教材
四种常见误区
第一，把进阶理解成功能越多越好。本章的进阶，指的是任务组织更成熟、边界更清楚，而不是把更多技术名词塞进同一个 Skill。
第二，把 Skill 写成协议教程。如果大部分篇幅都在解释底层格式和通信细节，主线就已经跑偏了。
第三，把不同层级的机制全写成一层。它们解决的问题并不相同：有的负责任务编排，有的负责外部接口，有的负责分发与共享。如果放在同一层讨论，边界会越来越乱。
第四，把所有自动化都塞进 Skill。低频任务不值得沉淀，强状态服务不适合硬塞，确定性动作用脚本就够了。
| 误区 | 问题 | 正确做法 |
|---|---|---|
| 进阶 = 功能越多越好 | 职责膨胀、维护困难 | 进阶是判断更成熟，不是塞更多东西 |
| Skill 当协议教程写 | 主线跑偏 | 讲工程判断，不讲底层协议 |
| 所有机制混为一层 | 边界模糊 | 把任务编排、外部接口、分发共享分开理解 |
| 所有自动化都塞进 Skill | 过度封装 | 低频用脚本，强状态用独立服务，固定节点处理交给专门机制 |
使用范围与共享路径
Skill 写好之后，可以先按使用范围理解它的共享路径。
个人 Skill：存放在个人 Skills 目录（如 ~/.claude/skills/），只有本人可用。适合个人工作流和偏好设置。
项目 Skill：存放在项目目录的 .claude/skills/ 下，随代码仓库分发。团队成员克隆项目后自动获得。适合项目专属流程，如特定报告模板、代码规范检查。
组织级共享：由团队统一维护，成员进入工作区后按统一规则使用。适合企业标准化流程，如合规检查、品牌文档规范。
GitHub 是目前最常用的 Skill 分发渠道。Anthropic 官方仓库 anthropics/skills 提供了多个可直接使用或定制的 Skill。
从 Skill 到子代理
当以下任意一个条件出现时，就值得评估是否还应继续使用 Skill：
| 条件 | 说明 | 示例 |
|---|---|---|
| 需要独立上下文 | 任务的中间过程很长，会挤占主对话空间 | 读取 20 个文件并逐一分析 |
| 需要独立权限 | 不同子任务需要不同的工具和权限组合 | 数据获取只读、报告生成可写 |
| 需要独立提示 | 子任务需要完全不同的角色设定和指令 | 审阅需要批判视角，写作需要建设视角 |
如果三个条件同时出现，基本可以确定需要从 Skill 升级为子代理（Subagent）。
这三个升级判据，恰好对应子代理的三个核心特性：
| Skill 遇到的瓶颈 | 子代理提供的解决方案 |
|---|---|
| 中间过程挤占主对话空间 | 独立上下文——每个子代理拥有自己的上下文窗口，中间过程不影响主代理 |
| 不同子任务需要不同工具 | 工具隔离——每个子代理只获得完成自身任务所需的最小工具集 |
| 子任务需要完全不同的角色设定 | 独立提示——每个子代理通过 agent.md 或 Agent 工具调用获得专属系统提示 |
子代理执行完毕后只将最终结果返回给主对话（或更好的做法：直接保存到文件，只返回状态摘要），中间过程不会挤占主对话空间。
Skill 解决怎样把能力组织成一个任务单元。子代理解决怎样把任务进一步拆成多个协作单元。当一个 Skill 的内部逻辑复杂到需要多个独立执行者分工配合时，Skill 可以在内部编排多个子代理——这就是多子代理编排模式，让 Skill 从单步指令升级为多阶段工作流的调度中心。