原因不难理解。它并非不能上网，而是能力有限：读静态 HTML 页面没问题，碰上 JavaScript 渲染或反爬系统就卡住。查论坛讨论时，它只能依赖搜索摘要，而摘要本身往往陈旧。内置工具也不返回结构化数据，模型只能自己从一段概述里连蒙带猜，想精确取某个数值时基本用不上。

该撰稿人的解法是接入一个叫 Firecrawl 的服务：它负责处理 JavaScript 渲染和动态内容，把网页转成大模型能直接消化的结构化内容，免费额度下就能看出差别。

一、给 Claude Code 接上 Firecrawl

1. 先到 Firecrawl 官网创建一个 API 密钥
2. 终端执行一条命令即可（密钥换成自己的）：claude mcp add --transport http firecrawl https://mcp.firecrawl.dev/v2/mcp --header "Authorization: Bearer 你的密钥"
3. 用 claude mcp list 确认服务已添加，或在会话里输入 /mcp 查看连接状态和详情
4. 也可以走账号登录的方式，地址改成 https://mcp.firecrawl.dev/v2/mcp-oauth，由客户端拉起浏览器完成授权
5. 密钥放进环境变量或客户端自带的密钥存储，官方明确提醒：不要把它拼进 MCP 地址里

网页版 Claude 的接法不同：在 Connectors 列表里添加 Firecrawl，之后用输入框旁的加号按钮选中它触发。

二、接上之后多了哪些工具

1. firecrawl_scrape：已知网址时取页面内容或结构化字段，想按提示词、按 JSON 结构取数据也是用它的 JSON 格式
2. firecrawl_search：只有关键词、没有具体网址时用
3. firecrawl_map：先摸清一个站点有哪些页面，再决定抓哪几个
4. firecrawl_crawl：成批遍历整站或某个板块
5. firecrawl_parse：解析 PDF、文档、表格和 HTML 文件

有一处需要留意：原文提到的 Extract 工具，官方文档已标注弃用，现在改用 Scrape 配 JSON 格式，或交给自动检索多个来源的 Agent 工具。

三、变化体现在哪

该撰稿人给出三点实际感受：查论坛近期讨论不再返回半成品答案或错误码；非 HTML 构建的页面也读得动，不必再把网页转成 PDF 或 Markdown 上传一遍；批量从多个网页取数据时，明显比内置抓取快。做文献综述和事实核对时，因为工具确实访问了页面，结果也更可信。

注意事项

它不是万能的。需要过验证码或防护很强的站点进不去，需要多步登录的页面也无能为力，这两种情况仍要靠 Claude 桌面版的内置浏览器。

另外要清楚不同接入方式的差别：不配密钥的免费模式只有搜索、抓取、解析这三个工具，登录或配好密钥才是完整工具集。遇到 401 报错先查配置的地址——填的是 /v2/mcp 就换密钥，填的是 /v2/mcp-oauth 就重新登录，改完记得新开一个会话。

来源：MakeUseOf

它能做什么

Implant 的核心是提供一个 MCP 工具 run_vscode_script。通过它，AI 智能体可以实时调用 VS Code 及其第三方扩展的能力：查找引用、跳转到定义、悬浮提示类型、查看工作区诊断、读取 git blame、浏览符号大纲，以及运行任何扩展注册的命令。

更实用的是修改代码的能力：结构化重命名、快速修复、重构、整理导入、通过 WorkspaceEdit 安全地创建/重命名/删除文件、使用格式化程序、执行源码操作。这些编辑都走语言服务器，而不是粗暴的文本替换，因此更能尊重作用域、导入和语义。

为什么比纯文本对话更安全

插件作者 Pavel Mikhailovskii 强调，Implant 默认不会自动执行任何脚本。每次调用都会弹出一个带有语法高亮的 webview，让用户选择“运行”、“运行并信任本次会话”或“拒绝”。只有用户明确批准后，脚本才会在 VS Code 扩展宿主中执行。

插件本地 HTTP 服务器只绑定 127.0.0.1，并依赖每次启动都会重新生成的会话令牌，未授权请求会返回 401 并弹出警告。不过作者也提醒：不要在共享机器上使用，因为任何以同一用户身份运行的进程都能读取会话文件。

安装与配置

安装 Implant 后，它会询问是否将其安装到当前工作区。这一步会在项目里生成五份可提交到版本控制的文件：

• .vscode/implant/call.js：stdio 与 HTTP MCP 代理

• .mcp.json：Claude Code / 通用 MCP 配置

• .cursor/mcp.json：Cursor MCP 配置

• .claude/skills/implant/SKILL.md：Claude Code 技能说明

• .cursor/rules/implant.mdc：Cursor 规则文件

同时，它会在 .github/copilot-instructions.md 中插入一段 <!-- BEGIN Implant --> 标记的指导语。VS Code 1.101 及以上版本的 MCP 原生客户端会自动发现该工具；命令行智能体则通过工作区配置文件读取。

适合谁用

如果你经常让 AI 处理中大型代码库，却总被“找不到定义”“改错了导入”“重命名漏了引用”困扰，Implant 相当于给智能体配了一副眼镜和一套手术刀。它不会替你思考，但能让智能体真正看懂并操作工程。

局限

目前 Implant 仍依赖每次调用的手动确认，不适合完全无人值守的自动化流水线。另外，由于脚本在扩展宿主内以扩展同等权限运行，任何安全沙箱的缺失都是其设计本身带来的取舍。

来源：Visual Studio Marketplace / Implant

Cloudflare 在 8 月 6 日推出了 WebMCP 的开发者预览版，试图改变这一局面：网站只需在控制台里打开一个开关，无需编写任何代码，也不改动源站，浏览器中的 AI 代理就能直接调用这个网站提供的工具。Cloudflare 会向页面注入一个轻量桥接层，为访客的代理注册一套可用工具集。

从「爬」到「调用」

过去，AI 获取网站内容的通行做法是爬虫抓取：把内容复制回自己的服务器，往往既不给原网站带去流量，也不留下多少署名。Cloudflare 认为存在一条更好的路径，而且这条路径不需要爬取。

WebMCP 是一项新的浏览器标准，目前已在 Chrome 146 中实验性上线，在页面里以 document.modelContext 的形式呈现。网站可以主动向浏览器内运行的代理暴露一组工具，代理就不必再对着为人类设计的页面元素反复猜测。这样一来，代理的浏览体验可以与人类用户完全不同，token 花在真正要完成的任务上，而不是消耗在无谓的页面导航中。唯一的门槛在于：网站必须自己去实现它。

Cloudflare 一直在这条链路的两端同时布局。其远程浏览器 BrowserRun 已支持 WebMCP，代理可以发现并调用网站暴露的工具；Cloudflare Radar 也即将提供自己的 WebMCP 工具。这次的预览版针对的是另一端——让任何托管在 Cloudflare 上的网站，通过一个开关、零代码就获得这些能力。

技术实现：边缘注入加浏览器桥接

手动实现 WebMCP 本身就是一个不小的工程：需要设计要暴露哪些工具、把它们接入现有界面，还要随着标准演进持续维护。Cloudflare 的目标是把这件事简化成拨动一个设置开关。

这些工具以「工具包」（pack）的形式组织，相关工具可以整体启用。工具包的设计考虑了扩展性：随着 Cloudflare 陆续增加新包，网站只需打开开关即可接入更多能力，无需重新部署。当前开发者预览版包含两个工具包，两者都完全在浏览器中运行。

整套实现由两部分组成，均位于源站之前，不触碰网站自身代码，且对静态站点和单页应用一视同仁。

第一部分是边缘注入。当网站在 Cloudflare 控制台中开启 WebMCP 后，Cloudflare 使用 HTMLRewriter 在每个 HTML 响应中添加一行内容——一个指向桥接脚本的引用。标签和它加载的脚本都来自边缘节点、同源提供，页面的其他部分保持原样：

<script
  type="module"
  src="/.webmcp/bridge.js"
  data-packs="c2pa,mcp-server-client"
  data-mcp-url="/mcp"></script>

其中 data-packs 属性列出要激活的工具包。如果网站已有自建的 MCP（Model Context Protocol，模型上下文协议）服务器，data-mcp-url 就指向该服务器，默认为同源的 /mcp 路径。

第二部分是桥接层。它在页面中运行，负责寻找 WebMCP 接口。如果浏览器不支持该接口，脚本直接返回、什么也不做，页面行为与之前完全一致。

找到接口后，桥接层会把 data-packs 中列出的工具包合成一份工具清单，逐个通过 .registerTool 注册。一个工具包就是一组 MCP 工具描述符及其处理函数。像内容凭证包这样的静态包会预先声明自己的工具；而像站点 MCP 服务器包这样的动态包，则在启动时先发现工具，再进行注册。

在当前预览版中，每个工具都完全在访客的浏览器内运行，不存在向 Cloudflare 服务器的往返请求。内容凭证包在本地抓取图片并解析其前几 KB 的内容溯源元数据；站点 MCP 服务器包则从页面直接与网站的 MCP 服务器端点通信，使用访客所在的源和其已有的会话。

桥接层代码由运行在边缘的 Worker 提供。Cloudflare 表示这为后续扩展留出了空间——未来的工具包将能够调用这个 Worker，去完成页面自身无法独立完成的任务，比如用 Workers AI 总结站点地图，或查询 AI 搜索索引。

对代理而言，这些都只是普通的 MCP 工具。Cloudflare 直接沿用了 Model Context Protocol 自身的 Tool 和 CallToolResult 类型，因此一个已经能与 MCP 服务器对话的代理，不需要任何额外改造就能驱动页面。用 Cloudflare 的说法：浏览器只是 MCP 运行的又一个场所。

两个预览工具包

内容凭证包用于读取图片的溯源元数据，服务于 C2PA 内容凭证计划的参与方。其中 scan_images_c2pa 会扫描页面上的每一张图片，返回一份简短摘要，包含图片总数、已扫描数量、带有 C2PA 信息的数量，以及每张图的格式、声明生成方（例如 Adobe Firefly）、标题和签名者等字段。若需要更细致的信息，inspect_image_c2pa 可以解码单张图片的完整清单，包括编辑历史、声明的作者以及签名证书。

另一个是站点 MCP 服务器包。它会读取网站自有 MCP 服务器通过 tools/list 公布的每一个工具，为其注册一个代理封装。当代理调用该工具时，封装函数会以同源方式向 /mcp 发起 POST 请求，携带访客现有的会话凭据，并将返回的 CallToolResult 原样传回。

对站点运营者来说，这一变化的实际意义在于 AI 流量的处理方式：代理不必再从原始 HTML 中反推网站意图，而是可以调用结构化工具、拿到准确且符合预期的结果，同时保留会话上下文，网站方也能完整看到代理的交互行为。

WebMCP 采用 MCP 2026-07-28 版本规范，该版本将协议从有状态的会话管理转向基于 Streamable HTTP 的无状态模型，代理通过标准 POST 请求调用工具，用 Mcp-Method 和 Mcp-Name 请求头路由指令，从而更适合在边缘基础设施上横向扩展。

需要注意的是，这仍是开发者预览版，WebMCP 标准本身在 Chrome 中也处于实验阶段。站点运营者可以将 BrowserRun 指向自己的域名，查看代理究竟会发现哪些工具、又会如何调用它们，然后再决定是否放行生产流量。

来源：Cloudflare 官方博客、Cloudflare Browser Run 开发者文档

一套可携带的打包格式

Agent Plugins 被定义为一种开放、供应商中立的标准，核心是一套可携带的打包格式，用来把「智能体技能」和 MCP 服务器打包成可移植的插件。其 1.0.0 版规范规定了一个共享格式，让兼容的客户端能够一致地发现并加载这些组件。

换句话说，开发者今天为某一款 AI 产品写好的智能体能力，未来不必为每个平台重写一遍——只要对方支持这套标准，就能直接调用。

这项标准并非 OpenAI 一家说了算。据 Agent Plugins 官网介绍，项目「以开放许可、公开开发的方式进行」，技术指导委员会成员包括 Amazon、Cursor、Microsoft、OpenAI 与 Vercel，其中草案由 Vercel 发起。

首批确认支持的客户端已经铺开：ChatGPT、Codex、GitHub Copilot、VS Code、Cursor，以及 AWS 的 Kiro。这意味着从聊天机器人到代码编辑器，再到云厂商的 Agent 工作台，都有望共用同一套插件生态。

从单模型到智能体平台

GPT-5 于 2025 年 8 月 7 日取代 GPT-4o 成为 ChatGPT 默认模型，其标志性能力是「自动路由」——根据问题难度决定快速回答还是深度推理。此后一年里，模型序列快速迭代：5.1 追求更自然的语气，5.2 加速专业工作，5.3 修正「尴尬」语调，5.4 带来百万级上下文与电脑操作能力，再到 7 月的 5.6 系列（Sol、Terra、Luna）。Apple 也把 GPT-5 接进了 iOS 26、iPadOS 26 与 macOS Tahoe 26，覆盖 Siri 接管、写作工具与视觉智能。

围绕模型的软件形态也在变化。OpenAI 今年 2 月推出独立的 Codex Mac 应用作为编程智能体中枢，到 7 月，Codex 实际上成了新的 ChatGPT 桌面客户端，把 Chat、Work 与 Codex 合而为一，原生的旧客户端则改名为 ChatGPT Classic。

在 GPT-5 一周年节点上，Agent Plugins 释放出一个清晰信号：OpenAI 的竞争焦点正从「谁的模型更强」，转向「谁的智能体生态更能被复用」。当技能可以跨端流动，开发者的投入就不再被锁死在单一平台，这或许才是它真正想抢的护城河。

来源：9to5Mac、OpenAI、Agent Plugins 官网

article_id: 99d65f6ed836600d194f91e7119601d3

title_zh: Wispr 首款非听写产品：开会它替你记笔记

source: 9to5Mac

published_at: 2026-08-07

—

语音转文字工具 Wispr Flow 不再只做”把口语变成干净文字”这一件事了。8 月 5 日，该公司推出 Notetaker，这是其首款超越听写场景的产品，也是一款 AI 会议助手，直接内置在 Wispr Flow 应用左侧栏中。CEO 兼联合创始人 Tanay Kothari 表示，没人会去读会议逐字稿，但所有人都会据此行动——准确提炼关键决策与行动项，比一份冗长转写更有价值。

会前，Notetaker 会从用户的笔记和网络中汇总相关信息做简报，每一行都附上来源链接；它还会读取日历和 Slack 等已连接应用的上下文，判断这场对话到底在聊什么。会中，它提供实时转写，方便随时回看刚才说了什么。会议结束后，它会用这些额外上下文把整段录音再处理一遍，生成更准确的转写，以及摘要、决策、关键日期和行动项。用户还能就自己的全部会议历史提问，答案会链接到相关信息被讨论的那一刻；错过的片段也能一键补看。

技术路线上，Notetaker 采用端侧音频采集，而不是以”机器人”身份加入会议，因此不会在参会者名单里多出一个陌生账号。它跨 Zoom、Google Meet、Teams 和 Slack huddles 通用，并支持 MCP（模型上下文协议），可以把转写、摘要和笔记直接拉进 Claude、ChatGPT 或用户自定义的智能体与工作流。自动说话人归因对多人对谈尤其有用，而共享的自定义词典则能提升专有名词、人名和产品名的识别准确率。

平台方面，Notetaker 即日起在 Mac 上线，Windows 版本仍在开发中。Wispr 在 3 月披露，其用户基数正以每月 40% 的速度增长，语音输入走向主流的速度可能比许多人预期的更快。相比”派个机器人入会”的会议助手，端侧采集不打扰他人、跨平台通用，再加上 MCP 打通主流 AI，构成了 Notetaker 的差异化卖点。

来源：9to5Mac

Cloudflare 给出的答案叫 Cloudflare OS。8 月 5 日，这家公司宣布把它开源，任何组织都可以自行部署、接入内部系统并按需改造。

先在自家跑了三个月

今年 5 月，Cloudflare 向全体员工开放了第一个版本。据其官方博客描述，各职能部门数千人每天使用，其中很多人并非工程师——他们用它撰写文档和幻灯片、把重复性任务自动化、搭建小型应用来可视化数据。

更关键的是共享层。Cloudflare OS 为所有人提供了一个由各团队共建的上下文与技能库，把公司的术语、流程和处理常规工作的最佳做法，沉淀成智能体可以直接遵循的指令。一个人摸索出更好的做法，其他人立刻就能复用。

第一版也暴露了问题。它以个人私有工作区为中心，生成的应用是静态的，而非连接内部系统的活体软件；即便是几乎完全确定的重复任务，也得重新跑一遍智能体技能，白白消耗模型 token（模型处理文本的计费单位）。

协作环节的问题更根本。接入 MCP 服务（模型上下文协议，用于让智能体调用外部工具）只能告诉系统智能体可以调用哪些工具，却无法说明它实际读取过哪些底层资源。一旦开始共享工作区、应用和产出，就必须确保协作不会让人看到本不该看到的信息。

于是 Cloudflare 把整套系统在新底座上重建了一遍，核心判断是：安全必须是平台自带的能力，而不是每个搭应用、用智能体的人各自去正确实现一遍。

三个组成部分

新版 Cloudflare OS 由三块拼成：一个以公司自建上下文与技能为基础的智能体工作区，内置可让智能体编写并运行代码的隔离运行时；一套面向内部数据与服务的安全治理框架；以及一个支持个人搭建、共享并持续修改应用的平台。

工作区在浏览器里使用，不需要懂终端。它能做四类事：调用公司上下文与已授权资源做研究，且智能体是通过写代码去搜索、筛选、连接和分析信息，而不是把整个数据集塞进模型的上下文窗口；把研究结果转成可继续编辑的文档、演示或表格，这些产出可以与实时数据保持连接、随数据源更新，也能导出为常见格式；在文档表格不够用时，直接构建带界面、逻辑和状态的应用，供多人协同；以及把已知步骤的重复工作转成基本确定性的流程，用代码处理可预测部分，只在真正需要判断的环节调用模型，流程可按需触发、定时执行或由连接系统的事件驱动。

安全设计：智能体的默认权限是零

员工接触 AI 后最常提的诉求，往往是索要公司系统的 API 密钥。Cloudflare 的判断很明确：把密钥直接交给人和智能体既危险也无法规模化，密钥通常权限宽泛、有效期长，难以约束、难以安全共享、难以审计。

Cloudflare OS 的做法分三层。

默认无权限。 由 Cloudflare Access 控制谁能进入系统，进来之后每个智能体和应用的初始权限是零。智能体可以申请访问某个具体资源，由人决定批准或拒绝，生成的代码以类型化绑定的形式拿到该资源，凭据始终与智能体和代码完全隔离。服务端代码运行在关闭了全局出站网络的 Dynamic Worker 中，客户端代码运行在浏览器的沙箱框架内，两者除了显式授予的能力之外都无法访问互联网。

Gatekeeper 管资源和动作。 这是一个针对特定服务的 Worker，夹在 Cloudflare OS 与外部服务之间，理解该服务的接口、资源和可执行操作。官方举的例子是：把整个 GitHub 账号交给智能体范围太大，而 Gatekeeper 可以只开放单个仓库、只允许读取议题而不能读源码、屏蔽特定字段、施加速率限制，并要求合并请求前必须经人工审批。智能体看到的只是一个小巧的 TypeScript 接口，OAuth 授权、凭据保管、策略执行、读取记录和外部副作用的中介，全部由 Gatekeeper 承担。

策略跟着智能体看过的东西走。 只管住第一次读取是不够的。官方设想了这样一种场景：智能体读取数据仓库中一张敏感表，据此生成实时看板，分享看板不能变成把这张表分享给无权访问的人。为此，Cloudflare OS 记录智能体观察到的每一项资源，这些记录始终附着在智能体及其产出上。当另一个人试图打开工作区、与智能体交互或查看产出时，Gatekeeper 会核验此人对那些被观察资源的访问权限。同一套观察日志还用于判定智能体何时可以发起外部请求——读取过敏感数据，可能就会禁止它向特定目标写入、邀请新协作者、把工作移交给另一个智能体或发起外部请求。

每一个“文件”都是一个完整应用

多数生产力套件给的是固定几件套：文档、表格、演示。Cloudflare OS 的思路不同——每个“文件”都可以是一个应用，由智能体为某个人、某个项目或某个团队专门编写。

这些不是需要导出再另行部署的原型，而是自带客户端代码、服务端代码、接口和持久状态的全栈应用，默认私有，可像文档一样共享。智能体写应用时产出两部分：渲染界面的客户端代码，以及存储状态、实现逻辑的服务端代码。服务端以 Dynamic Worker 按需加载，并实例化为 Durable Object Facet（这两项能力都是为该项目专门构建的）。Facet 给每个应用一个独立的 SQLite 数据库，与管理它的运行时相互分离；Dynamic Workers 使用轻量级 V8 隔离环境，因此每个应用都能拥有独立运行时，而不必长期占用一台服务器或容器。

浏览器客户端通过 Cap’n Web 与服务端通信，这是 Cloudflare 开源的对象能力式远程过程调用系统。服务端方法可以像普通 JavaScript 函数一样从客户端调用——特别之处在于，智能体也能调用同一个方法。用官方博客的说法，只要一个人能造出工具来完成某项工作，那么在这个人不在的时候，智能体也能用同一件工具把活干完。

共享方式有两种：共享应用本身，其他人可基于同一份状态实时协作；共享应用的“蓝图”，其他人可创建属于自己的副本。从蓝图创建的应用包含原应用的代码，但不包含其 SQLite 数据、对话历史、凭据和已连接资源，每个新应用都从独立的状态和资源开始。这意味着团队成员可以自己用 AI 修改应用，而不必提工单等着原作者排期。

模型可换，花销可控

Cloudflare OS 支持任意模型，所有推理调用都经由 Cloudflare AI Gateway，组织可在同一处决定哪些模型可用、哪项工作交给哪个模型。官方给出的理由很实际：不是每项任务都需要最贵的模型——每天早上总结未读邮件，未必值得动用最昂贵的前沿模型。

每一次请求都会归属到发起它的人、团队或工作区。管理员可以看到推理支出流向，设定预算与速率限制，并决定触及上限后如何处理。

开源之后

代码已在 GitHub 的 cloudflare-os 仓库放出，可部署到自有 Cloudflare 账号，配合自家的 Access 策略、AI Gateway 配置、数据与集成。Cloudflare 一共发布两个仓库：Cloudflare OS 核心，以及一个基于其内部运行方式的示例部署；部署仓库不修改核心即可使用，用于承载配置、自定义界面、内部集成、分析和部署流水线。

值得一提的是，该项目在 GitHub 上把自己类比为一套真正的操作系统：workshop-backend 相当于内核，各类 Gatekeeper 相当于设备驱动，workshop-frontend 相当于 shell，Gadget 相当于进程，蓝图相当于可执行文件。而传统操作系统尚未管理的那一类对象，正是 AI 智能体——Cloudflare 的观点是，智能体不能简单当成用户对待，它必须对某个人类用户负责，同时拥有自己受限的权限，这种场景下更合适的安全模型是基于能力的安全，而非访问控制列表。

由于 Cloudflare Workers 的运行时 workerd 本身也是开源的，Cloudflare OS 并不局限于只能跑在 Cloudflare 上，完全可以架在自有服务器的 workerd 之上。

代码只是起点。Cloudflare 表示，其战略伙伴 Presidio 和 Happy Cog 会协助企业按自身运作方式定制并推广。后续规划包括：把 Cloudflare OS 做成 Cloudflare 控制台中的全托管产品、为开发流程增加容器支持，以及把工作区接入 Slack 等聊天工具。

来源：The Cloudflare Blog

据 Ars Technica 7 月 30 日报道，这次编号为 2026-07-28 的规范更新，把 MCP 从一个双向有状态协议，改造成了请求／响应式的无状态协议。请求不再依赖绑定在某个服务器实例上的会话，这一改动直指长期困扰 MCP 规模化部署的瓶颈。

握手和会话，一起被删掉了

在此前的 2025-11-25 版本中，客户端调用一个工具前必须先走一遍流程：发送 initialize 请求完成握手，服务器返回一个 Mcp-Session-Id，此后每次请求都要带上这个会话 ID。问题在于，这个 ID 把客户端牢牢钉死在了签发它的那个服务器实例上。要横向扩容，就得配置粘性会话（sticky session）或共享会话存储，网关还要做深度包检测才能正确路由。

新规范通过六个规范增强提案（SEP）联手拆掉了这套机制。initialize／initialized 握手被移除（SEP-2575），协议版本、客户端信息和能力声明改为随每次请求放在 _meta 字段中携带，同时新增 server/discover 方法，供客户端在需要时主动获取服务端能力。Mcp-Session-Id 头及协议层会话也一并移除（SEP-2567）。

两者取消之后，任何一个 MCP 请求都可以落到任何一个服务器实例上。一个原本需要粘性会话、共享会话存储和网关深度包检测的远程 MCP 服务，现在可以直接跑在普通的轮询负载均衡后面。

无状态协议并不意味着应用本身必须无状态。规范把一种做法正式化为”显式句柄模式”：需要跨调用保持状态的服务，可以像普通 HTTP API 那样，由某个工具返回一个明确的标识符（比如 basket_id、browser_id），再让模型在后续调用中把它当作普通参数传回来。维护者认为这不只是会话状态的替代品，往往还更好用——状态对模型可见，模型可以在不同工具之间组合、推理和传递这些句柄，而藏在传输层元数据里的会话状态做不到这一点。

服务端提问，改成”多轮往返”

无状态协议仍然需要一条通道，让服务端在处理过程中向客户端要点东西，比如弹出一个确认提示。两个提案重建了这个流程。

首先，服务端发起的请求现在只允许在服务端正在处理某个客户端请求期间发出（SEP-2260）。此前这只是推荐做法，现在成了硬性要求，用户不会再莫名其妙收到提示，每一次询问都能追溯到自己或自己的智能体发起的动作。

其次，多轮往返请求（SEP-2322）改变了提示的送达方式。服务端不再需要挂着一条 SSE 长连接，而是直接返回一个 InputRequiredResult 结果，里面带着询问内容和一段 requestState 状态串。客户端收集完答案后，带上 inputResponses 和原样回传的 requestState 重新发起调用。由于恢复所需的一切都在负载里，这次重试落到任意一个服务器实例上都能接着处理。

路由、缓存、追踪，三项运维层改进

还有三处较小的改动，让 MCP 流量更好管理。Streamable HTTP 传输现在强制要求携带 Mcp-Method 和 Mcp-Name 两个请求头（SEP-2243），负载均衡器、网关和限流组件无需解析请求体就能按操作路由；若请求头与请求体内容不一致，服务端会直接拒绝。列表与资源读取结果新增 ttlMs 和 cacheScope 字段（SEP-2549），语义参照 HTTP 的 Cache-Control，客户端由此明确知道一份 tools/list 响应能新鲜多久、是否可以跨用户共享，不必再靠一条长连接来得知列表变化。此外，W3C Trace Context 被固定在 _meta 中传播，跨 SDK 和网关的分布式追踪可直接对接 OpenTelemetry。

一条明确的弃用承诺

这次更新还带来了一项正式的弃用政策：一个特性从正式宣布弃用到真正被移除，中间至少要间隔 12 个月，只有关键安全更新属于狭窄的例外。Roots、Sampling、Logging 三项功能本次进入弃用状态，但在 2026-07-28 规范以及未来 12 个月内发布的每个版本中都继续可用。

在被删减的同时，扩展框架也从非正式约定升级为受治理的正式体系，采用反向 DNS 标识、能力协商机制和独立于核心规范的版本号。其中两个扩展值得单独一提：Tasks 为长时间运行的操作（持续集成流水线、批处理、人工审批等）定义了创建、轮询、取消、恢复的完整生命周期；MCP Apps 则允许服务端返回在沙箱 iframe 中渲染的交互式 HTML 界面，工具需提前声明 UI 模板，便于客户端预取和安全审查。

主要维护者 David Soria Parra 与 Den Delimarsky 在发布博文中写道：”这次发布的重点是无状态协议内核——MCP 正在从一个双向有状态协议，转变为请求／响应式的无状态协议。这是开发者呼声最高的特性之一，他们迫切希望自己的 MCP 服务获得更好的可靠性和可扩展性。”Soria Parra 还称，这是”远程 MCP 推出一年多以来最重要的一次更新”。

治理已经不只属于一家公司

MCP 由 Anthropic 在将近两年前推出，目前由 Linux 基金会旗下的 Agentic AI Foundation（AAIF）管理。Anthropic 对协议方向仍有相当影响力——上述两位主要维护者均在 Anthropic 任职——但 OpenAI、谷歌、微软和亚马逊也都在参与贡献，支持它的开发工具越来越多，应用范围也在从编程扩展到更广泛的知识与创意工作场景。按照规范的治理设计，最终决定权在各个维护者个人手中，而非这些公司本身。

来源：Ars Technica《New MCP specification addresses the main barrier to enterprise adoption》（作者 Samuel Axon，2026 年 7 月 30 日），https://arstechnica.com/ai/2026/07/with-a-stateless-makeover-new-mcp-spec-targets-enterprise-scale/ ；Model Context Protocol 官方博客 2026-07-28 规范说明

什么是 Gemini Spark？

Gemini Spark 被 Google 定位为“你的个人 AI 代理”（your personal agent）。与只能回答问题的传统聊天机器人不同，它可以在你的授权下主动执行复杂任务，并持续运行——即使你的电脑或手机已经关闭，因为它运行在云端。

Google 希望 Spark 把 Gemini 从“会回答问题的助手”升级为“能真正替你干活的搭档”。它可以在 Gmail、Google Docs、Sheets、Slides 等 Workspace 服务之间穿梭，也能通过第三方连接应用处理更多任务。

7月更新：Workspace 编辑、Mac 远程控制、第三方应用连接

此次向美国 Pro 用户开放的同时，Google 也公布了一系列新能力。

在 Google Workspace 方面，Spark 现在可以：编辑私人表格和演示文稿、读取表格和演示文稿中的评论、编辑共享文档、向文档和演示文稿添加图片，以及通过 Canvas 面板对文档进行精修。

对于 Mac 用户，Google 新增了远程控制功能：你可以让 Gemini 应用在你的 Mac 上执行操作，即使你在另一台设备上发起请求。

在 第三方连接应用 方面，Spark 的支持列表也在扩展。7月1日，Canva、Instacart、OpenTable 开始接入；7月7日，Dropbox 和 Zillow 加入。Google 表示，这些连接将通过 MCP（Model Context Protocol） 等机制实现，让 Spark 能够调用更多外部服务的数据和能力。

此外，Spark 的通知和来源检索也变得更智能：它会在需要输入时提供更详细的信息，并在你已经在网页端处理某个任务时避免重复发送手机通知；对于涉及多个来源的复杂任务，它可以并行检索和审核来源，提高处理速度。

付费与安全：Agent Payments Protocol 2

为了让用户放心让 AI 代理执行任务，Google 引入了 Agent Payments Protocol 2（AP2）。用户可以设置代理的消费上限、允许购买的商品类别以及可使用的商家，并生成交易记录，方便应对退货或订单问题。

在订阅层级上，Google AI Ultra 提供每月 100美元 和 200美元 两档，主要面向开发者、技术负责人和高级创作者；Google AI Pro 则位于更低的订阅档位。Google 还表示，正在把 Gemini 应用从“每日提示次数限制”转向“按计算量计费”的模式，即根据提示复杂度、使用功能和对话长度综合计算消耗。

它和其他 AI 助手有什么不同？

与市面上多数需要用户持续在线的 AI 工具相比，Gemini Spark 的核心卖点是“云端持续运行”。它可以在后台替你跟进多步骤任务，比如持续监控旅行价格、整理项目资料或跨应用更新日程。Google 还预告，今年晚些时候将推出名为 Android Halo 的新界面，用于直观展示代理的任务进度。

不过，这些能力也带来现实问题：用户需要把大量个人和工作数据授权给云端代理，隐私边界、错误执行和安全风险仍然是未来需要重点观察的维度。随着 Spark 向美国 Pro 用户开放，更多普通用户将有机会亲自测试这款 AI 代理的实际表现。

发现企业AI使用的”盲区”

Traceforce由Xia和Varun联合创立。Xia此前曾担任云备份初创公司Clumio的工程总监（该公司于2024年10月被Commvault收购）。在Clumio的经历让她深刻体会到，在鼓励员工使用AI工具提升效率的同时，确保安全团队对这些工具有足够的可见性和控制力，是一项极其困难但又至关重要的任务。

在访谈了50多位首席信息安全官（CISO）和首席信息官（CIO）之后，创始团队确认这是一个跨行业的普遍痛点：AI新功能的采用速度如此之快、范围如此之广，企业的可见性和控制能力根本跟不上。

传统安全工具在这一新兴领域显得力不从心。EDR（端点检测与响应）系统能看到进程，CASB（云访问安全代理）能看到网络流量，但两者都无法洞察AI应用内部发生的应用级活动——比如一个AI助手通过MCP（模型上下文协议）连接到了哪些内部数据库，或者一个AI编码工具是否正在将敏感API密钥嵌入到生成的代码中。

Traceforce如何工作

Traceforce的部署方式非常轻量：在每个需要监控的设备上安装一个二进制文件和浏览器扩展，30分钟内即可开始上传实时数据。安全团队可以在一个统一的仪表板上查看全公司所有设备上运行的AI应用和Agent，并实时监控它们的活动、实施控制策略，以及在安全风险出现时第一时间收到告警。

Traceforce的核心能力不仅在于发现设备上安装了哪些AI应用，更在于构建这些应用与外部数据源之间的完整连接图谱。当一个AI助手通过MCP连接到公司的数据库、代码仓库或第三方SaaS工具时，Traceforce能够识别出这些连接路径，并评估其中存在的漏洞和攻击面。

为了帮助企业识别MCP相关的安全风险，Traceforce还开源了一款动态MCP渗透测试工具——mcp-xray，用于检测存在漏洞的MCP配置。

在数据收集方面，Traceforce默认仅收集AI应用、MCP和工具的元数据与遥测信息。安全团队可以选择启用内容检查功能，用于检测、告警或阻止预定义的高风险或潜在破坏性操作。所有内容检查均在设备本地完成，用户提示词不会被存储，除非组织的安全管理员明确配置。

实际落地效果

截至目前，Traceforce已在10家组织的超过1000台设备上部署。数据显示，平均每台设备上运行着超过15个AI应用，每个应用又连接着5到10个MCP。这一数字直观地说明了企业AI使用规模的爆炸性增长，以及缺乏有效监控所带来的潜在风险。

Traceforce已帮助客户发现了多项真实安全问题，包括：MCP配置中暴露的明文密钥、通过AI生成代码泄露的API密钥，以及在执行”DROP TABLE”等潜在破坏性命令前向开发者发出警告。其”警告并确认”（warn and acknowledge）的方式尤其受到开发团队的欢迎——既给予了开发人员充分的工作自由，又帮助他们避免代价高昂的操作失误。

市场前景与竞争定位

Traceforce目前主要面向快速采用AI编码助手、ChatGPT、Claude和MCP的中小型企业（200名以上员工）。公司的目标是与安全、IT和AI平台团队合作，帮助它们在不拖慢员工效率的前提下，实际降低与AI相关的安全风险。

Traceforce的技术栈也值得一提：核心二进制文件使用Go语言构建，浏览器扩展则采用Node.js开发。创始人坦言，最具挑战性的部分在于为每个AI应用理解其配置和日志——这是一个劳动密集型的过程，因为每个应用都不同，且AI功能更新频繁。

随着AI工具在企业中的渗透率持续攀升，AI安全监控正在从一个”可有可无”的选项变成”必须有”的基础设施。Traceforce的出现，标志着企业安全边界正在从传统的网络和端点，扩展到AI应用和Agent这一全新维度。对于任何一家希望拥抱AI生产力革命、同时不愿以牺牲安全为代价的企业来说，这种 visibility（可见性）或许正是它们最迫切需要的。