AI智能体如何实现技能注入：完整的跨平台对比

引言

每个AI智能体框架都面临着同一个基本问题：如何让大语言模型擅长某个特定领域？模型本身具有广泛的通用知识，但当你需要它执行代码审查、部署基础设施或在Minecraft中探索时——它需要专门的指令、工具访问和领域上下文。

这就是技能注入问题。而每个主要框架的解决方案各不相同。

一些平台会将所有内容预先加载到系统提示词中。另一些使用延迟加载，仅在智能体需要时才展示能力。还有一些使用向量数据库基于语义相似度检索相关技能。这些差异并非纸上谈兵——它们直接影响token成本、智能体可靠性以及智能体实际能管理多少技能。

我们分析了11个主要的AI智能体平台，以精确了解技能在提示词中的位置、加载时机、token消耗以及上下文窗口满时的存活方式。这不是表面的功能对比。我们深入研究了源代码、文档和架构图，以绘制每个平台的精确注入机制。

总览对比表

以下是详细分析前的完整概览。

注入机制：位置、时机和方式

持久化、Token成本和常驻行为

准备好发展您的业务了吗？

今天开始免费试用，几天内即可看到结果。

申请演示 登录

“技能注入"到底意味着什么

在深入对比之前，让我们定义问题空间。AI智能体的上下文窗口——LLM每次调用时看到的全部文本——具有固定大小。每一个token的指令、对话历史、工具定义和检索数据都在争夺窗口中的空间。

智能体语境中的"技能"是任何改变智能体行为的结构化专业知识包。这可以是：

• 指令：告诉智能体如何处理特定领域（代码审查指南、部署检查清单）
• 工具定义：赋予智能体可调用函数（API集成、文件操作）
• 少样本示例：向智能体展示优质输出的样貌
• 检索知识：来自向量数据库或外部文档

注入机制——内容进入上下文的位置和时间——决定了三个关键属性：

1. Token效率：技能消耗多少token？即使不需要该技能时也要付出这个成本吗？
2. 可靠性：智能体在相关时能否始终使用该技能，还是可能错过触发信号？
3. 可扩展性：智能体可以访问多少技能，才不会因上下文膨胀而降低性能？

每个框架在这三个维度上做出不同的权衡。让我们逐一分析。

注入频谱：从常驻到按需

在所有11个平台中，技能注入方法分布在"所有内容预先加载"到"除非明确需要否则不加载"的频谱上。

在频谱的一端，CrewAI、SuperAGI和CAMEL-AI等平台在每次LLM调用中注入每个已激活技能的完整内容。智能体始终拥有完整的专业知识。简单、可靠，但token消耗高昂。

在另一端，Claude Code、LangChain Deep Agents和OpenAI的Responses API使用渐进式披露——智能体在启动时只看到技能名称和简短描述，完整内容按需加载。高效、可扩展，但需要智能体识别何时需要某项技能。

在中间位置，AutoGen Teachability和Voyager使用语义检索来为每轮对话仅注入最相关的技能，创建动态的、上下文敏感的注入模式。

还有一些独特的方法：DSPy离线编译优化的少样本示例并将其永久嵌入模块提示词中。MetaGPT将技能编码为action模板，仅在特定角色转换到特定action时才激活。

让我们详细分析每一个。

加入我们的新闻通讯

免费获取最新提示、趋势和优惠。

电子邮件地址

订阅

Claude Code：三层渐进式披露

Claude Code实现了最精密的技能注入架构之一，使用三层渐进式披露系统来平衡感知能力和token效率。

第一层：常驻上下文

在会话启动时，每个可用技能的名称和描述被注入到system-reminder消息中——模型始终可见的元数据块。每个技能约消耗250个字符，所有技能描述加起来约占上下文窗口预算的1%（大约8K字符作为回退预算，可通过SLASH_COMMAND_TOOL_CHAR_BUDGET环境变量覆盖）。

类似地，延迟工具——尚未加载完整JSON schema的工具——以仅名称列表的形式出现在system-reminder块中。从Claude Code v2.1.69起，即使是Bash、Read、Edit、Write、Glob和Grep等内置系统工具也延迟到ToolSearch之后，将系统工具上下文从约14-16K token减少到约968 token。

智能体看到足够的信息来知道有哪些可用功能，而无需支付完整定义的token成本。

第二层：激活时加载

当用户输入斜杠命令（例如/commit）或模型根据描述自动匹配技能时，完整的SKILL.md正文通过Skill工具作为对话消息加载。这个正文包含完整的指令——有时是数千token的详细指导。

关键细节：Shell预处理首先运行（技能文件中的任何!command指令会执行，其输出替换该指令），一旦加载，技能正文将在会话的剩余时间内保留在对话中。

第三层：按需加载

额外资源——参考文档、脚本、资产文件——仅在模型明确决定使用Read工具访问时才加载。这些资源永远不会自动加载。

上下文压缩行为

当对话接近上下文限制并触发压缩时，Claude Code以每技能5K token、总计25K上限的预算重新附加最近调用的技能。最近调用的技能获得优先级。较旧的技能可能被完全丢弃。

这种三层架构意味着拥有20+可用技能的智能体只需支付最小的前期成本，但可以在单轮对话中访问其中任何一个的完整专业知识。

CrewAI：将完整内容注入每个任务提示词

CrewAI采取了与渐进式披露相反的方法。当技能为智能体激活后，其完整内容会注入到智能体执行的每个任务提示词中。

工作原理

CrewAI中的技能是自包含的目录，每个都有一个SKILL.md文件，包含YAML frontmatter（名称、描述、许可证、兼容性、允许的工具）和markdown正文。技能系统区分技能和工具：技能注入指令和上下文来塑造智能体的思维方式，而工具提供可调用的函数来执行操作。

在智能体初始化期间，Agent.set_skills()调用discover_skills()在元数据级别扫描技能目录，然后调用activate_skill()读取完整的技能正文。在任务执行时，_finalize_task_prompt()为每个已激活的技能调用format_skill_context()，并将所有格式化的技能内容追加到任务提示词。

LLM接收到的内容为：[系统消息] + [任务提示词 + 所有技能正文]

Token影响

CrewAI对每个技能在50,000字符时发出软警告，但没有硬性限制。文档建议保持技能的聚焦和简洁，因为大量的提示注入会分散模型的注意力——鉴于上下文衰减的研究，这是一个真实的问题。

权衡很直接：智能体始终拥有完整的专业知识（高可靠性），但token成本随每个任务的技能数量线性增长（低效率）。对于拥有1-2个聚焦技能的智能体，这种方式效果很好。对于需要广泛能力集的智能体，成本会迅速上升。

无跨任务持久化

每个任务获得全新的注入。技能内容不会在任务之间累积——这实际上是一个特性而非缺陷。它意味着每个任务从干净的上下文开始，避免了基于会话的持久化可能产生的陈旧性问题。

LangChain Deep Agents：通过SkillsMiddleware实现智能体控制的加载

LangChain Deep Agents实现了一个基于中间件的精密技能系统，其中智能体本身决定何时加载完整的技能内容——这是一个真正的渐进式披露模型，由智能体控制激活。

三个层级

第一层（索引）： SkillsMiddleware在启动时解析所有SKILL.md的frontmatter，并将轻量级索引注入系统提示词。该索引仅包含名称和描述，每个技能约消耗278 token，而完整内容则需要3,302 token。

第二层（完整内容）： 当智能体确定某个技能相关时，它对技能的SKILL.md路径调用read_file()。这是一个常规的工具调用——框架不注入正文；智能体做出了有意识的加载决策。完整内容作为工具结果进入对话历史。

第三层（深入探索）： 辅助材料、参考文档和脚本仅在智能体明确读取时才被访问。

实践中的Token效率

拥有12个技能时，渐进式披露将上下文从约30,000 token（全部加载）减少到约600 token（仅索引），在为特定任务加载相关技能时扩展到2,000-5,000 token。这意味着技能相关token消耗可能减少83-98%。

可以叠加多个技能来源，当名称冲突时，最后一个来源优先。超过10 MB的文件会自动跳过。

与Claude Code的关键区别

虽然Claude Code使用专用的Skill工具来触发加载，但Deep Agents复用了智能体现有的read_file工具。这意味着加载机制是透明的——智能体读取技能文件的方式与读取任何其他文件相同。缺点是没有特殊的压缩行为：进入对话历史的技能内容受标准LangChain消息修剪规则约束，没有优先处理。

OpenAI Responses API和Agents SDK：平台管理的延迟加载

OpenAI通过两种不同但理念一致的机制实现技能注入：Responses API的tool_search工具类型和Agents SDK的ToolSearchTool。

Responses API: tool_search

tool_search工具类型（可在GPT-5.4+上使用）允许开发者将大型工具表面延迟到运行时。提供三种延迟策略：

• 单个函数延迟： @function_tool(defer_loading=True) — 模型看到函数名称和描述，但参数schema被延迟。节省参数级别的token。
• 命名空间延迟： tool_namespace(name=..., description=..., tools=[...]) — 将函数分组到单个命名空间下。模型只看到命名空间名称和描述，节省更多token。
• MCP服务器延迟： HostedMCPTool(tool_config={..., "defer_loading": True}) — 延迟整个MCP服务器工具表面。

当模型确定需要特定工具时，它发出tool_search调用。API返回3-5个相关的工具定义，注入到上下文窗口末尾以保留提示缓存。

Agents SDK: ToolSearchTool

Agents SDK提供了编程等效方案。工具命名空间被注册但不加载：

crm_tools = tool_namespace(
    name="crm",
    description="CRM management tools",
    tools=[...]
)
agent = Agent(tools=[*crm_tools, ToolSearchTool()])

在运行时，智能体只看到命名空间名称。它调用ToolSearchTool("crm")来发现和加载完整的schema，然后可以调用该命名空间内的各个工具。

无跨请求持久化

每个API请求都是独立的。发现的工具不会在调用之间持久化。这是我们对比中最无状态的方法——干净、可预测，但如果工具发生变化，则需要在每个请求上重新发现。

AutoGen Teachability：每轮语义检索

AutoGen的Teachability能力采取了与本次对比中其他所有框架根本不同的方法。它不是注入静态技能内容，而是在每一轮对话中从ChromaDB向量数据库动态检索相关"备忘录”。

每轮检索循环

Teachability在process_last_received_message上注册一个钩子，在智能体处理之前拦截每条传入的用户消息：

1. TextAnalyzerAgent从传入消息中提取关键概念
2. 这些概念用于查询ChromaDB（默认使用Sentence Transformer嵌入）
3. 检索前K个最相关的备忘录（通过max_num_retrievals配置，默认10个）
4. 检索到的备忘录在智能体看到之前追加到消息文本中

关键是，修改后的消息不会传播到存储的对话历史中——只有原始消息被存储。这防止了备忘录内容在各轮之间累积。

学习循环

在LLM响应后，第二个钩子分析响应中的新知识：

1. TextAnalyzerAgent识别响应中的新知识
2. 新备忘录作为键值对提取（输入文本 → 输出文本）
3. 这些备忘录存储在ChromaDB中，可用于未来的对话轮次和会话

这创建了一个真正的学习循环，智能体随时间积累专业知识。

跨会话持久化

AutoGen Teachability是我们对比中仅有的三个跨会话持久化技能的平台之一（另外两个是Voyager和DSPy）。ChromaDB数据库存储在磁盘上，这意味着智能体可以从周一的交互中学习，并在周五应用该知识。

recall_threshold参数（默认1.5）控制消息必须与存储的备忘录有多相似才能被检索，reset_db可以在需要时清除整个记忆。

Token效率

由于每轮对话仅注入相关备忘录（通常3-5个），无论备忘录数据库增长到多大，token成本都自然受限。拥有10,000个存储备忘录的智能体仍然只需为与当前轮次最相关的少数备忘录付费。

Semantic Kernel：作为常驻工具定义的插件Schema

微软的Semantic Kernel采取了直接的方法：插件是注册到Kernel的KernelFunction对象集合，它们的schema作为函数调用工具定义暴露给LLM。

两种注入路径

函数调用： 当设置ToolCallBehavior.AutoInvokeKernelFunctions时，所有已注册的函数在每次API请求中作为可用工具发送给LLM。LLM决定调用哪个；Semantic Kernel处理调用和结果路由。

提示模板： Semantic Kernel的模板语法（{{plugin.function}}、Handlebars或Liquid）允许在提示渲染期间内联调用函数。结果在到达LLM之前直接嵌入提示文本中——这是一种急切求值形式，而非延迟工具调用。

无渐进式披露

每个已注册插件的schema包含在每次API调用中。没有内置的延迟加载、命名空间分组或按需激活。文档明确建议仅导入特定场景所需的插件，以减少token消耗和误调用。

这使Semantic Kernel成为最可预测的平台之一——你始终确切知道智能体可以访问什么——但限制了可扩展性。拥有50个注册函数的智能体在每次调用时都要支付完整的schema成本。

持久化

插件注册基于每个Kernel实例，存储在内存中。没有内置的跨会话技能持久化机制。

MetaGPT：基于角色SOP中的Action模板

MetaGPT将技能编码为嵌入在标准操作流程（SOP）中的action模板，而非独立的包，这些SOP管控角色行为。

Role和Action架构

MetaGPT中的每个Role都有一个注入到提示词中的人设前缀和一组Action类。每个Action包含一个通过aask()调用的LLM代理，使用自然语言提示模板来构建LLM调用。

当Role._act()触发时，它支持三种react模式：

• "react"： LLM在思考-行动循环中动态选择action
• "by_order"： Action按预定顺序依次执行
• "plan_and_act"： 智能体先规划，然后按计划执行action

窄注入窗口

任何给定时刻只有当前Action的提示模板处于活跃状态。智能体看不到其他action的模板——它只看到其角色前缀加上特定action的上下文。这是我们研究的所有框架中最窄的注入窗口。

Action类中的上下文解析函数从输入中提取相关信息，因此每个action接收到的是可用上下文的精选子集，而非完整的对话历史。

单轮持久化

模板在每次action执行时重新渲染。没有累积或跨会话持久化。这保持了每个action的聚焦性，但意味着智能体无法在单个工作流中基于先前加载的技能内容进行构建。

Voyager：基于嵌入的技能检索实现终身学习

Voyager是来自NVIDIA和加州理工学院的Minecraft探索智能体，它实现了最优雅的技能注入架构之一：一个通过嵌入相似度检索、不断增长的已验证程序库。

技能库

当Voyager编写的代码通过自验证（生成的Mineflayer JavaScript确实在游戏中运行）时，代码及其文档字符串被存储在向量数据库中。文档字符串的嵌入成为检索键。

每任务检索

在自动课程系统提出的每个新任务上：

1. 任务描述和环境反馈被嵌入
2. 对所有存储的技能嵌入进行余弦相似度搜索
3. 检索前5个最相关的技能
4. 检索到的技能代码作为少样本示例包含在action智能体的提示词中

提示词看起来像这样：

You are a Minecraft bot. Here are some relevant skills you've learned:

// Skill: mineWoodLog
async function mineWoodLog(bot) { ... }

// Skill: craftPlanks
async function craftPlanks(bot) { ... }

Now write code to: build a wooden pickaxe

生成的代码可以按名称调用检索到的技能，实现组合式技能构建——从更简单的、已验证的原语构建复杂行为。

终身持久化

技能库是核心的"终身学习"机制。它在智能体的整个生命周期中不断增长，新技能基于旧技能构建。与大多数框架中技能由人类编写不同，Voyager的技能由智能体自身生成、验证和存储。

Token成本自然受限：无论库中包含50个还是5,000个技能，每个任务只需为5个最相关的检索付费。

DSPy：编译后的少样本示例作为冻结技能

DSPy采取了与其他所有框架截然不同的方法。DSPy不在运行时注入技能，而是离线编译最优的少样本示例，并将其永久嵌入模块提示词中。

编译过程

两个主要优化器负责编译：

BootstrapFewShot： 使用教师模块生成程序的执行轨迹。通过用户定义指标的轨迹被保留为示例。程序中的每个dspy.Predict模块获得自己精选的示例集。

MIPROv2（多提示指令提案优化器v2）： 三阶段过程：

1. 引导： 生成候选示例集
2. 提案： 生成感知数据分布和示例的候选指令文本
3. 搜索： 对所有模块的指令 × 示例联合空间进行贝叶斯优化

max_bootstrapped_demos（生成的示例）和max_labeled_demos（来自训练数据）等参数控制每个模块提示词中最终包含多少示例。

编译后固定

一旦编译完成，示例存储在每个Predict模块的demos属性中，并在每次LLM调用时格式化到提示词中。它们在运行时不会改变——“技能"是冻结的。

这意味着DSPy的技能在我们的对比中是最可预测的：编译后token成本已知，各轮之间没有差异，智能体始终看到相同的示例。缺点是不灵活——要改变技能，必须重新编译。

持久化

编译后的程序序列化为JSON，包括所有示例。它们具有完全的持久性，可跨会话加载，使DSPy成为最持久的技能存储机制之一。

SuperAGI：基于工具包的预先注册

SuperAGI使用传统的工具包模式，在智能体初始化时注册所有工具。

每个工具包扩展BaseToolkit，包含：

• name和description属性
• get_tools()方法，返回BaseTool实例列表
• get_env_keys()用于必需的环境变量

工具包通过SuperAGI的工具管理器从GitHub仓库安装。在智能体初始化时，BaseToolkit.get_tools()返回所有工具，其完整schema作为函数调用定义暴露给LLM。

没有延迟加载、没有渐进式披露、没有每轮过滤。每个注册工具的schema在每次调用中都存在。这是最简单的注入模型，适用于具有聚焦、小型工具集的智能体，但无法扩展到需要数十种能力的智能体。

CAMEL-AI：ChatAgent工具注册

CAMEL-AI遵循类似的预先注册模式。来自各种工具包（如MathToolkit、SearchToolkit）的工具在初始化时作为列表传递给ChatAgent(tools=[...])。

该框架强调自定义函数需要清晰的参数名称和全面的文档字符串，以便模型理解用法——工具schema是模型看到的唯一"技能"内容。没有单独的指令注入机制。

最近新增了通过MCPToolkit实现的MCP（模型上下文协议）支持，允许ChatAgent连接到MCP服务器并注册外部工具。这扩展了可用的工具表面，但不改变注入模型——所有发现的MCP工具仍然是预先注册的。

跨平台对比

技能注入时机

持久化模型

上下文压缩存活性

渐进式披露模式

这些平台中最重要的架构趋势是采用渐进式披露——这是一个借鉴自UI设计的概念，信息根据需要逐步揭示。

渐进式披露为何重要

朴素的技能注入方法——预先加载所有内容——产生两个问题：

1. Token浪费： 大多数技能与大多数轮次无关。当每轮只需要1-2个技能时加载20个完整技能正文，浪费了90%以上的技能相关token。
2. 注意力稀释： 关于上下文衰减的研究表明，当上下文包含大量无关信息时，LLM表现更差。上下文中更多的技能实际上可能降低技能应用的质量。

渐进式披露通过维护可用技能的轻量级索引并仅在需要时加载完整内容来解决这两个问题。

实现变体

Claude Code使用专用系统：system-reminder消息中的技能元数据、用于激活的Skill工具以及用于延迟工具schema的ToolSearch。框架使用基于优先级的压缩自动管理注入。

LangChain Deep Agents使用智能体现有的文件读取能力：SkillsMiddleware注入索引，智能体通过read_file()加载完整内容。这更透明，但框架级优化较少。

OpenAI Responses API使用基于命名空间的分组和平台管理的搜索：工具命名空间提供高级描述，tool_search返回相关schema。平台完全处理搜索逻辑。

实践中的Token节省

数据令人信服。以12个技能为例：

• 常驻注入（CrewAI/SuperAGI风格）：约30,000 token
• 仅渐进式披露索引：约600 token
• 索引 + 2个已激活技能：约2,000-5,000 token

这意味着每轮技能相关token消耗减少83-98%。在包含数百轮对话的长会话中，节省效果会大幅累积。

架构模式与权衡

纵观所有11个平台，出现了四种不同的架构模式：

模式1：常驻注入

使用者： CrewAI、SuperAGI、CAMEL-AI、Semantic Kernel

工作方式： 完整技能内容或工具schema在每次LLM调用中都存在。

优点：

• 最高可靠性——智能体始终拥有完整专业知识
• 最简单的实现——无需激活逻辑
• 可预测的token成本——每轮相同

缺点：

• Token成本随技能数量线性增长
• 多技能时注意力稀释
• 无法扩展到每智能体约5-10个以上的技能

最适合： 拥有1-3个始终相关的核心技能的聚焦型智能体。

模式2：渐进式披露

使用者： Claude Code、LangChain Deep Agents、OpenAI Responses API/Agents SDK

工作方式： 轻量级元数据始终存在；完整内容按需加载。

优点：

• 可扩展到数十或数百个可用技能
• 不需要技能时token成本极低
• 完整schema追加到末尾时保留提示缓存

缺点：

• 智能体可能错过激活相关技能的信号
• 激活步骤带来额外延迟
• 框架实现更复杂

最适合： 需要访问多种能力但每个任务只使用少数几个的通用型智能体。

模式3：语义检索

使用者： AutoGen Teachability、Voyager

工作方式： 向量数据库查询根据与当前上下文的语义相似度浮现相关技能/知识。

优点：

• 无论库大小如何，token成本自然受限
• 随着库的增长，内容相关性随时间提高
• 跨会话学习和积累
• 无需显式激活——相关性自动计算

缺点：

• 检索质量取决于嵌入模型质量
• 检索过时或微妙错误信息的风险
• 需要向量数据库基础设施
• 不太可预测——不同轮次加载不同内容

最适合： 需要从经验中学习并随时间积累领域知识的智能体。

模式4：编译/静态注入

使用者： DSPy、MetaGPT

工作方式： 技能被编译为固定的提示内容（DSPy）或通过严格的action模板激活（MetaGPT）。

优点：

• 最可预测的行为——每次相同的内容
• 优化可以离线完成（DSPy的编译）
• 无技能选择的运行时开销
• 对于定义明确、可重复的任务已证明有效

缺点：

• 不灵活——改变技能需要重新编译（DSPy）或代码更改（MetaGPT）
• 无法适应编译示例之外的新情况
• DSPy的编译过程本身需要许多LLM调用

最适合： 具有定义明确任务的生产流水线，其中可靠性优先于灵活性。

对智能体构建者的实际启示

选择正确的模式

正确的技能注入架构取决于智能体的特征：

如果你的智能体角色狭窄且定义明确（例如代码审查机器人、单一产品的客服智能体），常驻注入（CrewAI/SuperAGI模式）最简单、最可靠。2-3个常驻技能的token成本是可控的，且你避免了激活逻辑的复杂性。

如果你的智能体需要广泛的能力但每次交互只使用少数几个（例如开发助手、通用自动化智能体），渐进式披露（Claude Code/Deep Agents模式）是明显的赢家。大规模时83-98%的token节省太显著了，不容忽视。

如果你的智能体需要从交互中学习和改进（例如个人助理、积累知识的领域专家），语义检索（AutoGen Teachability模式）提供了其他模式所缺乏的学习循环。只需确保对进入知识库的内容有质量控制。

如果你的智能体运行定义明确的流水线（例如数据处理、报告生成、标准化工作流），编译注入（DSPy模式）给你最可预测、最优化的行为。

混合方法

对于需要智能体开箱即用的生产智能体团队，我们推荐混合方法：

核心技能（每智能体1-2个，定义其主要领域专长）：始终注入系统提示词，CrewAI风格。这些是智能体每轮都需要的不可协商的能力。

扩展技能（智能体可能需要的额外能力）：系统提示词中仅元数据，在需要时通过搜索/加载机制加载，Deep Agents风格。这些扩展了智能体的能力集，而在不相关时不会支付token成本。

学习知识（积累的领域专长）：存储在向量数据库中，每轮按语义检索，AutoGen风格。这允许智能体随时间改进，无需手动编写技能。

这种分层架构自然映射到系统提示词的构建方式：日期 → 人设 → 系统指令 → 核心技能 → 技能索引 → 角色/团队上下文。核心技能和索引增加了可预测、可控的token成本，而完整的技能正文仅在需要时出现。

跨框架的Token预算最佳实践

无论使用哪种注入模式，以下token管理策略都普遍适用：

缓存友好的排序

将不变的上下文（系统指令、工具schema）放在提示词前面。在支持提示缓存的提供商上，缓存的token成本降低75%。Claude Code和OpenAI都将发现的工具schema注入到上下文末尾，以保留静态前缀的缓存命中。

卸载

总结工具响应而非在上下文中保留完整结果。将完整数据存储在智能体可按需读取的外部引用中。这对于每次会话进行许多工具调用的智能体尤其重要。

精简

通过摘要压缩对话历史。从长对话中提取关键事实并压缩为精炼表示。每个具有基于会话持久化的框架都受益于积极的历史管理。

检索优于预加载

在运行时动态获取相关信息，而非预先加载所有内容。这适用于技能、知识库甚至对话历史。研究表明这可以将提示词大小减少高达70%。

隔离

为特定任务使用子智能体，使每个智能体的上下文保持聚焦。与其给一个智能体20个技能，不如创建5个智能体的团队，每个有4个技能。每个智能体维护精简的上下文窗口，团队集体覆盖完整的能力集。

结论

AI智能体框架将技能注入上下文的方式是智能体设计中最具影响力的架构决策之一——然而很少在这种详细程度上被讨论。

该领域正在明显地向渐进式披露收敛，作为通用智能体的首选模式，Claude Code、LangChain Deep Agents和OpenAI都独立地达到了类似的三层架构。与此同时，语义检索（AutoGen、Voyager）和编译注入（DSPy）等专门模式服务于渐进式披露单独无法解决的重要利基。

对于当前构建智能体系统的从业者来说，关键洞察是技能注入不是一个放之四海而皆准的问题。正确的方法取决于智能体的角色、它需要的技能数量、是否需要随时间学习，以及你对token成本与可靠性权衡的容忍度。

最健壮的生产系统很可能会组合多种模式——核心能力使用常驻注入、扩展技能使用渐进式披露、积累的知识使用语义检索——创建既高效又专业的智能体。