--- layout: post.njk source: https://yage.ai/share/ai-native-rent-buy-build-20261026.html web_feed: articleId: cmvpvwsw20001ed7dq6z18tjz feedSourceId: webfeed_yage_ai guid: https://yage.ai/share/ai-native-rent-buy-build-20261026.html sourceUrl: https://yage.ai/share/ai-native-rent-buy-build-20261026.html speaker: yage.ai title: |- AI 原生组织，到底靠买还是靠建：通用层、行业层、自有层的商业取舍 date: '2026-10-26' summary: 文章探讨了在构建AI原生组织时，商业取舍的决策逻辑，即如何将业务能力拆分为通用层、行业层和自有层，并决定每层是“用、买还是建”。核心观点是，不应在默认开关和从零自建之间二选一，而应先拆分能力，再逐层决定拿法。行业层倾向于购买包含行业规则和组装指南的“生成内核”，而自有层则专注于编写大模型无法自由发挥的商业判断函数和适配旧系统的安全护栏。最终建议采取“先内后外、先可逆后不可逆”的排期策略，对外用通用层免费开关卡位，对内先用行业层试点，再用自有层打补丁护栏，以稳健推进。 area: tech-engineering category: architecture tags: - ai-application - software-development - architecture - tech-trends - deployment people: [] companies_orgs: - Cloudflare - Shopify - Stripe - Vercel products_models: - Claude Code hooks/skills/MCP - WebMCP - Abilities API - Site MCP - ACP media_books: [] draft: true status: evergreen --- ## 一个公司的 FOMO 周五下午，老板在公司群里发了一个新闻，十万店铺域名一键接入AI agent，说有一个平台给近十万个店铺的域名默认打开了浏览器中的agent工具调用，只要商户不手动关闭，agent就可以直接调用网站的功能。在前一篇文章里，已经拆过背后的机制：平台不用改动商家原有代码，就能把工具装进十万个店铺页面。老板在群里点名了技术负责人和产品经理，问公司业务什么时候能做成 AI 原生。对老板来说，做不做 AI 原生首先是一笔获客账：当年客户找服务的入口从搜索转向应用商店，现在又开始转向对话界面和浏览器中的agent，每次入口迁移都需要重新计算获客成本。老板担心竞争对手率先在新入口接单，而自家的服务在外部agent面前隐形。被点名的技术负责人和管理层心里也发紧，不做怕落后于同行，动手又不知道该往哪一层投预算。眼看着周一要开例会拍板，大家的本能反应都是先做点看得见的东西探探路。 为了尽快看到效果，工程师花半天时间打开了平台自带的公开接口。团队用测试 agent 读出官网公开的产品目录、门店地址和常见问题，录了段演示视频发进周会群，看着像做成了 AI 原生。但平台默认开关本来就只能读公开页面、搜关键词，真实业务背后却连着内部旧系统的接口限制、不同角色的权限边界、合规审批和状态修改。这套演示放到日常业务里马上就走不通：老客户查带阶梯返点的年度合同价、改已进分拣的订单地址，或者核验某项服务的行业准入资质，全得连回内部系统和审批流，外部 agent 拿不到权限和接口，当场就会卡住。光在后台勾一个默认开关，根本解决不了这些问题。 撞墙之后，团队很容易滑向另一个极端。技术负责人和架构师起草了年度架构立项书，准备自研多协议转换层、跨站 agent 身份认证和密钥交换机制，再搭一套多轮对话状态底座。公司本来就人手少，背后又是一堆难动的老旧系统。几个主力工程师从日常需求里抽身，埋头干了大半年，研发经费花了不少。底层协议和对话状态刚跑通，还没接进两个真实业务流程，第二年云厂商和建站平台就把这些通用能力做成了所有商户免费使用的标配。大半年的心血转眼变成无人维护的重复基建，真正卡住业务的内部审批和旧系统接口还是没动。 把这两次折腾放在一起看，管理层和技术负责人就会发现，原来不用在默认开关和从零自建中间二选一，两条弯路之外还有第三条路：买一套带行业规则和组装指南的行业组件，让 AI 把它组装成自家的业务流程。以前需求刚来就争论买还是建，往往是因为还没拆清要改的是哪一层业务，就想用一套方案包打天下。要想拍板公司怎么走向 AI 原生，老板和技术负责人得先把业务能力拆成通用层、行业层、自有层，每层再决定用、买、建。理顺这个先后顺序，周一例会上的讨论就不再是互相催进度，而是先把需求按三层拆开、逐层挑定拿法，排出一份算得清投入产出的工期表。 ## 为什么买与建不够用了：软件商交付的东西变了 接到agent接入的需求之后，管理层和技术团队经常陷入一个陷阱，就是一上来先吵买还是建。过去这套二分法好用，是因为以前讨论的是一整套边界清楚的软件系统，要么买现成的系统，要么招人从头写。但要把业务接进agent，一个需求里同时混着三层完全不同的东西：最外面是平台免费送的公开接口，中间是同行都要用的行业流程，最里面是自家老系统的权限和风控。这三样东西搅在一起，上来就问整套东西该买还是该建，自然吵不出结果。只有先把这三层拆开，才能分别决定每一层是用、是买，还是建。 之所以不能再用老眼光看外部采购，是因为软件商交付的东西这几年发生了变化。以前企业采购的是流程写死的成品系统或者静态开发包，怎么调接口、怎么拼成业务全靠买方工程师自己写。到了 2026 年，Cloudflare、Shopify、Stripe 和 Vercel 等厂商开始交付一种新形态：除了底层接口和行业规则，还附带专门写给 AI 看的操作指导和配套工具，让买方的 AI 直接按自家需求把业务流程组装出来。Vercel 用技能包把可安装能力和指引打包分发，让工程经验随包复用；Shopify 的 AI Toolkit 让 skills 覆盖 GraphQL Admin API、Functions、Polaris、Liquid、Hydrogen 和 CLI，让 agent 按任务读取指导；Stripe 也推出配套插件来统一配置协议和技能。 目前行业内并没有一个统一的术语来描述这种新的交付方式。2025年的《超越DRY：AI原生软件工程的思考》曾用宜家的家具做了一个类比。以前，软件厂商交付的是功能固定的成品椅子，用户开箱就能用，但不能自己调整高度和颜色。现在，软件厂商交付的更像是宜家的家具套件，里面有一些用户自己做不出来的核心部件，以及一份写给组装机器人的详细说明书，同时提供一个内六角螺丝刀让机器人能更快更准地拧螺丝。那篇文章将这种组合称为生成内核，包括三部分：核心套件（外人替代不了的底层接口和行业规则）、引导知识（专门写给AI的组装指南和避坑说明）和杠杆工具（把AI概念上理解但写代码容易出错的步骤封装成确定性工具）。去年写那篇长文的时候，这套框架还是从个人开发经验里总结出来的理论推导，没想到不到一年，上面这几家大厂的产品就都长成这样了。下面说的生成内核就是指行业层供应商交付的这种组合包，不是把三层全部换个新名字。 要想看懂这套宜家套件在企业里怎么落地，得先分清 AI 参与业务的两种完全不同的方向：第一种是由 agent 主导业务运行，在接待客户或处理工单的现场动态调用 MCP 工具；第二种是由 AI 主导软件构建，AI 在开发阶段先读完厂商的文档与技能包、把代码写好，但最终跑在线上的仍然是一套确定性的传统软件系统，由这套静态系统去调用底层接口。这两种方向完全不同。Cloudflare Code Mode、Shopify Dev MCP 和 Stripe Agent Skills 走的都是后一种路径，本质上是在构建系统的过程中用 AI 大幅提效。前者把整个云端接口收拢到 search() 和 execute() 两个入口暴露出来，让模型直接写代码调用；Shopify 的开发通道支持按任务读取上述指导来构建应用；Stripe 的技能包也给编程 agent 提供构建支付集成的最新指导，让它先读懂规则再写出调用代码。 这种上游交付形态的改变，直接重划了买与建的边界。过去企业买外部 SDK 做二次开发之所以算作自建，是因为 SDK 只是半成品原料，怎么调接口、避开边界陷阱、把模块拼成完整业务的组装知识，全装在买方工程师脑子里。现在供应商把核心能力、行业规则、组装知识和工具一起交付，具体代码的组装交给 AI 完成，买方团队只需提供业务意图、内部上下文、私有数据并接好最后一公里。原本算作自建的买 SDK 二次开发，现在也就顺理成章变成了购买行业生成内核。 边界移动之后，技术决策就从原本单一的买或建，拆成了前后两步判断：第一步先看能力归属，分成通用层、行业层、自有层；第二步再看每层怎么拿到手，分成用、买、建。通用层一般直接用，行业层一般买，自有层一般建，但典型的获得方式并不等于层的定义，同一层的能力完全可以用、可以买、也可以自建。其中的通用层也不是新增，以前它一直藏在买平台这个动作里随着底座交付，现在团队单独看见了它，只是因为面向 agent 的标准入口显露了出来。 看到这里可能会有人好奇，为什么像 Shopify、Stripe 这样的公司，既出现在行业层的例子里，后面讲通用层时又会提到它们？其实通用层和行业层并不按厂商名字死板切分，关键看企业跟它处在哪种合作关系里。比如一家商家把网店开在 Shopify 上，自己是底座上的租户，随网店底座免费附带的公开搜索和加购接口就属于通用层；反过来，如果技术团队以客户身份使用 Shopify 的开发套件去写一套定制应用，或者向专业软件商单独采购一套行业组件，这就成了单独采购的供应商关系，拿到的开发套件就属于行业层。同一家厂商面对不同位置的买方，扮演的角色也不一样。 对比维度 通用层 行业层 自有层 谁拥有 平台（随租约附带） 行业供应商（单独采购） 企业自己 领域知识在哪 平台通用层 供应商的行业内核，含怎么建的知识和工具 企业私有的数据、判断和旧系统知识 谁担最终责任 平台只担基础设施 供应商只担软件缺陷 企业担业务后果 典型交付物 开关 生成内核（核心 + 知识 + 工具） 判断 + 旧系统补丁 典型获得方式 用 买 建 这个表只是典型情形，并不锁定每一层的拿法。层和获得方式是两件事，同一层可以用、买、建。下次立项排期前，先拿通用、行业、自有三层理清能力归属与责任边界，再逐层决定用、买、建。 通用层、行业层、自有层与用、买、建对照：通用层用平台开关，行业层买生成内核，自有层建业务判断与旧系统补丁 ## 通用层，平台已经替你铺好的那一层 前面定下了先分通用层、行业层、自有层，再决定用、买、建的原则。但是真开起项目立项排期会，管理层和技术负责人往往不会争论原则本身，而更多地会在一个具体的需求属于哪一层面，要不要批预算上产生分歧。接下来的三章，就顺着外部请求进入公司的路径，从最外面的通用层往里逐层算账。外部 agent 代表客户进入公司，首先要经过的是通用层。它负责在网关或网页上识别出这是个 agent、完成安全认证，并让 agent 读懂公开的业务信息、发起标准的查询或预约请求。不管公司做的是企业服务、专业咨询还是零售电商，这些最外层的迎宾和基础交互动作在一百家公司手里做法都一样，不包含行业秘密或内部审批。 过去技术团队默认这一层也得靠自己写代码接协议，但就在最近这几个月甚至最近几天，风向变了：网络网关、内容系统和支付底座正在把通用 agent 接入做成平台自带的免费能力。就在 2026 年 10 月 21 日，Cloudflare 在 Commerce.com 的案例里，直接在网络入口为近十万个域名默认开启把网页操作做成浏览器内工具的 WebMCP；同一年里，WordPress 6.9 的 Abilities API 和官方 MCP Adapter 把站点功能注册成标准工具，Wix 的 Site MCP 让访客 agent 连进单个网站，Stripe 的 agent 商业协议 ACP 和共享支付令牌接管标准付款握手，Shopify 的 Storefront MCP 也把公开目录和结账接口做进了底座。这些基础设施平台托管着成千上万家企业，开发一套标准接口摊到所有租户头上，单个企业的边际成本近乎零；反过来，单家公司如果自己抽人跟进底层协议、调试安全握手，干几个月做出来，外部标准一改又要重来。这给企业提供了一个过去没有的新选项：凡是落在让外部 agent 找到公司、执行公开标准动作这一层的需求，立项会上直接砍掉自研预算，优先去所用的网关、内容系统或支付平台后台打开现成开关；就算正在用的底座今天还没出，在选型和排期时顺着这类支持通用接入的平台走，也远比自己派人从头造划算。 省下了自研预算之后，管理层在这一层唯一需要防止的陷阱，是把免费的开关当成了万事大吉。前几天看到十万域名一键接入的新闻，很多老板第一反应是只要勾上这个开关，明天的外部订单就会自己流进来。其实后台开关只是在马路边立了一块标准路牌，让外部的 agent 找得到公司、读得懂公开目录，但这既不保证马路上立刻就有大把客流，也没法替公司把涉及内网权限和审批的业务走完。更现实的是，这块路牌的开放字段、刷新频率和限流水位全都攥在平台手里，哪天公司因为费率或合规迁出平台，通道当天就会收回。对待通用层，就是有免费开关顺手打开、不投人自建，也别拿订单增长指标去考核它。 ## 行业层，买生成内核，不买责任 外部或内部的 agent 跨过公开网页查询、开始办理具体业务，很快就会撞上特定行业的规矩。比如牙科诊所预约要连清算所核对医保，物业报修要做工单分级与派单，餐厅订座要处理定金与取消规则。看到这里有人可能会问，这些行业规矩在同行之间明明也差不多，为什么不能直接算进通用层，非要单独拆出一层来？原因在于范围从全网收窄到垂直行业之后，老板拍板时的算盘完全变了：通用大平台不会再替某一个细分行业免费买单，企业必须单独掏钱向垂直软件商采购；而且同行虽然共用一套底层行业规矩，每家店自己的排班和接待顺序却千差万别，根本没法靠后台勾一个固定开关解决，必须把买来的组件重新拼进自家的流程里；更关键的是，这一步已经动到了真实的交易和履约，一旦算错账或报错信息，就要有人掏真金白银赔付。 单家企业没必要派人从头摸索同行已经跑通的清算所接口或行业规则库，所以这一层最划算的拿法通常是买，尽管买只是行业层最典型的拿法，不等于层的定义。正因为每家企业要把行业规则拼进自己不同的流程里，以前买一套流程写死的成品模块，改个字段都要提工单；买裸 SDK 自己写又太慢。现在最理想的是采购第二章讲过的行业生成内核，也就是那套宜家家具套件：供应商提供包含规则库与底层连接器的行业核心套件、写给 AI 看的引导知识和防错杠杆工具，买方出业务意图、内部上下文、私有数据和最后一公里接入，让 AI 在开发阶段组装出贴合自家习惯的业务流。第二章提到的 Cloudflare、Shopify、Stripe 和 Vercel，已经在开发与电商支付工具里跑通了这种交付方式。买方拿到手里的是持续拼装流程的生成能力，不再是一套改不动的死板系统。 在具体行业场景中，企业向厂商采购生成内核让 AI 拼装流程，但保留关键业务决策权。例如牙科诊所向医疗软件商采购牙科保险生成内核，内置医保规则库、清算所连接器和给 AI 的核保组装指引。诊所不用买把所有预约分支写死的成品模块，而是通过 AI 按自家排班习惯设计预约验证和例外处理流程，比如老病人先占号再核保、新病人先核保再锁号，但疑难患者情况评估、特殊分期政策、医生临床决策、账单算错免赔额由谁赔付等最终仍由诊所决定。其他行业如物业对模糊租约条款解释、破门抢修赔付标准，餐厅对熟客改期费豁免、过敏原安全核查同样由企业自主掌控。 采购标的从固定软件变成了宜家式的生成内核，老板和技术负责人去跟供应商谈合同时，看的东西也得跟着变。以前买软件是拿着功能清单逐条打钩，现在买的是让自家 AI 拼流程的半成品和说明书，首先得在真实边缘场景里试试这套内核到底好不好拼：遇到改期重算、部分取消或者异常挂起，AI 能不能顺畅生成代码，还是只在厂商的演示视频里好看、真接进自家老系统却要工程师天天返工手改。其次要在签约前算清进出的账：接进自家旧系统最后一公里要改多少接口，万一明年想换一家供应商，积累下来的规则配置、交互流水和审计日志能不能按标准格式全量带走。最后也是最不能含糊的，是在合同里划清责任底线：供应商只对软件本身的缺陷、停机和接口故障负责，而具体业务规则怎么定、算错账单谁来赔，这些经营后果始终落在企业自己肩上。软件能力可以花钱买进，针对自家客户的业务判断与经营责任必须自留，这就是行业层买能力、不买责任的底线。 ## 自有层，只写独有的判断和旧系统补丁 顺着前两章往下走，通用层的公开开关打开了，行业层的生成内核也买回来拼好了，最后剩下的就是公司必须攥在自己手里的自有层。许多技术团队一听自有层要自建，第一反应就是立项重写那套跑了十年的老 ERP 或核心业务系统。但实际上，机房中的老系统并不等于核心。在 agent 接入的架构下，公司真正必须自己动手写的自有层非常薄，拆开看主要包括两样东西：不能让大模型自由发挥的商业判断，以及贴着老系统打的适配补丁与安全护栏。 先看商业判断。不管是外部的还是内部的 agent，它的背后都是大模型。而大模型天生就是概率性的，甚至有可能被外部提示词的套话带偏。比如一个工业品分销商对哪一位老客户破例让利，每个类别的毛利底线是多少，一个老客户有过历史逾期，还能不能批赊销额度，或者一个牙科诊所对哪些特殊的病人批准分期付款，如果账单出错了谁来赔偿。这些每家公司的商业规则完全不同，既是不能交给外部平台看到的商业机密，也是算错一笔账就要公司自己掏钱兜底的地方。所以定价和风控的算式不能写在提示词里让大模型凭感觉猜，也不能交给外部的通用插件，而要由公司自己的工程师用确定性的代码把参数范围、计算公式和返回的结构固定下来，封装成一个输入输出严格强类型的工具。比如审核一笔大额赊销订单，函数只能接受大模型传进来的客户编号和订单金额，返回剩余授信额度和历史逾期天数，但能不能批、批多少额度全看确定性的代码决定，不让大模型在真金白银和风控底线上自由发挥。 做完商业判断，下一步是把结果真正写进公司的数据库里。很多外部开发者觉得这不就是调个接口吗，但真正进过老企业机房的人都知道，外面买来的行业套件默认对接的是随时能读写的现代系统，而企业底下连着的往往是跑了十年的老系统，到处是外人根本不知道的怪脾气。比如平台懂通用接口，垂直供应商懂行业流程，但没有一家外部厂商知道，你们公司的财务系统每天半夜两点到四点要锁死数据库跑日终对账。这种历史包袱不会写在任何公开手册里，只藏在自家老员工的脑子里。自家工程师必须在老系统前面打一层补丁，把半夜进来的 agent 改单请求先拦下来排队；要是任由外部程序直接往里硬写，第二天一早财务对账就会彻底乱套。除了顺着老系统的脾气打补丁，这层代码还要充当最后一道安全护栏：平常的小额查询和常规操作可以自动放行，但只要碰到超额打折、大额付款或者批量改单，系统必须立刻踩刹车，把请求挂起并推给主管人工确认。 把自有层收缩到商业判断函数与老系统补丁护栏以后，技术负责人在排期表上就能理直气壮地砍掉那些最烧钱的自研基建了。像几个月一变的底层协议转换器、跨站通信和全局身份认证，本来就是浏览器厂商、支付网关和云平台正在铺的公共马路，单家公司派几个工程师去追标准，做出来也赶不上平台升级的速度；至于通用的 agent 状态机和可视化工作流底座，开源社区已经有现成成熟的框架可以拿来即用，自己关起门重造一遍，除了多背一份长期维护的技术债，并不会给公司带来半点业务壁垒。回看通用层、行业层和自有层的划分，自有层虽然通常靠自建，但重点是把私有知识和最终责任留在公司，并不等于全栈自研。公司完全可以用现成框架或让外部团队协助开发，只要把独有的判断写成大模型触不到的强类型函数，把老系统的脾气打好不会出事的补丁与护栏即可。平台负责通用通道，供应商负责生成内核，公司守住商业判断、经营责任与最后一道补丁护栏。 ## FOMO 与可逆性，先做什么，后做什么 回到周一的晨会上，老板问到何时能接上 agent，全公司只有几个工程师可以调动，底下还有旧的 ERP 系统、合规审批流程，以及不能停机的核心系统。面对 AI 原生时代的行业焦虑，老板和技术负责人最容易犯的错误，就是直接投入大量预算，为某种特定的外部 agent 入口进行定制。查看底层的接口标准和头部入口的真实进展，就能明白现在不能急于重注的原因。浏览器的底层接口标准尚未统一，WebMCP 在 Chrome 和 Edge 里还处在 Origin Trial 试验阶段，试验期一直排到 2027 年初，Safari 背后的 WebKit 和 Firefox 则还没有跟进信号。同时，头部入口也在不断改变方向，OpenAI 已经把 ChatGPT Atlas 标为 deprecated，今年 3 月又把 Instant Checkout 的重心转向商户在 ChatGPT 里的 App，仅保留了 ACP 作为连接层。底层标准尚未统一，头部入口每隔几个月就改变方向，此时投入宝贵的研发预算去定制纯对外的接口，很可能在入口改版后需要推倒重来。 先内后外、先可逆后不可逆：对外打开平台通用层免费开关并看日志，对内先把行业层内核与自有层判断补丁给内部员工和内部 agent 用起来 稳健的排期，是按先内后外、随时可退的顺序推进。对外用零成本卡位，在通用层直接打开 Cloudflare、WordPress、Wix、Stripe 或 Shopify 后台自带的默认开关，锁死高危写入权限，并在网关加一层日志，把真实的外部 agent 调用和爬虫、人类浏览器区分开；只要日志里没看到持续稳定的真实外部调用，浏览器与行业标准还没收敛，团队就不自建底层协议，也不为了没影的外部流量重组研发团队。对内则追求上线第一天就见效，把工程精力花在选用退出成本低的行业层生成内核做试点，以及编写自有层的确定性商业判断函数与旧系统补丁护栏，但把自家的一线客服、销售内勤和内部 agent 作为第一批用户。这些人每天都在几个老旧 ERP 系统之间翻表、录单、催审批，让内部员工和内部 agent 先用上这批强类型工具与旧系统补丁，从上线第一天起就能省下人工核对工时、减少录单出错。哪怕外部客户的 agent 流量晚来一年，这套投入靠内部提效也能持续产生实际收益；等到外部需求真正起量，团队只需从内部跑熟的工具库里挑出安全子集对外开放，进可攻、退可守。