技术 · 熟练
工具接得越多，越没人说得清谁在调谁
统一入口只是第一步，治理才是第二步
现在的开发环境里，同时开着十来个带 agent 能力的工具已经不算稀奇。每接一个，就多一条权限边界、一个版本依赖、一份审计义务 —— 而大多数人的盘点方式还停在「我装过哪些 AI 项目」。这一页给的是缺掉的那一层：一张技能 / 工具的注册表，它必须能回答三个问题 —— 谁能调什么（角色与权限来源）· 现在跑的是哪一版（能把版本钉住、能回滚）· 谁在什么时候调过什么、返回了什么（审计）。配套一条更反直觉的盘点判据：清单应当从「已经在用的平台」起算，而不是从「已批准的 AI 项目」起算 —— 因为相当一部分 agent 能力是通过一次例行产品更新悄悄进来的，从来没有经过一次「上新评审」。
方法 · 一图看懂
1
先改盘点起点 — 从「已在用的平台」列出内嵌 AI 能力，而不是从「已批准的 AI 项目」列
2
给每一次调用一个身份 — 哪个 agent 在代表谁行动；默认给身份、默认零权限
3
把版本钉住 — 记录每个技能 / 工具被哪个工作流依赖的是哪一版，允许钉版与回滚
4
留一份可查的调用日志 — 谁 · 何时 · 用什么参数 · 调了什么 · 返回了什么
5
把有后果的动作单独列出 — 需要显式批准的那几类，别和只读调用混在同一条审批里
原理 · 为什么有效
治理层缺位时，坏掉的方式几乎总是同一种：出事之后，没人能还原「是谁、代表谁、在什么权限下、调了哪一版、做了什么」。而这三个问题不能靠回忆回答 —— 它们分别对应注册表里的三件东西：身份与权限（谁是主体、被授权做什么）、版本（同名的技能在不同时间可能不是同一份逻辑，接口变了、语义变了，工作流却仍是按旧版设计的）、日志（没有审计痕迹，多步链路调试基本靠猜）。为什么起点要改成「已在用的平台」：按「已批准的项目」盘点，会系统性漏掉随产品更新进来的那一批 —— 它们在身份系统里默认不可见，却同样能读到你的上下文、能发起动作。而处置方向也值得记住：在出现越界行为之后，加固的正确位置通常是执行边界（隔离容器 · 最小权限 · 有后果的动作显式批准 · 完整日志），而不是指望在模型层多加一句约束。
适用场景
适用：同时在使用多个带 agent 能力的工具 / 平台、已经出现过「改了配置但不知道影响谁」或「出问题说不清调用链」的团队或个人。
⛔ 不适用：只用一个工具、且所有动作都发生在你眼皮底下的人 —— 这一层对你还没有成本可言。
⚠️ 前提：愿意先把「已在用的平台」列出来（这一步通常比想象的长）。
自测 · 5 问
我的清单是从「已批准的 AI 项目」列的，还是从「已在用的平台」列的？后者能列出几条前者没有的？
随便挑一次最近的调用，我能说出是哪个 agent 在代表谁行动吗？
我的某个工作流依赖的技能，我能说出它当时是哪一版吗？如果那一版被更新了，我怎么知道？
同一次调用的参数与返回，我能在日志里查到吗？还是只能靠回忆？
哪些调用是「有后果」的（改外部状态 / 花钱 / 对外发布）？它们是不是和只读调用混在同一条审批里？
怎么上手 · 验证步骤
别一上来铺全量。只挑一条你已经跑顺的多步链路（三到五个环节那种），把它上面用到的每一个技能 / 工具列成一行，逐行补齐三格：谁能调 · 当前版本 · 最近一次调用记录。在补齐的过程中，你几乎一定会遇到至少一格写不出来 —— 那一格就是这条链路上真正的裸露面。先把那一格补上（哪怕只是加一条钉版记录 + 一行日志），再往其它链路铺。
自检动作：拿一条链路，写下三行 —— 「调它的主体是＿＿」「它现在的版本是＿＿」「最近一次调用可以在＿＿查到」。三行里有一行填不下去，说明这一层还没建成，别急着接下一个工具。