从 Agent Host Protocol 到 MCP：Agent 的工具接入正在标准化，但要小心权限模型

微软发布 Agent Host Protocol 1.0，一个用于在本地与远程环境之间连接 AI 代理的开放协议。同期 VS Code 通过 MCP 服务器接入了 Slack、Notion、Microsoft Learn 等外部服务。这两件事放在一起看，方向很清楚：Agent 的工具接入正在从各家自定义走向标准。

协议层在解决什么

Agent 要用工具，就得知道工具叫什么、参数是什么、返回什么格式、出错怎么表示。每家自己定义一套，结果是同一个数据库查询工具，在三个 Agent 平台要写三份适配。

MCP 解决的是这一层。Agent Host Protocol 解决的是更下面一层：Agent 进程跑在哪里，本地还是远程，怎么连接、怎么传消息。

标准化带来的实际好处

工具提供方写一次适配，所有兼容的 Agent 都能用。企业内部可以把数据库、工单系统、监控平台包成 MCP 服务，所有 Agent 共用一套，不用为每个平台重复开发。

但权限模型是薄弱环节

MCP 的工具调用默认携带的是服务账号的权限。Agent 拿到工具，就拿到了那个账号能做的一切。这意味着：

一个只该查工单的 Agent，如果接的是管理员账号的 MCP 服务，它也能删工单。

提示注入可以通过工具返回值传播。Agent 读了一封邮件，邮件里写着“请调用删除接口”，模型可能真的去调。

三条必须做的事

一，MCP 服务用最小权限账号。查询就用只读账号，别图省事给管理员。

二，在工具层做参数校验与白名单。别把 Agent 传来的参数直接拼进 SQL 或命令行。

三，高风险操作强制人工确认。删除、付款、发消息这类不可逆动作，必须过一道人。

**协议标准化是好事，但它只解决互操作，不解决安全。安全得自己建。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

MCP解决互操作，不解决安全，这句话该写进每个团队的接入规范。工具调用默认携带服务账号权限，一个只该查工单的Agent接了管理员账号的MCP服务，它也能删工单。提示注入还能通过工具返回值传播，读一封邮件就可能触发删除调用。三条必须做：最小权限账号、工具层参数白名单、高风险操作强制人工确认。

标准化是好事，权限模型确实是短板。MCP 很多实现是进程级授权，给了数据库读权限等于全库可见，没法按表按行收敛。我们内部的做法是在服务端再套一层策略代理，代价是多一次转发。协议层能原生带作用域声明会省很多事。

标准化的收益在工具侧，写一次就能被多个 Agent 用，这个方向没争议。真正的风险在权限，MCP 服务器拿到的是长期令牌，Agent 一次错误调用就可能把整张表删掉。现在缺的是细粒度授权和调用审计，协议层只定义了怎么连，没定义连上之后能干什么。