skilder 框架：用渐进式技能发现管控 LLM 智能体的工具访问权限

随着大语言模型（LLM）智能体在企业场景中广泛接入内部工具集，如何在保障问题求解能力的同时，对工具调用实施严格的访问控制，成为一个亟待解决的问题。arXiv 上一篇新论文提出了名为 skilder 的框架，试图用「渐进式技能发现」的方式，把系统级安全边界从提示词层的概率性建议，转变为可被硬性执行的约束。

核心思路：把能力打包成「角色」

skilder 的基本单元是「角色（role）」，每个角色是一个捆绑包，内含三类资产：

• 技能（skills）：完成任务所需的工作流定义
• 工具（tools）：可被调用的具体接口
• 指令（instructions）：对技能与工具的使用说明

同时，角色还附带「限额（limits）」，用来界定该角色的调用边界。智能体启动时只拿到一个最小化的角色目录（minimal role catalog），在任务执行过程中按需学习（learn）所需角色，再通过单一 MCP（Model Context Protocol）服务器获取对应角色的技能、指令与工具。

治理机制：把边界从提示词搬到运行时

论文指出，传统做法把所有工具平铺给智能体，会带来三个问题：上下文窗口膨胀、工具选择退化、以及系统策略无法被硬性执行——因为写在 prompt 里的规则本质上只是「建议」。多智能体域委派（multi-agent domain delegation）等既有缓解方案则会把审计日志分散到不同子智能体，难以保证跨会话的策略合规。

skilder 的关键设计是：工具只在已被学习的技能内部才可达，因此同一个 MCP 服务器能够以确定性方式强制执行「已学习范围」。当智能体未学会某个角色时，即便工具接口存在，也无法触发。同时，框架支持智能体在任务中途动态获取跨角色能力（cross-role capabilities），从而保留问题求解的灵活度，而非将权限一刀切死。

评估：13 个任务、6 个模型、每组 10 次

作者将 skilder 与两种基线对比：

• 平铺上下文工具选择（flat-context tool selection）
• 多智能体编排（multi-agent orchestration）

实验覆盖 13 个任务、6 个模型，每种配置各跑 10 次。核心结果有两条：

• 当模型成功完成渐进式发现并发起受治理调用时，skilder 模拟的授权层零失误地执行了治理边界，没有出现任何未授权的工具调用或参数违规（例如突破支出上限）。
• 聚合任务通过率反映的是模型是否遵循发现协议并满足响应质量检查；这些未通过并不属于授权失败。

意义与局限

skilder 的价值在于，把企业最关心的两点——「智能体不能调用它没被授权的工具」和「权限策略必须可被强制执行」——转化为运行时层级的硬约束，而非依赖 prompt 自觉。它适合工具数量多、合规要求高的企业内部智能体场景。不过论文也坦承，整体通过率仍受模型自身对发现协议的遵循程度制约，治理层只能保证「被授权范围内不出错」，无法替代模型的能力短板。