企业官网建设流程全解析

内蒙古建设安全监督网站,网络营销就是网站营销,深圳比较好的ui设计公司,福州网站建站公司AI之Course之MCP/Agent#xff1a;智能体工具与模型上下文协议#xff08;MCP#xff09;互操作性 —— 深入解析工具生态#xff0c;理解AI智能体如何借助外部功能与API实现“行动”#xff0c;并探索通过MCP轻松发现与使用工具的方法—— 从集成爆炸到治理可控#xff…AI之Course之MCP/Agent智能体工具与模型上下文协议MCP互操作性 —— 深入解析工具生态理解AI智能体如何借助外部功能与API实现“行动”并探索通过MCP轻松发现与使用工具的方法—— 从集成爆炸到治理可控在 Model Context ProtocolMCP之上构建安全、可审计且可演化的 Agent 平台导读本文中讨论了把大型模型LLM变成可感知/可执行/可治理的 Agent需要把“模型”与“工具”标准化互操作MCP从而解决 N×M 集成、工具发现与复用问题但协议的开放性同时带来新的安全、身份与观测挑战企业应在 MCP 之上构建 Gateway/Registry/Control-Plane 做治理与防护。 价值命题工具把“预测式 AI”转为“代理式 AI”MCP 能显著降低集成成本并促进可复用工具生态。 架构三角Model推理、Tools执行/检索、Orchestration控制/会话/治理。 工具工程实践任务化Publish tasks、小粒度、结构化 I/O、示例输出、强校验与错误建议。 协议作用MCP 提供 Host/Client/Server 与 JSON-RPC 交互规范支持运行时发现与动态能力加载。 主要风险动态能力注入Dynamic Capability Injection、Tool Shadowing、恶意工具定义/返回、敏感信息泄露、权限/审计/观测不足。 落地路径企业不应“裸用 MCP”推荐在其上加 Gateway/Registry/Pinning/Scoped Credentials taint-tracking HIL人为确认等防护层。对工程/产品的可执行落地清单优先级排序先试点、后普及内部 Registry 上先包装 3-5 个关键工具跑 discovery → call → audit 流程。建 Gateway必须实现 allowlist、schema pinning、变更通知、流量/速率控制与审计日志。Credential 策略采用短期、scope-bound tokenper-call与 audience 校验Secrets 不进上下文。Context 管理tool-retrieval → subset-load不把全部 tool defs 注入 prompt对大返回采用 artifact/ref 模式。安全防护名称相似检测、mTLS、taint-tracking、输入/输出净化、HIL 强制高风险 sink。测试与监控建立回归集、LM Judge、traceprompt、tool calls、results、errors与报警工具失败率、异常调用等。组织治理明确谁能注册工具、谁审核、谁有审批权agent registry 的审核流程与 SLA。目录智能体工具与模型上下文协议MCP互操作性 —— 深入解析工具生态理解AI智能体如何借助外部功能与API实现“行动”并探索通过MCP轻松发现与使用工具的方法—— 从集成爆炸到治理可控在 Model Context ProtocolMCP之上构建安全、可审计且可演化的 Agent 平台1、Introduction: Models, Tools and Agents核心要点经验 / 实战技巧2、Tools and tool calling2.1、What do we mean by a tool?核心要点经验/技巧2.2、Types of tools核心要点按类经验 / 技巧2.2.1、Built-in tools核心要点经验/技巧2.2.2、Agent Tools核心要点经验/技巧2.3、Best Practices工具设计最佳实践2.3.1、Documentation is important核心要点经验/技巧2.3.2、Describe actions, not implementations核心要点经验/技巧2.3.3、Publish tasks, not API calls核心要点经验/技巧2.3.4、Make tools as granular as possible核心要点经验/技巧2.3.5、Design for concise output核心要点经验/技巧2.3.6、Use validation effectively核心要点经验/技巧3、Understanding the Model Context Protocol3.1、The N x M Integration Problem and the need for Standardization核心要点经验/技巧3.2、Core Architectural Components: Hosts, Clients, and Servers核心要点经验/技巧3.3、The Communication Layer: JSON-RPC, Transports, and Message Types核心要点经验/技巧3.4、Key Primitives: Tools and others3.4.1、Tool Definition核心要点经验/技巧3.4.2、Tool Results核心要点经验/技巧3.4.3、Structured Content核心要点经验/技巧3.4.4、Error Handling核心要點经验/技巧3.5、Other Capabilities3.5.1、Resources要点/风险经验/技巧3.5.2、Prompts要点/风险经验/技巧3.5.3、Sampling要点/风险经验/技巧3.5.4、Elicitation要点/风险经验/技巧3.5.5、Roots要点/风险经验/技巧4、Model Context Protocol: For and Against总体核心要点4.1、Capabilities and Strategic Advantages4.1.1、Accelerating Development and Fostering a Reusable Ecosystem核心要点经验/技巧4.1.2、Architectural Flexibility and Future-Proofing核心要点经验/技巧4.1.3、Foundations for Governance and Control核心要点经验/技巧4.2、Critical Risks and Challenges4.2.1、Enterprise Readiness Gaps核心要点经验/技巧5、Security in MCP5.1、New threat landscape核心要点经验/技巧5.2、Risks and Mitigations5.2.1、Tool Shadowing缓解措施核心经验/技巧5.2.2、Malicious Tool Definitions and Consumed Contents缓解措施核心经验/技巧5.2.3、Sensitive information Leaks缓解措施核心经验/技巧5.2.4、No support for limiting the scope of access风险说明缓解措施核心经验/技巧6、Conclusion智能体工具与模型上下文协议MCP互操作性 —— 深入解析工具生态理解AI智能体如何借助外部功能与API实现“行动”并探索通过MCP轻松发现与使用工具的方法—— 从集成爆炸到治理可控在 Model Context ProtocolMCP之上构建安全、可审计且可演化的 Agent 平台地址​​​​​​《Agent Tools Interoperability with MCP》https://drive.google.com/file/d/1ENMUDzybOzxnycQQxNh5sE9quRd0s3Sd/view时间2025年11月10日作者Google1、Introduction: Models, Tools and Agents基金模型foundation model本质上是模式预测引擎不能主动访问实时世界或直接执行外部动作工具tools为模型提供“眼睛与双手”使 agent 能检索实时数据或执行操作从而把模型从“生成”变成“行动”的主体。概述模型本身是无状态预测器工具赋予它“看/做”的能力从而构成 agent。核心要点模型有限性工具分“know/do”Agent Model Tools Orchestration。谁读产品经理、架构师、技术领导。立刻行动列出业务场景中的“必须由工具实现”的能力清单下单、写 DB、发邮件、检索事实等。核心要点模型的局限模型只能基于请求上下文输出无法直接访问实时数据或修改外部系统。工具的双重角色一类是“让模型知道know”的检索型工具另一类是“让模型做do”的执行/行动型工具API 调用、外部执行等。Agent 的定义Agent 模型推理 工具感知/执行 编排orchestration工具在 agent 中决定了是否能达成现实世界的目标。经验 / 实战技巧先从业务目标出发不要先选模型再倒推工具先明确要解决的业务动作比如“下单”“检索合同”再定义工具接口。把复杂/高风险操作交给工具实现的确定性代码权限校验、事务控制、回退机制把“模糊决策/规划”留给 LLM。2、Tools and tool calling工具在 LLM-应用中等同于函数契约名称、参数、自然语言说明是最小要素工具分多类Function Tools、Built-in Tools、Agent Tools并需要良好设计与文档以便模型在运行时选择与正确调用。概述把工具当作带 schema 的契约name/description/inputSchema/outputSchema并设计为“任务化、小粒度、可验证”。核心要点Function / Built-in / Agent Tools 三类文档、示例、校验至关重要。谁读后端工程、API 设计者、LLM 工程师。立刻行动为一两个高频后端能力写出 task-level tool 定义含示例返回与错误建议。2.1、What do we mean by a tool?工具 LLM 无法直接做但能调用的外部函数/程序按功能粗分为“检索型让模型获得外部事实”与“执行型对系统/世界进行操作”。把“工具”定义为模型不能直接完成、必须外部执行的功能检索/执行。立刻行动把业务能力映射为“tool required / tool optional”核心要点工具定义本身是「模型与外部系统之间的契约」该契约应当在请求上下文中被传给模型以指导模型何时以及如何调用。经验/技巧在需求阶段就把“哪些能力必须通过工具实现”列清单例如实时价格、数据库写操作、文件上传等把这些能力优先以 tool 接口形式封装。Figure 1: Weather agent tool-calling example2.2、Types of tools文档将工具分为 Function Tools开发者定义的函数、Built-in Tools模型服务端隐式提供、Agent Tools把子 agent 封装为工具 三类并给出分类下的常见用途与设计考量。Built-in平台端提供便捷但不可见实现Agent Tools子 agent 作为工具。立刻行动对平台的 built-in 能力做能力/风险矩阵。。核心要点按类Function Tools开发者显式定义的函数用 function-calling、schema 描述输入输出由 Host/Client 在请求中注入给模型。Built-in Tools由模型平台如 Gemini在服务端提供工具定义对开发者“不可见”但对模型可用如搜索、代码执行、URL 上下文提取等。优点是便捷缺点是开发者对实现细节可控性低。Agent Tools把一个专责子 agent 当做工具供主 agent 调用例如用 AgentTool 或 A2A 协议常用于多 agent 协作与能力分担。经验 / 技巧Function Tools务必把 inputSchema/outputSchema写清楚并给出示例返回example return帮助模型正确解析。Built-in Tools使用时注意审视平台文档它们可能会返回 metadata、自动抓取的上下文等并设计对这些返回的后续处理流程。Agent Tools在使用子 agent 时保持主 agent 的“控制权”把子 agent 的输出作为材料而不是自动信任的断言并对子 agent 做能力/权限约束。2.2.1、Built-in tools示例Google Gemini 的内置工具包括 Google Search Grounding、Code Execution、URL Context、Computer Use 等这些工具由模型服务端提供开发者调用时只需指明使用该工具。核心要点优点立即可用、能增强模型的实时性与执行能力。风险实现细节对开发者不可见在安全/审计上需额外设计。经验/技巧在设计调用这些工具的 agent 时把返回的 metadata / url_context 等当作“证据”和“信任级别”一起记录并审计。2.2.2、Agent Tools把一个“专责 agent”封装为工具例如 ADK 的 AgentTool 或 A2A 协议便于主 agent 调用并在主流程中检视/过滤子 agent 的输出。核心要点通过 Agent-as-Tool 可以实现“分工 可审计”的多 agent 协作模式便于能力复用与治理。经验/技巧权限隔离为子 agent 设定权限边界read-only vs read-write调用后验证主 agent 在接受子 agent 输出前要做 schema/信任验证与高风险动作的 HIL。2.3、Best Practices工具设计最佳实践文档列出若干成熟且可立即落地的设计规则清晰文档、描述动作而非实现、发布任务级工具、工具粒度小、输出精简、使用校验/验证 等。以下分项逐条展开。工具应是“任务”not raw API小粒度、返回简洁并有 schema 校验与示例。立刻行动为关键工具引入 outputSchema并在客户端强制校验。2.3.1、Documentation is important工具的 name/title/description、参数说明、示例返回都会被注入模型上下文清楚的文档直接提升模型选择工具与生成正确参数的概率。核心要点工具名应可读且具描述性便于模型/审计参数描述要说明类型、用途与默认值给出示例返回。经验/技巧示例优先对复杂 outputSchema 给出“Example return”对模型有明显效果。参数精简避免长参数列表对复杂 API 做“任务抽象”而非裸露 API 字段。2.3.2、Describe actions, not implementations在系统指令或高层说明中应描述“目标/动作”what不要在指令中写如何调用具体工具how以避免与工具定义冲突并提升可移植性尤其在 MCP 动态工具场景。核心要点描述目标如“创建一条 bug 报告”让模型决定最合适的工具/顺序不要重复工具的实现细节或 API 文档。经验/技巧在 system prompt 中写清业务意图 约束例如 “优先使用公司内部 issue tracker如无则询问用户”而非硬编码工具名。2.3.3、Publish tasks, not API calls工具应代表“用户可理解的任务”task而非简单封装后端 APIAPI 参数复杂、对 agent 动态决策不友好。核心要点任务化工具更适合 agent 在运行时做参数选择过多的底层 API 参数会使 agent 难以正确调用。经验/技巧把常见复杂工作流封装为“高阶任务工具”但要写明副作用、所需权限、失败回退。2.3.4、Make tools as granular as possible工具职责单一、粒度细小便于文档、测试与模型一致地判断何时调用。核心要点单一职责降低模型误用风险仅在常见多步序列频繁出现时才考虑将多个步骤合并为一个“高阶工具”。经验/技巧对每个工具写清楚用途、调用条件、返回数据结构与副作用是否修改状态、是否会产生外部可观察变化。2.3.5、Design for concise output工具应避免返回过大的数据块大表、原始文件、图片 base64 等以免占用 context tokens、降低性能并影响后续推理。核心要点若结果巨大应把数据存到临时存储并返回引用 ID或提供分页/摘要返回。经验/技巧使用 Artifact/临时表/云存储返回小引用如 artifact_id在需要时再让 agent 调用工具取回详细数据。2.3.6、Use validation effectively在工具定义中使用 inputSchema/outputSchema 做运行时校验以同时充当文档与防错层。核心要点schema 既指导模型生成参数也提供客户端对工具调用结果的结构化检验从而防止格式/类型错误及潜在注入风险。经验/技巧强制校验链客户端在把 tool result 写回会话/上下文前应校验 outputSchema对不合规范的结果触发补救重试、询问用户或切换备用工具。3、Understanding the Model Context ProtocolMCP 是为了解决模型与大量外部工具之间“N×M”集成爆炸问题而提出的开放标准类似 LSP通过 Host/Client/Server 的架构与 JSON-RPC/传输规范提供工具发现、工具声明schema、结果格式与若干扩展能力Resources、Prompts、Sampling、Elicitation、Roots。下文按小节详细拆解。概述MCP 是为了解决 N×M 集成而设计的协议Host/Client/Server JSON-RPC它支持动态工具发现与运行时注入。核心要点N×M 问题JSON-RPC/Streamable HTTPTool 定义/结果/结构化内容/错误处理为核心原语。谁读架构师、平台工程、安全工程师。立刻行动搭建内部 Registry PoC 并定义 tool pinning/whitelist 流程实验 tool-retrieval → subset-load 模式减少上下文膨胀。3.1、The N x M Integration Problem and the need for Standardization每个模型要对接每个工具会产生大量one-off 连接N×M难以维护MCP 的目标是用统一协议把工具注册、发现与调用标准化降低集成成本并促进工具生态。核心要点MCP 可使 agent 在运行时发现并加载工具定义而非硬编码从而动态增强能力并支持可替换后端。经验/技巧即便采用 MCP也建议在企业侧建设 Registry Gatewayallowlist/pinning以避免随时暴露的不受控能力注入风险见安全章节。3.2、Core Architectural Components: Hosts, Clients, and ServersMCP 模型采用类似 LSP 的三层Host应用/Orchestrator、Client嵌入 Host 的组件维护与 Server 的通道、Server提供工具和资源并发布工具声明。核心要点Host 负责用户体验、策略与 guardrailsClient管理会话与工具生命周期Server 广告工具并执行请求。企业部署中 Server 还承担治理/可扩展性职责。经验/技巧在企业环境中不要直接信任外部 MCP Server在 Gateway/Client 层做 allowlist、版本 pinning 与变更通知。Figure 2: MCP Host, Client and Server in an Agentic Application3.3、The Communication Layer: JSON-RPC, Transports, and Message TypesMCP 采用 JSON-RPC 2.0 为基本消息格式定义四类消息Requests/Results/Errors/Notifications支持两种传输本地 stdiosubprocess和远程 Streamable HTTP推荐。核心要点JSON-RPC 提供语言无关的轻量化交互Streamable HTTP 支持 SSE 风格流返回并兼顾无状态服务器实现。经验/技巧对于需要文件系统访问或较低延迟的本地工具优先 stdio注意权限边界对远程工具使用 Streamable HTTP 并在 Gateway 做流量与安全策略。3.4、Key Primitives: Tools and othersMCP 的核心原语是 Tool广泛被支持另有 Resources/Prompts服务器端和 Sampling/Elicitation/Roots客户端但这些扩展能力当前支持度较低。本文重点聚焦 Tools 并解释其 schema、结果类型、结构化内容与错误处理。3.4.1、Tool DefinitionMCP 中 Tool 必须遵守 JSON schema关键字段包括 name、title可选但建议、description、inputSchema必须、outputSchema建议、annotations可选的行为提示。核心要点inputSchema/outputSchema 应被视为必需它们既是文档又是运行时校验依据。annotations如 destructiveHint、idempotentHint、readOnlyHint仅为提示不可盲目信任来自非受信 server 的注释。经验/技巧在企业端对接 MCP server 时对每个 tool 做schema 校验 pinning版本或哈希并拒绝没有 outputSchema 的工具或将其仅限低信任模式。3.4.2、Tool ResultsMCP 工具返回可以是结构化 JSON或非结构化text/audio/image/base64也可以返回对外资源的引用或采用流式stream返回客户端需谨慎处理资源引用与嵌入内容。核心要点建议工具提供 outputSchema 以便客户端验证资源类结果Resource应仅从受信任 URL 拉取。经验/技巧客户端在把工具返回插入会话上下文前先做输出净化敏感信息检测与 schema 验证对大结果采用“引用 后续 pull”模式。3.4.3、Structured Content结构化内容指返回 JSON 且遵循 outputSchema便于自动解析、验证与下游消费这是对 LLM-Client 交互最友好的返回形式。核心要点OutputSchema 不仅帮助解析也教育 LLM 如何使用结果因为 schema 也进入模型上下文。经验/技巧在工具定义中把“关键字段”标为必需required并提供示例有助于减少模型误解析或 downstream 错误。3.4.4、Error HandlingMCP 支持两层错误协议层 JSON-RPC error如 unknown tool、bad args和工具执行层 isError: true 的业务错误如 API rate limit。错误消息是指导模型故障恢复的重要渠道。核心要點设计错误时应给出可操作性建议例如“等待 15 秒后重试”或“询问用户确认参数”便于模型自动选择下一步动作。经验/技巧把“常见失败模式”列入错误返回的建议动作中并在客户端实现基于错误码的 fallback 策略重试/降级/询问用户。3.5、Other CapabilitiesMCP 还定义若干服务器/客户端能力Resources、Prompts服务器端Sampling、Elicitation、Roots客户端。当前这些扩展支持度普遍较低且在企业场景存在显著安全/治理疑虑。3.5.1、ResourcesResources 是服务器端可供客户端使用的静态数据文件、记录、图像等可嵌入或以 URI 引用返回。要点/风险引入任意外部 content 到 LLM 上下文带来注入与泄露风险客户端应只从 allowlist/受信 URL 拉取并做净化。经验/技巧对资源拉取实现显式用户确认/白名单策略并在 Gateway 做内容扫描。3.5.2、PromptsServer 可向客户端提供 prompts 模板或示例客户端可用它们直接调用 LLM相当于 server 注入使用说明。要点/风险Prompts 会引入“第三方注入执行流”风险prompt injection在分布式企业场景风险尤大。文件建议“谨慎/尽量少用”直到安全模型成熟。经验/技巧默认禁用外部 prompts如必须使用先在 Gateway 通过内容审查/模板白名单过滤。3.5.3、SamplingSampling 允许 server 请求客户端发起 LLM 完成把 LLM 调用“反向”到 client适合 server 需要 client-side LLM 做子任务的场景。MCP 建议对 Sampling 插入 HITL。要点/风险优点client控制 LLM provider、成本、guardrails风险prompt injection 通道 用户可能被要求批准不安全请求。经验/技巧对 Sampling 请求做严格 prompt 过滤并保证清晰的用户审批 UI显示意图、来源、是否含敏感请求。3.5.4、ElicitationElicitation 允许 server 暂停并请求客户端向用户收集额外信息动态 UI 交互。规范要求 server 不应请求敏感信息但无法系统性强制。要点/风险风险在于恶意 server 借此向用户诱导泄露敏感数据客户端必须实现 UI 层面的保护与显式同意。经验/技巧对所有 elicitation 请求在 UI 中以明确、逐项的方式展示“要收集什么、为什么、将如何使用”并允许拒绝/审计。3.5.5、RootsRoots 用于界定服务器在文件系统或 URI 空间的操作边界当前仅支持 file: URI 的 root但规范对 server 遵守 roots 的行为只有“建议SHOULD”因此客户端不应过度依赖。要点/风险由于缺乏强制性保障Servers 可能越界访问客户端应在本地代理/Gateway 做进一步限制。经验/技巧把 Root 交给受控容器环境或在 Gateway 做文件系统代理避免直接把本地路径暴露给远端 Server。4、Model Context Protocol: For and Against本章先肯定 MCP 在减少集成成本、推动工具生态与模块化架构方面的价值再审视其在企业生产化过程中暴露的性能、安全与治理短板——特别是当 MCP 从“本地开发/实验”推进到“远程/企业级服务”时所带来的新挑战。概述评估 MCP 的利与弊加速开发/弹性/治理基础 VS 企业就绪差距与安全风险。核心要点生态与替换性的战略价值需要 Gateway/Control Plane 才能企业化。谁读技术决策层、信息安全/合规团队。立刻行动制定 MCP 接入的“信任分级”策略trusted/untrusted与变更通知机制。总体核心要点MCP 带来动态发现、标准化工具描述和生态化复用三大战略优势。同时引入了上下文窗口膨胀context bloat、状态管理复杂性和企业级就绪身份/审计/可观测缺口等问题。企业通常不会直接采用“裸 MCP”更实际的路径是把 MCP 嵌入到带有 Gateway / Registry / Control Plane 的治理层。4.1、Capabilities and Strategic Advantages本节系统说明 MCP 在技术与战略层面的正面影响它能降低 N×M 集成复杂度、支持运行时能力扩展并为企业构建可替换/可演进的 agent 架构提供基础。4.1.1、Accelerating Development and Fostering a Reusable Ecosystem核心要点减少重复开发MCP 以统一协议替代一对一连接降低每增加新模型或工具时的集成成本解决 N×M 问题。工具即资产通过 Registry / marketplace工具MCP server可以被发现、复用与共享形成网络效应。经验/技巧试点阶段优先把最常用/高价值的几个内部服务包装为 MCP server 并在内部 Registry 上线以快速验证“发现→调用”闭环的稳定性与安全模型。在 Registry 中对每个工具做 metadata 标注风险等级、side-effects、需要的权限便于后续做 allowlist/自动化审计。4.1.2、Architectural Flexibility and Future-Proofing核心要点解耦能力实现替换性MCP 把 agent 与后端能力解耦便于替换 LLM 供应商或 backend实现长期演进而无需大规模重构。支持模块化/agentic-mesh 架构逻辑、记忆、工具可作为独立组件组合降低维护复杂度并助力分层治理。经验/技巧 采用“接口优先contract-first”策略先用 MCP schema 明确工具契约input/output/annotations再实现后端这样切换实现只需确保契约兼容。 在早期设计中明确哪些能力需要“高信任 / 高审计”通路例如支付并单独走受控 MCP server 或 Gateway。4.1.3、Foundations for Governance and Control核心要点集中治理点虽然 MCP 本身轻量但其架构提供将策略/访问控制内嵌到 MCP server 的可能性从而形成单点策略执行policy enforcement。促进 HITLHuman-in-the-loop规范推荐在执行敏感工具前需用户同意这为实现可控自动化提供制度基础。经验/技巧把“是否需要用户确认HIL”作为工具 metadata/annotations 的必检项并在 Gateway 层强制执行高风险操作一律 HIL。对外部 MCP server 做分级信任trusted / untrustedtrusted server 可被允许更多 capability但必须先经过审计与 pinning。4.2、Critical Risks and Challenges本节罗列 MCP 在转企业级部署时的主要风险点不仅是技术性能、状态管理更有安全动态能力注入、shadowing、治理身份/审计等多维挑战。4.2.1、Enterprise Readiness Gaps核心要点认证/授权不足早期 MCP 规范对企业级 authN/authZ 的覆盖不够OAuth 实现与部分企业实践冲突缺乏 per-tool/per-resource 级别的细粒度控制。身份传播模糊协议尚未定义清晰的“谁在发起操作”终端用户 / agent / system影响审计与问责。缺少原生观测能力协议没定义 logging/tracing/metrics 原语企业需在上层构建可观测平台如用 API Gateway/Apigee。上下文窗口膨胀Context Window Bloat把所有工具定义预加载到 prompt 会耗尽 token影响模型推理与成本。经验/技巧不要“裸用”MCP在企业内部放置 Gateway Registry PinningGateway 做 allowlist、变更通知、审计与速率控制。对 tool definitions 采用“tool-retrieval → subset-load”策略首先检索相关工具索引RAG 风格只把最相关的少量定义注入上下文缓解 token 膨胀与混淆。设计身份链路把用户身份/权限以短期、受约束的 scoped token 形式传给 MCP server并在 server 端校验 audience/scope。5、Security in MCP本章系统描述 MCP 引入的新威胁面既有来自其作为新 API 表面的风险也有来自其作为去中心化协议带来的供应链与注入风险并针对主要风险提出一系列工程化缓解措施包括 allowlist、pinning、taint-tracking、HIL、网关过滤等。概述列出 MCP 引入的新威胁shadowing、malicious definitions、sensitive leaks、no scope control并提供缓解allowlist、pinning、taint-tracking、scoped credentials、HIL。核心要点协议开放带来供应链与注入风险必须设计 perimeterGateway与 runtime policy。谁读安全团队、平台团队。立刻行动在 Gateway 实现 tool name collision 检测、output sanitization 与 high-risk HIL 策略。5.1、New threat landscape核心要点两类来源一是 MCP 作为新的 API 表面缺乏内置 auth/quotas/observability二是作为标准协议易被滥用、出现供应链与注入攻击。高风险后果未经授权操作、敏感数据泄露、confused-deputy代理被利用完成越权操作等。文档用“代码库泄露”示例详细说明了 confused deputy 攻击路径。经验/技巧把安全策略写入设计规范在每个 MCP 对接项目启动前列出授权范围、审计要求、和 HIL 触发条件并把这些要求做成自动检测/测试项。5.2、Risks and Mitigations原文把若干高风险类别逐一列出Dynamic Capability Injection、Tool Shadowing、Malicious Tool Definitions、Sensitive Info Leaks、No scope limiting并给出可执行缓解措施。下面分别按子项展开。5.2.1、Tool Shadowing风险说明定义恶意/未受信工具通过语义或触发条件覆盖shadow合法工具使 planner 误选并造成数据泄露或误动作。示例恶意 save 工具覆盖企业 secure_storage_service。缓解措施核心名称冲突检测semantic在 Client/Gateway 过滤新工具时做语义相似度检测阻止潜在“影子”工具注册。mTLS 与身份验证对高敏感 MCP 连接使用 mutual TLS 和强身份验证以确保 server 身份。策略执行点在发现/调用/返回等关键拦截点强制策略检查plugin/callback。HIL 强制对所有高风险 sink删除、写 DB、外部传输要求人工确认无论是哪个工具发起。经验/技巧把工具“信任等级”做成显式字段trusted / semi-trusted / untrusted在 planner 层与 Gateway 做分流策略例如 untrusted 只能提供 readonly/preview 功能。5.2.2、Malicious Tool Definitions and Consumed Contents风险说明恶意工具描述或工具返回内容可通过 prompt injection、恶意 schema 或恶意资源让模型执行非预期动作或泄露敏感信息。工具本身或其返回的资源都可能成为攻击载体。缓解措施核心输入/输出净化对 tool inputs 做严格校验对 tool outputs 进行敏感数据/注入检测例如去掉 active HTML、脚本、Token 样式字符串。分离 system prompts避免 server 提供的 prompts 直接注入模型 system 指令Prompts 应受白名单与审计。trusted vs untrusted planners引入双 planner 架构trusted planner 访问受信工具untrusted planner 访问第三方工具二者通信受限且经过审计。经验/技巧在 Gateway 实施“工具描述清洗”流程把 server 提供的 tool definitions 先通过过滤器/LLM-safe-checker或正则 ML清洗再注入 client。并对 outputSchema 缺失的工具限制其能力。5.2.3、Sensitive information Leaks风险说明工具可能无意或恶意返回含敏感数据PII、凭证、内部文件路径等Elicitation 功能甚至能诱导用户提供敏感信息。缓解措施核心标注与 taint-tracking把输入/输出标记为 tainted/untrusted传播时触发策略阻断或 HIL。输出字段注释使用工具 annotations 或自定义字段来标注可能携带敏感信息的字段并在客户端严格处理。UI 层的用户同意任何 Elicitation 请求必须通过清晰 UI 展示“为何收集、如何使用”并取得用户明确同意。经验/技巧对工具返回做自动敏感数据检测电话号码、信用卡、SSN、JWT-like tokens一旦检测到“敏感片段”自动 redact 并记录审计事件。5.2.4、No support for limiting the scope of access风险说明MCP 原生仅支持粗粒度授权一次性 client↔server 授权缺乏本地对每个工具/资源的细粒度 scope 授权与可替代的 credential 传递机制容易导致 confused-deputy 类越权。缓解措施核心Scoped / Audience-bound Credentials在客户端对每次调用生成短期、范围受限scoped凭证并要求 server 在每次执行时校验 audience 与 scope。最小权限原则每个工具只被授予必要最少权限read-only vs read-write并对权限作频繁审计。Secrets 不进入上下文把密钥、token 保留在 MCP client 本地通过安全 side-channel 传递不要把 secrets 写入 agent 会话或工具定义。经验/技巧在 Gateway 层实现“per-tool policy mapping”把企业角色和工具权限映射为策略并在调用时做 policy-as-code 验证对高风险调用启用多重签名或 HIL。6、Conclusion概述MCP 是强工具但“无治理即风险”企业应在 MCP 之上构建统一控制面并把安全/审计当作第一阶工程任务。谁读高层决策者、实施负责人。立刻行动把 MCP 相关的合规/安全要求写入项目启动清单SoW / SRS。价值MCP 通过标准化工具发现/描述/调用能显著降低集成成本、催生工具生态并为模块化 agent 架构提供基础动态能力扩展、替换性强。代价原生 MCP 在企业级部署面临实质性挑战——安全动态注入、shadowing、confused deputy、性能上下文膨胀、stateful 调度与可观测/身份治理缺口。企业通常会把 MCP 嵌入到受控 Gateway/Registry/Control Plane 之下以补齐这些短板。