简介：本文围绕 AI Agent 技能管理中的“按需加载”与“全量注入”两种方案展开对比，从上下文消耗、缓存命中、多 Agent 隔离、实现复杂度等维度分析各自优劣，帮助开发者在构建复杂 Agent 系统时做出更合理的架构选型。
构建一个功能丰富的 AI Agent 时，开发者普遍面临一个矛盾：Agent 需要掌握代码审查、数据分析、文档撰写、测试生成等数十种技能，但单次任务通常只需要其中一两种。如何在“能力覆盖面”与“上下文效率”之间取得平衡，成为 Agent 架构设计中的关键问题。
围绕这一问题，业界演化出两条主要技术路线：
本文将从架构设计、Token 消耗、缓存友好性、多 Agent 安全性、实现复杂度等维度对两种方案进行系统对比，为技术选型提供参考依据。
全量注入是早期的常见做法，也是实现上最直接的方式。开发者将所有可用技能的说明文本拼接到 System Prompt 中，Agent 在每次推理时都看到完整信息。这种方案的核心理念是“信息前置”——让模型在第一时间掌握全部能力描述，避免加载延迟或选择错误。
按需加载借鉴了 UI 设计中的“渐进式披露”原则：先提供概览让用户决策，需要时再展开详情。在 Skill 机制中的具体映射为：
可以将其类比为餐厅点餐流程：先看菜单（概览），点菜后厨师开始制作（加载），用餐完毕自动撤盘（过期清理）。
尽管两种方案在实现逻辑上存在显著差异，但它们共享以下基础目标：
这是两种方案最直观的差异点。
在全量注入方案中，假设 Agent 拥有 30 个技能，每个技能的平均说明文本为 800 Token，则仅技能描述部分就占据约 24,000 Token。而实际任务中，约 90% 的场景仅需 1~2 个技能，这意味着绝大部分 Token 消耗属于“无效载荷”。
按需加载方案将技能描述拆分为概览层和详情层。概览层的 30 个技能仅需约 50~100 Token（每个技能名称加一句话描述），详情层仅在需要时加载 1~2 个技能，额外增加约 800~1,600 Token。整体上下文占用从数万 Token 降至千 Token 级别，显著提升了上下文窗口的可用空间。
Prompt Caching 是降低 LLM API 调用成本的关键机制。其基本原理是：当请求的前缀部分（通常包含 System Prompt）保持稳定时，服务端可以复用之前计算的 KV Cache，从而减少计算耗时和费用。
全量注入方案的缓存困境：如果开发者根据任务类型动态拼接不同的技能组合，那么每次请求的 System Prompt 都可能不同，导致缓存前缀不匹配，缓存命中率大幅下降。即使有缓存机制，动态拼接也会破坏缓存的稳定性边界。
按需加载方案的缓存优势：由于 System Prompt 中只包含稳定的概览信息（技能列表通常固定不变），请求前缀保持一致，缓存命中率自然维持在较高水平。技能详情的加载发生在工具调用阶段，不会破坏初始请求的缓存结构。这在多轮 Agent 交互场景中尤其重要——多轮对话中 System Prompt 的稳定性决定了缓存的持续有效性。
在多 Agent 协作场景中，不同 Agent 可能承担不同角色，例如一个负责代码审查，另一个负责数据可视化。如果所有 Agent 共享同一个全量技能注入 Prompt，可能出现以下问题：
按需加载方案天然提供了隔离边界：每个 Agent 会话维护独立的加载状态（Session State），只有被显式加载的技能详情才会进入该会话的上下文。不同 Agent 之间的技能加载互不干扰，角色定位更加清晰。
全量注入方案的隐含假设是“信息越多，选择越准”。但实际上，当上下文包含大量不相关技能信息时，模型可能面临注意力分散问题。特别是技能数量较多时，技能之间的相似描述可能导致模型选择错误的技能路径。
按需加载方案将选择过程分解为两步：
这种“先粗后细”的流程在信息检索和决策理论中通常比“一次性给出全部信息”更可靠。同时，概览中一句话描述的设计也迫使技能作者提炼出最核心的能力标识，降低了歧义性。
全量注入方案的实现优势：无需额外的工具定义、状态管理或加载逻辑，开发者只需在构建请求时拼接所有技能文本。对于技能数量较少（如 5 个以内）的场景，这是最经济的实现方式。
按需加载方案的实现成本：按需加载需要额外的架构支撑，包括：
这些组件增加了系统设计和维护的复杂度，尤其在需要支持多用户、高并发时，状态管理需要配合分布式会话层实现。
按需加载方案引入了一次额外的工具调用往返。在极端简单任务中，Agent 需要先发起加载请求，等待返回后再继续推理，这可能增加 0.5~2 秒的响应延迟。
全量注入方案则不存在这一额外往返——所有信息在首次请求中已就绪，Agent 可以直接进入推理和任务执行流程。因此，在对响应延迟极为敏感且技能数量有限的场景中，全量注入仍有其适用价值。
当技能数量从 10 个增长到 100 个时，两种方案的差异会急剧放大：
这一特性使得按需加载方案更适合“技能生态持续扩张”的长期规划场景。
| 对比维度 | 全量注入方案 | 按需加载方案 |
|---|---|---|
| 上下文 Token 消耗 | 高，随技能数量线性增长 | 低，概览层恒定，详情层按需 |
| Prompt 缓存友好性 | 差，动态拼接时缓存难以命中 | 好，System Prompt 稳定，缓存命中率高 |
| 多 Agent 隔离性 | 弱，存在信息串扰风险 | 强，会话级加载状态天然隔离 |
| 技能选择准确性 | 技能多时注意力分散，准确率受影响 | 分步选择，粗筛后精读，准确性更可控 |
| 实现复杂度 | 低，仅需拼接字符串 | 中高，需仓库、工具、状态管理和过期策略 |
| 响应延迟 | 无额外交互轮次 | 多一次工具调用往返 |
| 可扩展性 | 受上下文窗口硬限制 | 与技能总量基本解耦 |
| 调试可观测性 | 难以判断哪些技能影响了模型行为 | 可通过加载日志精确追踪 |
| 适用技能规模 | 5~10 个以内 | 10 个以上，尤其适合持续扩展的场景 |
选型判断应基于以下核心问题：
第一，技能总量和增长速度是首要评估指标。 如果技能总数稳定在 10 个以内且未来没有大量扩展计划，全量注入足以胜任。如果技能数量在持续增长，或已经超过 10 个，建议优先考虑按需加载架构。
第二，评估上下文预算。 计算处理器技能描述在上下文中的占比：如果技能描述占上下文总预算的 30% 以上，按需加载带来的空间释放将直接转化为更好的任务执行能力和更低的 Token 成本。
第三，考虑团队的工程化能力。 按需加载方案需要维护额外的组件，如果团队规模有限且迭代节奏紧张，可以先从轻量级的手动加载工具开始，逐步演进到完整的自动生命周期管理。
第四，关注缓存收益的实际计算。 在评估缓存收益时，建议结合实际的请求模式（是否多轮？System Prompt 是否稳定？）进行模拟测算，而非仅凭理论判断。
从全量注入迁移到按需加载并非简单替换，需要关注以下风险点：
技能内容的拆分与重组：原有技能文档需要拆分为“概览描述”和“详情内容”两层。概览描述的质量直接影响模型能否做出正确的加载决策。一句话描述需要精确、无歧义地表达技能的核心能力边界。
模型对加载工具的使用能力：并非所有模型在 Tool Calling 能力上表现一致。迁移前需要验证目标模型是否能在“看到概览后被期待使用加载工具”的流程中稳定表现。部分模型可能倾向于“用已有的概览信息猜测”，而非主动加载详情。
加载失败与异常处理：需设计加载失败时的回退机制（例如重试、降级或返回错误提示），避免 Agent 在加载失败后自行编造技能内容。
过期策略的调优：过期策略设置过短会导致频繁重复加载，过长则会削弱按需加载的 Token 节省效果。建议根据实际会话轮次分布进行调优。
渐进式迁移路径：不必一步到位。可以先在会话中引入显式的技能助记流程，通过日志分析模型的技能选择行为，确认可行后再逐步将高频加载的技能详情固化到缓存层，降低工具调用的额外延迟。
Agent Skill 的按需加载与全量注入代表了两种不同的架构哲学：全量注入追求“信息完整性”和“实现简单性”，按需加载追求“上下文效率”和“系统可持续性”。核心差异不在于技能内容本身，而在于信息分发策略——是全量前置还是渐进披露。
在技能数量有限、延迟要求苛刻的场景中，全量注入仍然是一个合理选择。但当技能生态持续扩张、成本控制成为关键指标、多 Agent 隔离成为架构刚需时，按需加载的优势将随着规模增长而愈发明显。
最终选型应当回到业务的具体约束：技能规模、成本敏感度、延迟容忍度、工程化能力，以及团队对长期架构演进的预期。没有一种方案能在所有场景下胜出，但理解二者差异的本质，能帮助你在正确的场景做出正确的架构决策。