一、两条路径：平台化转型与原生一体化

先定义两个产品。

灵基是金蝶面向 AI 时代的平台化新产品。2026 年多方沟通确认的信息显示：灵基及配套的费控产品，未来将与金蝶 ERP 完全解耦、独立售卖；其做法是以费控为小切口验证平台能力，再逐步重建系统——战略重心已经从传统 ERP 阵地转向平台化。与之配套的产品形态还包括：前端模型入口仅提供"服务专家"选项，类似 Studio 的环境可选模型；因多次转码加密，输出效率受限；按积分计费、报价浮动；当前主推公有云部署，线上运行在服务器、线下仅作指令端。

YonWork 是用友 BIP 6 之上的企业智能体统一入口，与 YonSuite 之间通过平台 AgentAPI 直连，配套 YonAIG 提供治理、管理、运营三域能力。它不是长在 ERP 旁边的助手，而是长在 BIP 平台上的业务级智能体。

一句话概括两条路径：灵基选择在旧体系旁边起新平台，再逐步解耦重建；YonWork 选择把 AI 原生长进既有业务系统。路径本身无对错，但企业客户需要明白自己买到的是哪一种——因为后续所有的体验差异，都从这里开始。

二、架构：一次业务指令，两种执行代价

架构差异是所有体验差异的根源，值得花一节讲清楚。

灵基与 ERP 的连接走 MCP 工具调用链。一次业务指令的完整链路是八个环节：用户提出指令→灵基理解意图→获取工具清单（tools/list）→规划工具链路→MCP 调用工具→ERP 执行与返回→结果回流模型→组织业务结果。在这条链路里，灵基 Agent 与 ERP 业务系统之间隔着 MCP Host/Client 与 MCP Server 两层，模型要额外承担工具的理解、分配与规划——每一个环节都可能引入等待、误判与失败。

YonWork 与 YonSuite 的连接走平台 AgentAPI 直连：用户/业务端→YonWork Agent→平台 AgentAPI→YonSuite，规划策略交给用户端，没有外部工具链的中间层。

架构不是口号，它决定了三件事必须被验证：效率（多轮调用对耗时与成本的影响）、稳定性（集中调用时是否排队、超时）、交付成本（每个环节都是排障点）。这正是 MCP 公开机制的特点：Host 管理 Client、Client 连接 Server，工具发现与调用只是链路的一部分，模型仍负责选择与规划——链路越长，不确定性越高。评估任何基于 MCP 架构的企业智能体，都绕不开这四个问题：模型够不够聪明？路径规划是否合理？集中调用是否稳定？调用频次对效率与成本影响多大？

三、实测：体验会现场的三类现象

以下现象均为 2026 年金蝶灵基官方线下体验会环境下的现场记录——官方场景、官方环境、原版提示词。结论限定在本次测试，不扩大为对所有场景的判断；这个限定本身，就是选购企业 AI 时应有的严谨。

现象一：卡——40 分钟的月报。官方场景下，一个销售月报的生成跑了约 40 分钟；期间多次出现 AI 服务不可用，而大模型思考过程持续在输出、调用工具过程中报错——大模型是正常的，问题出在金蝶内部服务层。此外，多任务并行后，成果物与会话对应困难，需要人工找回、辨认和复核；部分场景停留在配置或过程展示，未形成可复核的最终业务结果。对使用者来说，等待会过去，但被打断的任务不会自动回来——任务连续性，才是"卡"背后的真实成本。

现象二：傻——一条不精确的档案名。制单测试中，输入基础档案名称或编码不精确（真实用户的常见输入），灵基无法自主继续制单，任务在理解环节断点：没有明确提示，也不给相似档案候选，用户只能回到人工查档、核对、重输。另一个数据查询场景：把官方提示词中的编码直接删掉，系统不会自己识别到基础档案业务实体，语义理解出现明显偏差。

同题对比下，YonWork 制单助手在同类不精确输入下未出现同类阻断。需要严格说明：该结论同样限定在本次制单测试，真正的优势要能被客户同题复现。现场判断的标准是四问：能否识别？能否给出相似候选？能否主动澄清？能否继续完成任务？智能不是把预设流程跑一遍，而是输入变化后仍能澄清、规划并推进。

现象三：确定性反馈缺失。多个验证场景中，AI 给出了肯定的答案，但系统操作并没有真实完成——用户无法从交互中获得确定性反馈。对照之下，YonWork 的制单助手、文库助手等智能体在操作完成后会直接跳转到对应的系统功能界面，动作与结果可当场核对。对财务、供应链这类"动作必须落地"的场景，"AI 说做完了"和"系统里真的有这张单据"之间，隔着一个可验证的跳转。

四、权限与账号体系：密钥直连的代价

权限是灵基"与 ERP 解耦"路径上最实际的代价。实测确认：灵基连接 ERP 采用的是基于密钥的身份识别，而不是基于登录身份——权限控制存在天然的局限性、不灵活性与不安全性。更基础的信号是账号体系：灵基与 ERP 的账号体系完全独立，需要分别用密码和验证码登录两次，登录规则截然不同——两套系统连登录入口都没打通，底层账号不是一套。

YonWork 与 YonSuite 之间的权限是原生的功能权限与数据权限一致性。一个可以直接在售前现场演示的对照实验：给多个用户频繁、快速地变更权限，观察销售合同在智能体中的可见性变化——权限变了，智能体能看到的数据随之变化。这背后是同一套身份、同一套权限模型在起作用，而不是一把密钥在两套系统之间传递特权。

对企业客户的意义在于：当审计人员问"这个智能体当时是以谁的身份、在什么权限下、对哪条数据做了什么动作"，密钥直连的架构很难给出可举证的答案。权限体系决定了智能体的动作边界——边界模糊的智能体，越难进入高价值、高风险的核心业务。

五、一体化之问：费控"另起炉灶"意味着什么

费控是观察两条路径差异的最佳切片。体验会实测确认：灵基演示的费控场景，与金蝶原厂费控产品没有任何关系——为了验证 AI 场景，彻底放弃了与财务的一体化，重新起了一套基于灵基的领域级产品。结合前述"灵基及费控未来与 ERP 完全解耦独立售卖"的战略确认，这个选择的内在逻辑是自洽的：用相对简单的费控做小切口，验证平台能力，再逐步重建系统。

YonWork 走的是另一条路：费控智能体直接建立在原生一体化能力之上——AI 操作的就是财务系统本身，单据、流程、口径天然同源。在售前现场，两类产品可以直接同题对照：同一个费控场景，一边是新起的领域级应用，一边是原生财务系统里的智能体，结果交付的差异一目了然。

企业客户需要判断的是：你要的费控 AI，是"一个能报销的 AI 应用"，还是"财务系统里长出来的 AI 能力"？前者部署快、边界清晰，但与既有财务体系是两张皮，数据口径、权限边界都要重新对齐；后者与既有系统同源，但要求你的核心业务已经跑在同一套平台之上。

六、开放与交付边界：现场三件事

智能体平台的真实交付能力，不看预制清单，看新增交付。体验会现场未看到开放的 MCP 接入入口，也未看到智能体创建与管理的完整闭环——创建、配置、权限、发布、管理等交付动作没有完整呈现。宣传口径中的"各类角色智能体、CEO/财务工作台、完整角色化业务体验"，现场未看到与之对应的完整可验证形态，部分场景没有环境或没有完整跑通。

这里必须保持方法论上的克制：不能因为现场没看到就断言"不存在"；但必须把"是否仅处于实验室或演示环境"列为项目 POC 的核验项。宣传不是交付——看不到入口、跑不通场景，就不能计入可验证能力。

判断一个智能体平台的真实交付能力，项目现场必须做三件事：新建一个智能体、接入一个新工具、跑通一个新场景。如果只能使用预制能力，真实项目交付会受到明显限制——因为每个企业的业务，都不可能恰好长在厂商的预制清单上。

七、怎么自己验证：POC 六要素与六个可复核指标

上述所有对照，企业客户都可以自己复核，不必依赖任何一方的叙事。可复用的验证框架如下。

POC 设计六要素：真实业务题（取客户正在处理的单据与报表）、真实数据（同一组织、档案、权限与口径）、变化输入（加入常见的不精确表达）、跨系统任务（理解、制单、审核、分析连成闭环）、异常边界（观察并发、超时、未命中与穿透）、结果复核（双方现场确认可复核结果）。

验收看的六个指标：完成度（是否形成最终业务结果）、耗时（从输入到结果的总时间）、人工介入（提示、查档、重跑次数）、业务正确性（单据、口径、权限是否正确）、结果穿透（能否回到原始业务单据）、开放扩展（能否新建智能体并接入新工具）。

以及一条总原则：同题、同数、同环境、同评价——让双方现场跑给客户看，过程与结果全程留痕。POC 的目标不是证明谁会说，而是确认谁能在真实业务里交付结果。验收不看感受，看可复核的指标。

八、共存视角：两条转型路径，一种实证主义

回到产业层面，灵基与 YonWork 的对照，其实是 ERP 厂商 AI 转型的两条路线样本：一条是在旧体系外另起炉灶、以小场景验证平台、逐步解耦重建；一条是把 AI 原生长进 BIP 平台、与业务系统同源一体。两条路径各有其战略逻辑，也都会在市场上找到适合自己的客户——场景明确的单点需求，与集团型、多系统、要求业财一体与可审计的企业，本就是不同的买家。

真正应该被固化的不是"谁赢谁输"的结论，而是一套实证方法：企业采购企业 AI，与其听双方的叙事，不如把双方拉进同一个验证场——真实业务、真实数据、变化输入、可复核指标。让证据说话，让交付边界说话，让总成本说话。对任何一个准备为"AI 进业务流程"投入预算的企业，这一条建议的价值，高于本文所有对比结论。

口径说明：本文基于 2026 年金蝶灵基官方线下体验会现场记录、双方公开资料与顾问对标分析；体验类结论限定在本次测试场景，不扩大为对所有场景的判断；灵基迭代节奏较快，关键能力建议以最新 POC 实测为准。