AI Agent 的技能不是工具权限：为什么"会怎么做"和"允许做什么"必须分开？
完整研究版：中文版 · English version
如果给一个 AI Agent（人工智能智能体）一份"应用发布手册"，它学会了构建、测试和部署；环境里又刚好有终端和文件写入工具------它是否就拥有直接发布的权限？
很多系统不知不觉给出了肯定答案。问题在于，它们把四件不同的事混在了一起：模型知道方法、环境存在工具、角色可以调用工具、这一次具体操作已经获准。
可以把它想成一次办公室发布：Skill（技能）是操作手册；Tool（工具）是真正能改文件、调用接口的机器；角色能力是机房门禁卡；操作策略是写明目标和影响的工作单；人工批准则是只盖在本次工作单上的印章。
会看手册、会操作机器、持有门禁卡和获准执行这一次，是四件不同的事。
四道门，分别回答四个问题
| 层次 | 回答的问题 | 绝不能顺带推出什么 |
|---|---|---|
| Skill / 行为手册 | 这件事应该怎样做？ | 因此允许执行 |
| 角色能力 | 这个角色能调用哪些工具？ | 所有目标都可以操作 |
| 操作策略 | 本次动作影响哪个对象、产生什么副作用？ | 人已经批准 |
| 单次批准 | 当前这个完整动作是否放行？ | 以后或修改后的动作也放行 |
**Tool 不是权限，也不天然安全。**它只是产生真实副作用的接口。门禁配置错误时，一个确定性的工具同样可能拥有过大的能力。
为什么不能靠提示词守权限
Skill 通常存在于大模型上下文中，适合拆解意图、选择流程和组装参数，但它仍是概率文本，会受到指令冲突和提示词注入影响。
授权必须放在模型上下文之外。无论使用 MCP（模型上下文协议）工具、本地 Runtime（运行系统）还是普通 API（应用程序接口），中立门禁至少应核对：
text
调用者身份
AND 角色与工具能力
AND 规范化项目根目录
AND 目标白名单
AND 操作策略
AND 完全匹配的单次批准
AND 操作系统或沙箱权限模型可以提出动作，但不能由提出动作的模型自己裁决"我有权执行"。
批准必须绑定环境状态
只比对命令参数还不够。审批人可能针对 Git 提交 abc123 批准了一个补丁；真正执行前，另一个进程已经修改分支。命令没有变化，实际影响的状态却变了。
因此操作指纹还应绑定项目根、Git Commit（提交标识）、目标文件哈希、过期时间和 Nonce（单次随机标识）。执行副作用前重新计算；状态不匹配、凭证过期或 Nonce 重放，都必须拒绝。
网络重试不等于重新授权。同一个操作标识可以返回已经保存的结果；只要目标、参数或环境指纹变化，就必须重新审批。
静态解析挡不住所有绕过，沙箱仍是底线
命令解析和路径白名单无法提前证明所有副作用。Shell 展开、符号链接、环境变量、子进程和第三方工具行为都可能越过朴素检查。
所以门禁下面仍需硬控制：
- 高风险工具运行在受限进程或容器中；
- 进程只获得必要的文件和网络权限；
- 规范化真实路径并拒绝越出项目根；
- 记录命令、退出码、标准输出/错误位置和工件哈希；
- 身份、状态或批准证据缺失时采用 Fail-closed（失败时默认拒绝）。
35 项测试验证了什么
公开 CodeFlowMu Runtime 的受测链路把 Skill 上下文路由、角色/工具能力、操作授权、批准持久化和单次消费分开。在本文锁定的实现版本上，22 项门禁测试与 13 项批准持久化/消费测试全部通过，共 35/35。
这支持的是受测路径，不等于渗透测试、第三方安全认证，也不能证明每个下游工具都能完美解析目标。测试边界必须与绿色数字同时说明。
可以直接用于审计的八个问题
- Skill 只能提出结构化请求，还是可以直接产生副作用？
- 角色能力是否由确定性代码执行？
- 请求中是否绑定规范化项目根目录？
- 操作策略是否检查真实目标和副作用？
- 批准是否绑定参数与相关环境状态？
- 批准是否会过期并防止重放？
- 底层进程是否缺少不必要的文件和网络权限？
- 审查者能否还原谁提出、谁批准、谁执行、谁验证？
最终原则可以压缩成一句话：让 Skill 负责解释与提案，让确定性软件负责授权与执行。
完整事实矩阵、源码链接与实现边界见中文版原文，也可阅读英文版。
更多双语 Agent 工程研究：JoinWell52 Research Center