企业AI部署的碎片化新阶段:当智能体嵌入软件之后|Enterprise Deployment Signals · April 2026, Vol. 2
NextAI+ | Enterprise AI Deployment Signals · April 2026, Vol. 2
本周企业AI部署的核心仍然是在讨论多智能体协同趋势，但出发点与上期有所不同。上期我们看到的是，企业先把AI放进生产流程，随着产出放量，才逐步暴露出治理与智能体协同问题；而本期更值得关注的变化是，各类企业软件厂商正在将AI直接嵌入财务、供应链、客户体验等业务系统内部，使其成为软件的原生功能。
4月8日，澳洲一站式企业服务软件公司MYOB与微软宣布达成一项为期五年的合作：《MYOB与微软签署五年战略合作协议，共同为澳大利亚和新西兰企业提供资金、构建和扩展人工智能驱动的创新解决方案》（MYOB and Microsoft sign five-year strategic partnership to jointly fund, build, and scale AI-powered innovation for Australian and New Zealand businesses），MYOB 通过在现有软件产品中嵌入由微软支持的智能代理与原生AI功能，为中小企业及中端市场客户提供现金流预测、情境化财务见解及财务自动化工作，旨在减少人工干预并实现业务决策的智能化；
4月9日，美国甲骨文公司（Oracle）在其官网上连续发布两则新闻：《Oracle推出面向金融和供应链的融合型智能体应用程序》（Oracle Introduces Fusion Agentic Applications for Finance and Supply Chain）和《推出面向客户体验的融合型智能体应用程序》（Oracle Introduces Fusion Agentic Applications for Customer Experience）。这一举措旨在将融合型智能体应用（Fusion Agentic Applications）直接内置于融合云应用（Fusion Cloud Applications）之中，在财务、供应链、制造以及客户体验等业务场景里，使应用能够基于既有的数据、流程、审批层级、权限和交易上下文，自主推进业务操作；
同样在4月9日，美国金融服务数据公司Trintech也宣布将面向财务原生的AI智能助手Beacon直接整合到其财务应用程序中，并高度参与分录录入、对账、交易匹配及关账管理等环节，见《Trintech为金融打造的AI代理推动金融结算》（Trintech Advances Financial Close with Agentic AI Built for Finance）。
先前，企业部署AI往往需要在既有业务系统之外另行采购和部署；而现在，越来越多业务软件自身就已开始集成原生AI能力。企业接下来面临的挑战，不再是单一入口的AI主动引入，而是如何应对众多分散入口同时并存所形成的新复杂局面。
OpenAI在4月8日发布的《企业AI的下一阶段》（The next phase of enterprise AI）中也犀利地指出了同样的问题：“企业已经对那些彼此之间无法对话、只会制造混乱的AI点解决方案感到疲惫，它们真正想要的是一个能够连接内部系统、外部数据源，并在正确权限和控制约束下运行的统一AI操作层。”这意味着，企业接下来真正要解决的，是如何让这些分散在不同业务软件中的智能体在同一权限、身份与控制逻辑下共同运作。
美国科技公司Okta本周公开招聘AI身份架构师（AI Identity Architect），所释放出的信号正是对这一问题的正面回应。一方面，Okta要求这一岗位先在公司内部落地相关方案，用真实生产场景验证：当多个智能体分散在不同应用中运行时，企业能否仍然用一套统一的身份与权限规则去管理它们；另一方面，这一岗位的职责也很清楚，就是把原本只适用于“人”的身份管理能力，扩展到这些分散在各类软件中的智能体身上，使企业能够持续识别每个智能体是谁、代表谁行动、可以访问哪些系统，并在必要时对其进行限制、调整和回收。Okta所做的努力，本质上是在为企业构建一套“能够管理碎片化AI入口”的身份与控制框架。
NextAI+ 是一个面向未来的AI咨询品牌，致力于打造一个围绕 “What’s Next in AI” 的跨界共创实验平台。我们与创始人、管理者、开发者和研究者一道，持续探索人工智能在真实世界中的落地边界、组织影响与长期战略，帮助各类组织在不确定性中形成更清晰、更可执行的决策。
Enterprise AI Deployment Signals是 NextAI+ 推出的企业级 AI 落地信号专栏，聚焦全球企业如何从 AI 兴趣、试点与概念验证，逐步走向生产级部署与系统化应用。我们持续追踪不同行业中最具代表性的 AI use case、企业采购与预算释放信号、组织能力建设、部署瓶颈、治理机制演进，以及从单点工具到多模型、多智能体协同的架构变化，将分散的市场动态沉淀为真正具有战略价值的企业级 AI 落地战略。
Oracle、Trintech、MYOB释放出的共同信号，是AI正在沿着企业现有软件体系进入组织：有的进入统一业务套件的核心层，有的进入高控制专业流程的工作台层，有的进入日常经营软件的产品层。本期企业AI的真实部署路径，可以按嵌入层级来理解。
它这次推进的路径很完整：融合型智能体应用直接内置到Oracle融合云应用程序，由多组专门的AI代理在统一企业数据、工作流、政策、审批层级、权限和交易上下文中执行动作，覆盖财务、供应链、制造、销售、服务和营销等场景。这样的部署方式，天然适合从核心经营流程切入，因为数据已经沉淀在套件内部，流程已经被系统编排，控制框架也已经存在，AI可以顺着原有业务链路进入执行面。企业由此得到的，往往是跨流程效率的提升，例如手工跟进减少、异常响应加快、交接等待缩短、客户与运营动作更连续。映射到开源技术栈，这类套件级嵌入更接近“编排层 + 模型接入层 + 权限控制层 + 观测层”的组合，能够类比到LangGraph、LiteLLM、OpenFGA与 Langfuse或Phoenix这类能力的协同落地。
第二种模式：流程级嵌入（代表案例：Trintech）
它此次的重点落在财务关账这一垂直工作流内部，将面向财务原生的AI直接带入“记录到报告”的关键环节，让AI在分录录入、对账、交易匹配和关账管理中持续提供风险识别、下一步建议、任务优先级、文档生成以及应用内引导。这里的部署逻辑带有很强的岗位与流程特征：财务结账周期短、控制要求高、重复动作密集、审计留痕明确，因此AI更容易贴着具体工作台进入日常操作。企业首先看到的非常直接的价值在于：分录准备、对账匹配、异常排查和关账调度的人工负担会明显下降，同时控制力度和透明度同步上升。若映射到开源技术栈，这类流程级嵌入更像是将LangGraph式的工作流编排、规则与评分逻辑，以及Langfuse或Phoenix式的观测能力，深度压进专业工作台之中。
第三种模式：产品级嵌入（代表案例：MYOB&微软）
这里的部署节奏更接近日常软件分发：双方通过为期五年的合作，将AI持续嵌入MYOB的业务管理解决方案之中，使中小企业和中端市场客户在继续使用原有产品的过程中，逐步获得现金流预测、经营表现理解、手工工作压缩以及面向客户的智能体AI等能力；同时，微软提供专属工程支持，并通过Foundry、Copilot Studio等环境支撑AI的构建、部署与规模化放量。这一路径特别适合中小企业，因为它更贴近日常经营软件的使用方式，AI能力会伴随产品更新持续进入业务动作，企业可以在原有工作流中逐步吸收智能能力。企业由此获得的收益，集中体现在日常经营判断更快、手工操作更少、经营洞察更贴近具体工作场景。若映射到开源技术栈，这类产品级嵌入更接近“轻量级智能体应用层+批量部署与治理层”的组合，可类比为LangGraph或CrewAI这一类任务型智能体框架，再叠加模型接入、权限控制与观测能力。
把这三种层级放在一起看，企业先接受它们的原因也很明了。AI沿着套件、流程、产品三条路径进入企业后，价值都离真实业务动作很近：Oracle覆盖的是跨部门经营链路，Trintech 覆盖的是高控制专业流程，MYOB覆盖的是中小企业高频日常经营动作。处理效率、异常识别、流程推进、人工负担压缩和经营洞察改善，都能在较短时间内被业务部门直接感知。这种贴着现有系统和现有岗位的部署方式，也使企业更容易在局部场景中先看到效果，再接受下一轮扩展。
但这三条路径共同带来的后续影响，同样值得单独看待。Oracle这类套件级嵌入，会在核心业务系统中长出能力很强的系统级智能体网络；Trintech这类流程级嵌入，会在关键工作流中长出高度专业化的流程线段；MYOB 这类产品级嵌入，则会随着软件持续使用，把AI能力散点式稳定平铺进企业日常经营表面。企业局部环节的效率因此提升，但也会同步形成多个分布在不同层级、不同边界中的智能体节点。到了这一步，企业随后要处理的课题便延伸到“这些分散在不同系统中的智能体如何共同运作”。局部收益越快兑现，整体协同的复杂度越值得被前置规划，这也正是本期部署模式最值得重视的地方，我们将会在随后的“瓶颈和摩擦”进一步解读。
本期更接近真实预算化的第一类场景，已经落在核心业务软件本身。原因并不复杂：当AI以嵌入式能力写进Oracle这类企业级业务套件，或写进MYOB这类企业经营管理软件之后，企业为之付费的方式也随之发生变化。它不再需要先单独设立一个“AI 项目”，再去证明这套能力能否嵌回既有系统；相反，AI 已经随着企业资源计划、业务管理软件和核心经营系统的既有预算里进入企业。预算原本就来自系统升级、流程数字化、产品能力增强和经营效率改善，现在AI让这些投入有了更直接的业务解释——它可以被翻译成回款效率、流程推进速度、人工处理负担、经营判断质量和客户响应效率的改善。对企业而言，这类项目之所以更容易从概念走向预算，关键就在于它服务的本来就是经营主流程，价值也能够被翻译成熟悉的业务语言。
与此同时，预算开始从单一应用外溢到统一运行与身份控制层。这个变化的逻辑要比“企业愿意为治理花钱”更具体。当企业采购Oracle、MYOB、Trintech这类软件时，首先买到的是各自系统里的嵌入式AI，短期内看到的也是局部环节的效率收益；但当这些能力分别长在不同软件里之后，企业很快会遇到一个更现实的问题：多个智能体已经在不同系统里行动，谁代表谁、谁能调用什么、跨系统动作如何授权、权限何时收回、出了问题由谁留痕和追责，这些问题都不会因为单个应用运行顺畅而自动消失。到了这一步，预算关注点就会从“某个软件里的 AI 好不好用”，转向“这些分散的软件AI能否被持续、统一、可控地运行”。这类投入的形成机制也很清楚：局部效率收益已经兑现，新的成本与风险将集中到运行秩序本身，企业便需要为统一识别、统一授权、统一部署和持续管理补上正式预算投入。
综合来看，本期真正开始预算化的，可以收敛为两层：第一层是核心业务软件，解释了为什么AI能够更顺利地进入企业；第二层是统一运行与身份控制层，旨在说明为什么企业在看到局部收益之后，会决定将预算继续推向更底层的运行与控制能力。
以Oracle为例，AI已经能够在其自身的业务套件中理解订单、库存、采购、财务、客户处理等连续数据，并沿着既有流程自主推进动作，单看这一套系统，运行效率和连续性都会明显提高；一旦放回企业整体环境，情况就会立刻复杂起来。现实中的公司通常还会同时使用数据平台、客服系统、区域财务系统等其他软件，Oracle里的智能体对这些系统之外的上下文并不天然可见。结果就是，一个系统内部可以持续推进动作，跨系统协同时却容易出现信息断层、判断错位和动作先后不一致，这就是典型的系统边界型碎片化。
以Trintech为例，AI已经深度进入财务关账流程中的分录、对账、匹配和关账管理，这一段流程会因此变得更快、更稳、也更容易控制。企业真正的工作链条却远不止这一段。合同、订单、收入确认、费用归集、经营分析，往往仍然分布在其他系统与团队之中。于是，关账这一节点会率先智能化，前后的上下游环节仍按各自节奏运行。企业很快就会看到一种现实场景：中间这一段已经具备很强的自动判断和执行能力，前后环节的衔接却依旧依赖人工确认、跨团队沟通和系统间核对，这就是流程节点型碎片化。
MYOB这一类路径的特点，在于AI会随着产品更新持续进入日常经营软件，现金流预测、经营洞察、自动化处理和客户相关智能能力，会不断出现在企业日常使用的软件界面中。单看MYOB自己，这些能力仍然集中在同一套产品体系里；放回企业全局之后，问题会转成另一种形态。企业往往不会只使用MYOB，一家成熟公司手里通常同时拥有企业资源计划、财务控制工具、CRM、数据平台以及各类区域性系统。每一家软件厂商都在往自己的产品里嵌入AI，企业内部的智能入口数量就会持续增加。最后形成的局面是：很多软件都更智能了，很多界面都能给出建议、触发动作、推进任务，企业整体上却缺少一套统一的协调机制，这就是入口数量型碎片化。
把这三层放在一起看，企业随后面对的摩擦会迅速上升。企业最终承受的，已经是一种三层碎片化同时存在的运行环境：系统和系统之间有边界，流程节点和节点之间有断层，软件入口和入口之间持续增加。这样一种环境，天然会把多智能体协同推成企业级难题。
2. 现实企业的软件偏好与连续性风险，会让“统一到一家软件厂商”很难成为可持续答案
第二类核心摩擦，来自企业对软件格局的真实选择。很多成熟工作流都有自己长期形成的软件偏好。比方说，财务团队可能更愿意把关账和控制交给Trintech这类工具，因为它贴近财务职能部门的节奏和审计要求；运营与供应链团队往往更依赖Oracle这类套件，因为它适合承接跨部门执行；区域子公司或中小业务单元，则更愿意保留MYOB这样的经营管理软件，因为部署门槛更低、使用习惯更贴合本地团队。对公司来说，这种多软件并存并不代表混乱，它更像是一种长期形成的业务分工。统一替换成一家厂商的全套产品，往往意味着流程重构、团队再培训、历史配置迁移和内部协调，推进成本很高，组织意愿也通常有限。
风险考量也会把这件事解构得更清楚。若一家企业把关键业务流程尽量压到同一家厂商的全套 AI 应用上，短期内智能体协调会更统一、采购看起来更简单，长期风险却会明显抬升。一旦这家厂商出现系统故障、接口异常、权限配置失误、区域性服务中断或关键产品调整，受影响的就不只是一个工具，而可能是整条业务链路。订单、客户处理、回款、关账、经营判断都寄托在同一套全AI软件体系上，任何一次重大异常都可能演化成组织级停摆。对真正依赖连续运转的企业来说，保留多套软件并行，本身就是一种分散风险的经营安排。问题随之转成另一种更现实的要求：企业需要的并不是把所有业务都托付给一家厂商，而是让这些原本就会并存的软件和智能体，能够在企业自己的规则下协同工作。
把这两类摩擦放在一起看，答案已经很清楚了。企业今天面对的课题，集中在如何把一张有边界的网、几条各自强化的线段，以及越来越多散落在业务表面的智能点，重新组织成适合自己公司的运行体系。这里需要先做的是工作流层面的判断：哪些环节值得跨系统打通，哪些环节应该保留原有软件偏好，哪些动作适合自动推进，哪些动作仍然要留给人工把关。接下来才进入系统层面的建设：任务编排、模型接入、身份授权、权限治理、留痕观测、异常回退和成本控制。前一段决定协同顺序，后一段决定运行质量，二者共同构成企业自己的多智能体工作流。
这也是NextAI+可以接手的位置。前文已经拆开看到，套件级、流程级、产品级嵌入分别对应着不同层级的能力模块，也都能映射到一组较成熟的开源技术栈：工作流编排可以借助 LangGraph这一类框架，模型统一接入和路由可以对应LiteLLM，身份与权限控制可以参考 OpenFGA，运行观测与评估可以落到Langfuse或Phoenix，轻量任务型智能体则可以结合 CrewAI一类框架。虽然Okta提出了引进AI身份架构师岗位的办法去治理多模型碎片化的问题，但NextAI+的价值，在于提供一种从根本上解决问题的战略与技术方案并且将其执行下去——我们可以帮助企业保留现有软件格局的前提下，围绕自身真实业务设计搭建定制化的AI工作流，把已经存在于不同系统，流程，入口中的智能能力重新整合起来，让网、线和点在企业自己的协同框架里形成更可控的运行效果。这样一来，各类成熟软件在各自环节中的优势能够继续保留，多智能体碎片化带来的协同成本也有机会进一步下降。
版权声明：本报告由NextAI+ Research编制，信息来源均为公开资料，不构成任何投资建议。未经NextAI+书面授权，禁止任何形式的转载、复制或引用。版权所有，侵权必究。
© 2026 NextAI+ Research. All rights reserved.
夜雨聆风
