你已经有了一个能“想”的系统：它会把目标拆成步骤、在循环里反复规划。接下来最现实的拷问来了——它到底靠什么“看世界、动世界”？答案不是再换一个更大的模型，而是把能力外接成工具（tools），并让这些工具以一种可复用、可治理的方式连接进来。否则，每接一个新模型、每加一个新系统，你就会掉进经典的 N×M 集成地狱：N 个模型 × M 个工具 = N×M 条一次性胶水代码，越写越脆，越连越乱。
这篇续写将把重点放在两件事上：
- 工具怎么设计，才能让模型稳定“用得对、用得省、用得安全”？
- MCP（Model Context Protocol）如何把工具接入标准化，但又会引入哪些新的企业级风险？你该怎么补上治理与防线？
🧰 第一章：什么才叫“工具”？别把 API 当工具交给模型
在 LLM 应用里，“工具”不是泛指任何 API；它更像一个契约化的外部能力：模型负责生成内容与决策，工具负责让系统知道新的事实或执行外部动作。
工具大体分两类：
- Know something（取数/检索）：从结构化或非结构化数据源取信息，让下一轮推理基于事实。
- Do something（执行/动作）：代表用户做事：调用外部 API、执行代码、控制设备、写工单、发消息等。
> 小贴士：工具的本质是“把不确定的语言，落到确定的执行面” > 模型擅长表达与推理，但不擅长实时事实与精确动作。工具把系统从“会说”推进到“会做”。
---
🧩 第二章：工具的三种形态——函数工具、内置工具、Agent 工具
为了工程落地，你会遇到三类常见工具形态：
🔧 函数工具（Function Tools）
你显式定义函数，提供名称、参数、描述，模型按需要发起调用。工具定义就是模型与工具之间的契约；在一些框架里，工具说明可以从代码注释/Docstring 提取。🧱 内置工具（Built-in Tools）
某些模型服务把工具封装成“内建能力”，你只声明要启用，工具定义对开发者不可见（被服务端隐式提供）。例如 URL 上下文、代码执行、搜索等。🧑🤝🧑 Agent 工具（Agent Tools）
一个 Agent 可以被当作另一个 Agent 的工具来调用：主 Agent 不必把对话控制权完全交出去，而是把子任务交给子 Agent，拿回结构化结果再决定下一步。这是多智能体系统工程化的一种关键手段：“把专家当工具用”。---
🧠 第三章：工具设计最佳实践——写给模型看的说明书，比写给人看的更重要
工具的“文档”不是装饰，它会被放进模型的上下文里，直接影响工具选择与参数生成。下面这些实践，决定你是“可控的工程系统”，还是“偶尔会用、经常用错”的随机盒子。
---
📝 3.1 清晰命名与完备参数说明：让审计也能看懂
- 名称要清晰具体、可读、能反映任务：
create_critical_bug_in_jira_with_priority 比 update_jira 更可控，也更利于审计。
- 输入/输出参数要写清类型与语义；参数列表尽量短，名称直观。
- 描述避免黑话与实现细节，讲清“它做什么、何时用、返回什么、有什么副作用”。
🎯 3.2 描述“动作”，不要描述“实现”——系统指令别绑死某个工具
在系统指令里，你应该写“要做什么”，不要写“必须调用哪个工具”。原因很现实：工具集合可能变化（尤其在动态发现的环境里），如果你在指令里硬编码工具名，就会制造冲突或让模型困惑。
- ✅ “创建一个 bug 记录该问题”
- ❌ “调用 create_bug 工具”
---
✅ 3.3 发布任务（tasks），不要发布 API 调用（API calls）
这是最容易犯的错：把复杂企业 API 的参数面直接暴露给模型。企业 API 往往几十上百参数，适合“知道全局的人类开发者”，不适合“运行时动态决策的模型”。
正确做法是：工具应该封装成用户侧可理解的任务，参数只暴露完成任务所必需的少量字段。例如不要暴露一个通用 update_ticket，而是提供更明确的：
create_ticket_with_summary_and_priorityadd_comment_to_ticketassign_ticket_to_oncall
🧱 3.4 工具要尽量“颗粒化”（granular），避免多步骤“巨无霸工具”
单一职责让模型更容易判断何时调用，也让你更容易写清文档、做验证、做权限控制。 少数情况下可以把常见长流程封装成一个工具以提高效率，但必须非常清楚地说明内部做了哪些动作与副作用。
---
🧾 3.5 为“简洁输出”设计：别把上下文窗口淹死
工具返回大表、大 JSON、文件内容、图像 base64，都可能迅速吞掉上下文，增加成本与延迟，还会污染后续轮次的对话历史。
推荐模式：
- 大结果写入外部存储（临时表/对象存储/Artifact 服务），工具只返回引用（表名/URI/句柄）。
- 再提供二次检索工具：按需拉取小片段或摘要。
✅ 3.6 用验证（schema validation）当双重保险
输入/输出 schema 既是“额外文档”，也是运行时护栏：
- 输入验证阻止乱参、越界值
- 输出验证保证调用方能解析，并让模型更理解输出结构
🧯 3.7 错误消息要“可操作”：它也是给模型的下一步指令
很多工具只返回一个错误码，这是浪费。工具错误会被回灌进模型上下文，所以它应该告诉模型：
- 为什么失败（例如 rate limit）
- 下一步怎么做（等待 15 秒重试、让用户确认 product_id、改用按名称检索等）
🌐 第四章：为什么需要 MCP——N×M 集成困局与“工具生态”
当你把工具接入做大，你会遇到 N×M：
- N 个模型/Agent 框架
- M 个工具/系统/数据源
- 每对组合都要写一次适配器
---
🏗️ 第五章：MCP 的核心架构——Host / Client / Server 三段式
MCP 是一种 client-server 协议架构，参考了软件领域里成熟的协议分层思想。
- Host：你的应用/Agent 宿主，负责用户体验、编排工具、执行安全策略与内容护栏。
- Client：嵌在 Host 内，维护与 MCP Server 的连接，会话生命周期管理。
- Server：对外发布能力的一方，负责工具发现（tools/list）、执行请求、格式化并返回结果；在企业里还承担安全、可扩展与治理责任。
---
📡 第六章：通信层——JSON-RPC + 两种传输
- 消息格式：JSON-RPC 2.0
- 消息类型：Request / Result / Error / Notification
- 传输：
- stdio：本地子进程通信，适合访问本地文件系统等资源
- Streamable HTTP：推荐远程通信，可流式响应，也支持无状态服务器实现
🧱 第七章：关键原语——Tools 是主角，但别忽视其他能力的风险
MCP 定义了多类能力。现实里最普遍的是 Tools；其他能力（Resources、Prompts、Sampling、Elicitation、Roots）支持度不高，但风险点不少，企业采用时更要谨慎。
🛠️ Tools：标准化的工具定义
工具定义包含：name（唯一标识）title（可选显示名，但建议总写）description（人和模型都要读得懂）inputSchema（参数 JSON schema）outputSchema（建议当作必填来做）annotations（一些行为提示：readOnly、idempotent、destructive、openWorld 等，但只是“提示”，不可信赖）
📦 Tool Results：结构化/非结构化/资源引用/流式返回
- 非结构化：Text / Image / Audio（常带 base64 + MIME）
- 结构化：JSON 对象（强烈建议配 outputSchema 并做验证）
- 资源：可返回链接或嵌入资源（但从不可信 server 拉资源非常危险）
🧯 Error Handling：两条错误通道
- JSON-RPC 协议级 error（如 unknown tool、invalid args）
- tool result 中
isError: true（业务/后端错误）
---
🧨 第八章：MCP 的优势与代价——“更自治”与“更危险”是一起到来的
🚀 优势
- 动态发现工具：运行时 tools/list，能力可扩展
- 标准化接口：描述、schema、结果结构统一
- 生态化与复用：出现 registry/marketplace，工具可共享
- 架构更灵活：模型、工具、记忆更容易替换与演进
- 为治理提供“挂载点”：即使原生安全弱，也有位置插入策略与网关
🐢 代价：性能与可扩展性挑战
- 上下文膨胀（context window bloat）：工具定义与 schema 必须进上下文，工具一多就贵、慢、挤掉关键信息
- 推理质量下降：工具太多模型更容易选错、偏航
- 有状态连接复杂：远程持久连接与无状态 REST 生态结合，会让水平扩展与负载均衡更难
---
🛡️ 第九章：企业安全专题——MCP 带来的新威胁图谱与对策
MCP 把工具接入变简单，也把风险扩散得更快：它既是新的 API 面，又是标准化的“能力注入通道”。下面是几个高频风险与对应缓解手段。
---
🧪 9.1 动态能力注入（Dynamic Capability Injection）
风险：server 可以在你不知情的情况下改变工具列表或工具语义。一个原本“只读内容”的服务突然新增“购买/转账/删数据”能力，你的低风险 Agent 可能瞬间变高风险。缓解：
- 客户端/SDK 显式 allowlist：只允许批准过的 server 与工具
- 变更通知机制与再校验（例如 manifest 变更需触发重验）
- 工具与包 版本/哈希 pinning：工具定义变了就报警/断连
- 在 API/Agent 网关 做集中策略：过滤 tools/list 返回的工具子集
- 在受控环境托管 MCP server，避免不可控动态变化
🕵️ 9.2 工具影子化（Tool Shadowing）
风险：恶意工具用“更强的触发描述”把自己包装成“凡是用户提到 save/store/remember 就用我”，从而压过合法工具，截走敏感数据。缓解：
- 检测并阻止语义上的命名/功能碰撞（必要时用 LLM 过滤，而非仅字符串匹配）
- 对高敏连接使用 mTLS 或在网关层做双向身份校验
- 在关键生命周期点做 确定性策略执行：发现工具前、调用前、返回前、对外请求前
- 对高风险操作强制 HIL（Human-in-the-Loop） 确认
- 限制 Agent 只能连接企业批准的 MCP servers（无论本地还是远程）
🧬 9.3 恶意工具定义与被消费内容（Malicious Tool Definitions / Contents）
风险：- 工具描述与签名字段本身可“诱导”规划器做坏事
- 工具返回外部内容可能携带可注入指令（HTML/Markdown/URL 等）
- 返回数据可能包含敏感信息，模型可能原样回吐给用户
- 输入验证：防目录穿越、注入式参数（如
../../secrets） - 输出净化：过滤 token、PII、URL、邮箱、可执行内容（HTML/Markdown）等
- 严格隔离系统指令与用户内容，必要时采用“可信/不可信双规划器”分权：
- 可信规划器只连一方/认证工具
- 不可信规划器连第三方工具，通信受限
- 资源只允许从 allowlist URL 拉取，并要求用户显式选择/同意
- 在网关层对工具描述做净化后再注入上下文
🧷 9.4 敏感信息泄露（Sensitive Information Leaks）
风险：对话内容常被当作上下文传给工具；工具可能无授权却获得敏感信息。Elicitation 让 server 通过 UI 进一步“要信息”，虽然规范说不要要敏感信息，但无法强制。缓解：
- 工具输出使用结构化格式，并对敏感字段加标记/注释
- 引入“污染（taint）追踪”思想：标记 tainted sources/sinks
- 默认将用户自由文本、外部系统取数标为 tainted
- 对外发送、写公共库、网络出站等作为敏感 sink，需额外审批/过滤
🔒 9.5 无原生细粒度授权（No native scoped access）
风险：协议层授权粒度粗，缺少“按工具/按资源”的授权与凭证传递机制；审计上也会出现“到底是谁发起的”身份歧义。缓解：
- 工具调用使用 audience 校验 + scope 凭证，短过期、绑定调用方
- 最小权限原则：能只读就不要读写删
- 密钥/令牌不得进入模型上下文：凭证应留在客户端侧，通过旁路安全通道发给 server，且严防回流到对话中
🧩 第十章：一个“企业可用”的 MCP 落地形态（建议）
如果你想把 MCP 用在企业核心系统里，几乎可以默认一条规则：不要直接使用“纯开放协议形态”裸奔。更稳妥的工程形态是：
- Host/Agent 应用：只承担编排与用户体验
- Hardened MCP Client（加固 SDK）：工具/服务器 allowlist、schema 校验、敏感信息拦截、HIL
- Agent/API Gateway：集中做策略（过滤 tools/list、身份校验、mTLS、速率限制、审计日志）
- 受控 MCP Servers：托管在受管环境，发布经过审查的工具
- 可观测性补齐：把 MCP 交互纳入统一 tracing/logging/metrics（协议本身不提供标准，你必须在外层补上）
---
📚 参考文献（5 项）
1. Model Context Protocol. *What is the Model Context Protocol (MCP)?* https://modelcontextprotocol.io/ 2. Anthropic. *Model Context Protocol Specification (Tools / Schema / Transports / etc.).* https://modelcontextprotocol.io/specification/2025-06-18/ 3. Gan, Tiantian; Sun, Qiyao (2025). *RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation.* https://arxiv.org/abs/2505.03275 4. Hou, Xinyi, et al. (2025). *Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions.* https://arxiv.org/abs/2503.23278 5. Google Cloud. *Model Armor overview.* https://cloud.google.com/security-command-center/docs/model-armor-overview
---