简介：当 AI Agent 技能数量持续增加时，全量注入 System Prompt 会带来上下文浪费、缓存失效与多 Agent 干扰等问题。本文从架构设计角度对比“技能按需加载”与“全量静态注入”两种方案，围绕加载机制、Token 消耗、缓存友好性、多 Agent 隔离和实现复杂度展开分析，并结合渐进式披露、会话状态管理与过期清理策略，给出不同场景下的选型建议与迁移注意事项。
构建一个功能丰富的 AI Agent 时，技能数量往往从最初的三五项迅速增长到几十项。代码审查、日志分析、数据清洗、文档摘要、安全扫描、接口调试、测试用例生成……每一项技能都可能包含数百到数千 Token 的指导文本、示例和边界条件说明。
面对这些技能，传统做法是将全部技能说明一次性写入 System Prompt。这种“全量静态注入”方案在技能较少时简单直接，但随着技能规模增长，问题逐渐暴露：
正是在这一背景下，“技能按需加载”作为一套系统化解决方案被提出。本文将其与“全量静态注入”进行对比，帮助读者判断在什么条件下应该引入按需加载，以及实现过程中需要关注哪些架构问题。
全量静态注入是指在 Agent 启动或每次请求构造时，将所有可用技能的完整说明文本拼接进 System Prompt。Agent 在一开始就“看到”了全部能力信息。
基本特征：
技能按需加载是指将技能的“概览信息”与“完整内容”分离。每次请求只携带所有技能的名称和一句话描述，当 Agent 判断当前任务需要某项技能时，通过工具调用主动获取该技能的完整说明，加载后的内容进入会话状态，并根据策略自动过期。
基本特征：
尽管两种方案在实现路径上差异明显，但它们共享以下目标与基础逻辑：
第一，都服务于“让 Agent 正确理解并执行技能”这一核心目标。 无论是提前注入还是运行时加载，最终都是为了给模型提供足够的上下文，使其按照预期方式完成任务。
第二，都依赖“技能描述文本”作为知识载体。 两种方案中，技能的本质都是结构化或半结构化的自然语言指令，包含目标说明、执行步骤、输入输出格式和注意事项。
第三，都需要考虑技能的组织与版本管理。 无论采用哪种加载策略，技能内容的编写规范、分类体系和更新流程都是工程实践中必须面对的问题。
第四，都受到上下文窗口的物理约束。 即使是按需加载，当单个技能本身非常庞大或者多个技能同时被加载时，依然可能逼近上下文上限。
全量静态注入的加载逻辑发生在请求构造阶段，由系统代码决定哪些技能被拼入提示词。它不依赖模型自身的判断，也不消耗推理轮次来做“是否加载”的决策。
技能按需加载则将加载决策权交给了模型本身。模型看到技能概览列表后，需要判断“当前任务是否匹配某个技能”，然后显式发出工具调用请求。这增加了一个推理环节，但换来了对上下文内容的精准控制。
差异影响： 按需加载引入了额外的推理开销和不确定性——模型可能判断失误，加载了不相关的技能，或者漏加载了必要技能。因此，按需加载方案通常需要在设计中加入“技能建议器”或“任务分类器”等辅助机制来提高加载准确性。
全量静态注入的 Token 消耗是恒定的。无论任务简单还是复杂，每次请求都支付相同的技能说明成本。设技能总数为 N，平均每个技能 M Token，则每次请求的固定开销为 N×M。
技能按需加载将固定开销压缩到概览层。概览层通常每个技能仅 10-30 Token，N 个技能的日常开销从 N×M 降至 N×30 左右。详情层只在被加载时才产生成本。对于仅需 1-2 个技能的典型任务，总 Token 消耗显著下降。
差异影响： 当 M 较大（例如每个技能数千 Token）而概览层很小（几十 Token）时，按需加载的 Token 节省效果最为明显。但如果任务本身就需要遍历使用大量技能，两种方案的差距会缩小，甚至按需加载因为额外的工具调用轮次反而可能增加总消耗。
LLM API 的 Prompt Caching 通常基于请求前缀的字节级匹配。全量静态注入方案中，如果所有请求使用完全相同的技能文本块，缓存可以稳定命中。但问题恰恰在于——实际场景中不同任务需要不同技能，开发者往往会将技能按任务类型分组拼接，导致系统提示词频繁变化。
技能按需加载将系统提示词拆分为“稳定的概览部分”和“动态的详情部分”。概览部分对所有请求一致，可以稳定命中缓存。详情部分虽然在会话内动态变化，但体积相对可控，且加载动作往往发生在会话早期，对后续轮次的缓存命中影响较小。
差异影响： 按需加载在缓存设计上具有天然优势，但这要求实现时严格遵守“概览层内容所有请求完全一致”的原则。如果概览层本身也根据任务类型动态变化，缓存优势就会大打折扣。
在多 Agent 协作场景中，全量静态注入通常使用同一套提示词模板服务于所有 Agent。如果模板中包含了大量特定角色的技能说明，就会产生“技能串扰”——Agent A 看到 Agent B 的技能说明后，可能在执行任务时错误地采用了不属于自己职责范围的工具或流程。
技能按需加载将技能加载状态放在会话级别。每个 Agent 会话维护自己的已加载技能集合，互不可见。即使是同一个模型实例处理多个 Agent 的请求，也可以通过会话 ID 进行状态隔离。
差异影响： 按需加载在隔离性上明显优于全量注入，但这要求运行时框架必须提供可靠的会话状态管理能力，包括会话创建、状态读写、过期清理和并发安全。
全量静态注入的实现极为简单。只需要一个技能文本文件或配置项，在构造请求时拼接即可。对小型项目来说，这几乎没有任何架构成本。
技能按需加载则是一个系统性工程。它至少需要以下组件协同工作：
这是一笔不可忽视的开发与维护成本。
| 对比维度 | 全量静态注入 | 技能按需加载 |
|---|---|---|
| 加载方式 | 请求构造时全量拼接 | 模型运行时按需工具调用 |
| Token 消耗 | 每次请求恒定，技能越多越高 | 日常仅概览层，按需加载详情 |
| 缓存命中 | 技能内容变化时命中率下降 | 概览层稳定，缓存友好 |
| 多 Agent 隔离 | 模板共享，技能相互可见 | 会话级状态，技能互不可见 |
| 实现复杂度 | 低，仅需文本拼接 | 高，需仓库、工具、状态管理等 |
| 模型推理开销 | 无额外决策轮次 | 需技能选择决策 + 工具调用轮次 |
| 技能更新方式 | 修改提示词模板后重新部署 | 更新仓库内容，概览层自动同步 |
| 上下文边界控制 | 弱，全部技能始终可见 | 强，精确控制哪些技能进入上下文 |
| 适用技能数量 | 少量技能（通常 ≤10） | 中大规模技能（通常 ≥15） |
| 故障容忍度 | 无加载失败风险 | 工具调用失败时可能影响任务完成 |
技能数量少且稳定的场景。 如果 Agent 只有 5-8 项技能，且这些技能在大多数任务中确实都会用到，全量注入的简单性带来的收益远大于 Token 的微小浪费。
对延迟敏感且不容忍额外推理轮次的场景。 某些实时交互系统对响应时间有严格要求，按需加载所增加的工具调用轮次可能不可接受。
开发资源有限的原型验证阶段。 在概念验证阶段，快速跑通业务逻辑比架构优雅更重要。全量注入可以让团队先验证技能本身的有效性。
单 Agent、单任务类型的垂直场景。 当 Agent 的职责边界高度明确且技能集合恰好覆盖该职责时，全量注入不会产生明显的上下文浪费。
技能数量多且任务类型多样的通用 Agent 场景。 当一个 Agent 需要覆盖代码审查、数据分析、文档生成、测试设计等数十种技能，而单次任务通常只涉及其中一两种时，按需加载的 Token 节省效果显著。
对 Prompt Caching 命中率有较高要求的成本敏感场景。 如果系统每天处理大量请求，且希望最大化利用缓存降低推理成本，按需加载的稳定概览层设计是更优选择。
多 Agent 协作且角色分工明确的场景。 不同 Agent 承担不同职责时，会话级技能隔离可以避免角色混淆和技能误用。
技能迭代频繁的场景。 当技能内容经常更新时，按需加载将更新集中在仓库层，不需要每次修改都重新部署整个提示词模板。
选型判断的核心变量是技能数量与任务技能比的乘积效应。
用伪代码表达这一决策逻辑：
if 技能总数 <= 10 and 任务类型单一:选择全量静态注入elif 技能总数 >= 15 and 单任务平均所需技能 <= 3:选择技能按需加载elif 多Agent协作 and 角色隔离是硬性需求:选择技能按需加载elif 开发阶段 == "原型验证" and 团队规模 <= 3:先全量注入，后续演进else:采用混合策略：高频核心技能常驻 + 低频技能按需加载
上述混合策略值得特别说明。并非所有技能都必须走按需加载路径。将少量高频使用的核心技能（例如“通用格式规范”“安全红线”）常驻在概览层中，将大量低频或领域专属技能放入按需加载层，可以在简单性和效率之间取得平衡。
如果决定从全量静态注入迁移到技能按需加载，以下事项需要提前评估。
迁移的第一步是将现有的“大段技能描述”拆分为“元数据 + 完整内容”。元数据包括技能名称、触发条件、一句话描述和适用任务类型。这一步需要人工评审，因为概览层的质量直接决定模型的加载决策准确性。描述太模糊会导致漏加载，描述太宽泛会导致过度加载。
按需加载依赖工具调用机制。工具接口需要处理以下异常情况：
建议在加载工具中加入参数校验和幂等处理，并设置单次会话的最大加载技能数量上限，防止内容无限累积。
已加载技能的过期策略是动态加载方案的核心机制之一。常见策略包括：
无论采用哪种策略，都需要在请求处理器中实现确定性的清理逻辑，保证行为可预测。
迁移到按需加载后，系统提示词的结构发生变化。为最大化缓存命中率，应确保概览层文本在所有请求中字节级一致，包括空格和换行符。技能列表的排序也必须固定，避免因哈希顺序或字典序变化导致缓存失效。
按需加载引入了新的故障模式：技能加载错误、漏加载、过度加载。建议在运行时记录每次请求的以下信息：
这些数据是后续调优概览层描述和加载策略的基础。
全量静态注入与技能按需加载并非“新旧替代”关系，而是对应不同复杂度阶段的两种工程选择。全量注入胜在简单、确定性高、无额外推理开销，适合技能数量少、任务类型单一的原型和垂直应用。按需加载则将“该不该让模型看到某段内容”的决策权交给运行时判断，用一定的实现复杂度和推理开销，换取 Token 效率、缓存友好性和多 Agent 隔离能力。
从架构演进角度看，技能按需加载所代表的“渐进式披露”思想具有更广泛的适用性。它本质上解决的是“信息量与注意力资源不匹配”的问题——当模型面对的信息总量超过单次任务所需时，让模型自己决定加载什么，比由开发者替它决定全部内容更加灵活。如果正在构建的 Agent 技能规模已经超过十几项，或者已经感受到 Token 成本与缓存命中率的压力，那么认真评估按需加载方案，是一个值得投入的工程方向。