周五下午，老板在工作群里转发了一条新闻，说十万店铺域名一键接入 AI agent，某平台为近十万个店铺域名默认打开了浏览器里的 agent 工具调用（WebMCP），只要商户不手动关闭，浏览器里的 agent 就能直接调用网站的功能。这条新闻背后的机制，前一篇文章拆过：平台怎么在不改商家代码的情况下，把工具装进十万个店铺的页面。老板 @ 了技术负责人和 PM，问公司业务什么时候能实现“AI 原生”。客户寻找服务的入口从搜索转向了应用商店，现在又转向对话界面和浏览器里的 agent，每次入口迁移都要重新计算获客成本。老板担心同行先在新入口接上单，自家的服务却在外部 agent 面前隐形。接球的技术负责人和员工心里也跟着发慌，不做怕被同行甩开，做又不知从哪里下手。眼看周一就要开例会，大家的第一反应是先做点看得见的东西，好在周会上有个交代。
为了在周一例会前交差，工程师花了半天时间把平台自带的公开接口打开了。团队找了一个测试 agent 读出官网公开的产品目录、门店地址和常见问题，录了一段演示视频发到周会群里。看上去公司已经实现了“AI 原生”。但拿真实业务一试就断：老客户查一份带阶梯返点的年度合同价、改一笔已经进入分拣状态的订单地址，或者核验某项服务是否符合行业准入资质，外部 agent 当场卡死。平台自带的默认开关只能读公开页面、搜关键词，碰到公司内部的业务校验、权限核对和状态修改就中断了。真实业务背后连着内部旧系统的接口限制、不同角色的权限边界和合规审批要求，单靠勾一个默认开关根本够不到这一层。
撞墙之后，团队又滑向了另一个极端。技术负责人和架构师起草了一份年度架构立项书，准备自研多协议转换层、跨站 agent 身份认证、密钥交换机制，还要自己搭一套多轮对话状态底座。公司本来人手就少，背后还是一堆不能轻易改动的老旧系统。几个主力工程师从日常需求里抽身，埋头干了大半年，研发经费花了不少。底层协议和对话状态刚跑通，还没接进两个真实业务流程，第二年云厂商和建站平台就把这些通用能力做成了所有商户免费使用的标配。大半年的心血转眼变成无人维护的重复基建，真正要改的内部审批和旧系统接口还是没动。
把这两次折腾放在一起回头看，团队才意识到，回答老板那句什么时候能实现“AI 原生”，关键不在建还是买，而在哪一层租、哪一层买、哪一层建。想通这一点，员工再去开周会心里就不慌了：先把要改的需求分成三层，会上的讨论就从催进度变成了排期。
前面两条路都撞了墙，原因不在平台选错或者代码写错。两条路都在回答一个旧问题：买还是建。这种问法假定技术负责人要决定的，是一个完整的产品或者一套封闭的系统：要么向外部供应商买一套成熟软件，要么由内部团队自己从头写一套系统。“AI 原生”把这个决策对象换掉了。现在企业要决定的是接口和动作：外部 agent 能不能顺利找到你、能不能准确调用你的动作、能不能替你把事真正办完。决策对象从整套产品和系统变成了具体的接口和动作，买与建的二分法自然不够用了。
只买平台能力，企业拿到的是前半段：agent 能顺着标准入口找到你，也能调用搜索、加购这些标准动作。拿不到的是后半段：agent 不知道这个客户的合同价是八折，不知道这笔订单已经进入分拣、不能改地址，也不知道这项服务要不要先过合规审批。平台不替你承担业务后果，所以它只是找到了你，并没有替你把事真正办完。反过来走全自建路线，团队虽然能拿到后半段，代价却是把平台马上要免费给的通用层从头重造一遍，平台那部分的钱等于白花，公司特有的业务规则和串起系统的胶水代码还是得自己写。
要跳出买还是建的旧框架，技术负责人需要把面向 agent 的接口拆成三层。这里的租不是订阅，买也不是买断：租说的是能力随平台附带、接口由平台定义；买说的是向外部供应商采购已经编码好的行业规则和连接器。通用层向平台租，拿到的是被 agent 找到、调用标准动作的通道。行业共性层向供应商买，接的是同行都要面对、平台又不会替你维护的行业规则。公司独有的核心和把系统串起来的胶水自己建，专有定价、风控判断和跨系统编排留给自己。这三层的预算、责任和退出方式都不一样，得拆开算。同一家企业往往三层同时在动，每类需求各自找到对应的层，不必在三者之间挑一个。下面这张表把三层放在一起对照，后面三节分别展开。
| 对比维度 | 租：平台默认通用层 | 买：行业共性能力层 | 建：公司独有核心与胶水层 |
|---|---|---|---|
| 谁定接口 | 平台统一定义开放字段与标准端点，企业随主体服务直接启用，迁出平台时通道自动收回。 | 垂直软件商定义行业模块接口，企业按订阅或项目获得使用权，并保留历史数据导出权。 | 内部团队定义严格的输入输出边界，规则代码、历史数据与编排逻辑全部归企业自有。 |
| 谁担责任 | 平台保障底层基础设施合规与传输安全，不包揽企业具体业务动作的履约后果。 | 供应商按合同对软件缺陷、停机与接口故障担责，不承担企业的经营判断后果。 | 企业独立承担业务判断、越权拦截、异常处理以及最终向客户赔付的全部责任。 |
| 钱花在哪 | 核对默认开放的公开字段、启用平台免费开关，并在网关层埋好 agent 访问日志与监控。 | 评估模块契合度、集成成本与退出成本，审定合同责任条款并完成接入验收。 | 编写核心定价与风控工具、处理旧系统锁表与冲突，并设计熔断机制与人工确认。 |
下次排期立项，先用这张表把需求放到三层；真正要回答的问题只剩下一个：哪一层承载企业的商业责任和核心差异化。
先看租这一层。建站、支付和电商平台纷纷把通用 agent 接入做成免费标配，靠的是多租户底座的规模效应。一个平台底下托管着成千上万家商户，加一套 agent 接口的研发和常年维护成本可以摊到所有租户头上，单个企业拿到的边际成本接近于零。企业如果自己抽人去跟进底层协议、统一数据格式、做安全握手，往往要投入几个月工时，而且外部标准一变就得重做。2026 年 10 月 21 日，Cloudflare 在 Commerce.com 的案例中为近十万个店铺域名默认开启了把网页操作变成浏览器内工具的 WebMCP，这说明默认开关背后是平台层面的成本结构，跟个别厂商的促销不是一回事。
从这个共同的底座出发，企业从平台租到的能力其实只有两种：被 agent 找到，以及调用标准动作。Cloudflare 的 WebMCP 把浏览器里的搜索、加购变成工具；WordPress 6.9 的 Abilities API 和官方 MCP Adapter 把插件功能注册成供模型统一调用的 MCP 标准工具；Wix 的 Site MCP 让访客的 agent 连进单个站点；Stripe 的代理商业协议 ACP 和共享支付令牌把下单和付款握手接过去；Shopify 的 Storefront MCP 把商品目录、库存和结账放到自家底座上。这五个平台切入的位置不同，但做的是同一件事的不同入口。企业拿到的是：agent 能找到你，能调用搜索商品、加入购物车、查空位、建工单这类全行业长相一致的标准动作。这些动作在一百家公司眼里没有本质差别，不碰审批流和监管红线，所以平台能用一套多租户模板统一接管。
租不到的东西有三样。第一样是让 agent 把事办完的能力，默认开关只说明 agent 能找到你、能读公开信息，不等于它能替你走完一笔真实业务。真实业务还得过公司内部的规则、权限和审批，合同价要核，超额折扣要批，订单状态不能随便改，这一层平台不碰、也不该碰。第二样是外部需求，打开开关只是供给侧的单向动作，就像路边立了块标准路牌。路牌不会自己带来车流，开关也不会让第二天早上多出一批真实订单，外部 agent 是否调用，取决于入口那边有多少用户真在用 agent 办事，这不是企业能决定的。第三样是接口所有权，接口开放哪些字段、缓存多久刷新、限流卡在什么水位，定义权都在平台手里，企业不能要求平台为自家的会员等级或专属合同价改全局接口。这条通道只是随托管关系附带的公共服务，哪天因为费率、合规或业务扩张迁出平台，通道当天就会收回。
把这些账合在一起，平台替所有租户托管了一层共同的基础设施，企业租到的是被 agent 找到和调用标准动作的能力，租不到的是把事办完的能力、外部需求和接口所有权。租用这层通用基础设施仍然是性价比最高的选项，这一点不用犹豫。技术负责人跟管理层对齐预期时只需要把账记清楚：租来的是通道，不是资产。团队可以放心沿着平台铺好的轨道搭便车，同时把自研预算花在平台碰不到的地方。
租不到的部分，先看哪些能买。当外部或内部的 agent 跨过公开网页读取、开始替客户办理具体业务，平台免费的通用开关就会停在行业规则门口。通用开关能处理商品搜索、加购结账这类通用动作，却碰不到藏在每家企业自己系统、历史数据库和线下合同里的专属规则。牙科预约前要核验保险，物业接报修后要按合同派单，工业品 B2B 采购要按历史提货量折算合同价，这些动作才决定 agent 能不能替企业把整单业务办完。平台方不会替各个垂直行业维护这些规则，企业也没必要抽调内部工程师从头摸索同行已经跑通的共性流程。只要某项规则是同行普遍要跨的门槛，团队到了这一层就得花钱买，不能继续等平台免费开放。
企业采购的这三样东西，是行业规则的编码、连接旧系统的适配器和供应商对软件缺陷的责任条款。目前公开资料里没有企业大规模采购这类方案的证据，但工程上已经出现三种形态。想把现成的行业规则快速装进现有流程，团队会采购标准化软件模块或插件。想让外部服务实时返回核验与计算结果，团队会订阅行业 API 或清算所服务。内部旧系统结构复杂、需要定制打通时，企业会委托系统集成商做对接项目。不管哪种形态，企业买的是别人写好的软件能力，不是经营责任。
软件能力可以花钱买进，但针对自家客户的业务判断、例外处理、客户关系和最终赔付责任，这四样必须留在企业自己手里，这就是买能力，不买责任。用牙科诊所举例，诊所可以买成熟的牙科管理插件、保险规则库或清算所接口，让系统在预约前自动核对保险计划、免赔额和报销比例。但某个保险计划的个案例外、主治医生排班、临床决策以及账单出错时的赔付，外部模块替不了，必须诊所自己担。其他行业也一样，物业公司的租约条款解释与破门抢修赔付、餐厅的常客改期豁免与过敏原安全责任、工业品 B2B 分销的破例临时授信与让利底线拍板，都得留在企业自己手里。
在明确了买什么和留什么之后，技术负责人和业务负责人在选择外部解决方案时，需要按四个标准逐一过筛。团队要看模块自带的流程和字段是否符合本行业实际操作，是否支持改期重算、部分取消和异常挂起，这是看流程契合度。技术团队还要算清把模块接进现有旧系统需要改多少内部接口，免得为了迁就外部工具反而搭进去大量内部研发工时，这是看集成成本。企业在签约前要确认规则配置、交互流水和审计日志能不能以标准格式全量导出，防止日后换供应商时历史数据困在别人系统里，这是看退出成本。法务和技术负责人还要看清供应商对软件缺陷、停机和接口故障承担什么赔付，免责边界画在哪，这是看责任条款。买不是失败，但供应商的合同责任停在哪里，你的责任就从哪里开始。
租来的通用通道和买来的行业模块都到位以后，企业内部团队真正该自己写代码的地方只剩下两样：公司独有的核心逻辑，以及把租来的平台、买来的模块和自家旧系统接起来的胶水层。这两样之外的活，市面上几乎都能找到比自己动手更便宜的现成答案。把这笔账算清楚，技术团队自然知道别去造通用协议，也别去造通用 agent 平台。
核心逻辑必须留在内部自己写，因为它直接决定公司在行业里凭什么赚钱。动态定价、账期授信、多级风控审批和独占的历史运营数据，这些看家本领既不能托管到外部平台，也不能塞进通用插件，否则机密外泄之外，差异化优势也一起没了。内部 Builder 要做的，是把这些规则的参数范围、计算公式和返回结构全部钉死，封装成输入输出严格的强类型工具。模型只能决定调不调、传什么参数，不能自己改算式。比如审核一笔赊销订单时，模型能读到客户的授信额度和逾期天数，但批不批、批多少由确定性代码说了算，不让它在真金白银和风控底线上自由发挥。
胶水层干的活听起来琐碎，每一件都对应一条真实的赔付风险。它要把一次业务操作串过租来的前端通道、买来的行业连接器和十年前的老数据库；每次调用前核对发起人的身份、部门角色、单笔金额上限和操作时间窗口；库存锁住之后审批超时或下游接口失败，它得把前面的状态干净撤销，不在老系统里留下死锁脏数据；碰上超额折扣、大额资金划拨、批量改单或例外条款，它要挂起自动执行，把审批单推给人类主管。跨系统编排、细粒度权限、超时与冲突回滚、高风险动作前的人工确认，这四件事都得贴着自家的旧系统写。原因不在技术难度，而在知识位置。平台厂商懂通用接口，插件商懂行业平均流程，但没人知道这家的财务系统每天半夜两点到四点会全库锁表跑批处理。这段时间进来的改单请求必须先落本地缓冲队列，直接写库就会账实不平。这类约束藏在老员工脑子和故障复盘文档里，不会出现在任何供应商的接口文档里。
负面清单同样要画清楚。通用协议转换器不自建，标准几个月一变版，平台和社区的适配速度远快于企业小团队。通用 agent 编排平台或可视化工作流底座不自建，成熟框架已经把状态机组件化做完了，自己再造只是多背一份维护成本。跨站通信和全局身份底座也不自建，那是浏览器厂商、支付网关和云平台正在共同铺的基础设施。把这三类排除掉，内部 Builder 的价值就落在剩下的地方：把公司独有的判断写成模型碰不得的工具，把老系统的脾气写成不会出事的护栏。平台负责通用，供应商负责行业，责任和最后一道护栏只能留在公司内部。
在周一的晨会上，老板询问何时才能接入 agent，公司却只有几名工程师，背后是旧 ERP、一长串合规审批和不能停机的核心系统。这时，技术负责人和产品经理不需要情绪安抚，而是需要一个立即可以拍板的行动计划，明确今天应该做什么，什么暂时不用做，以及什么情况下需要加码。由于调用外部 agent 的需求尚未成熟，团队眼下最稳妥的工程策略是先做随时能撤回、可调整的可逆投入，而不是一上来就押注外部入口的形态。团队封装好的强类型工具，应该先把公司内部员工和内部 agent 当作第一个调用方，外部 agent 做第二个调用方。按照这样的顺序进行，即使外部 agent 的需求比预期晚了一年，也不会浪费任何工程时间。
浏览器底层的接口标准还没定，WebMCP 在 Chrome 里仍是试验特性，计划 2026 年出货，Edge 的源试验排到 2027 年，Safari 背后的 WebKit 和 Firefox 还没有跟进信号。头部入口也在频繁更换形态，OpenAI 已经把 ChatGPT Atlas 标为 deprecated，今年 3 月又把 Instant Checkout 的重心转向商户在 ChatGPT 里的 App，只留 ACP 继续作为连接层。底层标准没统一，头部入口还在换形态，此时押重注风险极高。
下周一先在公司正在使用的 Cloudflare、WordPress、Wix、Stripe 或 Shopify 后台，把面向公开目录和基础查询的免费开关打开，把高危写入权限锁死。然后在网关和边缘加一层 agent 专用日志，把外部 agent、爬虫和人类浏览器的访问记录清晰地分开。接着在公司内部找一个边界清晰的场景，用小范围试用把那套强类型工具跑起来。再选一两个按月付费、退出成本低的行业模块做试点，摸清外部模块与旧系统对接的边界。与此同时，不可逆的重投入立刻按住，工程排期上不自建通用协议层，设计上不把架构押在单一外部 agent 平台，以免外部入口改版时推倒重来。团队分工上不为可能到来的外部调用量重组研发团队，优先保障现有核心系统的日常稳定。
按住外部重投入不等于团队闲着，一线客服、销售内勤和运营天天在几个旧系统里翻表、录单、对审批。让内部员工和内部 agent 先用上这套强类型工具，权限校验、异常回滚、锁表窗口缓冲这些胶水逻辑从上线第一天就开始为公司省去人工核对工时和录单错误，哪怕外部需求晚来整整一年也早已收回研发成本。等到外部调用真的起量，团队只需要从内部已经跑熟的工具库里挑一小部分安全功能对外开放。至于何时向外加码，团队在日常监控里盯着自己定的四个观察信号。第一个是自家网关日志里剔除爬虫之后，外部 agent 的有效业务调用量连续多月跨过团队预设的阈值。第二个是主流浏览器完成标准收敛，WebMCP 正式进 Chrome 稳定版且得到 Safari、Firefox 跟进支持。第三个是所在行业的头部软件商或主流支付平台上线了带明确赔付责任的接口。第四个是同行业公司跑出可核实的外部 agent 成交与真实复购数据，而不是停留在公关演示。日常巡检时看这四个观察指标亮几个，就按比例追加多少面向外部的投入。始终做清醒的平台消费者，不做平台的竞争者；先把手头可逆的动作做扎实，等真实信号亮起再推门。