Claude Agent SDK新特性解析：子代理、技能与权限

Claude Agent SDK 的演进方向

Claude Agent SDK 在 2026 年下半年的更新，核心思路是把「代理」从单点能力推向可组合、可治理的工程系统。据官方更新说明，这一轮改动集中在五个方面：嵌套子代理（带数量上限）、SessionStore、技能（skills）、插件（plugins）、结构化输出与权限默认值。对于已经在生产环境跑代理的团队来说，这些不是锦上添花的功能，而是直接影响架构设计的约束条件。

嵌套子代理允许一个代理在运行中派生下级代理，但官方明确设置了层数与数量的上限。这个设计取向值得注意：它没有追求「无限递归」的理论能力，而是优先保证成本可控与调试可追溯。对开发者而言，这意味着任务分解的深度需要提前规划，而不是依赖运行时动态扩张。

嵌套子代理：能力与边界同时到来

子代理的价值在于把复杂任务拆成独立上下文处理，避免单一会话被大量中间结果撑爆。带 caps 的嵌套机制意味着 SDK 会强制约束派生规模，团队需要在上限内做任务编排。

实际落地时要注意两点。其一，子代理的上下文隔离是双刃剑：隔离减少了干扰，但也意味着父代理必须显式传递必要信息，否则子代理会因为缺少背景而输出偏差。其二，上限的存在要求开发者在设计阶段就估算最坏情况下的派生数量，把编排逻辑写进代码而不是交给模型即兴决定。

SessionStore 解决的是状态持久化

SessionStore 把会话状态从内存搬到可管理的存储层。官方描述中它被列为独立能力，而不是附属功能，说明团队意识到长任务场景下状态丢失是真实痛点。对于需要跨轮次、跨进程继续执行的代理，SessionStore 提供了恢复点；对于审计需求，它留下了可回放的操作轨迹。

上下文隔离与信息传递：在代理系统中，“上下文”指模型在一次会话中可见的全部信息，包括系统提示、历史消息、工具调用结果等。子代理通常运行在独立的上下文窗口中，这意味着父代理的对话历史不会自动对子代理可见。这种隔离能防止中间结果污染父代理的推理，但也要求父代理在派生时显式构造任务说明、背景资料和约束条件。若传递不完整，子代理可能基于片面信息做出错误判断，且错误会沿调用链向上传播。因此，嵌套代理的设计重点不仅是“能否派生”，更是“派生时传什么”。

会话状态与可回放轨迹：会话状态通常包括消息历史、工具调用记录、中间变量和代理决策路径。将状态从进程内存迁移到外部存储后，代理可以在进程重启、跨轮次等待或人工审批后继续执行，而不必从头开始。可回放轨迹则意味着每一次工具调用和模型输出都有序落盘，事后可以重放整个决策过程，用于审计、归因和故障复现。这对受监管行业尤其重要，因为仅靠日志文本难以还原代理为何选择某条路径。

技能与插件：把可复用能力标准化

skills 和 plugins 是这轮更新里最贴近工程实践的部分。技能可以理解为封装好的能力单元，插件则是把外部工具接入代理体系的通道。官方把两者并列提出，暗示了一种分工：技能偏内部逻辑复用，插件偏外部系统集成。

这种分层的意义在于降低重复建设。过去每个团队都要自己写工具调用胶水代码，现在可以把通用能力沉淀为技能，把第三方服务封装为插件，在多个代理项目间共享。代价是引入了一层抽象，调试时需要多跳一层才能定位问题。

技能与插件的分工：技能通常指以声明方式封装的一组指令、工具调用序列或提示模板，面向代理内部逻辑的复用；插件则更接近适配器层，负责把外部 API、数据库或第三方服务暴露为代理可调用的工具。两者并列时，技能解决“同类任务怎么做”的知识沉淀，插件解决“外部系统怎么接”的连接问题。这种分层让复用发生在不同粒度上，但也意味着排障时需要区分问题出在技能逻辑、插件适配还是底层服务。

结构化输出与权限默认值

结构化输出让代理的返回值可以直接被下游程序消费，减少了「模型输出一段话再解析」的脆弱环节。配合权限默认值，SDK 在安全侧的取向变得清晰：默认收紧，按需放开。

权限默认值的变化容易被低估。代理系统一旦接入真实工具，权限配置就是攻击面。默认值收紧意味着新项目在起步阶段不会因为疏忽而获得过大权限，团队需要显式声明所需能力。这对安全是好事，对上手速度是摩擦，文档和示例的清晰度会直接决定采用体验。

结构化输出与权限默认值：结构化输出指模型按预定义 schema（如 JSON Schema）返回字段固定的数据，下游程序可以直接反序列化使用，而不必用正则或自然语言解析。它降低了输出格式漂移带来的脆弱性，但仍需校验字段完整性和取值合法性。权限默认值则遵循最小权限原则：新建代理默认只拥有最低限度的工具访问权，团队必须显式声明所需能力。这减少了因配置疏忽导致的越权风险，但也要求开发者在项目初期就梳理清楚代理实际需要哪些权限。

怎么用：从最小可行代理开始

基于官方说明，合理的上手路径是先跑通单代理加结构化输出，再引入 SessionStore 做状态持久化，最后才拆分子代理。技能和插件应该在出现第二个复用需求时再抽象，过早封装反而增加理解成本。

需要提醒的是，嵌套子代理的上限、权限默认值的具体规则，官方描述较为概括。生产环境采用前应查阅对应版本的详细文档，并以实际测试结果为准，不要仅凭概览性描述做架构决策。

常见问题

Q：嵌套子代理有层数限制吗？ A：有。官方更新说明提到 caps，即对派生规模设置上限，具体数值需查对应版本文档。

Q：SessionStore 是必选项吗？ A：不是。短任务可以不接入，长任务或需要恢复与审计的场景建议启用。

Q：权限默认值收紧会影响已有项目吗？ A：默认值变化通常影响新建配置，已有项目升级时应核对显式权限声明是否完整。