大模型的能力早就到位了；可走进不少企业看一眼，还是老样子——AI 聊天，人干活。查一笔订单的状态、录一条请假记录、追一个卡住的审批，AI 一律够不着，业务还得人点开系统，一屏一屏地操作。
有意思的是，这些系统个个都建得不算差——表结构清楚，流程跑得顺；缺的就是那一个对外的口子。
问题来了：这扇门，到底有没有标准的开法？有，而且比想象中近。
够不着，是因为没留路
企业 AI 落地最常见的画面，是问答机器人挂在门户里。问它“现在库存够不够这批订单”，它客气地回一句“请前往 WMS 系统查询”。答得没错；可用户想要的，其实是它替自己去查。
传统路径下，让 AI 真正碰得着系统，得给每套系统定制开发对接——接口、鉴权、联调，一套工程下来，贵到没人愿意为“让 AI 帮忙查个订单”这个念头买单。这事儿在多系统的企业里尤其明显——仓库一套、客户一套、审批又一套，按老办法逐个打通，打到最后往往是打了个寂寞，维护还得排人守着。
结果呢，AI 就一直停在聊天框里，越聊越熟练，越聊越没用。
其实缺的东西一点都不玄。
系统得把自己能干的活，按 AI 认识的方式交出去。行业里管这套标准叫 MCP——模型上下文协议。它做的事一句话能讲清——让应用把业务动作封装成“工具”，AI 按需调用，拿到结构化的结果，不用猜、也不用等全文。这两年主流智能体都接了这套标准，2026 年它已经是 AI 圈的通用语言。
为什么以前没人这么干？改造贵，回头难。系统为某 1 家 AI 改了口子，过两年那家倒了、接口换了，改造的钱就打了水漂；标准是行业共用的，跟着标准走，不用担心押错宝。
打个比方，系统像一台功能齐全的家电，MCP 就是给它装上的通用插座；插座不起眼，可没有它，家电再好也只能孤零零立在墙角。
标准为什么这么关键？其实它把“1 对 1 谈”变成了“1 对多接”。以前系统接 AI，每接 1 家就谈 1 轮、开发 1 轮；有了标准协议，系统只管把工具按标准开放出去，谁来连、连几家，都不用再改系统本身。接口的主动权，从集成商手里回到了系统自己手里。
应用里的业务动作，能变成 AI 的工具
放在低代码平台上，这 1 步轻得有点出乎意料。
应用里的业务动作——查询订单状态、创建 1 条请假记录这类——勾选之后，就能封装成标准的 MCP 工具；不用写适配层，也不用另起对接工程，应用一发布，这些工具就对 AI 侧可见了。你别说，从“一套定制工程”到“勾选发布”，中间差的只是 1 个行业标准成熟了。
一家企业往往不止一套系统。仓库用 WMS 管、客户用 CRM 管、审批挂在流程平台上——这时候可以把多套系统的工具汇到一处，做一个统一的 AI 入口，谁的问题就智能调用谁的工具。用户不用再记“查库存开哪个、查客户开哪个”；开口问，就有人接。新员工入职第 1 周，最常见的求助是“这个去哪个系统查”；有了统一入口，这句话直接问 AI——答案从各系统的工具里来，不带猜的。
这事儿对老企业的意义，比新企业还大。系统是 5 年前建的，人还是那批人，业务早就滚了几轮——推倒重写没人敢拍板，继续手点又不甘心。工具化这条路刚好卡在中间：系统不动，动作开放，AI 照样进场。
这 1 步对企业还有更深一层的账好算。一套系统从立项到上线，短则几个月长则 1 年；建好之后如果只服务“人手点”这 1 种用法，产出上限就卡在人效上。把动作开放给 AI，同样的系统、同样的逻辑，多出一种不知疲倦的调用方——老资产不用追加投入，先吃上 AI 的红利。
豆包、WorkBuddy 这些智能体，都能连过来
工具开放出来，另一头谁在用？
MCP 是开放协议，主流智能体客户端基本都支持连接 MCP 服务器——豆包、WorkBuddy 这类产品都在其列，2026 年这是公开的行业事实。应用发布成标准 MCP 服务后，这些客户端都能连过来调用，不存在绑死某一家的问题。
连上之后的画面，值得想象一下。
在常用的智能体里说一句“查一下最近 3 笔未发货订单的状态”，它调用工具、返回结果；接着再说“把异常的那几笔备注到工单里”，它再调 1 次工具。业务系统还是那个业务系统，操作它的人，从“员工逐屏点”换成了“AI 一句话”。
这套连接还有个隐性好处——入口统一了，责任反而清楚了。以前流程散在各个系统里，出了问题互相推；工具从同一个口子进、调用有记录，谁的命令、动了什么、什么时候动的，1 条条都对得上号。出了争议，回放就行。
手机上能连，桌面端也能连；在家值班的仓库主管，跟坐在工位上的计划员，用的是同一套工具。系统建设攒了那么多年，这一刻等于直接续上了智能体这班车——原来锁在各套系统里的流程和规则，变成了可调度、可管理的服务资产；AI 时代的系统建设不用推倒重来，从已经建好的那 1 批开始盘活就行。
有意思的是，角色还换了位。原来系统等着人来用，人下班，系统就闲着；现在系统等着 AI 来调，白天调、夜里调、周末也调。资产还是那些资产，时间的褶皱被熨平了。
反正门已经在了，差的就是把它推开这个动作；推开之后的事，交给工具和权限去管。
门开了，锁还在
只有被明确勾选的公开动作，才会成为工具；调用走开放的权限体系，AI 能干什么、不能干什么，权限说了算；每 1 次调用还留下记录，出了问题能回头查。开放和管控，从头到尾是一件事的两面。
这 1 层值得多说两句。企业对“让 AI 进系统”的犹豫，多半落在安全上——AI 会不会误删数据？会不会看到不该看的字段？权限体系答的就是这几问：公开哪些动作，人勾选；调到什么程度，权限定；真出了事，日志里查得到来龙去脉。
老实说，企业怕的未必是 AI 出错，是出错之后说不清——谁授权的、动了什么、能不能补救。日志和权限把这几问都接住了；怕的东西有了着落，门才敢真开。
权限之外，范围也得划。哪些表能被查、哪些动作只读不写、写进去的数据过不过校验——这些口子全在设计期就定死，运行期不临时放水。AI 拿到的工具箱长什么样，企业说了算，不是模型说了算。
再补 1 个实操层面的安心点——工具清单是活的。今天先开放 5 个动作试水，跑顺了明天再开放 10 个；出了状况，随时把某个动作收回来，不影响系统其他部分。开放的程度跟着信任走，不必 1 次到位；这种先小额、再加码的节奏，也是企业 IT 熟悉的路数。
说白了，门开多大、钥匙给谁，主动权还在企业手里。AI 进门是干活来的，不是参观来的；干多干少，规矩先讲在前面。讲真，能把开放和管控这两面同时做实的方案，才敢往企业里放。
活字格从 V11.0 Update1 起就把这条双向通路铺好了——应用能 1 键开放为 MCP 服务，外部能力零代码接入，V12.1 继续往前推进。要是你的企业也停在“AI 很强、系统不接”这 1 步，官网的更新说明里有这条路的完整走法。从业务动作到智能体调用，中间没有定制工程这一站；门推开之后，路是直的。
