MCP的价值不只是“让模型接上工具”
当 Agent 需要搜索资料、读取数据库、调用企业应用或操作第三方服务时，工具连接会成为系统基础设施。MCP 等协议让工具描述、输入输出和调用方式更标准，开发者不用为每个模型重新写一套连接逻辑。这会降低接入门槛，也会让更多人快速做出 Agent。
但连接变容易之后，治理的重要性反而更高。一个被模型发现的工具，是否真的应该对当前用户可见？工具返回的数据是否包含不该访问的字段？模型传入的参数是否经过服务器校验？一个发送邮件或修改记录的动作，是否应该自动执行？协议可以帮助系统互通，却不会自动替你完成身份、权限、审批和审计。
先搭工具网关
可靠的企业架构，最好不要让模型直接连接所有业务系统，而是在中间放一个工具网关。网关负责身份认证、权限判断、参数校验、速率限制、日志、错误处理和版本管理。模型只看到被允许使用的工具，业务系统也只接受经过网关检查的请求。
工具要足够窄。不要定义一个执行任意 SQL 或管理所有客户的超级工具，而要按业务动作拆分，例如查询订单、创建内部待办、生成邮件草稿、获取项目指标。范围越清晰，权限越容易审查，错误影响越小。读工具和写工具要分离，写工具带上审批、幂等和回滚信息。
身份要贯穿每次调用
企业 Agent 不能只知道这是一个模型请求，还要知道请求来自哪个用户、组织、项目和会话。工具网关要把用户身份绑定到调用上下文，不要让模型自己传一个 userId 就当成可信身份。
销售员工可以查看自己负责的客户，内容编辑可以创建草稿但不能改服务器配置，管理员可以审核发布但仍需要留下操作记录。权限判断应该在服务器端完成，并尽量复用企业已有角色。多租户 SaaS 还要让检索、缓存、日志和异步任务带上租户隔离标识。
参数校验不能省
模型输出看起来结构化，不代表参数正确。日期可能写错，金额可能多一个零，客户名称可能相似，SQL 条件可能缺少限制。工具接口必须像普通后端 API 一样做类型、范围、格式和业务规则校验。
有副作用的工具还要做重复执行保护。创建订单、发送邮件和发布文章都应该有幂等键或状态检查，防止 Agent 重试时产生两份结果。超时后不能假设动作没有执行，系统需要查询状态或标记待确认。错误消息也要清晰，让 Agent 能安全停止或请求人工。
让用户真正理解授权
企业授权不能只是一行允许访问。用户需要知道工具读取什么数据、执行什么动作、影响哪些对象、权限有效多久，以及如何撤销。敏感工具可以采用一次性授权、按任务授权或按字段授权，避免长期开放。
审批界面应该展示动作摘要和关键参数，例如“将12条符合条件的线索分配给华东销售组”，而不是“Agent请求执行操作”。用户要能查看使用的来源、修改范围、风险提示和回滚方式。如果工具无法提供这些信息，就不适合直接交给 Agent。
工具要有版本和契约
协议能让工具被不同宿主发现，但工具仍会变化。参数可能新增，字段可能改名，权限可能收紧，返回结构也可能变化。企业应该为工具 schema 设置版本，保留兼容期，并使用契约测试确保 Agent 能正确处理。
工具描述也要写清适用范围和禁止事项。不要只写搜索客户，要说明数据来源、可查询字段、返回上限和权限规则；不要只写更新记录，要说明哪些字段可改、哪些状态不能回退、什么条件下必须人工审批。清晰的描述既帮助模型，也帮助开发者和审计人员。
观测工具调用，不只观测回答
Agent 最终回答可能很短，但背后调用了多个工具。系统应该保存任务 ID、用户身份、工具版本、参数摘要、返回状态、耗时、错误、审批记录和最终结果。敏感字段可以脱敏，但不能完全失去调试能力。
监控指标包括工具成功率、平均调用次数、重复调用、权限拒绝、超时、人工接管、异常峰值和每项工具成本。发现某个 Agent 突然频繁访问一个系统，或某个工具错误率上升，平台应该能够告警并临时禁用，而不是等用户投诉。
给工具设置防护等级
可以把工具分成四级：公开只读、内部只读、低风险写入和高风险写入。不同等级采用不同的模型权限和操作流程。第一阶段只接公开及内部只读工具；第二阶段加入生成草稿和内部待办；第三阶段开放低风险写入；最后再评估更高风险动作。
每增加一个工具，就新增正常样本、权限样本、异常样本和拒绝样本。工具越多，模型选择空间和失败路径越复杂，评测也越困难。不要因为连接标准统一，就忽略业务边界。
小团队的实现顺序
先列出业务系统和常用动作，挑一个频繁、可衡量的流程。为它定义只读工具，接入测试数据和日志；确认用户、角色和权限后，再增加结构化输出；建立审批页面，最后才增加写入动作，并用幂等、回滚和告警保护。
对后台产品也可以采用同样结构：采集是只读候选，改写是草稿，上传图片是素材管理，SEO检查是发布前校验，最终发布是受控写入。这样后台不是一排孤零零的按钮，而是一条可以理解、编辑、撤回和复盘的工作流。
总结
MCP 及类似标准会让模型连接工具更方便，但企业级 Agent 还需要身份、权限、参数校验、审批、日志、版本、成本和回滚。协议负责互通，治理负责可用。
对小白来说，理解 Agent 不必从复杂框架开始，可以先理解一次工具调用的完整生命周期：谁发起、模型提出什么、系统检查什么、工具做什么、谁批准、结果如何记录。对创业者和 FDE 来说，把这条链路做得清楚、稳定、可解释，就是把 AI 从 Demo 变成产品的关键。