甲骨文公开 1124 个技能文件，教智能体配置企业系统

企业软件商开始把自家系统的实施配置经验，写成编程智能体能直接执行的公开技能：上一个 ERP 项目里顾问反复手工做的那段配置，现在有了官方的智能体版本。

我们的看法是，甲骨文这次交出去的是活，不是责任。技能由它来写、来维护，但仓库自己写明这不是产品功能、不在产品支持范围内，配错了的后果仍落在客户和实施商身上。

发生了什么

10 月 26 日，甲骨文在 AI World 大会上发布了 Fusion 设置与配置注册库（FSCR）。据甲骨文的发布稿（企业宣称），这是一个公开的 Git 仓库，把 Fusion 云应用（财务、人力、供应链、客户体验几套系统）的设置与配置写成智能体可执行的技能：OpenAI 等公司的编程智能体可以把业务需求、流程文档和现有配置翻译成实施步骤，直接在系统里完成配置，再自动测试和验证，最后由专家审阅、批准上线。发布稿称它是 Fusion 配置「权威的、机器可读、可执行的来源」，埃森哲、德勤、普华永道、致同等实施商都在稿中表态支持。

我们打开了这个仓库（官方文件）。10 月 26 日读取时，按我们对仓库目录的统计，共有 1124 个技能文件，其中人力资源 457 个、供应链 243 个、客户体验 196 个、财务 101 个，其余是入口路由、通用方法和底层服务。README 写明，这些技能需要 Fusion 26D 版本加 10 月 16 日的维护包才能用，测试用的是 OpenAI 的 GPT 5.6 Terra Medium 模型，并提醒换模型效果会不同；使用者要自己在系统里建授权应用、填自己的凭据，并在执行前审阅生成的方案和改动。

写在仓库里的另一句话

发布稿和仓库对它的定位并不一样。README 第一段就说，FSCR 是「单独发布的样例和参考材料」，「不是 Oracle Fusion Cloud 的产品功能，不在 Fusion Cloud 产品支持范围内」。仓库的安全说明还有一句通用条款：样例代码用来演示概念，未必足够加固到可以用于生产。

分析推断：这两种说法放在一起，意思是甲骨文愿意为「技能写得对不对」持续更新，却不为「智能体照着技能把你的系统改成什么样」兜底。配置一个人力或财务系统，改的是薪资规则、审批流和会计科目，错一处会延续到之后每一笔业务。发布稿里由专家审阅、批准上线这一步，在仓库里落成了使用者自己的责任。

为什么值得在意

甲骨文应用开发执行副总裁 Chris Leone 在发布稿里说，客户和合作伙伴常常要在每个实施项目里重建关键的配置知识，或者依赖很快过时的静态文档。Techzine 的报道（媒体报道）把 FSCR 放在甲骨文更大的思路里：业务目标交给它的智能体层去翻译成交易、流程和审批，而外部智能体能插手的空间比别家小。FSCR 是这条路上对外开的一扇门，进门的是 OpenAI 这类通用编程智能体。

分析推断：如果这套技能真能跑通，实施商卖的东西会从「配置工时」移到「审阅与担责」。几家实施商在发布稿里都说要把精力转向行业方案和流程改造，说法一致，但没有一家给出用了 FSCR 之后项目周期或人数的变化。

最强反方

最有力的反驳是：开源样例不担保，是软件行业的通行写法，并不代表甲骨文在甩锅。真正的责任从来写在实施合同里，由客户和实施商约定；而 FSCR 恰恰保留了人工审阅、测试和批准上线几道关，比顾问凭经验手工配置更可追溯。对客户来说，配置知识随产品版本一起更新，本身就减少了用过期文档配错的风险。

我们接受这一点：免责条款是惯例，审阅环节也确实在。但我们仍坚持，发布稿把它称作「权威来源」、仓库却称作「不受支持的样例」，这个落差需要客户在签实施合同时自己补上，否则智能体配错时，会出现谁都能说「不是我」的局面。

我们不知道什么

我们不知道已经有多少客户或实施项目实际用 FSCR 完成了配置，发布稿和仓库都没有给出使用数字；10 月 26 日仓库只有 15 个星标、3 个分叉，还看不出外部参与。我们没有在真实的 Fusion 环境里运行这些技能，不知道智能体配置的出错率和需要人改回的比例。几家实施商会不会在合同里为智能体完成的配置承担和人工配置同样的责任，目前没有公开条款。

接下来看什么

甲骨文会不会把 FSCR 纳入正式的产品支持；实施商是否公布用它之后的项目周期和人力变化；以及 SAP、Workday 等其他企业软件商，会不会把各自的实施知识也写成智能体技能公开出来。