工具全给，等于没给边界
让一个智能体直接面对企业几十上百个内部工具，会同时触发三个问题：上下文窗口被撑爆、选工具变得不准、治理出现大洞——因为写在提示词里的策略终究是概率性建议，不是硬约束。现有的缓解办法，比如把任务拆给不同智能体分头负责，又会让审计日志分散，难以保证跨会话的合规。近期一篇 arXiv 预印本（框架名 skilder）换了个思路：与其把工具平铺出去，不如把能力打包成「角色」。
这里的角色，是技能、工具、指令，以及约束它们的那组边界，捆在一起下发。智能体起步只持有一份很小的角色目录，遇到任务才去学习这个任务需要的角色，而每个角色里的技能、指令和工具，都通过同一个 MCP 服务送进来。关键点在于：工具只在「学到的技能」内部才到达智能体，于是同一个 MCP 服务就能确定性地守住「学到什么就能碰什么」。边界不再是模型嘴边的一句话，而是服务端的一道关卡。
边界由服务硬拦，而不是靠模型自觉
skilder 在 13 个任务、6 个模型、每个跑 10 次的环境里做了评测。结果里最值得记的一句是：当模型完成了「发现角色」这一步、并发出一个受治理的调用时，那层模拟授权会挡住越界——没有任何未授权的工具调用或参数越界（比如突破支出上限）真的执行。需要客观看待的是，整批任务的总通过率，反映的是模型有没有走完发现协议、有没有过响应质量检查；那些没过的，属于协议或质量问题，并不等于授权失效。换句话说，skilder 把「授权」和「能不能把任务做好」这两件事拆开了：前者由服务兜底，后者仍取决于模型。
它还有一处巧思：允许智能体在任务中途动态获取跨角色能力。这就在「保持解题灵活」和「提供系统级硬约束」之间找到了平衡——模型该扩权时仍能扩权，但扩的每一份权限都仍由那个 MCP 服务兜底。对比纯提示词策略，skilder 把「最小权限」从一句建议变成了服务端的确定性执行；对比多智能体分权，它又把审计点收回到一个服务而不是散落各处。
对落地团队的启发
这篇论文没有给出具体的 arXiv 编号细节，我们以其披露的评测设定为准。它给工程团队的抓手很实在：与其纠结「给智能体多少工具」，不如先定义清楚「每个角色能碰什么、碰不动什么」，再把角色当成独立可审计的单元下发。当权限的边界由服务而不是由模型的话术来保证，生产环境里那类「提示词被绕过就出事」的隐患，才有机会从源头收敛。对正在搭 MCP 服务的团队，这等于一个提醒：授权检查应当写在 server 这一侧，而不是信任客户端模型会自觉守规矩。
当然 skilder 也有它的前提：它默认那个 MCP 服务本身是可信的。一旦服务侧被攻破，整条确定性保障会随之坍塌，所以角色目录与边界仍要配合服务自身的鉴权来用。它真正改写的，是把「最小权限」从模型提示词的软建议，变成了一次调用时由服务端校验的硬事实——模型可以偷懒、可以走错发现协议，但越界的动作在到达工具之前就被拦下。
对正在写 MCP server 的团队，可以照 skilder 的思路落几条硬规矩：每个角色在 server 侧维护一份工具与参数白名单，调用进来先过白名单再放行；学习新角色时下发的是白名单而不是「建议」；跨角色扩权也走同一道校验，不在客户端留口子。最小权限的边界最终要落在 server 的代码里，而不是写在给模型的提示词里——后者再严谨也只是概率性约束，前者才是能拦住越界的事实。