把 AI 的「工作说明书」交出去：一天之内，四家公司把智能体的地基交给了同一个基金会

大多数企业采购软件时不看标准，看功能。但真正决定「能不能换供应商」的，往往是那些看不见的约定：数据能不能导出、接口是不是通用、流程定义存在谁的格式里。

AI 智能体把这个问题放大了。一个智能体要干活，需要三样东西：知道怎么干、能跟模型和工具说上话、有地方安全地跑。这三样过去各家用各家的，迁一次等于重做一次，投入越大越不敢动。

10 月 22 日，Linux 基金会旗下的 Agentic AI Foundation 一次性接收了四个项目，正好覆盖这三层：Anthropic 的 Agent Skills、OpenAI 的 Open Responses、Hugging Face 的 OpenEnv、阿里的 OpenSandbox。

同一天，这个基金会的托管项目从成立时的 3 个增加到 10 个，会员组织达到 305 家。这个数字比任何一场发布会都更能说明问题：智能体的竞争，已经从「谁的模型强」转向「谁定规矩」。

对不写代码的企业来说，这件事看着很远，实际很近。你买的每一套带 AI 的软件，背后都在用某一种技能格式、某一种接口、某一种沙箱。标准定在哪里，决定了三年后你能不能换掉它，以及换掉时要付多少钱。

Agent Skills 的形态朴素得有点意外：一个文件夹，里面一个 SKILL.md，写清楚这个任务该怎么做；需要的话再带脚本、模板和参考资料。智能体遇到对应任务时按需加载，不用每次都从头交代。

它解决的问题很具体。通用模型懂很多常识，但不懂你家公司的报销细则、审稿口径、报价规则。这些「程序性知识」过去靠提示词硬塞：塞多了上下文爆炸，塞少了又不准，换个模型还得重写一遍。

把流程写成技能文件，等于给智能体发了一本岗位手册。手册可以版本化、可以评审、可以复用——这正是它比提示词更接近「企业资产」的地方。

也正因为它像资产，归属问题才重要。技能写在谁的格式里、放在谁的平台上、换一个智能体还能不能用，这些在试点阶段没人问，规模化之后每一个都是成本。

一个具体的差别：提示词改错了，最多这一次回答不好；技能写错了，会被反复加载、反复执行，错得很稳定。所以技能一旦进入生产，就必须有校对与回滚，不能像改聊天记录那样随手改。

表面看，捐出标准是让利：名称、标志、GitHub 组织、域名全部交出去，连维护者都以个人身份参与。但标准这件事有个规律——只有中立，才会被广泛采用；只有被广泛采用，自己的产品才不会变成孤岛。

Anthropic 此前已经把 MCP 捐给同一个基金会，这次是第二个。OpenAI 把 Open Responses 交出来，等于承认「接口统一」比「我的接口独家」更有利；阿里把 OpenSandbox 交出来，是在执行环境这一层换取互认。

这是一种典型的「基础设施换生态」策略。标准归公，产品归己：谁都能实现，但谁实现得好、跟自己的模型配合得顺，仍然是竞争力。

对使用方来说，这个动作的实际意义是降低了「押错」的概率。标准中立，意味着将来换供应商时，至少技能和接口不用推倒重来——这在过去是谈判桌上最难拿到的东西。

当然，中立也有代价。标准要照顾多家实现，推进速度一定比单一公司慢；提案流程、版本发布、兼容性讨论，每一项都会拖时间。企业要接受一个现实：标准化的东西往往不是最强的，但它最不容易把你困住。

对中小企业来说，这套逻辑有个直接推论：不必急着站队。标准中立之后，等一等反而更安全——先看哪家的实现真的稳定，再决定把流程放上去，比一开始就全部押注要划算。

Agent Skills 管「怎么干」。它把流程、脚本、模板打包，让智能体按说明书执行，而不是靠临场发挥。对业务来说，这决定了输出稳不稳定。

Open Responses 管「怎么说话」。不同厂商的接口格式、流式输出、工具调用各有各的写法，换模型就要改一轮代码。统一规范的目标，是让切换成本降到只改配置。

OpenEnv 管「在哪练」。强化学习需要环境，环境要可复现、可共享。把训练环境做成公共品，等于让「练手的地方」不必每家自己搭一遍。

OpenSandbox 管「在哪跑」。让智能体执行代码、操作文件，必须有隔离的沙箱；沙箱做得靠不靠得住，直接决定企业敢不敢把权限放出去。

把这四块放在一起看，会发现它们分别对应四个「谁来负责」的问题：技能回答「按谁的规矩干」，接口回答「跟谁都能接上」，环境回答「在哪儿练坏不心疼」，沙箱回答「跑坏了关得住吗」。企业评估任何一套智能体方案，都可以拿这四问过一遍。

Anthropic 披露，自 2025 年 12 月标准发布以来，70 多个智能体平台完成集成，包括 ChatGPT、Cursor、GitHub Copilot 与 VS Code；公开技能约 100 万份，累计安装接近 2.8 亿次。

这些数字是厂商自述，没有独立审计，也没有说明「安装」怎么计数——是拉取一次算一次，还是装进某个平台算一次，差别很大。引用时最好把口径一起带上，别把它当成行业统计。

但即便打折看，70 多个平台的集成面也足够说明问题：技能已经不只是某一家产品的功能，而是跨平台流通的格式。格式一旦流通，就会反过来约束产品设计——不支持它的产品，会被用户嫌弃「搬不过去」。

另一个问号是质量。100 万份技能里，必然混着大量一次性、未经验证、甚至带风险的说明书。路线图里专门有一条「给编写和安装技能的人提供安全指引」，说明这件事已经被当成问题看待。

这一点值得企业警惕：技能本质上是「可执行的说明书」，里面可能带脚本。装一个来路不明的技能，和从网上下载一个来路不明的安装包，风险结构是相似的。区别在于，前者往往被当成「配置一下」，没人走安全评审。

过去两年，企业在 AI 上最容易被套牢的不是模型，而是「调教成果」：一堆提示词、一堆工作流配置、一堆微调数据，全都长在某个平台的格式里。换平台，等于把经验清零。

技能以文件夹形式存在，意味着它可以进 Git、可以走评审、可以随代码一起交付。这对交付型企业的意义尤其大：给客户做的智能体，技能库可以作为交付物留下，而不是一堆截图和口头说明。

接口统一则是另一层保险。这类规范如果真被广泛实现，未来换模型的动作会从「改代码」变成「换端点」，多模型比价才真正可行——否则每次比价都要先算一遍改造成本。

环境与沙箱的公共化，降低的是试错门槛。过去要验证一个智能体能不能干某件事，得先搭一套隔离环境；现在可以先用公共环境跑，跑通了再搬到自己的机房。

这三层合起来，改变的是「试一次的成本」。试错便宜，企业才愿意多试；多试，才可能撞上真正适合自己的场景。过去 AI 项目难落地，很大一部分原因不是模型不行，而是每次试错都要立项、采购、搭环境。

第一，指定归属。每个技能必须有负责人和有效期。技能写的是流程，流程会变；没人维护的技能比没有技能更危险，因为它会让智能体按旧规矩办事，而且错得很稳定。

第二，做分级。哪些技能只是查询（低风险），哪些会写数据、发消息、动钱（高风险），要分开存放、分开授权。全放一个仓库、一套权限，等于把风险拉平到最高那一档。

第三，留痕。技能被谁加载、在哪个任务里用过、产生了什么结果，要能查。这一点和权限系统是同一件事：不是不信任 AI，而是出了事要能说清楚。

如果企业已经有知识库或文档管理系统，技能库不必另起一套。把技能当成一类特殊文档：有模板、有评审、有版本、有权限，复用的正是现有的治理能力，成本也最低。

一个常被忽略的细节是「退役」。流程改了、系统换了、口径调整了，旧技能必须能下线，而且要能查出哪些任务还在引用它。做不到这一点，技能库会以每年几十个的速度长成一片废墟，最后谁也不敢动。

标准刚中立，最容易出现的动作是「先建个平台」。但对多数中小企业来说，一开始就做中台，结果通常是做一个没人用的目录——技能没几个，评审流程倒有七步。

更务实的路径是反过来的：先挑三个高频、标准明确的流程，写成技能，跑一个月，看它到底省了谁的时间。跑得通，再考虑第二个部门；跑不通，损失也就是几个文档的工作量。

判断标准也很朴素：这个流程有没有明确的输入和验收？有没有人愿意为结果负责？两个都答「有」，才值得写成技能。答不上来的，多半是流程本身还没理顺。

标准的意义，最终要落到「换得起」这三个字上。技能能搬走、接口能替换、环境能复用，企业在谈判桌上才有位置。至于用哪家的模型，反倒是最后一步才需要决定的事。

再往前看一步：当技能、接口、环境都标准化之后，差异会集中到两处——数据质量与流程理解。这两样谁也拿不走，也谁的模型都替代不了。把精力放在这里，比追每一个新模型划算得多。