MCP

arXiv 2601.17549 对 MCP 规范本身做了第一次系统性安全分析，并提出 ProtoAmp 框架来度量协议级攻击面。结论是三个协议设计层的缺陷，靠改某个客户端修不好。 ProtoAmp 指出的三条信任裂缝是什么？ 第一，缺能力证明。MCP server 可以随意宣称自己有什么权限，协议没有要求它出示可验证的凭据。一个恶意 server 声称自己「只读」，实际却能写文件，Agent 无从分辨。 第二，双向采样无来源认证。MCP 允许 server 反过来向客户端请求采样（sampling），但没有认证这个请求到底来自哪。攻击者借此把提示注入塞进模型上下文，而 Agent 以为是用户的指令。 第三，多服务器隐式信任传递。当一个 Agent 同时连多个 MCP server，server 之间可以互相影响，信任被隐式传递，没有一道显式的授权闸。 针对这三条裂缝该怎么加固？ 能力证明：要求 server 在握手时出示声明的权限边界，客户端按最小权限放行。采样来源：对 server 发起的采样请求做来源白名单，拒绝任何未经用户确认的反向调用。多服务器隔离：不同 server 的上下文物理隔开，禁止一个 server 的内容直接成为另一个 server 的工具输入。 MCP 信任问题的本质到底是什么？ MCP 的问题本质是「把网络信任默认成了本地信任」。在 Agent 自动执行一切的时代，每一次工具握手都应该是一次显式授权，而不是一句「默认信任」。 落地时必须守住哪三条红线？ 第一，不信任任何 server 自报的权限。让 server 在握手时出示它要访问哪些资源，由你按最小集合批准，而不是它说只读就只读。第二，默认拒绝 server 反向发起的采样请求，确有需要时弹给用户确认，绝不让 server 借模型之手发指令。第三，多 server 之间做上下文隔离，一个 server 返回的内容在喂给另一个 server 的工具前，必须经过清洗与标注。这三条做到，ProtoAmp 指出的三类协议级风险就被兜住了大半。协议本身要补，但企业侧的防御不能等协议修完才动手。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：MCP能力证明

9 月 12 日 arXiv 上线一篇 MCP 生态安全普查（2609.14119），标题很直白：《同名不同服务器》。它扫描了整个 MCP 注册库，结论比预想更糟。 普查里最硬的两个数字是什么？ 普查发现，15.2% 的被扫服务器至少带一项安全发现，11.1% 至少一项高危，其中未鉴权的网络暴露占了高危的大头。即使做了精确率校正，高危盘子缩小但并未消失。10 月初社区又整理出官方 MCP server 上约 140 处「静默合同变更」——工具接口在版本升级时悄悄改了行为，调用方却毫无察觉。典型案例包括 CVE-2026-81486 路径穿越（CISA 已通报）与 CVSS 9.6 的 AWS Labs postgres MCP 服务器命令注入 CVE-2026-87911。 为什么「描述漂移」是最隐蔽的风险？ 更值得警惕的是注册库的不稳定：半数多版本服务器悄悄修改了对外宣称的工具描述。MCP 把工具描述直接拼进模型的上下文，描述一变，模型对工具行为的理解就跟着变——这等于让攻击者可以通过更新一个包，悄悄改写 Agent 的行为边界，而人完全不会去逐字比对版本间的描述差异。 面对工具描述漂移该怎么防？ 把工具描述纳入版本 diff 监控；对生产环境锁定 server 版本与哈希；建立工具调用的最小权限边界，即使描述被篡改，工具能做的事也有限。 MCP 生态正在重演哪段历史？ MCP 生态正在重演 npm 早年的供应链乱象，但因为工具会被模型自动执行，后果从「偷代码」升级成「自动执行命令」。审计工具链，必须像审计依赖项一样严格。 怎么给工具描述做常态化安检？ 既然描述会漂移，就要把它纳入变更管理。给生产环境用到的每个 MCP server 存一份当前工具描述快照，每次升级包后自动 diff：工具数量、参数 schema、描述文本任一变化都告警。尤其警惕描述里「悄悄多了一句能力」的情况——那往往是攻击面扩大的信号。再配合锁定版本哈希、最小权限运行，即使某个 server 被投毒，Agent 能用它做的事也有限。供应链安全在 Agent 时代的核心，就是假设你下载的每个工具都可能随时变坏，并为此留好熔断装置。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：MCP静默漂移

今年 4 月 15 日前后，OX Security 披露了一起被称作「AI 供应链之母」的漏洞：MCP 的 STDIO 传输接口存在系统性远程命令执行缺陷。Cloud Security Alliance 的研究笔记估算，受影响实例约 20 万个，背后供应链包下载量超过 1.5 亿次，后续累计演进出 11 个 CVE。 为什么说它是设计缺陷而不是代码 bug？ 关键在于：这不是 Anthropic 官方 SDK 在某一行代码写错了，而是 STDIO 传输这个默认通道本身的设计选择——Python、TypeScript、Java、Rust 各语言官方 SDK 都把用户可控的配置一路传到 shell 执行。由于所有下游项目都信任参考实现，同一个缺陷被复制进了成千上万个 MCP server。Anthropic 后来也确认了这一行为。 换句话说，漏洞不是被「写出来」的，是被「设计出来」的，然后通过 SDK 默认值扩散到整个生态。 这个漏洞对企业实际意味着什么？ 任何能影响 MCP server 配置的人，都可能在宿主机上执行任意命令。这比传统 Web 漏洞更隐蔽，因为 MCP server 往往以开发者或自动化 Agent 的高权限后台身份运行。NIST 在其智能体安全材料里，已把 MCP、A2A、ACP 一并列为「不安全协议」。 面对 STDIO RCE 该怎么加固？ 不要把 MCP server 暴露在公网；用容器或沙箱隔离工具进程；升级到修复后的 SDK；对 server 配置做签名校验，拒绝来历不明的工具描述。把 MCP 当作一段会被模型自动调用的代码来审计，而不是当作无害插件。 这轮 STDIO RCE 给行业敲了什么警钟？ 这轮 STDIO RCE 给整个 Agent 行业敲了警钟：协议默认安全，必须从第一版就设计进去，而不是事后补 CVE。 ...

MCP（Model Context Protocol）是 2025 年底以来智能体连接外部工具的事实协议，但 2026 年它连续曝出协议级问题。4 月 OX Security 披露：MCP 官方 SDK 的 STDIO 传输存在一个系统性设计缺陷——本地启动服务器进程时，底层会执行任何传入的操作系统命令，即便伪造服务器启动失败返回错误，命令照样执行。该漏洞波及约 20 万个实例，供应链下载量超 1.5 亿次，覆盖 Anthropic 官方支持的全部 11 种语言 SDK；Anthropic 确认这是有意设计，拒绝修改。 三种投毒攻击面 CSA 七月的研究笔记把攻击归为三类，结构同源——客户端默认信任它连接的服务器，且从不持续校验这种信任： 工具描述投毒：恶意指令藏在工具描述、参数 schema 里，智能体注册工具时就被劫持。 rug-pull：服务器今天行为正常，某次更新后突然变坏，客户端毫无察觉。 工具影子化：影子工具冒充合法工具，窃取凭证。 学术侧也在跟进：arXiv 上 ShareLock 研究多工具阈值投毒，VIPER-MCP 用污点分析挖 MCP 服务器里的命令注入、SSRF 与路径穿越。 为什么不是修个 bug 就完事 因为 MCP 把工具元数据直接喂进模型上下文，模型天然把它当可信指令。这不是某家客户端的 bug，而是协议信任模型的结构性缺陷：只要工具描述能影响模型决策，投毒就可能发生。 工程上怎么挡 在客户端与 MCP 服务器之间加一层网关，对工具描述、返回内容做注入检测与白名单过滤。 工具凭证与模型进程隔离，就算上下文被劫持也拿不到密钥。 只信任经过审核的工具源，禁止智能体动态加载来路不明的 MCP 服务器。 特别要警惕供应链一環：很多 MCP 服务器本身依赖第三方 Python 包，一旦依赖被投毒，恶意代码就在服务器进程里执行，能拿到该服务器可见的一切上下文与凭证。安装时锁定依赖版本、定期做漏洞扫描，是这道防线上最容易被忽视却最致命的一环。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：MCP 工具投毒

配置文件是第一道坎 接 MCP 最常见的挫败不是代码错，而是配了等于没配——工具列表里死活不出现，又没有报错。根因几乎都在那个 JSON 配置文件。Claude Desktop 的配置文件位置：macOS 在 ~/Library/Application Support/Claude/claude_desktop_config.json，Windows 在 %APPDATA%\Claude\claude_desktop_config.json。 一个最小可用的配置长这样（以官方 filesystem 服务器为例）： { "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/yourname/notes"] } } } 关键：command 和 args 分开写，路径写绝对路径，JSON 不能有注释、不能有多余逗号。配完必须完全退出 Claude Desktop 再重开——它只在启动时加载配置，热更新不生效，这是最多人栽的地方。 排查三步法 工具没出现时，按这个顺序查： 第一，看日志：Claude Desktop 日志在 macOS 的 ~/Library/Logs/Claude/，Windows 的 %APPDATA%\Claude\logs\。MCP 启动失败的报错（npx 找不到、路径不存在、Python 报错）都记在这里，别猜。第二，手动跑一遍命令：把配置里的 command + args 原样复制到终端执行，能跑通说明是环境问题，跑不通就是命令本身错。第三，确认 npx/node 版本：很多官方服务器是 Node 包，本机 Node 版本太低会静默失败，先 node -v 确认在 18 以上。 几个开箱即用的官方服务器 服务器 作用 适用场景 filesystem 读写指定目录文件 让助手整理笔记、改文档 fetch 抓取网页内容 让助手读指定 URL sqlite / postgres 查询数据库 自然语言查业务数据 git 读仓库状态、diff 代码助手看提交历史 配好之后，Claude 对话框里会出现小锤子图标，点进去就能看到加载成功的工具清单。VS Code 的 Copilot、Cursor 这类 IDE 也都支持 MCP，配置思路一致——都是告诉客户端「去哪里启动这个 server」。 ...

MCP Server 到底是什么 很多人把 MCP 想得很复杂，其实它就是一个把你的函数暴露成「模型可调用工具」的标准壳子。你写一个 Python 函数（查数据库、发消息、跑脚本），用 MCP SDK 装饰一下，客户端（Claude Desktop、各种 Agent 框架）启动时自动发现它、列出工具清单、按 schema 传参调用。你不用再为每个模型适配一套 function calling 格式——MCP 帮你把这层标准化了。 最小可运行模板 环境准备：pip install mcp，然后建一个 server.py。核心结构就三块——导入 SDK、用 @server.tool() 装饰你的函数、启动 stdio 服务： from mcp.server.fastmcp import FastMCP mcp = FastMCP("my-tools") @mcp.tool() def query_sales(region: str, month: str) -> str: """按地区和月份查询销售额。region 为中文地区名，month 格式 YYYY-MM。""" # 这里换成你真实的数据库查询 return f"{region} {month} 销售额：￥1,280,000" if __name__ == "__main__": mcp.run(transport="stdio") 注意三件事：函数 docstring 就是模型看到的工具说明，所以要写清参数含义和格式；类型注解（region: str）会被 SDK 自动转成 JSON Schema；transport="stdio" 表示通过标准输入输出和客户端通信，这是本地工具最常用的方式。 三个必踩的坑 第一，权限边界：MCP Server 跑在你本机，等于把工具的真实读写权限交给了模型。一个 delete_file 工具被模型误调就是真实删除。生产前给危险操作加二次确认或白名单目录。第二，路径与依赖：Claude Desktop 启动 MCP Server 时的工作目录和你命令行里不一样，import 失败常是路径问题，配置里要写绝对路径和显式的 Python 解释器。第三，配置文件格式：在 Claude Desktop 的 claude_desktop_config.json 里注册 server，格式是 JSON，写错逗号或路径，客户端静默不加载——调试时先看客户端日志，别对着代码发呆。 ...

什么是MCP MCP（Model Context Protocol）让AI通过统一接口连接外部工具。就像USB-C标准，一个接口连所有设备。 核心概念 Server：工具提供方（文件、数据库、API） Client：AI应用（接入工具） 资源：可读的数据 工具：可调用的操作 能做什么 读文件、写文件 查数据库 调用API 控制浏览器 快速上手 装一个MCP Server（如filesystem） 在AI客户端配置 让AI调用工具 为什么重要 MCP让AI从聊天变做事。Agent能力的标准接口，未来所有AI应用都会支持。

什么是MCP MCP让AI模型通过统一接口连接外部工具和数据源，类似USB-C之于硬件。 为什么重要 不用为每个模型写不同的集成 工具开发者写一次，所有模型都能用 Agent生态开始标准化 已有节点 文件系统、数据库、浏览器、GitHub、Google Drive、Slack……越来越多。

为什么记忆是Agent的最后一块拼图 2025年的AI Agent缺的不是工具调用能力，而是长期记忆。一个不能记住用户偏好、不能从历史交互中学习的Agent，每次对话都是从零开始。 2026年，这个问题正在被解决。 三大技术路线 1. MCP Memory协议 Anthropic推出的MCP协议生态中，Memory Server成为最热门的节点。Agent可以通过标准接口读写长期记忆，不再需要每个应用自己造轮子。 2. 向量数据库+知识图谱 纯向量检索容易产生"语义漂移"，2026年的主流方案是向量+图谱混合检索：向量负责语义相似，图谱负责逻辑关联。 3. 分层记忆架构 工作记忆：当前对话上下文 情景记忆：历史交互记录 语义记忆：提取的知识和偏好 程序记忆：学会的技能和工作流 实际效果 接入记忆系统后，Agent的用户留存率提升40%以上，因为它"认识你了"——记得你的项目、你的偏好、你上次聊到哪。 下一步 记忆系统标准化之后，下一个战场是记忆的隐私和所有权——谁拥有Agent的记忆数据？用户能不能导出、删除？

硅基速览 9月10日，OpenAI Agents API进入公开测试阶段，提供托管式Codex harness。 核心能力：沙箱环境、上下文压缩、并行子Agent、MCP协议支持、可恢复会话。 与Claude Code（终端Agent）和Cursor Projects（多Agent工作区）形成2026年9月Agent开发框架的三足鼎立。 正文 OpenAI补齐Agent拼图 2026年9月10日，OpenAI的Agents API进入公开测试（Public Beta）。根据andrew.ooo在9月14日发布的对比文章，这个API的定位是"托管式Codex harness"——你不需要自己搭建Agent运行环境，OpenAI帮你托管好。 在Agents API之前，OpenAI的Agent能力分散在多个产品里：Codex CLI（终端编程Agent）、GPT Store（自定义Gpts）、Assistants API（基础对话Agent）。但这些产品要么需要你自己搭建运行环境，要么能力有限。Agents API第一次把所有Agent能力整合到一个托管平台上。 核心组件包括： 沙箱环境（Sandboxes）。 每个Agent任务都在一个隔离的容器中运行，有独立的文件系统、网络访问权限和计算资源。Agent可以在沙箱里执行代码、调用工具、访问API，但不会影响到你的生产环境。 上下文压缩（Compaction）。 长任务运行过程中，Agent的上下文窗口会不断增长。Agents API自动进行上下文压缩——把早期的对话历史和工具调用结果总结成摘要，释放上下文空间，让Agent可以处理长达数小时的任务而不超出token限制。 并行子Agent（Parallel Subagents）。 主Agent可以派生多个子Agent并行执行不同子任务。比如主Agent需要"分析这个代码库"，它可以派一个子Agent读前端代码、一个读后端代码、一个读配置文件，然后汇总结果。这比单个Agent串行处理快3-5倍。 MCP协议支持。 Model Context Protocol是Anthropic发起的开放协议，现在已成为Agent连接外部工具的事实标准。OpenAI在Agents API中支持MCP，意味着你可以用任何兼容MCP的工具服务器（数据库、文件系统、浏览器、GitHub等）直接接入Agent。 可恢复会话（Resumable Sessions）。 Agent执行长任务时如果中断（网络问题、超时、错误），会话状态会被持久化，可以从中断点恢复，不需要从头再来。 与Claude Code和Cursor Projects的对比 到2026年9月，Agent开发框架已经形成三足鼎立格局： 维度 OpenAI Agents API Claude Code Cursor Projects 定位 托管式Agent后端 终端编程Agent IDE内多Agent工作区 状态 Public Beta（9月10日） GA（Fable 5.1接入） Beta（9月10日全量推送） 核心场景 API集成、企业工作流 终端软件开发 团队协作编程 子Agent 并行云端子Agent 子Agent+Hooks 协调Agent+云端子Agent MCP支持 支持 支持 通过IDE插件 会话恢复 原生支持 通过Cowork 通过共享上下文 三者的定位差异很清晰：OpenAI Agents API面向"后端开发者"——你在自己的应用里嵌入Agent能力，OpenAI帮你托管运行环境；Claude Code面向"个人开发者"——你在终端里直接与Agent结对编程；Cursor Projects面向"团队协作"——多个人+多个Agent在一个共享工作区里协作开发。 ...