夜雨聆风过去一年，做 AI 产品的人很容易被模型新闻牵着走。
今天某个模型更快，明天某个模型更便宜，后天又有人发了一个能自动写代码、查数据、做表格的 Agent。每次看起来都像新机会，但真正做产品时，团队很快会遇到另一个更现实的问题：
你的能力怎么被不同 AI 工具稳定发现、安装、调用和更新？
2026 年 8 月 7 日这期 AIHOT 日报里，最值得中文开发者和 AI 创业团队关注的，不是单个模型分数，而是 Google Developers Blog 提到的 Agent Plugins 1.0.0。
它不是一个新的大模型，也不是一个新聊天应用。它做的事更基础：把 Agent Skills 和 MCP server 打包成一个可移植的插件目录，用统一的 plugin.json 和固定目录结构，让同一套能力更容易在不同 AI 编程工具、IDE 和 Agent 客户端之间流动。
这件事短期看像工程格式，长期看是分发入口。
AI 工具的混乱，先发生在包装层
很多团队已经开始写 MCP server，也开始给内部 Agent 写 Skills。问题是，单个能力可复用，不代表整套产品可分发。
比如你做了一个“销售周报助手”。它需要一个说明文档告诉 Agent 怎么写周报，还需要一个 MCP server 去查 CRM 和报表库。能力本身没有问题，但一旦你想支持多个客户端，就会出现一堆重复劳动：
最后团队会维护好几份几乎一样的包。文档复制一份，配置复制一份，脚本复制一份。刚开始还能忍，版本一多就会漂移：A 客户端修了参数，B 客户端忘了改；A 平台支持新工具，C 平台还是老说明。
Agent Plugins 1.0.0 要解决的就是这层问题。
它的判断很克制：插件就是一个目录。目录里放 plugin.json，Skills 放在固定位置，MCP server 也按固定位置声明。客户端有自己专属能力时，可以放进反向域名命名的扩展目录；不认识这部分的客户端可以忽略它，不影响可移植的核心能力。
这不是“又一个标准”，而是渠道开始合并
标准最怕没人用。但这次值得看，是因为参与方和使用场景都比较关键。
AIHOT 摘要里提到，Agent Plugins 1.0.0 得到 Google、Amazon、Microsoft 等支持。Google 官方文章进一步说明，这个规格由 Amazon、Cursor、Microsoft、OpenAI、Vercel 的核心维护者发布，Google 也以核心维护者身份加入，并开始把支持接入自己的产品。
更具体的是两个产品：
这对创业团队的启发很直接。
如果你做的是一个单独 MCP server，只服务一个客户端，继续用 MCP 就够了。如果你只写了一个单独 Skill，也没必要马上封装成插件。
但如果你的产品能力天然由多块组成，比如“行业知识 + 工具调用 + 数据连接 + 工作流模板”，而且你希望它能进入多个 AI 客户端，那么插件格式就开始有意义了。
因为未来的竞争可能不是“用户打开你的官网”，而是“用户在自己的 AI 工作台里搜索某个任务，你的能力能不能被发现”。
开发者产品会从功能收费，走向任务分发
Cursor Router 的文章提供了另一个信号：AI 工具正在变得更像动态系统，而不是固定聊天框。
Cursor 说，它的路由系统会根据当前轮次、最近对话状态、工具调用和任务类别来选择模型。Auto Intelligence 在用户满意度超过 Fable 的情况下，成本低 68%；Auto Balance 在表现超过 Opus 4.8 的情况下，成本低 41%。
这组数据不只是 Cursor 的模型调度成绩，也说明一件事：AI 产品的成本和体验，越来越依赖“任务理解”。
当客户端能判断任务复杂度、能选择模型、能调度工具，也就自然会需要更多结构化能力包：
对 AI 创业团队来说，这里有一个重要变化：你不一定要拥有最终入口，才有分发机会。
如果你的插件能解决一个明确任务，例如“把电商客服工单和退款政策变成可审计回复”“把数据库查询结果变成老板能看的周报”“把代码仓库和监控日志连起来定位线上问题”，它就有机会进入多个 Agent 客户端，而不只是自己做一个独立应用。
但别误会：Agent Plugins 还不是安全和分发市场
Google 官方文章也把边界说得很清楚：Agent Plugins v1 是包格式，不定义安装机制、分发协议、权限模型、沙箱要求、信任来源验证和用户体验。
这句话很重要。
它意味着今天还不能把 Agent Plugins 理解成“插件商店已经成熟”。它更像一个底层约定：先让能力可以被同一种方式打包，再让不同客户端和市场围绕它继续长出安装、审核、权限、计费和推荐机制。
创业团队如果现在就跟进，重点不是追概念，而是做三件实际工作：
1. 把自己的 Agent 能力拆成可复用组件：说明、工具、配置、样例、权限需求。 2. 记录每个组件的适用任务：它解决什么问题，不解决什么问题，需要哪些输入。 3. 从一开始就设计版本、审计和回滚：插件一旦进入别人工作流，出错成本比网页应用更高。
尤其是企业客户场景，插件不是“装上就能用”。客户会关心它访问哪些系统、能读什么数据、能不能写入、日志在哪里、出错后谁负责。
中文团队的机会在垂直场景，不在再造一个通用 Agent
这次 Agent Plugins 的意义，不是让每个团队都去做一个大而全的 Agent 平台。
相反，它更可能给垂直能力团队创造机会。
中国市场有很多复杂业务场景：跨境电商、直播投放、本地生活、制造排产、教育教研、财税合规、客服质检、销售跟进。它们共同的问题不是“缺一个聊天框”，而是缺一套能被 Agent 稳定调用的业务能力包。
一个好的插件，不应该只告诉模型“你是一个专家”。它应该把业务对象、工具边界、失败处理、输出格式和审核要求都放进去。
这才是创业团队可以做深的地方。
模型会继续变化，客户端也会继续变化。但如果能力分发开始标准化，真正值钱的部分会逐渐从“谁包了一层模型 API”，转向“谁能把一个真实业务任务封装成可迁移、可审核、可持续更新的能力”。
今天看 Agent Plugins 1.0.0，不需要急着喊“新生态来了”。更务实的判断是：
AI Agent 的下一段竞争，不只是谁的模型更强，而是谁的能力更容易被带到用户已经在用的工作流里。
对开发者来说，现在可以开始整理自己的 Skills 和 MCP server。对产品人来说，现在要重新思考分发：未来用户可能不是在应用商店搜索你，而是在 Agent 里交代一个任务，然后由客户端帮他找到最合适的能力包。