Fragment

Fragment 是面向大型制造商、分销商和能源企业的采购与应付账款 AI 平台。它关注采购订单变更、发票差异、收货记录缺失等跨系统异常，通过理解企业规则、合同和业务记录，让代理在授权范围内调查问题、执行处理并保留审计线索。对于仍靠人工在 ERP、表格和供应商邮件之间反复核对的团队，它提供了一条不以更换核心系统为前提的自动化路径。

产品背景与近期动态

产品由 Fragment Data Technologies, Inc. 提供，官网为 fragment.ai，与同名的其他交易或开发工具无关。2026年10月28日，公司宣布正式推出平台，并披露累计获得5600万美元融资，其中包含由8VC领投的A轮和此前种子轮。这是累计融资额，不能理解为A轮单轮金额。公司发布稿

Fragment 的核心是 Autonomous Context Engine（ACE，自主上下文引擎）。官方介绍称，它连接 ERP、MES、表格和供应商门户，把企业政策与业务关系组织成代理可使用的上下文；处理逻辑和实际动作应能追溯。这里的“无需迁移”指沿用现有数据系统，并不代表企业可以省略接口授权、字段核对和安全审查。ACE说明

核心功能与应用场景

• 发票异常与三单匹配：对照采购订单、收货记录和发票，区分价格、数量、税费或缺失记录等问题，再按企业设定的容差和升级规则处理。例如，发现缺少收货确认时，需要向相应系统和人员补证，而非直接把发票视为有效。发票场景
• 采购订单变更：读取需求变化，核对数量、日期与合同价格，跟踪供应商确认，并将确认后的变更写回系统。高金额修改、新供应商或特定品类可以保留人工审批节点。订单变更场景
• 跨系统执行与追溯：将异常调查、沟通和处理串成流程，减少信息在采购、仓库与财务之间反复转交。审阅时应同时看原始记录、代理判断和最终动作，不能仅凭一段解释文字确认业务已经正确完成。

典型适用对象是订单量较大、系统分散、异常处理频繁的采购运营、应付账款和共享服务团队。只有少量票据的个人用户，或只是需要识别发票图片的公司，未必需要如此完整的企业实施方案。

建议怎样开始使用

1. 选定一个具体流程。先统计某类异常的数量、处理时长和错误成本，例如缺少收货记录的发票。不要一开始就把所有采购工作都交给代理。
2. 联系官方演示。在 Request demo 页面说明现有系统和业务难点，要求用相近任务展示完整处理链。初次沟通优先采用脱敏示例，不上传无权分享的合同或供应商资料。
3. 确认数据与动作边界。列出允许读取的数据、允许写回的字段、金额阈值、审批人和回滚方式。仅为演示而开放生产付款权限，没有必要。
4. 先验证，再扩大自动化。先让系统在测试环境或只读模式下给出处理建议，对照人工结果检查；通过后才逐步放开低风险动作，并抽查误处理、漏处理和升级人工的情况。
5. 按业务结果验收。比较相同任务下的结案时间、人工介入次数、处理正确率和审计记录完整性。供应商宣传的部署速度或自动处理比例，不应直接作为本企业的验收成绩。

与相关方案怎么选

比较依据为 SAP采购到付款产品说明及 UiPath采购到付款说明。三者范围有交集，也可能与现有系统协同；不能只按“有没有AI”决定替换。更有效的做法是用同一组异常、相同审批条件和实际集成成本进行比较。

费用、部署和使用限制

费用：公开入口以企业演示和方案沟通为主，没有可据以计算统一月费的公开价目表。服务条款规定费用、期限和用量规则由具体订单约定。询价时应分别确认实施费用、流程数量、处理量、超额计费和持续支持，不把融资新闻或演示预约理解为免费试用。服务条款

监督责任：条款明确提示模型输出可能不完整或不准确，客户需按风险进行审阅，并合理设置审批、沙箱与回滚。采购数量、供应商资料和付款相关记录都是可能产生实际损失的字段，允许读取与允许执行应分别授权。

数据与可用性：部署前需确认系统版本、接口、数据处理位置、保留策略和第三方模型供应商。中文业务支持、特定地区可用性以及本地私有化部署不能从英文官网推定，应由销售和实施团队确认。无需更换ERP也不等于无需实施工作。

效果判断：官网展示的客户案例和自动化比例属于厂商披露，并非对所有行业的保证。更值得关注的是一笔异常为什么被处理、谁批准了动作，以及出错后能否定位和恢复。

签约前还应约定异常升级后的责任归属：供应商未确认、数据互相冲突或审批人离岗时，流程应停在哪里、由谁接手，以及如何避免重复提交同一笔变更。这些细节直接影响日常可用性。

使用建议

如果企业已经有核心采购系统，却仍被大量跨系统例外拖慢，Fragment 值得放进试点评估名单。先围绕一种异常建立可靠闭环，再扩大到相邻流程，通常比追求一次性“全自主采购”更容易看清收益与风险。它的价值应由可核对的处理结果证明，而不是由代理数量或融资金额决定。