工具治理与 MCP Host Playbook
三个工具以内，把函数列表直接交给模型通常能跑。工具增加到十几个以后，问题会集中出现：能力散落在各处、每次请求都暴露全量工具、模型选错工具、权限靠后端拒绝、MCP 接入后不知道 Host 该管什么。
这页给出一条更稳的工具治理路线：集中注册、按场景激活、规划和执行解耦，MCP 只作为能力来源接入，业务治理仍由 Host 掌握。
四层结构
| 层 | 负责什么 | Agently 对应能力 |
|---|---|---|
| 能力注册 | 系统有哪些 action、参数 schema、描述、副作用等级 | Actions / Action Runtime |
| 按需激活 | 本次任务让模型看见哪些能力 | Agent definition、policy、runtime options |
| 规划选择 | 模型或规则决定调用哪个能力、参数是什么 | output schema、Action Runtime、TriggerFlow chunk |
| 执行归一 | 本地函数、HTTP、MCP、沙盒都以同一执行语义返回结果 | Action Executor、ExecutionEnvironment |
这四层分开以后，接入新能力来源不会影响规划逻辑；切换规划策略也不用重写所有 executor。
四层不要互相越界
工具治理最容易失控的地方，是把“系统有哪些能力”“这次让模型看见哪些能力”“模型决定怎么调用”“能力实际怎么执行”混在一起。
| 边界 | 正确做法 | 常见后果 |
|---|---|---|
| 注册 != 激活 | 启动时登记完整能力目录；每次请求按身份、场景、风险裁剪可见能力 | 全量工具暴露给模型，越权和误选一起出现 |
| 激活 != 规划 | 激活只决定本轮候选；规划才决定调用哪个、参数是什么 | 权限策略和模型推理混在 prompt 里，难以审计 |
| 规划 != 执行 | 规划层不关心本地函数、HTTP、MCP、沙箱或浏览器细节 | 换一个工具来源就要重写 planner |
| 执行 != 业务判断 | Executor 只按规范调用能力、返回结果和日志 | 执行层偷偷决定业务路径，流程不可解释 |
这也是 Agently 推荐 Actions / Action Runtime / ExecutionEnvironment 分层的原因：Planner 可以是模型、规则或 TriggerFlow chunk；Executor 可以接本地函数、MCP、HTTP adapter 或沙箱。两边通过 action schema 和 action result 对齐，不互相绑死。
工具多了以后先建能力目录
每个可调用能力至少需要这些信息：
| 字段 | 用途 |
|---|---|
id / name | 唯一标识，供 action logs 和审计定位 |
| description | 给模型读，影响选择准确率 |
| input schema | 参数类型、必填项和业务含义 |
| side effect level | read / write / exec，决定是否要审批或更严格策略 |
| executor | 实际执行函数、MCP 调用、HTTP adapter 或沙盒任务 |
| owner / source | 便于排障和版本管理 |
描述不是给人看的 README。它要帮助模型区分“什么时候用这个能力、什么时候不用、参数怎么填”。
不要让模型每次看见所有工具
全量暴露工具会带来三个问题：
- token 成本固定增长；
- 模型在相似工具里更容易选错；
- 用户没有权限的能力先暴露再拒绝，体验和审计都变差。
更好的做法是按任务、角色、场景和风险裁剪可见能力：
user request + identity + route
-> candidate actions
-> policy filter
-> model-visible action surface
-> action logs + audit只读查询、写入业务系统、执行脚本和高风险审批不应出现在同一个无差别工具列表里。
MCP 接入时先分清三角色
MCP 不是一个“工具按钮”，而是三类角色协作：
| 角色 | 职责 |
|---|---|
| Server | 暴露工具、资源或 prompt；定义 schema；执行真实能力 |
| Client | 管连接、握手、发现和转发调用 |
| Host | 决定什么时候让模型看到哪个能力、怎么注入身份、如何脱敏和审计 |
Agently 把 MCP tool 接进 Action Runtime 后，模型会把它和本地 action 视作同一类可调用能力。但企业应用仍要自己掌握 Host 逻辑。
企业 Host 不能省的四件事
身份透传
最终用户登录的是你的应用，不是 MCP Server。Host 要把当前 end-user 的 token 或身份上下文传给 MCP Client / Server，让后端系统能做行级权限和审计。所有调用落到共享服务账号，会让“谁查了什么”失效。
可见能力裁剪
不同角色看到的工具形态应该不同。普通员工可以查自己的假期，部门经理才可能看到批量查询。不要让模型先看到全量工具，再让 Server 一次次拒绝。
结果脱敏
敏感字段应该在进入模型上下文前被脱敏、聚合或删除。哪些字段要脱、按谁的权限脱、脱成什么形态，属于业务规则，不应交给模型即兴决定。
调用审计
Server 记录“谁访问了哪份资源”。Host 还要记录“为什么把这个工具暴露给模型、模型为什么选择它、调用前后做了哪些确认和脱敏”。两边的审计位置不同，不能互相替代。
MCP 和 Skills 的关系
MCP 是能力接入层，Skills 是行为资产层。
| 问题 | MCP | Skills |
|---|---|---|
| 外部系统能力怎么标准化暴露 | 负责 | 不负责 |
| 遇到某类任务该怎么思考和执行 | 不负责 | 负责 |
| 工具参数 schema 和调用结果 | 负责 | 可以引用 |
| 多步规范、资源、脚本和输出模板 | 可作为依赖 | 负责打包 |
| 生命周期 | Server / Client / Host | 选择 / 加载 / 映射到运行时能力 |
一个 Skill 可以依赖 MCP 工具：Skill 描述处理方法，MCP 提供执行能力。两者生命周期不同，不要把 MCP Prompt 当成企业 Skills 体系的替代品。
推荐接入路径
- 先把一个本地函数做成 Action，确认 action logs 和结果读取方式。
- 把工具描述、schema、副作用等级和 owner 集中管理。
- 按场景或身份裁剪本次可见 action surface。
- 接入 MCP Server，只把它当作新的能力来源。
- 如果 MCP Server、浏览器、数据库或沙盒需要托管生命周期，进入 ExecutionEnvironment。
- 如果工具调用处在多阶段任务里，用 TriggerFlow 表达阶段、等待、回填和 stream。
- 高风险写入、批量执行、外部副作用进入审批或 fail-closed 路径。
常见误用
| 写法 | 后果 |
|---|---|
| 工具散落在各个 prompt 或 handler 里 | 无法回答系统到底有哪些能力 |
| 所有工具每次都暴露给模型 | 选错、越权、成本高 |
| 让 planner 直接知道某个能力来自 MCP 还是本地函数 | 能力来源一换，规划逻辑就要改 |
| 在 executor 里做业务路线判断 | 调用层和业务流程耦合，难以测试和回放 |
| MCP 接上就认为权限完成 | MCP 解决连接，业务治理还在 Host |
| 让 Server 端脱敏替代 Host 端脱敏 | 敏感数据可能已进入模型上下文 |
| 把 Skill 当成 MCP 或 Tool 的替代 | 行为资产层和能力接入层混淆 |
| 在 Action 里私自启动长期进程 | 生命周期、健康检查和清理没有 owner |