以技能作为工具访问入口：更好地扩展智能体上下文

NanthAI:Edge 技术案例研究。

大多数 AI 智能体扩展能力的方式有问题：每增加一项能力，就增加更多提示词文本、工具模式定义，以及模型做出错误选择的机会。在 NanthAI:Edge 中，这不只是理论。当前可见技能目录的元数据约占 5.1k 个 token，而完整可见技能正文约占 67k 个。基础注册表呈现 4 个工具，完全展开的注册表则有 115 个。这不能证明任务成功率更高，但足以证明上下文的呈现范围大幅缩小。

摘要

使用工具的大语言模型（LLM）智能体，在能力广度与上下文精简之间面临结构性矛盾。每条额外注入模型上下文的工作流指令、每个额外工具模式定义，都会消耗 token，增加延迟和费用，并可能降低工具选择的可靠性。本文阐述以技能为入口逐步开放工具访问的设计模式：通过一个精简、缓存稳定的技能目录，协调指令的按需加载和可执行工具注册表的逐步扩展。

这里将技能视为模块化、可发现的指令包，包含元数据、完整行为指导，以及声明的工具配置组要求。系统不会在每次请求中注入所有技能和工具，而是先呈现轻量技能元数据；任务与技能匹配时，模型调用 load_skill；随后，已加载的技能注入详细指令，并启用相关工具配置组。

本文结合提示词膨胀、函数调用可扩展性、基于检索的工具选择、提示词缓存、渐进式披露和模块化智能体架构等文献讨论这一模式，再利用系统作者提供的实现细节，对 NanthAI:Edge 进行具体案例分析。NanthAI:Edge 通过账户等级、技能和可执行工具三层组织能力。本文解释该架构的预期收益、主要风险和实现取舍。

以技能控制访问的工具注册表工作流概览

1. 引言

现代 LLM 智能体系统通常会在每次请求中组合三类上下文：系统指令、工具模式定义和对话状态。随着智能体能力积累，各层都倾向于增长。新工作流增加提示词指令，新集成增加工具模式定义，新的用户偏好和记忆增加上下文。系统因此能力更强，却也越来越重。

这带来两个相关问题：

1. 提示词膨胀：系统提示词不断累积大量行为指令、策略、工作流指导、示例、记忆和上下文规则。
2. 工具注册表膨胀：大量可执行工具被呈现给模型，无论它们是否与当前任务相关。

两者代价都很高。它们消耗输入 token、提高延迟、增加提供商费用，并让提示词缓存更复杂。更关键的是，它们可能降低决策质量。要求模型从数十甚至数百个工具中选择时，模型必须比较更多候选项、关注更多描述，并处理更多语义重叠。

近期关于检索增强工具选择的工作支持这种担忧。Gan 和 Sun 的 RAG-MCP 研究报告，在一个 MCPBench WebSearch 设置下，检索相关工具模式定义而非传入全部定义，将选择准确率从 13.62% 提升到 43.13%，同时使提示词 token 数约减少一半。这些数字仅针对特定基准测试，不应盲目推广，但它们说明了核心压力：将所有工具平铺呈现，往往不是好的信息架构。

本文探讨一种结构化替代方案：以技能为入口逐步开放工具访问。

模式很简单：

1. 呈现精简的可用技能目录。
2. 让模型通过 load_skill 加载相关技能。
3. 仅在启用后注入完整技能指令。
4. 仅通过已加载技能所需的配置组扩展当前工具注册表。

这一设计将用户体验中的渐进式披露，以及软件架构中的信息隐藏，应用于 LLM 上下文窗口的成本管理。细节并非对人类用户隐藏，而是在任务确有需要之前不向模型呈现。

我们通过 NanthAI:Edge 分析这一模式。这个商业智能体运行环境实现了分层账户能力、技能发现、技能加载和受配置组控制的工具扩展。本文涉及 NanthAI 的具体细节，均为系统作者提供的案例实现细节。

本文的贡献包括：

1. 将技能作为指令与工具渐进式访问入口的概念框架。
2. 对 NanthAI:Edge 三层架构的案例分析。
3. 对缓存稳定性、路由意图和基于配置组的注册表扩展的讨论。
4. 一份着重说明技能误选和漏加载的风险清单。

2. 背景：提示词膨胀、工具模式定义与智能体工具使用

2.1 函数调用与工具呈现

函数调用 API 要求通过名称、自然语言描述和结构化参数模式向模型介绍工具。模型决定是否调用工具、调用哪个工具，以及提供什么参数。Berkeley Function Calling Leaderboard 等基准测试会在单轮、多轮、并行和需要判断相关性的场景中评估这项能力。

工具使用并非单一能力，可以分解为：

• 工具选择：选择正确函数。
• 参数构造：生成有效且语义正确的参数。
• 调用排序：按正确顺序调用工具。
• 结果解读：正确使用工具输出。
• 任务完成：满足用户的实际意图。

系统可能选对工具，却在参数上出错；可能调用看似合理的工具，却没完成任务；也可能成功一次，却在多轮执行过程中退化。因此，仅对最终答案评分不足以评估智能体系统。

2.2 提示词膨胀

提示词膨胀常被视为费用问题，但更深层的问题是注意力聚焦。长提示词可能包含相关信息、无关信息、过时指令、重复策略和大量工具定义。更大的上下文窗口能容纳这些信息，但装得下不等于能可靠使用。

“Lost in the Middle”等长上下文研究表明，模型利用信息的可靠性可能受其在上下文中位置的影响。其他长上下文和工具调用研究也提示，上下文长度、工具数量和多轮累积之间的相互作用可能很脆弱。具体阈值因模型和任务而异，因此本文不声称“模型在 N 个工具后就会失败”。更有依据的说法是：不必要的指令和无关模式定义会扩大模型面对的决策范围，并可能恶化路由条件。

2.3 工具注册表膨胀

工具注册表膨胀是提示词膨胀在工具方面的体现。庞大的平铺注册表迫使所有可用工具在每项任务中争夺注意力。当工具语义重叠时，问题尤其明显，例如多个搜索工具、文档工具、日历工具、工作区工具，或针对不同集成的多个变体。

基于检索的工具选择直接针对这一问题。RAG-MCP 会在构造提示词前检索相关模式定义，而非呈现所有工具。Tool Attention 和动态模式加载方法也主张缩小当前候选集合。这些方法不能证明技能访问控制有效，但支持一个更普遍的观点：模型不应总是看到所有可执行能力。

2.4 工具描述质量

减少工具呈现还不够。仍然可见的工具和技能必须描述清楚。ToolACE 报告了经验证的高质量函数调用数据带来的提升，说明模式定义和描述质量会影响工具使用准确率。API 文档研究同样提示，参数说明不清和接口复杂会增加错误。

这形成了核心设计矛盾：

• 详细指令和模式定义有助于执行。
• 全局呈现所有详细指令和模式定义会造成膨胀。

渐进式技能访问控制通过分离发现元数据与执行细节来处理这一矛盾。

2.5 提示词缓存

重复使用稳定前缀时，提示词缓存可降低延迟和费用。但缓存依赖稳定的提示词结构。如果工具列表或系统指令被不可预测地重写，缓存复用可能退化。

这形成第二个设计矛盾：

• 动态加载减少无关上下文。
• 动态插入可能破坏缓存稳定性。

因此，可行的技能访问控制架构必须管理已加载指令出现的位置和方式。后文所述 NanthAI:Edge 的做法是保持基础提示词和目录稳定，再在可预测的位置追加规范化的已加载技能区块。

3. 作为模块化指令包的技能

技能是具名、可发现的能力包。它不只是工具，也不只是提示词片段，而是位于用户意图与可执行函数之间。

技能通常包含：

• slug
• name
• summary
• runtimeMode
• 完整工作流指令
• 所需工具 ID
• 所需工具配置组
• 所需集成
• 所需账户能力
• 策略约束
• 版本元数据

工具是可执行操作。技能是工作流层面的能力，可能使用零个、一个或多个工具。

例如，文档生成工具可以创建 .docx 文件；“研究论文写作”技能则可以定义来源处理规则、引用规范、结构、综合分析要求和文档生成预期，并启用文档、搜索和分析工具。

渐进式技能访问控制跨三个披露层级运作：

这种结构让技能成为上下文管理的基本单元。它们同时也是：

• 能力的单元；
• 指令适用范围的单元；
• 工具注册表扩展的单元；
• 治理和可观测性的单元。

4. NanthAI:Edge 案例研究

本节概述系统作者提供的案例实现细节。应将其视为架构文档，而非经独立审计的证据。

4.1 三层能力模型

NanthAI:Edge 通过三层组织能力：

1. 账户能力与等级
2. 技能
3. 可执行工具

账户层决定用户获准访问什么。免费用户获得普通聊天，不提供模型可调用的工具注册表。使用支持工具的模型时，Pro 用户会获得小型基础注册表。

技能层包含模块化指令包，带有元数据和启用规则。

可执行工具层包含实际的工具模式定义与实现，但默认不呈现大型工具族。它们通过技能声明的配置组解锁。

4.2 基础注册表

基础注册表包含轻量通用工具，例如：

• load_skill
• list_skills
• search_chats
• fetch_image

关键工具是 load_skill。它让路由成为模型的一项显式操作。模型不需要预先获得每条指令，只需足够的元数据来判断何时需要更深入的指令。

4.3 技能元数据

NanthAI 技能包含结构化元数据：

• slug
• name
• summary
• runtimeMode
• requiredToolIds
• requiredToolProfiles
• requiredIntegrationIds
• requiredCapabilities

这些元数据既支持面向模型的发现，也支持运行时策略执行。例如，用户尚未连接 Slack 时，可以隐藏需要 Slack 的技能；需要 Pro 能力的技能可不向免费用户展示。

4.4 可用技能目录

系统会将判定为可用的技能渲染为系统提示词中的 <available_skills> XML 区块。目录包含精简元数据，不包含完整指令。

简化示例：

<available_skills>
<skill slug="analytics_report">
<name>Analytics Report</name>
<summary>Use when the user needs data analysis, charts, or structured analytical output.</summary>
</skill>
<skill slug="document_drafting">
<name>Document Drafting</name>
<summary>Use when the user needs a structured document, proposal, memo, or generated file.</summary>
</skill>
</available_skills>

目录是路由界面。它告诉模型有哪些能力，而不强迫模型完整处理每个工作流。

4.5 技能状态

NanthAI 在四个范围内解析技能：

• 账户设置；
• Persona；
• 对话；
• 单轮覆盖设置。

每项技能可以设为三种状态之一：

• always：每轮注入完整指令；
• available：列入目录，可按需加载；
• never：完全排除。

这支持细粒度策略。通用规则可以始终启用，专门工作流可以设为可用，不允许或无关的能力可以隐藏。

4.6 load_skill

模型判断任务与某技能匹配时，会以技能 slug 调用 load_skill。运行环境返回完整指令和路由元数据。

NanthAI 不依赖原始工具结果记录，而是将已加载指令规范化为专用的已加载技能系统消息。这让当前指令状态明确，也避免累积嘈杂的工具调用历史。

4.7 渐进式工具配置组

技能声明 requiredToolProfiles。加载技能可以启用一个或多个工具配置组。作者提供的配置组包括：

• docs
• analytics
• workspace
• persistentRuntime
• subagents
• google
• microsoft
• notion
• appleCalendar
• cloze CRM
• slack
• scheduledJobs
• skillsManagement
• personas

示例：

• docs 解锁文档与文件生成／编辑工具。
• analytics 解锁 Python 和数据工具。
• workspace 解锁工作区文件与执行工具。
• 集成配置组仅在连接后解锁相应应用的工具。
• subagents 仅在获准时解锁子智能体创建功能。

因此，注册表根据已启用技能扩展，而非根据平台总能力扩展。

4.8 运行时防护指令

NanthAI 包含运行时防护指令，要求模型不要虚构不可用工具：不得访问本地文件系统、Shell、浏览器自动化、未配置的 MCP 服务器，也不得绕过显式 NanthAI 工具直接发起网络请求。

这一提示词层面的防护本身不是安全边界。真正的安全边界必须由运行时授权和工具允许列表执行。但这项防护能强化模型对当前可用能力范围的理解。

5. 架构分析

5.1 Token 成本模型

在单体式设计下，每轮提示词成本近似为：

base_prompt + all_skill_instructions + all_tool_schemas + conversation_state

在渐进式技能访问控制下，成本近似为：

base_prompt + skill_catalog_metadata + loaded_skill_instructions + active_profile_tool_schemas + conversation_state

关键区别在于，哪些内容随平台总能力增长。在单体式设计中，大量指令和模式定义的成本随全部可用能力增长。在渐进式设计中，这类高成本随已启用能力增长。目录仍会增长，但只以精简元数据的形式增长。

这就是该架构在成本方面的核心。

5.2 作为缓存稳定路由界面的目录

available_skills 区块旨在跨轮次保持稳定，除非用户能力、Persona、对话设置或单轮覆盖设置发生变化。稳定性很重要，因为提示词缓存依赖可复用前缀。精简、稳定的目录可以保持缓存友好，而完整技能正文仍延迟加载。

5.3 已加载技能区块

将已加载技能指令规范化为专用系统消息，有两个好处：

1. 首先，它让指令状态保持清晰。模型将已加载技能指导视为当前系统上下文，而非历史工具结果。
2. 其次，它有助于保持提示词缓存结构。如果将已加载技能追加在稳定的基础提示词和目录之后，新启用的技能只会扩展上下文，不会重写稳定前缀。

这是 NanthAI 设计中最重要的架构认识之一：动态能力扩展与提示词缓存并非天然兼容，因此消息结构必须明确协调两者。

5.4 基于配置组的注册表扩展

工具配置组在技能和工具之间建立了间接层，优于让每项技能直接拥有一长串独立工具模式定义。

配置组间接层有几项优点：

• 多项技能可以共享一个配置组；
• 可将配置组作为能力包测试；
• 每个配置组只需检查一次集成可用性；
• 相关工具可以一起呈现；
• 可在配置组层面应用策略；
• 当前注册表仍然可解释。

例如，许多技能都可能需要生成文档。它们可以启用 docs 配置组，而无需在各技能中重复文档工具列表。

5.5 路由意图

在平铺注册表中，意图是隐含的。模型调用工具后，工程师必须推断原因。在以技能控制访问的系统中，路由意图变得明确：

用户任务 → 已加载技能 → 已启用配置组 → 所选工具

这提升了可观测性。可以按层分解失败：

• 正确技能是否可见？
• 是否已加载？
• 是否启用了正确配置组？
• 是否选择了正确工具？
• 参数是否正确？
• 最终回答是否完成任务？

相较单体式提示词，这在评估上具有明显优势。

6. 核心反对意见：元数据路由可能失败

对渐进式技能访问控制最有力的质疑是：隐藏完整指令可能损害路由。

模型可能无法仅凭元数据区分相似技能。如果目录摘要太短、模糊或相互重叠，模型可能：

• 加载错误技能；
• 未加载任何技能；
• 加载过多技能；
• 启用错误工具配置组；
• 生成看似合理但说明不足的回答。

这不是无关紧要的边缘情况，而是核心取舍。渐进式访问控制是以全局膨胀这个问题，换来路由召回率和精确率这个新问题。

该架构在以下条件下最有效：

• 技能目录规模适中；
• 技能摘要有区分度；
• 技能之间没有大量重叠；
• 允许用澄清兜底；
• 路由决策有记录并接受评估；
• 语义检索可辅助目录匹配。

以下条件下最薄弱：

• 有数千项相似技能；
• 摘要过于泛化；
• 任务需要细微区分；
• 模型被引导避免提出澄清问题；
• 漏掉技能后，系统悄然生成质量较差却看似合理的输出。

因此，稳健实现应将模型判断与确定性检查、检索、版本管理和评估结合。

7. 风险与失败模式

R1：技能选择错误

模型加载了相近但不合适的技能，可能注入错误指令并启用无关工具。

缓解措施：有区分度的摘要、示例、“不应使用的情况”说明、离线路由测试、置信度阈值。

R2：技能漏加载

模型在没有加载技能的情况下继续。危险在于输出可能看起来可接受，却违反工作流要求。

缓解措施：加强加载指导、漏加载检测器、事后分类器、澄清行为。

R3：指令过时

技能更新后，先前加载的指令可能继续保留。

缓解措施：技能版本 ID、缓存失效、重新加载规则、兼容性测试。

R4：隐含耦合

技能和配置组可能逐渐不一致。技能可能假定配置组提供某些实际上不可用的工具。

缓解措施：requiredToolProfiles、requiredToolIds、配置组测试、依赖检查。

R5：额外延迟

load_skill 在工作开始前增加一轮工具调用。

缓解措施：将高频工作流设为 always、推测性预加载，或使用混合式基础注册表。

R6：缓存失效

动态内容插入过早，可能破坏缓存复用。

缓解措施：严格保持前缀稳定、仅追加的已加载技能区块、缓存测试。

R7：提示词注入

用户编写的技能可能包含不安全的指令。

缓解措施：技能审查、策略检查、沙盒隔离、权限范围、运行时强制执行。

R8：过度依赖模型判断

面对歧义时，模型可能不善于路由。

缓解措施：检索辅助路由、确定性策略检查、用户澄清、遥测。

8. 讨论

渐进式技能访问控制将工具注册重新视为能力架构。智能体运行环境从平铺的工具列表变为分层结构：

账户策略 → 技能目录 → 技能加载 → 配置组启用 → 工具执行

这带来几项影响：

1. 技能成为主要治理单元。等级访问权限、集成状态、工具配置组和运行模式，都可以通过技能元数据表达。
2. 路由变得可检查。load_skill 事件可以记录、测量和评估。
3. 技能市场更易管理。用户编写的技能可以声明要求，并在限定能力范围内获准接入。
4. 混合设计可能最好。小型通用工具应留在基础注册表中；专业、高风险、高成本或长尾工具应受访问控制。always 技能应较少，专业工作流默认应为 available，never 应屏蔽不允许的能力。
5. 技能目录质量成为产品的一部分。目录摘要不是内部标签，而是面向模型的路由接口，需要与 API 文档同样严谨。

这正是我们在 NanthAI:Edge 中推进的方向：能力应可被发现，却不必永久注入；强大工具应仅在当前工作流确有需要时出现。

9. 静态架构测量

完整行为验证需要一套基准测试，但有些主张可以直接从当前 NanthAI:Edge 实现中评估。具体来说，代码库允许测量技能目录和渐进式工具注册表呈现的上下文范围。

这些测量量化了论证中节省上下文的一面：相较预先注入所有技能正文和工具模式定义，呈现精简技能元数据与小型基础注册表能减少多少提示词和工具模式内容。

9.1 技能目录压缩

当前 NanthAI:Edge 系统目录包含 55 项可见技能，以及 11 项隐藏或不可见技能。可见技能作为轻量元数据渲染到面向模型的 available_skills 目录中，包括技能名称、摘要和要求提示。在技能被显式加载之前，不提供完整指令正文。

针对当前可见目录的测量如下：

这意味着默认技能发现内容的规模，约为完整可见技能指令集的十三分之一。模型仍然知道这些能力存在，但除非任务确实需要，否则不必承担完整指令成本。

这支持了架构关于节省上下文的第一项主张：技能发现可以保持广泛，而指令启用保持选择性。

9.2 工具注册表压缩

工具注册表的效果更明显。当前渐进式注册表的基础工具集只呈现四个通用工具：

• load_skill
• list_skills
• search_chats
• fetch_image

展开所有工具配置组后，注册表包含 115 个工具。模式定义的 token 数差异很大：

这支持第二项节省上下文的主张：模型默认的可执行操作空间，远小于平台总能力范围。

单体式设计会在每个支持工具的轮次中向模型呈现完整注册表；渐进式扩展则只呈现基础工具，直到已加载技能启用一个或多个配置组。

9.3 已启用配置组的成本示例

不同工作流启用不同工具配置组，因此节省幅度取决于任务。范围较窄的分析工作流，比文档生成工作流呈现的工具少得多，而两者都远少于完全展开的注册表。

这些示例说明了配置组间接层为何重要。数据分析任务不需要日历、Slack、文档编辑、定时任务或 Persona 管理工具。Slack 任务不需要 Python 执行或文档生成工具。文档任务可能需要相对庞大的 docs 配置组，但除非明确需要，仍能避开大多数集成和运行时工具。

因此，系统将工具模式成本从“用户可用的一切”，转为“当前已启用工作流确有理由使用的一切”。

9.4 解读

这些测量验证的是架构的上下文缩减前提，而非完整的行为效果承诺。

它们表明，NanthAI:Edge 的渐进式设计显著减少了：

• 默认呈现的技能指令；
• 默认呈现的工具模式定义；
• 模型面对的操作空间规模；
• 为缓存而必须保持稳定的提示词材料；
• 特定任务启用前的无关工具候选项。

但这些测量不能证明模型路由更好、工具选择更准确或任务完成更成功。这些主张需要行为评估。

静态测量回答了一个问题：

在这个实现中，渐进式技能访问控制是否确实减少了上下文和模式定义的呈现？

答案是肯定的。当前实现的缩减幅度很大：相较完整呈现，技能指令约减少 92.5%，基础工具注册表约减少 97.7%。

10. 结论

AI 智能体系统面临日益增长的信息架构问题。随着工具、集成、工作流和策略积累，单体式提示词与工具注册表设计的成本越来越高，也越来越难评估。大上下文窗口提升了容量，却无法解决相关性、路由、缓存稳定性或治理问题。

以技能为入口逐步开放工具访问，提供了一种有原则的替代方案。精简技能目录支持发现，load_skill 提供显式启用，已加载技能指令提供任务专用指导，工具配置组提供有边界的注册表扩展，运行时授权和防护则保持能力边界。

NanthAI:Edge 案例展示了如何通过账户等级、分层技能状态、可用技能目录、规范化的已加载技能消息、由配置组控制的注册表，以及运行时防护来实现这一模式。这种架构有前景，因为它让上下文成本对应已启用的能力，而不是平台的全部能力。

尚未解决的核心问题需要实证回答：元数据优先的技能选择所引入的路由成本，是否超过了减少提示词与注册表膨胀的收益？答案取决于目录规模、技能重叠程度、模型系列、任务分布和实现质量。

智能体平台应逐步呈现能力，让路由可观测，并仅在任务确有需要时启用工具。

参考文献

• Gan, T., & Sun, Q. (2025). RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation. arXiv. https://arxiv.org/abs/2505.03275

• Liu et al. (2025). Lost in the Middle: How Language Models Use Long Contexts. https://arxiv.org/abs/2307.03172

• Gim, I., Chen, G., Lee, S.-s., Sarda, N., Khandelwal, A., & Zhong, L. (2024). Prompt Cache: Modular Attention Reuse for Low-Latency Inference. Proceedings of MLSys 2024. https://proceedings.mlsys.org/paper_files/paper/2024/file/a66caa1703fe34705a4368c3014c1966-Paper-Conference.pdf

• Liu, W., et al. (2024). ToolACE: Winning the Points of LLM Function Calling. arXiv. https://arxiv.org/html/2409.00920v2

• Yang, S., et al. (2023). Improving Planning with LLMs: A Modular Approach. arXiv. https://arxiv.org/html/2310.00194v4

• Wang, et al. (2025). Evaluating Position Bias in Large Language Model Recommendations. arXiv. https://arxiv.org/html/2508.02020v1

• Berkeley Function Calling Leaderboard. https://gorilla.cs.berkeley.edu/leaderboard.html

• Nielsen, J. (2006). Progressive Disclosure. Nielsen Norman Group. https://www.nngroup.com/articles/progressive-disclosure/

• Fowler, M. Function calling using LLMs. https://martinfowler.com/articles/function-call-LLM.html

• AWS. AI agents in enterprises: Best practices with Amazon Bedrock AgentCore. https://aws.amazon.com/blogs/machine-learning/ai-agents-in-enterprises-best-practices-with-amazon-bedrock-agentcore/

• NanthAI:Edge 架构说明。系统作者提供的案例材料；未经独立验证。

亦发表于 LinkedIn.