Oracle的六类实施智能体，瞄准ERP上线之前的工作

Ken Jo根据下方列出的来源制作的原创说明图。

在新业务系统能够批准一张发票之前，必须先有人决定谁有权批准、公司如何组织，以及哪些系统需要与它交换信息。这些决定随后变成设计、配置设置、集成代码和测试。订阅软件，只是这项工作的开始。

Oracle于2026年10月26日宣布，通过Oracle AI Success Navigator提供智能体实施平台，覆盖发现、设计、配置、测试、集成和创新六类角色。Oracle提供财务、人力资源和供应链等业务应用；这次公告聚焦于引入和改进这些应用所需的工作。官方公告。

有意思的变化，在于辅助介入流程的位置。帮助使用现有ERP的智能体在既定配置内工作，而实施智能体帮助创建配置。本文解释Oracle方案背后的注册库、三个实用评估场景，以及项目团队在把生成配置变成真实运营之前应要求哪些证据。

业务规则与设置之间的交接最费工夫

企业资源规划，即ERP，通过共享的应用和数据结构连接核心业务活动。即使供应商发票审批这样熟悉的流程，也包含因组织而异的选择。正确配置取决于这些选择是否被明确作出，并得到一致转换。

举一个假设需求：超过一定金额的发票需要额外审批人。项目团队必须确定金额、币种、业务单位，以及审批人不在时如何处理。实施过程必须让这些决定在设计、设置和测试中保持一致。

漂亮的流程图并不够。如果书面规则与部署配置偏离，系统可能始终如一地做错事。因此，实施包含懂业务、懂软件和懂运行环境的人之间反复交接的工作。

Oracle的方案针对这些交接。机会在于将产品专属知识带入规划与配置，减少各团队重新推导设置逻辑的工作。我们的判断是：真正有意义的结果，是缩短从经过审阅的需求到经过测试、且业务人员能解释其行为的配置之间的路径。

FSCR为智能体提供产品专属指令集

Oracle同日宣布Fusion Setup and Configuration Registry，简称FSCR。公司将其描述为一个公开Git仓库，包含机器可读、可执行的实施知识，涉及配置选项、依赖关系、顺序、测试和验证。Oracle称会随着Fusion Applications共同维护该注册库。2026年10月26日FSCR公告。

这比向智能体提供一堆通用ERP文章更具体。有效的实施指令必须把目标结果连接到相应设置和前置条件，也需要一种方法检查这些设置是否达到预期。

可以把注册库看作与实际厨房对应的菜谱。原料和步骤必须匹配执行工作的软件。忽略必要前置条件的菜谱，即使听起来合理，也可能让应用停在不完整状态。

注册库不会替公司选择业务政策。组织仍需决定审批结构、运营模式和可接受的例外。产品知识有助于把决定转成配置，但不能仅靠生成更长的实施计划来解决利益相关者的分歧。

对项目团队，版本对齐因此成为值得追问的问题。提议配置依据的是哪个产品版本和注册库修订？应用变化后，哪些假设需要重新检查？这些是从注册库方法推导的评估问题，并非声称产品拥有某种特定的自动跟踪控制。

六类智能体把工作拆成可审阅的产物

Oracle在10月26日公告中为新智能体分配不同工作。发现负责了解现状，设计把流程转为应用设计，配置构建原型，测试开发相关用例，集成处理现有系统连接，创新识别进一步采用的机会。这种区分很重要，因为每一阶段都应产出不同审阅者能够理解的成果。

实施团队不应被迫把“AI的工作”当作一个不加区分的整体批准。业务负责人可以检查流程设计，应用专家可以检查配置，测试负责人可以检查用例是否覆盖预期行为。按产物拆分，会让讨论更具体。

前两列概括公告中的角色，审阅问题则是我们提出的评估标准。它们帮助检查有用产物，而不把角色名称当成所有结果质量的保证。结构良好的草稿仍需对照实际使用它的组织进行检验。

实施应保持业务需求与满足它的配置之间的联系。审阅点是建议的评估边界，并非对某个Oracle界面的描述。

财务原型能揭示设计是否足够具体

第一个有用场景，是测试环境中的小型财务流程。选择一条审批规则，包含常规情况、例外，以及应停下来等待审查的情况。目的是在配置开始前，检查提议设计是否把预期行为讲清楚。

例如，团队可以提供一张虚构供应商发票和两位可能的审批人。设计应说明谁处理哪种情况，以及缺少必要信息时怎么办。这些是示例输入，不是本文实际实施过的部署描述。

团队批准设计后，再检查原型如何表达它。有用证据是需求、相关设置和每项测试观察结果之间的关系。常规情况通过令人鼓舞，但例外往往更能揭示设置是否真正反映业务规则。

模糊之处也会在这里显现。如果两位相关方给出不同审批阈值，生成配置并不能解决政策问题。下一步应先解决分歧并记录批准的规则，再重新生成或调整受影响的工作。

集成试验暴露应用之间的工作

第二个场景，是Fusion与现有系统之间有边界的连接。选择一个业务对象，指定哪个系统拥有它、哪些字段需要传输，以及错误如何处理。范围小，才能更容易区分有用的生成集成与大量貌似合理的代码。

假设一次重试让示例客户记录到达两遍。团队应决定接收系统是更新原记录、拒绝重复，还是创建新记录。正确行为取决于业务和技术约定，不应让生成实现把它隐含处理。

要求提供边界处的证据。标识符缺失、目标不可用、字段值不被接收系统接受时会怎样？这些情况把集成讨论从一次成功演示，转为对实际运营行为的审查。

Oracle的FSCR公告明确描述专家审查已完成配置、要求调整并批准部署。对集成产物也应遵循同样纪律：审阅生成工作，用代表性数据测试，并定义失败变更如何恢复。只有维护团队仍能理解连接时，更快创建才有价值。

新智能体尚未全部可用，现有平台也能支持评估

Success Navigator已经有围绕实施和采用的公开产品体验。Oracle于2026年5月11日介绍26.1版本时，讨论了AI Assist首页、更新规划、版本就绪、采用路线图和Starter Configuration。这些现有能力为承接10月智能体新增的平台提供背景。官方26.1版本文章。

因此，第三个评估场景是现有Fusion客户的下一次更新。团队可以确定候选功能、受影响流程，以及必须理解变化的人。目标价值是更连贯地决定是否采用，而不是因为功能出现在发布列表就启用。

让评估与可观察结果相连。如果变化旨在简化审查流程，就先明确当前如何审查，以及什么算改善。随后团队才能判断该功能是否值得投入配置和测试，而不是把推荐直接当作部署指令。

可用性也需要同样精确。10月公告讨论了早期采用者与新增智能体，但未给出所有角色统一的全面供应日期，也没有每个角色独立价格。计划试验前，应确认实际账户适用哪些能力与访问条件。

80%描述的是一次实施中的特定部分

Oracle引用Lexington Health的说法，称通过智能体交付方式，某些设计与配置工作量减少了80%。这一客户表述出现在10月26日公告中。它是早期采用者经验的有用证据，同时有明确的工作范围边界。

这个边界改变了数字的用法。它不是整个ERP项目工期或预算减少80%，也不能证明另一组织会取得相同结果。测试、数据、集成、培训和组织决策，在不同项目中占比不同。

一个示例计算能说明分母为何重要。假设项目在某项设计活动上投入100小时，其他工作投入400小时，该设计活动减少80%就节约80小时，占总计500小时的16%。这些虚构输入只是解释算术，并非Lexington Health项目数据，也不是Oracle性能估计。

应用公开百分比来形成测量问题：哪项活动变短，原先基线是什么，哪些工作仍然存在？这样，团队才能比较自己的有限任务，而不把一个诱人的数字搬进无关的商业论证。

有价值的首次评估应跟随一项需求直至结果

首次试验应小到人能检查完整链条。有明确验收标准的窄流程，比“实施财务”这种宽泛要求更能揭示问题。以下是对公告方案的建议评估步骤。

1. 确认访问与范围。 使用Success Navigator的账户申请路径，确认组织和环境可用哪些已宣布能力。
2. 选择一个业务流程。 明确负责人、预期结果和例外，使用测试环境及适当样本数据。
3. 记录起始基线。 估算或测量该具体任务当前所需努力，把无关项目活动排除在比较之外。
4. 审阅提议设计。 配置前解决模糊需求，保留获批决定与相关产品假设。
5. 检查原型与集成。 将重要设置和字段映射追溯至设计，联系不清时要求修改。
6. 运行常规及例外情况。 检查成功工作、缺失信息、重复请求和相关失败条件，记录结果而不只记录生成解释。
7. 决定是否扩大。 将有效产出、审阅努力和返工与基线比较，在扩范围前分配持续维护责任。

测量完整且有边界的任务，包括审阅和返工。生成工作量下降只是结果的一项贡献，不能替代其余实施工作。

审阅负担尤其能说明问题。如果智能体迅速生成配置，但专家批准时必须重建每个假设，表面节约可能只是把工作从一个阶段移到另一个阶段。相反，清晰设计和可复现测试，即使生成并非瞬间完成，也能让审阅更容易。

实施智能体靠人能解释的配置赢得信任

Oracle的方式把产品知识、可执行设置指令和专业角色带入同一实施流程。值得期待的结果，是业务批准内容与应用实际行为之间更直接的联系。当审阅者可以检查、测试，并在初始项目结束后维护这条联系时，它才产生价值。

因此，正确的第一个问题很具体：团队能否让一项真实需求经过设计、配置和测试，减少可避免的工作，并得到更清楚的结果？成功回答这个问题，才能为下一次实施决定提供扎实基础。

来源

• Oracle智能体实施平台公告，2026年10月26日：六类角色、早期采用及Lexington Health表述。
• Oracle Fusion Setup and Configuration Registry公告，2026年10月26日：注册库范围与审阅方式。
• Oracle AI Success Navigator 26.1版本文章，2026年5月11日：现有平台能力。
• Oracle AI Success Navigator产品页面与Oracle截图使用政策，2026年10月27日查阅：公开界面、账户申请路径与图片使用条件。

场景、建议评估标准以及500小时算例均为示例。客户百分比保留其明确出处和范围；本文未进行实施基准测试。

---

Telli.sh推荐： 随项目推进，让实施研讨记录、获批决定和参考资料始终便于回顾。创建Telli.sh账户，整理项目笔记。