在基于 LLM 的 Agent 开发中，如何优雅地扩展智能体的能力边界，同时避免长上下文带来的 Token 消耗与“注意力偏移”，是架构设计的核心痛点。
Claude Agent SDK（及其底层的 Claude Code 引擎）通过引入基于文件系统的技能（Skill）概念，并结合渐进式披露（Progressive Disclosure）与子智能体派生（Subagent Forking）机制，给出了一套极具工程参考价值的解决方案。
本文将以一个具体的 frontend-design（前端开发）技能为例，假设历史会话中存在业务上下文（“我们的主题色是蓝色”），深度拆解技能从发现、触发到最终执行的完整生命周期与 Context 构造原理。
一、 阶段一：渐进式发现与触发
底层引擎对技能的处理遵循“元数据先行，按需加载实体”的渐进式原则。
1. 技能注册与 Context 构造
引擎启动时，扫描本地技能目录（如 .claude/skills/frontend-design/SKILL.md），仅提取文件的 YAML 元数据（name, description）。这些元数据被拼装成一个统一的底层原生工具——Skill Tool，并注入到 LLM 的上下文中。
此时，主 Agent (Main Agent) 的 Context 结构如下：
{
"system": "你是一个全能的AI编程助手...",
"tools":[
{
"name": "Skill",
"description": "调用外部专业技能以完成复杂任务...\n<available_skills>\n - name: frontend-design\n description: 编写React组件，包含严格的质量检查。\n</available_skills>"
},
{"name": "Bash", "description": "..."},
{"name": "Write", "description": "..."}
],
"messages":[
{"role": "user", "content": "我们的主题色是蓝色。"},
{"role": "assistant", "content": "记住了，主题色是蓝色。"}
]
}
2. 意图匹配与触发请求
当用户输入新指令 “帮我写一个 Login 组件”，主 Agent 通过推理，判定需求命中 frontend-design 技能的描述。主 Agent 中断文本输出，发起 Tool Call：
{"role": "assistant", "tool_calls":[{"id": "call_1", "name": "Skill", "input": {"command": "frontend-design"}}]}
二、 阶段二：执行引擎的两种模式分野
SDK 拦截到上述调用后，会从磁盘完整读取 SKILL.md 正文（即执行剧本）。此时，根据技能是否配置了 context: fork 参数，底层引擎将采用两种完全不同的上下文突变（Context Mutation）策略。
模式一：主 Agent 模式（In-place Execution）
若未配置 fork，技能将在当前上下文中原地展开。SDK 会将长篇剧本伪装成工具的返回结果（Tool Result），强制注入当前 messages 数组。
突变后的 Context 结构：
{
"messages":[
{"role": "user", "content": "我们的主题色是蓝色。"},
{"role": "user", "content": "帮我写一个 Login 组件。"},
{"role": "assistant", "tool_calls":[{"id": "call_1", "name": "Skill", "input": {"command": "frontend-design"}}]},
{
"role": "user",
"content":[
{
"type": "tool_result",
"tool_use_id": "call_1",
"content": "成功加载技能。请严格按照以下剧本执行：\n1. 检查目录...\n2. 编写代码...\n3. 运行 ESLint...\n[...此处省略数千字的长剧本...]"
}
]
}
]
}
- 执行表现：主 Agent 读取到剧本后，开始循环调用
Bash、Write 等工具干活。由于处于同一 messages 数组中，它自然能继承“蓝色主题”的上下文。
- 架构缺陷：严重的上下文污染（Context Pollution）。执行期间产生的所有底层操作、试错日志和 ESLint 报错，都会被永久追加到主对话历史中。随着任务增加，Token 开销将呈指数级上升，且极易导致模型在后续对话中注意力失焦。
模式二：子智能体派生模式（Subagent Forking）- 推荐实践
若技能配置了 context: fork，SDK 会冻结主 Agent 的时间线，利用深拷贝（Deep Copy）在内存中拉起一个具备状态隔离的子智能体（Subagent）。
Subagent 被唤醒时的独立 Context 结构：
{
// 1. System Prompt 覆写：主 Agent 的通用人设被丢弃，直接替换为具体的技能长剧本
"system": "你是一个受限的子智能体。你的唯一任务是执行以下剧本：\n1. 检查目录...\n2. 编写代码...\n3. 运行 ESLint...\n[...省略数千字...]",
// 2. 权限沙盒：工具列表被严格阉割（例如移除 Skill 自身以防递归套娃）
"tools": [{"name": "Bash"}, {"name": "Write"}, {"name": "Edit"}],
// 3. 记忆继承：主 Agent 的历史会话被全量克隆，并在尾部追加强制触发指令
"messages":[
{"role": "user", "content": "我们的主题色是蓝色。"},
{"role": "user", "content": "帮我写一个 Login 组件。"},
{"role": "user", "content": "<skill_invocation>主Agent已委派任务，请基于上述上下文立即调度工具执行剧本，勿输出冗余寒暄。</skill_invocation>"}
]
}
- 执行表现：Subagent 在这个被隔离的“沙盒”内，带着“蓝色主题”的先验记忆，高效地进行代码编写与纠错循环。
- 状态销毁与上下文归并（合并成果）：任务完成后，Subagent 输出最终的验收报告。此时，SDK 执行“阅后即焚”操作——直接从内存中销毁该 Subagent 及其产生的所有中间脏数据（几十轮的报错与调试日志）。
- 唤醒主 Agent：SDK 仅将 Subagent 的最终报告作为
tool_result 交还给主 Agent。主 Agent 的 Context 依然保持极度清爽：
{
"messages":[
{"role": "user", "content": "帮我写一个 Login 组件。"},
{"role": "assistant", "tool_calls":[{"id": "call_1", "name": "Skill", "input": {"command": "frontend-design"}}]},
// 主对话历史保持干净，仅包含最终结果
{"role": "user", "content":[{"type": "tool_result", "tool_use_id": "call_1", "content": "组件已完成，沿用蓝色主题，代码校验通过。"}]}
]
}
三、 总结
Claude Agent SDK 的技能机制本质上是“对 LLM 上下文生命周期的精细化重构”。
| 核心维度 |
主 Agent 原地执行 |
Subagent 派生执行 (context: fork) |
| 技能长文本注入位置 |
注入至 messages 尾部（作为工具结果） |
覆写 system prompt（作为最高指令） |
| 上下文状态传递 |
数组自然延展，内存共享 |
messages 数组深拷贝(Deep Copy)传递 |
| 安全与权限控制 |
具有全量权限，存在越权执行风险 |
沙盒隔离，按需分配只读或特定工具 |
| Token 与记忆管理 |
试错日志永久污染主状态机，不可伸缩 |
脏数据生命周期短（阅后即焚），主队列干净 |
在工程实践中，构建稳健的 Agentic 系统，应默认将复杂工序抽象为技能，并强制启用 context: fork 进行多智能体委派隔离。这种架构不仅保障了主状态机的稳定性，也极大优化了 API 调用的经济效益。
