模型公司还在争谁更聪明，开发者已经开始争另一件东西。谁来决定智能体能做什么？

过去一周，几条看起来很分散的产品消息同时出现。Agent Plugins 发布 1.0.0 规范，Google 宣布参与维护；Cloudflare 推出为智能体设计的浏览器 Kitesurf；LangChain 把 Managed Deep Agents 推进公开测试；Google Cloud 又给 API Gateway 增加了多模型路由。

把它们放在一起看，会出现一条比模型跑分更清楚的产业线索。

Agent 正在形成自己的软件栈。模型负责判断，插件提供能力，运行时维持状态，浏览器接触外部世界，网关选择模型并控制成本。谁能把这几层连接起来，谁就有机会成为智能体时代的入口。

「新的 App Store」是一个方便的比喻，但目前还只能说到这里。商店尚未成形，货架、包装、权限和收银台已经有人开始搭了。

插件第一次有了统一包装箱

Agent Plugins 1.0.0 规范定义了一种可移植的插件包。一个插件以目录为单位，根目录包含 plugin.json，里面可以携带 Skill，也可以配置 MCP 服务器。开发者可以把说明、工具和运行配置放进同一个包里，让不同智能体客户端按约定发现和加载。

这项变化解决的是一个很朴素的问题。

过去，同一项能力要接入 Claude Code、Codex、Gemini CLI 或其他智能体，开发者往往需要维护多套目录、清单和安装说明。模型可以互换，插件却被不同客户端的包装方式锁住。统一格式希望把这层重复劳动拿掉。

不过，1.0.0 目前仍标明为 Working Draft。它是一份正在形成的规范，距离所有平台稳定实现还有很长一段路。

规范本身也写出了重要边界。它要求插件声明文件和组件路径留在插件根目录内，却明确说明这种路径约束不等于沙箱，不能阻止插件子进程访问运行时允许的其他位置。规范没有提供统一 OAuth 配置，也不把凭据存储问题交给插件包解决。

包装格式已经统一，保险柜仍由各客户端各自建设。

Google 参与维护并在自己的智能体工具中支持这种格式，说明大公司愿意推动插件跨客户端移动。采用速度仍取决于兼容性、安全审查和分发机制能不能跟上。

浏览器正在从人的窗口变成 Agent 的执行器

插件给智能体增加工具，浏览器则把工具连接到网页世界。

Cloudflare 这一周发布的 Kitesurf，被定义为「agent-first browser」。它运行在 Cloudflare Workers 的 V8 isolates 中，优先服务需要读取页面、执行脚本和完成网页任务的智能体，视觉点击界面退到了次要位置。

传统浏览器先为人渲染视觉界面，再让自动化工具模拟点击。Agent-first browser 倒过来设计，优先考虑可编程访问、隔离执行、并发和靠近云端数据的位置。

这个方向会让智能体完成任务更容易，也会把浏览器变成新的权限边界。一个 Agent 能打开网页、登录账号、下载文件、提交表单，它得到的就不再是一项「浏览」能力，而是一组可以影响现实账户的动作。

浏览器平台因此掌握三种重要权力。它可以决定哪些网络请求允许发出，哪些凭据可以注入，哪些动作需要留下审计记录。模型提供了行动计划，浏览器决定计划能走到哪一步。

这与手机操作系统管理相机、通讯录和定位权限很相似。差别在于，手机应用的权限通常由开发者预先声明，智能体的动作可能在任务过程中动态生成。一次「帮我订行程」会临时展开成搜索、登录、读取邮件、比较价格和付款，多出来的每一步都需要新的边界判断。

托管运行时开始接管 Agent 的一生

单次模型调用很短。能够持续工作的 Agent 往往要运行几分钟、几小时，甚至隔天继续。它需要记住任务状态，在失败后恢复，使用文件和工具，把高风险动作交给人确认，并让开发者知道中间发生了什么。

LangChain 的 Managed Deep Agents 正在把这些能力做成托管服务。公开信息列出的组件包括持久执行、记忆、沙箱、检查点、评测和生产可见性。团队不必为每个 Agent 重建一套服务器，就能把本地原型放进一个持续运行的环境。

这会明显降低开发门槛，也会制造平台黏性。

Agent 的价值不只存在于一段提示词里。运行记录、长期记忆、工具配置、评测集、恢复点和权限策略会逐步积累。一旦这些资产全部进入某个托管平台，换模型可能只需要改一个名字，换运行时却可能要迁走整套工作历史。

所以，Agent 时代的锁定未必发生在模型层。模型越来越多，API 越来越兼容，任务状态和执行治理反倒更难搬。

商店还掌握货架之外的规则

App Store 的力量并不来自它存放了很多应用。它控制分发入口、身份、权限、支付、审核和更新。Agent 插件生态如果继续成熟，也会遇到同一组问题。

一套成熟的分发系统必须说明插件由谁审核，某项 Skill 会调用哪些外部服务，权限扩大后是否需要用户重新同意。它还要处理收费、平台分成和事故责任。恶意插件一旦造成损失，作者、商店、模型公司与运行平台之间需要有清楚的责任边界。

现有规范还没有回答全部问题，这恰好说明竞争才刚开始。

开放标准的支持者会说，可移植格式能避免一家平台垄断分发。这个判断有道理。只要插件目录可以被不同客户端加载，开发者就不必为每个入口重新开发。

平台方也有一条同样有力的理由。Agent 能接触文件、代码、邮箱和支付工具，完全开放的安装机制会放大供应链攻击。安全审核、签名、权限提示和快速下架都需要中心化基础设施。

分歧最终会落到一项更具体的设计上。平台能否提供足够安全的默认设置，同时允许用户把插件、数据和运行记录带走？

下一场模型战争，可能由模型之外的层决定

Google Cloud 的多模型路由也在这一周进入公开预览。应用可以通过统一入口，把请求转给 Gemini、Claude 或其他兼容模型。模型选择由网关处理，产品代码不必绑定单一提供商。

模型越容易切换，插件和运行时越重要。开发者会把模型当作可替换的算力，把长期价值放在工具、上下文、评测和业务连接上。

这并不意味着模型失去护城河。能力、价格、速度和安全水平仍会直接影响 Agent 的上限。变化在于，最强模型不一定自动拥有最大的生态。能让插件被发现、被信任、获得正确权限并稳定完成任务的平台，可能掌握更靠近用户的一层。

接下来判断一个 Agent 平台，我会少看几张演示视频，多看四件事。插件能否跨客户端移动，权限能否被看懂和撤销，任务状态能否导出，高风险动作有没有可靠的确认与审计。

一个平台允许你安装多少插件，说明它的货架有多长。

你能不能看清每个插件拿走了什么，又能不能把自己的数据和工作流带走，才决定这家商店最终属于谁。

参考资料

/ 作者，钟懿