业务软件自带Agent，企业还需要另搭一套吗？

文／侯彦君

企业已经买了CRM、ERP、人力资源系统，现在这些软件又开始自带Agent了。原来的供应商说，在现有系统里就能做AI应用；外面的服务商说，可以再搭一套，把不同系统连起来。企业该怎么选？

这事儿不能光比功能列表。两边可能都能查数据、生成报告、跑流程，可真接到实际业务里，要改多少东西、谁来维护，差别可能就大了。

10月21日，Oracle发布了一个面向行业应用的AI Agent Studio，提供创建、测试、编排、部署和监测Agent的环境，说白了就是强调用现有应用里的数据、工具和业务流程。[1] 这次发布其实反映出一个挺值得关注的方向，企业用AI，不一定非得从一个独立的聊天窗口开始，也可以从员工正在用的业务系统里往外扩。

对已经在用这些软件的企业来说，这条路确实挺有吸引力。客户、订单、员工这些资料本来就在系统里，操作权限和审批流程也都是现成的。要是Agent能直接把这些能力用起来，就能少做不少数据搬运和重复配置的活儿。

不过，“系统自带”不等于就一定适合你的业务。到底支持哪些模块、能执行哪些操作、现在这个版本能不能用，还有新功能怎么收费，这些都得一项项确认。发布会上能演示出来的能力，跟你企业当前账号实际能用的能力，中间可能还有段距离。

要是要解决的问题主要就发生在一个系统里，那先看看现有软件能做到哪一步，通常更实在。

比如说，员工已经在CRM里记录客户沟通了，企业只是希望能更快地整理跟进情况、准备下次拜访资料。要是原系统就能干这个，那就没必要光为了换个AI界面，再复制一套客户资料。不然的话，两边信息谁负责更新、改完以后以哪边为准，又成了新的麻烦事。

另搭平台的理由，应该是原系统真解决不了的具体问题。

企业里的活儿经常是跨系统的。准备一份项目经营分析，要用到CRM里的销售承诺、财务系统里的回款、项目管理工具里的交付进展，还有散在文件里的合同条款。单个系统就算有Agent，也不代表它就能把这些信息都接起来。

但跨系统也不是把接口接通就完事了。同一个客户在不同系统里可能名字都不一样，一份订单可能对应好几个交付项目，“收入”“签约额”“到账金额”又是不同的口径。数据是能取出来，可还得确定怎么对应、怎么算，这样的结果才有业务意义。

要是这些关系没理清，独立平台很快就给你生成一份完整报告，结果却把不同口径的数据放在一起比对。这样的结果越流畅，反而越得认真核对。

所以决定另搭之前，企业自己得先想清楚，新平台到底准备补哪一段，是把资料汇集起来，还是提供分析建议，还是说直接去改原系统里的数据、推动后面的流程？这几种用途需要的集成深度和维护投入完全不一样，不能笼统地说一句“建一个企业AI平台”，然后把要干的事儿不断往里塞。

我目前推进的企业AI应用，既有基于WorkBuddy这类第三方平台配置的部分，也有自己研发的系统。具体选哪条路，还是得回到任务本身来看。有些活儿主要靠专业知识、任务分工和工具调用，那用现成平台就能先把流程跑起来；有些活儿对数据处理规则、检查过程和结果还原都有明确要求，那就得单独设计相关功能。

比如说，在AI数据安全处理系统里，企业资料先经过脱敏和安全检查，再交给外部AI工具去分析，分析结果回来后还要按映射关系复原。单独把这一块建起来，用途是很清楚的，数据交出去之前怎么处理、哪些情况必须拦下来、结果回来以后怎么还原，这些都得能查得到。它跟后面的AI分析工具各管一段，没必要为了“另搭一套”，再把所有分析能力也重新做一遍。

业务软件和独立Agent平台之间，其实也可以按这个思路来分工。

原有系统继续保存正式业务记录、执行已经定好的审批流程，Agent就负责整理跨系统资料、提提建议，或者通过受控接口把待审核的内容提交上去。独立平台不一定非得取代原系统，更没必要一上来就要拿到所有系统的写入权限。

当然了，多接一个平台，就多一块需要维护的东西。原系统接口变了、字段调整了、账号权限改了以后，相关流程还能不能正常跑，得有人负责去查。使用过程中要是加了新要求，也得判断是该改原系统、改Agent配置，还是改两者之间的连接。

要是上线的时候只讨论“能不能做出来”，没确定以后谁来维护，企业很可能很快就拿到一个演示挺好看、但谁也不敢随便改的系统。服务商交付完走了，业务人员发现结果不对，技术人员又不了解当初的业务判断，最后只能继续找原来那帮实施人员来处理。

所以比较方案的时候，首次报价只是其中一项，还得了解以后新增业务怎么调整、修改费用怎么算、数据能不能导出来，还有换了服务商以后别人能不能接得上。原系统自带Agent，也得按这些条件去查一遍，不能因为是原来的供应商，就默认后面成本一定更低。

企业完全可以先拿一项真实的活儿，让不同方案各做一次，再比较从准备资料到结果能用，中间实际走了哪些步骤。

原系统本来就能直接干的部分，另搭以后是不是重复了？独立平台多做了些什么，值不值得多出来的维护工作？碰到数据缺失或者口径对不上，两边分别怎么处理？这些过程看清楚了，选择起来会比光听“原生集成”或者“统一入口”这些介绍要具体得多。

要是原系统就差一个小功能，那就先把这个功能补上；要是业务确实跨好几个系统，而且这件事反复发生、投入也有明确用途，那再考虑搭一个独立的协作和分析层。

企业要的是把工作做好。最后用了几个平台，应该是解决问题以后自然形成的结果，不用提前就把“另建一套”当成目标。

参考资料

[1] Oracle，2026年10月21日：Oracle AI Agent Studio for Industry Applications Helps Accelerate Business Outcomes。官方产品公告，所述集成和执行能力适用于其支持的应用与场景，不代表所有Oracle客户当前均可使用全部功能。