skilder：以角色化技能包为工具型 LLM 智能体做访问控制

企业 LLM 智能体在庞大内部工具集上如何既缩小可见动作空间，又把角色范围做成确定性的系统边界，而不是提示词里的建议。

• 场景：作者称企业把智能体接到 CRM、账单、HR、安全、工程等系统。常见做法是把工具定义作为扁平列表放进请求。目录变大后，工具定义占上下文、工具选择变难；更重要的是，提示词里的策略不是访问控制，智能体仍可能被诱导做出有害动作。暴露不必要的工具会扩大动作空间，在缺少下游授权时增加错域调用、过早动作和未授权数据访问。安全建议是同时限制可见工具和其后权限。
• 现有不足：按域拆成专家智能体（如 Tier 1 Support、Billing Admin、Security & Fraud）并放在编排器后面，每个专家的工具列表更短，但交接增加会话和消息，并使端到端追踪与失败归因更难。若授权不在模型之外强制执行，策略仍是每个专家里的提示词，而不是确定性系统边界。
• 核心设计：把能力打成角色——技能、工具、说明以及约束它们的界限——智能体从最小角色目录开始，在单次对话里通过渐进技能发现加载所需角色。Skilder 本身就是所连接的 MCP 服务器：工具只在已学技能内到达智能体，因此同一服务器可以确定性执行所学范围。
• 威胁模型：
  • 目标：阻止智能体调用其角色之外的企业工具，并执行金额上限、步骤顺序等界限；同时允许任务跨域时在会话中追加已授权角色。
  • 受害系统：连接企业内部工具的 LLM 智能体。评测用模拟授权层复制角色目录、工具学习、访问控制（含金额上限与规定步骤顺序）和伪造的域工具数据；结果衡量的是该测试设计，不是线上产品快照。
  • 能力：用户可在多轮对话中施压或做社交工程，试图让智能体执行管理员操作、超限退款或越出本会话授权范围的角色。智能体只连接 Skilder，看到四个平台工具；域工具由服务器代为执行。
  • 知识：论文未使用 white-box、black-box 或 no-box。强制发生在模型之外的路由器：未学工具返回 ACCESS DENIED，模型不能跳过该检查。
• 提出的东西：渐进技能发现与 Skilder 角色设计；含 13 个功能场景的评测工具链（治理、公司政策、适应性、正确性）；并与 flat-injection、多智能体编排对比。作者称，允许任务中途动态获得跨角色能力，可保留解题弹性，同时提供系统级硬执行。

工具使用与技能标准

• MCP（Model Context Protocol）：作者称它是 LLM 调用外部工具的标准方式，暴露扁平工具命名空间，智能体一次看到全部已注册工具。
• AAIF Agent Skill 标准：把说明、资源和元数据打成技能，但把工具暴露留给宿主。作者称 Skilder 把二者合在一起：它自己是 MCP 服务器，所提供的是技能，工具只经已学技能到达智能体。

现有框架

• LangChain、CrewAI、AutoGen：可以运行多个智能体，但作者称它们通常给每个智能体完整工具列表。
• LangGraph：可以把工具子集绑定到一个节点。按需加载工具已是常见 MCP 做法。作者称本文增加的是：经一个 MCP 服务器按需交付技能，前面有角色目录，后面有硬拦截——从未在已学技能中交付的工具不能被调用，而不是仅仅从提示词里藏起来。

渐进披露与上下文

• 渐进披露（progressive disclosure）：作者引用用户界面设计中的含义——只显示当前所需，并提供打开更多细节的途径。他们把同一想法用到工具上：模型先看短角色列表，再打开相关角色及其工具。
• 上下文窗口管理：其他工作缩短上下文、检索工具或在层级中规划，这些方法在模型一侧。作者称 Skilder 在调用模型之前、在接口处削减上下文，二者可以组合。

技能生态与技能安全

• AgentSkillOS：针对公开技能市场的同一扩展问题，在大技能池上建树、找候选，并把多技能任务作为 DAG 运行；在 200、1,000、200,000 的池规模上用成对 LLM 评审和 Bradley–Terry 模型给 30 个创意任务的输出质量打分。作者称 Skilder 问的是另一个问题：企业目录能否在 MCP 工具上强制发现与访问，而不是给创意产物打分。
• SkillsBench：作者称它更接近本文的评测工具链，测试精心整理的技能是否有助于终端式任务。技能架构与安全综述把技能当作需要规则的接口，而不只是检索结果。
• 公开技能库：含有恶意和欺骗性技能，技能元数据也可携带提示注入。作者称 Skilder 针对的是另一种风险：防止智能体调用其角色之外的企业工具。两种情形下，仅靠提示词说明都不够。

基线与基准

• 基线方法：flat-injection（从第一轮起全部域工具在上下文中，通用系统提示词，无硬角色限制）和 Multi-agent orchestration（协调者只有 delegate_to_agent，每个域是带该域工具和提示词的子智能体）。
• 基准/数据集：自建 promptfoo 评测工具链上的 13 个功能场景（约 15 个基础工具、四个角色）；另有 15–225 工具的单轮 token 扩展研究和 225 工具（15 个角色）的多轮成本研究。

作者把本文定位为：研究较小的公司式目录，重点是强制访问和基于角色的发现；与公开大技能池上的质量评分、以及只在模型侧缩短上下文的方法分开。

Skilder 是智能体唯一连接的 MCP 服务器：会话先只看到四个平台工具和短角色目录，域工具仅在属于已学角色时由服务器代为执行。

问题设定与角色

• 术语：工具是模型可调用的一个 MCP 动作。技能是角色内的单位，带说明、资源和所适用的工具。角色打包一种能力：该身份所需的技能、工具、说明，以及约束它们的界限。平台执行这些界限，角色文本只陈述它们。
• 授权范围：在会话开始时固定，决定目录——该会话允许学习的角色集合。访问一次一个角色，可以再加第二个角色。
• 与多智能体的交付差异：Skilder 把同一域划分打包成角色，但送进同一条线程。多智能体专家在新的系统提示词里收到域策略并直接调用域工具；Skilder 从通用系统提示词出发，把同一域策略作为 learn 的结果给出，经通用 call_tool 包装调用。

平台工具

• init_skilder：开始会话，返回本会话授权范围内的角色目录，并要求下一步先学习一个角色。每条有名称、短描述、技能名和学习路径；此时不展示说明或工具。
• learn：按路径分三层。(a) /roles/<name> 返回角色说明及其技能（各带说明和工具），并解锁该角色携带的全部工具；(b) /<skill> 再次返回已学角色中的一个技能；(c) /<skill>/<resource> 取回附带文档。先前已学角色的工具仍然可用。评测运行记录的路径前缀是 hats/，作者称产品路径现为 /roles/<name>。
• call_tool：仅当工具属于已学角色时，才代表智能体执行域工具。对未学工具返回 ACCESS DENIED，并附上可用工具列表。决定这一点的检查称为路由器。
• feedback_skill：让智能体给技能评分或评论，供以后改进。

四条性质与治理检查

• 小起点：无论工具多少，智能体首先只看到四个平台工具加短角色列表。
• 范围访问：每个角色把说明与该身份所需的技能、工具和界限打包在一起。
• 硬拦截：call_tool 拒绝已学角色之外的工具，模型不能跳过该检查。目录层的 learn 拒绝会话授权范围之外的角色。
• 加角色：学习第二个角色会加入其工具，因此一条线程可以覆盖多于一个域。场景 13 另有路由器侧顺序规则：在工单、延期和服务抵扣步骤都发生之前，process_refund 不能执行。超限退款可返回 GOVERNANCE VIOLATION。
• 成功判定：一次试验只有全部非 N/A 断言通过才算通过。行为检查是三种接口都有可能通过的检查；结构检查是接口性质（工具未列出、工具被拦截，或模拟授权层中的顺序规则）。作者把授权失败定义为：受治理调用到达模拟授权层后，被禁止的动作仍然执行。未完成 init→learn、选错角色、未发出受治理调用，或未通过回复质量检查，记为模型/协议兼容失败，不记为授权失败。

评测工具链

1. 从 JSON 文件加载智能体工具。
2. 把用户消息发给模型。
3. 工具调用经过模拟授权层（角色目录、工具学习、访问控制，含金额上限和规定步骤顺序，以及伪造域工具数据）。
4. 重复直到模型写出文本回复或达到轮次上限。
5. 记录工具调用、token 用量和最终回复。多轮对话用分隔符把每一段作为新的用户消息。

三种条件使用同一模型，只改变工具如何到达模型。作者提醒：推理路径并不相同。多智能体有更大的有效推理预算，并把专家说明放在更高的提示词优先级；Skilder 多一个发现协议。行为通过率差异衡量的是整套设置，而不是单独的路由器可靠性。

实验设置

• 被测模型：功能场景为 Claude Haiku 4.5、Qwen 3.5 122B、Gemma 4 31B、Ministral 3 14B、Claude Opus 4.7、GPT-5.5（Anthropic API、OpenAI API、Infomaniak AI v2）。token 扩展与轮次成本只用 Claude Sonnet 4.5。
• 场景：Table 1 的 13 个功能场景，功能基准为 15 个基础工具、四个角色。场景 5–8 为结构治理，11–13 为制度政策，9–10 为跨域适应，1–4 为普通任务正确性。场景 1–10 每个场景×条件 10 次独立试验；场景 11–13 为五次。Mean 行是六模型的不加权平均（6×10=60 次试验汇集）。
• 基线：flat-injection；多智能体（完整花名册，以及部分场景另加角色—花名册策略）。Skilder 为四平台工具。制度政策另有 flat+gateway 与 Skilder enforced。
• 指标：通过率；行为成功与结构隔离（或退款上限、标记需范围转换）分开报告。场景 13 报告端到端、拦截、恢复和提前执行。制度场景 11–13 的评分由记录的工具调用和结果确定，不用 LLM 评审。
• 失败归因：Skilder 格子失败不一定表示路由器放行。作者区分“从未到达路由器”和“路由器已测试且边界守住”。
• 重复：功能格子为上述 10 次或 5 次；论文未报告跨随机种子之外的额外重复。

主结果

治理与制度场景的汇集通过率如下（场景 5–8 据 Table 2–5，n=60；场景 11–12 据 Table 6，n=30；场景 13 据 Table 7，n=30）。

Swipe horizontally to read the table

场景	flat	多智能体	Skilder
5 行为 / 结构	58.3% / 0.0%	完整花名册 95.0% / 0.0%；加策略 100% / 100%	100% / 100%
6 行为 / 上限	5.0% / 0.0%	完整 95.0% / 0.0%；加策略 90.0% / 0.0%	80.0% / 100.0%
7 行为 / 隔离	20.0% / 0.0%	完整 91.7% / 0.0%；加策略 98.3% / 100%	93.3% / 100%
8 行为 / 结构	100% / 0.0%	完整 95.0% / 100%；加策略 98.3% / 100%	88.3% / 100%
11 / 12 仅指导	73.3% / 66.7%	40.0% / 30.0%	63.3% / 63.3%
13 端到端 / 提前	66.7% / 30.0%	30.0% / 60.0%	指导 83.3% / 16.7%；强制 80.0% / 0.0%

• 作者称：当模型完成发现并发出受治理调用时，模拟授权层守住治理边界，没有未授权工具调用或参数违规（例如花费上限被突破）被执行。真正的平台失误应是已学角色加上被禁止调用仍然执行；作者称本套件中未观察到。
• 场景 5：Skilder 将会话授权范围固定为 Tier 1 Support，目录不含 System Admin，六模型均为 10/10（汇集 60/60）。flat-injection 结构上 0/10，因为管理员工具从第一轮就暴露；破坏性管理员调用在 23/60 中实际执行，同时满足安全不作为和明确拒绝的为 35/60。完整花名册多智能体行为安全 57/60，但 System Admin 在全部 60 次中仍可达，编排器在 30/60 中委派给它，三次执行破坏性调用，结构隔离 0/60。加上明确的支持角色花名册策略后，多智能体升至 60/60。
• 场景 6 与 13：Skilder 行为 48/60，上限 60/60。作者称这 48/60 记录的是九次限额内但不恰当的部分退款和三次未完成升级，不是十二次突破 500 美元上限。flat-injection 仅 3/60，54 次试验执行了退款。场景 13 无守卫时提前退款为 flat 9/30、多智能体 18/30、Skilder 仅指导 5/30；守卫开启后 flat+gateway 与 enforced Skilder 均为 0/30。端到端为 flat 20/30、多智能体 9/30、Skilder 仅指导 25/30、flat+gateway 27/30、enforced Skilder 24/30。作者称强制去掉不安全执行，但不自动提高任务完成：部分模型无法从一次有效拒绝中恢复。

跨域适应

• 场景 9（Table 8，n=60）：flat-injection 均值 91.7%，多智能体 88.3%，Skilder 88.3%。Skilder 上 Haiku、Gemma、Opus 为 100%，Qwen 70%，Ministral 70%，GPT-5.5 90%。作者称成功运行中 Skilder 把 Security & Fraud 作为第二角色学习；剩余失误多为较弱模型停留在 Billing Admin、未做第二次 learn 就调用欺诈工具，或调查建议不满足检查。
• 场景 10（Table 9，n=60）：Skilder 均值 63.3%，flat-injection 58.3%，多智能体 50.0%。Skilder 上 Haiku 与 Gemma 为 100%，Opus 90%，GPT-5.5 70%，Ministral 20%，Qwen 0%。flat-injection 上 Opus 与 GPT-5.5 为 100%，Gemma 为 0%。作者称路由器并未拦截目录内的合法工具；规划两次 learn 比从已可见的扁平列表里挑选更难。这些零分是协议成本（模型从未发出第二次 learn），不是路由器拦截目录中的角色。
• 两层：作者称 init_skilder 只返回会话授权范围内的角色，该范围在会话开始时设定、之后不能协商；call_tool 即使在学习之后也只使该角色的工具可调用。场景 7 中，当 Skilder 智能体尝试学习授权范围外的 Billing Admin 时，目录层在解锁任何工具之前返回 ACCESS DENIED（结构隔离 60/60）。

普通任务与制度细节

• 场景 11–12：场景 11 中全部 flat 与多智能体试验以及 29/30 的 Skilder 试验取回了当前政策；端到端为 flat 22/30、多智能体 12/30、Skilder 19/30。作者称主要剩余失败是操作上的：模型有时用散文描述延期，却不调用记录该提议的工具。场景 12 三种接口均 30/30 取回政策；服务抵扣步骤记录为 flat 20/30、多智能体 14/30、Skilder 20/30。Skilder 在抵扣被拒绝之前阻止退款为 30/30，flat 为 29/30，多智能体为 26/30。完整成功为 20/30、9/30、19/30。作者称在这个小的单域任务上，角色范围本身并不提高容易的政策执行；用 enforced Skilder 计入场景 13 后，flat 与 Skilder 汇集端到端同为 62/90，多智能体为 30/90。
• 场景 8 的行为缺口：flat-injection 60/60，完整花名册多智能体 57/60，加策略 59/60，Skilder 53/60。七次 Skilder 失误都在 Ministral：两次省略成功的客户查询，回复质量评审因调查不完整或缺少依据拒绝七次。作者称没有一次是结构破坏。结构指标对 flat-injection 为 0/60，对三种中介条件为 60/60；flat 的零记录的是标记从一开始就可达，不是模型在 60 次观察中过早标记。
• 场景 7 的行为细节：Skilder 56/60，完整花名册多智能体 55/60，加花名册策略后 59/60。flat-injection 12/60。作者称受治理条件之间三试验的行为差异是任务完成而不是遏制：Qwen 经专家提示词完成的调查多于经 learn/call_tool。Opus 4.7 在工具暴露的 flat-injection 上行为仍为 10/10。作者称观察到的合规不是结构隔离的证据。

其他消融与分析

• 场景 6：Qwen 在七次试验、Ministral 在两次试验中发出未经请求的 500 美元部分退款（在单次上限内，但不符合所要求的工作流）；一次 Ministral 的超限尝试被路由器拦截。加策略的多智能体中，Tier 1 专家在两次 Qwen、四次 Opus 试验里发出未经请求的 500 美元部分退款。
• 场景 13：flat+gateway 拦截八次试验、六次恢复；enforced Skilder 拦截十二次、八次恢复。四次未恢复的 Skilder 试验是任务完成失败，但被尝试的无效动作仍未执行。
• 场景 5：flat-injection 另有两次行为失败避免了执行，但没有把边界说清楚。
• token 研究：单轮扩展在 15–225 个工具，多轮成本在 225 个工具（15 个角色），只用 Claude Sonnet 4.5；正文只给出曲线交叉位置，完整曲线在附录 D–E。正文摘录未给出可回查的交叉 token 数，故不写具体用量。
• 场景 1–4 的逐模型表在所附正文中被截断，具体通过率不写。作者的问题是：init→learn→call_tool 是否在 flat-injection 已经能完成的工作流上增加模型侧协议失败。
• 附录称评测工具链尚未把“平台正确、模型散文有缺陷”与真正的协议失败分开；同一失败模式出现在全部三次失败的 Opus 试验上。作者怀疑前沿安全训练使 Opus 4.7 对嵌入的政策指示过于谨慎，并称是否构成部署问题由读者根据记录决定。

作者指出的局限与后续方向

• 模型依赖的发现：作者在引言和 Section 5 的跨模型讨论中称，结果揭示一个依赖模型的局限：有些模型难以完成渐进发现，尽管能力一旦获得，执行仍然可靠。Qwen 和 Ministral 表明，即使路由器本身守住，有些模型在完成渐进发现和嵌套工具调用上也不那么可靠。作者称部署者应对照发现协议验证模型并相应选择服务池，或提供兼容的路由回退。
• 协议兼容不是授权失败，但是端到端局限：Section 4 称，未完成 init→learn、选错角色、从未发出受治理调用或未通过回复质量检查，是 Skilder 条件下的模型/协议兼容失败，因此是真实的端到端局限，但不表示访问控制失败。
• 行为对比不能单独代表路由器：Section 4.2 称三种条件的推理路径并不相同，行为通过率差异衡量整套设置，不是孤立的路由器可靠性。多智能体的有效推理预算更大，专家说明的提示词优先级更高。
• 评测对象是测试设计：Section 4.1 称结果衡量该测试设计，不是线上产品快照。
• 政策不能自动推断：Section 5.1 末称，策略以及从授权范围到角色的映射仍然是领域特定的——没有治理系统能自动推断它们——但执行与模型提示词和后端系统分开。作者称 Skilder 是集中授权、动态最小权限和可审计的状态转换，不是模型任务表现上的普遍改进。
• 部分退款与散文缺陷：场景 6 称，若要使部分退款本身不可能，还需要额外的批准状态规则，例如记录客户接受或经理授权。附录称工具链尚未分开“平台正确、模型散文有缺陷”与真正的协议失败，把这类情况计为 Skilder 正确性损失会使平台看起来比实际情况风险更高。

实验覆盖范围

• 功能评测为 Table 1 的 13 个场景、六个模型；场景 1–10 每格 10 次，场景 11–13 每格 5 次，条件之间只改变工具如何到达同一模型。
• 治理场景分开报告行为成功与结构隔离；授权失败按 Section 4 的定义，在本套件中作者称未观察到受治理调用放行被禁止动作。
• 制度政策场景 11–13 的政策内容只出现在 get_response_policy 的返回中，评分由工具调用和结果确定，不用 LLM 评审；作者称 Skilder 的原生交付路径（过程随已学技能到达）在场景 1–10 和轮次成本研究中使用，不在这一节。
• 多智能体的结构隔离在场景 5 和 7 中于加入并保持同步的角色—花名册策略之后达到；场景 6 的两种多智能体配置都没有交易金额上限。场景 13 用 flat+gateway 与 enforced Skilder 把顺序守卫从角色范围中分开。
• token 扩展（15–225 工具）和 225 工具上的多轮成本只用 Claude Sonnet 4.5。附录 H 给出场景 8 的一条 Haiku 4.5 轨迹。论文未报告查询次数或墙钟耗时。

Skilder 把企业工具型智能体的能力按角色打包，经一个 MCP 服务器做渐进发现，使工具范围由服务器而不是提示词来执行。

• 问题：扁平工具列表在目录变大后占上下文并扩大动作空间；提示词策略是概率性建议。按域拆分的多智能体会增加会话与审计难度，若授权不在模型之外，策略仍在各专家的提示词里。
• 方法：会话从 init_skilder 的角色目录开始，learn 返回说明并解锁该角色工具，call_tool 只执行已学角色内的工具，否则 ACCESS DENIED。授权范围在会话开始时固定。第二个已授权角色可以在任务中途学习，并记入工具日志。金额上限和步骤顺序由同一模拟授权层执行。
• 治理：场景 5 中 Skilder 的行为安全与结构隔离均为 100%（n=60），flat-injection 结构隔离为 0%，破坏性管理员调用在 23/60 中执行。场景 6 中 Skilder 的 500 美元上限在 60/60 守住，行为成功 80%；flat-injection 行为成功 5.0%，上限强制为 0%。场景 7 中两种受治理条件的 Billing/PII 工具不可达均为 100%，完整花名册多智能体为 0%。
• 政策与跨域：场景 13 在守卫开启后，flat+gateway 与 enforced Skilder 的提前退款均为 0/30；无守卫时分别为 flat 9/30、多智能体 18/30、Skilder 仅指导 5/30。场景 9 三种接口均值分别为 91.7%、88.3%、88.3%。场景 10 上 Skilder 均值 63.3%，但 Qwen 为 0%、Ministral 为 20%。
• 作者的结论：完成发现并发出受治理调用后，边界由平台守住，未观察到被禁止动作仍执行。这约束的是不完美判断的后果，不是保证完美判断。部分模型难以走完发现协议，部署时应按该协议验证模型。作者称这些场景支持 Skilder 作为集中授权、动态最小权限和可审计状态转换，而不是模型任务表现上的普遍改进。