子代理与代理技能：为长期代理任务执行可重用知识

# 子代理与代理技能：执行可复用知识以完成长期智能体任务  
来源：https://arxiv.org/html/2609.09233  
Rachel Lawrence、Alicia Curth、Sushrut Karmalkar、Niranjani Prasad  
康奈尔大学、微软剑桥研究院  

###### 摘要  
语言模型代理如何有效利用可复用知识库来解决长期任务？近期研究日益关注“代理技能”：即作为技能包呈现的可复用能力，这些技能包包含多文件集合（如指令、脚本及其他资源），帮助代理执行特定任务。代理技能通常通过将技能指令加载到代理上下文中并依赖代理遵循这些指令来执行。然而，随着任务周期延长，这种方法变得日益脆弱，因为上下文窗口中积累的信息越多，推理质量越会下降。我们研究了一种替代方案：将技能包作为子代理调用。子代理执行不是将技能指令加载到主上下文中，而是生成独立的上下文窗口来处理单个子任务。我们证明，当技能包具有明确的输入-输出契约且其指令编码了履行这些契约所需的程序知识时，子代理执行的性能优于代理技能执行。其代价是额外的通信开销，因为需要在主代理及其子代理之间交换额外的token。我们的结果表明，可复用知识的价值不仅取决于其内容，还取决于其组织形式和调用方式。  
11脚注：本工作在微软剑桥研究院实习期间完成。  

## 1 引言  
我们如何为AI代理配备特定领域的知识，使其能够解决复杂任务？这是AI领域的长期问题，可追溯至符号AI时代。当时研究者尝试通过规则、逻辑和知识图谱等结构化表示显式地编码知识（Shortliffe 1976；Lenat 1995；Brachman et al. 2004；Speer et al. 2017）。深度学习的兴起将范式从直接知识注入转向基于权重的学习：知识从数据中获取并隐式存储在神经网络权重中。大型语言模型（LLMs）的出现部分推动了向显式知识注入的回归。通过上下文学习，LLMs在推理时无需更新权重即可获取并应用新信息，这种表示方式是自然语言——最富表达力的符号形式之一。  

近期，*代理技能*（Anthropic 2025）已成为LLM代理进行知识注入的有效方式。每个代理技能由一个*技能包*表示：包含指令和脚本的多文件包，适用于解决特定任务。可用技能的名称和描述会提供给LLM代理。当代理调用技能时，它将获取该技能的指令并遵循执行。这些代理技能已成为为LLM代理提供可复用领域特定知识的主流方式。  

尽管名称相似，代理技能与强化学习中的“技能”概念（Sutton et al. 1999；Parr and Russell 1997；Dietterich 2000）有显著差异：技能是由高层控制器调用的时间扩展策略。而代理技能调用仅将技能配方（SKILL.md文件）加载到LLM代理的上下文中，而非直接执行技能或解决子任务。因此，即使代理技能包含相关信息，调用它也可能效果不佳，因为添加更多指令会增加上下文长度，而代理性能会随上下文增长而下降（Liu et al. 2024；Du et al. 2025；Hong et al. 2025；Li et al. 2026a）。随着任务周期延长，这种上下文膨胀问题变得愈发严重。  

因此，我们研究了代理技能的替代方案：将技能包作为*子代理*执行。子代理执行不是将技能指令加载到主上下文中，而是生成新的上下文窗口，以技能指令为种子，独立执行技能，仅将输出返回给主代理。我们认为，通过将任务分配到多个上下文窗口，可以降低每个单独上下文处理的最大信息量（图1）。虽然现有的代理框架确实包含子代理，但其通常未被充分利用，主要用于独立子任务并行执行以降低延迟的场景（Anthropic 2026）。  

然而，将技能作为子代理执行存在缺点。例如，我们失去了组合多个技能的知识来解决子任务的能力。在本文中，我们证明当技能包以程序性知识的形式呈现，并具有清晰的输入和输出契约时，它适用于子代理执行——这类似于强化学习中的“选项框架”（Sutton et al. 1999）。具有明确输入输出接口的程序性技能本质上是自包含的，允许将其内部推理委托到单独的上下文中。  

在SkillsBench（评估代理技能的基准测试）中，我们合成了从成功任务轨迹中提取的、遵循契约的程序性技能包，并证明将这些技能包作为子代理执行显著优于代理技能执行。我们的发现表明，技能的执行方式以及技能知识的组织方式都是重要的设计选择，对代理性能有重大影响。  

图1：两种技能包执行方式：代理技能与子代理。代理技能执行在单个上下文中进行所有推理，而子代理执行为每个子任务创建新的上下文窗口，每个窗口以技能指令（SKILL.md）初始化。由于子代理在自己的上下文中推理，主代理与子代理之间需要额外的token进行通信。  

## 2 背景：工具代理、代理技能与子代理  
我们关注一种迭代操作的工具调用语言模型代理。令 \(c_t\) 表示第 \(t\) 轮的代理上下文。为简化符号，假设代理每轮调用一个工具。在每轮 \(t\)，语言模型 \(\pi_{LLM}\) 生成文本响应 \(r_t\)、工具 \(k_t\) 和工具参数 \(x_t\)：  
\[
(r_t, k_t, x_t) = \pi_{LLM}(c_t) \tag{1}
\]  
所选工具由工具执行器 \(E\) 执行：  
\[
o_t = E(k_t, x_t) \tag{2}
\]  
其中 \(o_t\) 表示工具输出。然后通过追加响应、工具调用和工具结果来更新代理上下文：  
\[
c_{t+1} = c_t \oplus (r_t, k_t, x_t, o_t) \tag{3}
\]  
我们略微滥用符号，使用 \(\oplus\) 表示将交互轨迹追加到上下文。假设任何结构化对象在连接前已转换为文本表示。代理重复此过程，直到在某轮 \(T\) 产生最终答案。  

#### 代理技能  
代理技能由技能包 \(s\) 指定：描述 \(d\) 简要概述技能目的，始终提供给主代理以发现技能；指令文件 \(m_k\)（实现为 SKILL.md）指定如何执行技能；资源集合 \(R\) 包含支持性工件，如脚本、示例、参考文档和嵌套目录。代理技能是由技能包构建的工具，记为 \(k = \mathrm{AgentSkill}(s)\)，其底层包的指令文件记为 \(m_k\)。调用代理技能无需额外参数，仅返回技能指令 \(m_k\)：  
\[
E(k = \mathrm{AgentSkill}(s), \varnothing) = m_k \tag{5}
\]  
因此，技能内容直接暴露给主上下文，其规定的流程由 \(\pi_{LLM}\) 自身执行：技能执行的每个步骤都是主上下文 \(c\) 中的普通代理步骤，应用公式（1）、（2）和（3）。  

#### 子代理  
子代理提供了利用可复用知识的替代机制。与代理技能类似，子代理也由技能包构建，记为 \(k = \mathrm{Subagent}(s)\)。但不同于代理技能，调用子代理不会将技能指令文件直接暴露给主代理，其执行也不由 \(\pi_{LLM}\) 进行。相反，工具执行器实例化一个不同的策略，以技能指令 \(m_k\) 为条件，并根据任务输入 \(x_t\) 初始化新的代理上下文：  
\[
\pi^{(k)}(\cdot) \triangleq \pi_{LLM}(m_k \oplus \cdot), \quad c_0^{(k)} = x_t \tag{6}
\]  
子代理然后在该独立上下文中执行独立的工具调用推理过程，在 \(\pi^{(k)}\) 下遵循公式（1）、（2）和（3），并仅返回最后一轮 \(T\) 的响应 \(r_T^{(k)}\)：  
\[
E(k = \mathrm{Subagent}(s), x_t) = r_T^{(k)} \tag{7}
\]  

两种机制均使用相同的技能包 \(s\)，但知识条件化的策略不同。代理技能让单个策略 \(\pi_{LLM}\) 在单个上下文中运行，技能执行作为主代理自身轮次序列的一部分展开；子代理则为每个技能包引入单独的子策略 \(\pi^{(k)}\)，每个子策略在主代理既不读取也不写入的上下文中操作。注意 \(\pi^{(k)}\) 定义在与主 \(\pi_{LLM}\) 相同的LLM上，但也可以从不同的LLM实例化；使其成为单独策略的原因是它独立实例化，并且仅通过输入 \(x_t\) 和输出 \(r_T^{(k)}\) 与主代理通信。  

## 3 子代理用于长期智能体任务  
LLM推理能力随上下文长度增加而下降（Liu et al. 2024；Du et al. 2025；Hong et al. 2025；Li et al. 2026a）；这种下降与带宽受限的注意力机制相关：LLM只能在长输入中传递有限量的信息（Schnabel et al. 2026）。长期智能体任务尤其容易受此退化影响：它们要求代理对越来越长的轨迹进行推理，这些轨迹包含冗长的工具输入输出和中间推理。虽然技能包可能包含解决此类任务的有用知识，但调用代理技能（将技能指令加载到代理上下文中）会加剧上下文过载问题。解决长期任务可能不仅取决于能否访问有用的技能，还取决于能否以控制上下文增长的方式执行这些技能。为此，我们探索了使用*子代理*的方案。  

### 3.1 通过子代理执行减少峰值上下文长度  
为控制上下文增长，我们直接探讨生成更多上下文窗口是否有帮助。上述带宽限制的关键不是任务消耗的总上下文长度，而是任何单个窗口必须处理的*峰值*上下文长度。如果能将任务分解为更小、自包含的子任务，并在单独的上下文窗口中执行每个子任务，我们期望所有这些窗口的峰值上下文长度将小于单个整体上下文窗口的长度。子代理执行正好编码了这种机制（图1）。  

当调用子代理时，会生成新的上下文窗口，并以子代理的输入及其技能包的指令进行初始化。看待子代理执行的一种视角是通过信息封装。子代理封装了子任务特定的信息。子代理的内部轨迹对主代理（父代理）隐藏。只有子代理的最终输出对主代理可见。主代理需要推理的信息因此减少，从而能更好地推理。  

然而，子代理的峰值上下文减少是有代价的。跨多个上下文窗口执行任务会引入主代理与子代理之间的通信开销（图1）：由于子代理看不到主上下文，必须为它们提供足够的输入信息以执行子任务，这意味着相关信息通常在上下文窗口间重复。因此，子代理执行以更高的总token数为代价换取更短的峰值上下文长度。  

我们注意到，流行的代理框架如Claude Code和OpenAI Codex确实支持生成子代理，但它们通常用于任务并行化而非信息封装（Anthropic 2026）。在许多情况下，生成的子代理不使用任何技能包；它们作为轻量级并行工作者发挥作用。将子代理作为执行可复用知识的机制仍相对未被充分探索。  

### 3.2 有效子代理的输入输出契约  
通过子代理减少峰值上下文长度，*仅当*子上下文窗口中的子任务被正确解决时，才对代理性能有益。与代理技能不同，子代理引入了额外的子任务委派问题：主代理必须为子任务识别合适的子代理，并提供足够的信息使其成功解决任务。如果主代理在任一方面失败，子代理将变得低效。  

为确保主代理正确委派子任务并为每个子任务提供所需信息，每个技能描述需要告知主代理对应子代理能解决什么子任务以及应向其提供什么信息。当然，技能指令随后必须与技能描述匹配：它们必须告诉子代理如何解决描述承诺要解决的子任务。如此设计的技能包呼应了“选项框架”（Sutton et al. 1999）：作为子代理调用时，它们表现为基于语言的选项。选项定义为：  
\[
\omega = (\mathcal{I}_\omega, \pi_\omega, \beta_\omega) \tag{8}
\]  
其中 \(\mathcal{I}_\omega\) 是初始集，\(\pi_\omega\) 是选项策略，\(\beta_\omega\) 是终止条件。选项只能在属于 \(\mathcal{I}_\omega\) 的状态中被调用，之后它遵循 \(\pi_\omega\) 直到根据 \(\beta_\omega\) 发生终止。