系统集成没有银弹，只有对业务场景的清醒判断。

财务共享中心最怕什么？不是单据太多，而是“数据在系统里，但流程没连上”。

一笔采购付款，采购订单在 ERP，入库记录在 WMS，发票在税务平台，付款指令在网银。财务人员的工作本质上是在这些系统之间“人肉搬运”数据，然后再用 Excel 做三单匹配。年审单量到十万级之后，这种模式就撞上了天花板。

财务 Agent 的价值，不是替代某一个系统，而是 连接现有系统 。ERP 仍然管资源计划，OA 仍然管审批流，Agent 负责在它们之间搬运、校验和补充数据 。

但怎么“接”进去，才是真正考验架构选型的环节。目前主流的接入方式可以归纳为三条路线：API 直连、RPA 界面操作、混合模式。三条路线没有绝对优劣，只有场景匹配度。

路线一：API 直连——最规范，也最受限

API 是 ERP 厂商开放的标准化接口。SAP 有 BAPI，Oracle 有 REST API，用友金蝶也提供了 OpenAPI 体系。通过 API 读写数据，效率高、稳定性好，不依赖界面渲染，适合批量数据处理和实时同步 。

这条路线的问题在于 接口开放程度参差不齐 。SAP、Oracle 等国际厂商的接口体系相对成熟，但国内大量中小企业的 ERP 要么没有开放接口，要么只开放了查询权限，写入操作需要单独采购或定制开发 。

更隐蔽的问题是 数据口径 。ERP 界面上的“订单金额”和数据库里实际存储的字段可能是两回事——界面做了加工后的展示，API 返回的也可能是聚合后的结果。如果 Agent 需要做细粒度的三单匹配，必须先搞清楚目标字段的真实来源和计算逻辑。

API 直连适合的场景很明确： 系统开放、字段清晰、数据量大、对实时性有要求 。比如从 SAP 批量拉取应付账款明细用于对账，或向金蝶写入审核通过的付款单。

路线二：RPA 界面操作——最通用，也最脆弱

RPA 不依赖接口，模拟人的鼠标键盘操作，理论上可以操作任何有界面的系统。对于没有 API 的老旧 ERP、网银客户端、税务局网站，这是唯一可行的自动化路径 。

但 RPA 有两个硬伤。

第一个是效率。 每一步操作都要模拟点击、等待页面加载、识别元素，处理速度远低于 API 调用。一张凭证的录入可能涉及十几个界面交互，批量处理时延迟会累积。

第二个是脆弱性。 界面按钮位置变了、弹窗顺序调整了、分辨率变了，基于坐标或固定选择器的脚本就会失效。ERP 升级一次，可能需要重新调试大量流程 。

传统 RPA 的应对方式是不断维护选择器，但这本质上是在用人力对抗系统的自然演化。

实在 Agent 在这一路线上做了一个关键的技术转向： 不依赖坐标和固定选择器，而是“看懂”屏幕 。它采用 ISSUT 屏幕语义理解技术，通过视觉模型实时解析屏幕上的可交互元素，再结合大语言模型理解元素的业务含义，动态生成操作序列 。换句话说，它不是记住“提交按钮在 (500, 300) 这个坐标”，而是理解“那个蓝色的、在表单右下角的按钮是提交”。界面改版后，只要业务语义不变，Agent 仍然能完成任务。

这让 RPA 路线的 维护成本 有了实质性下降，但效率问题依然存在。因此它最适合的场景是 接口缺失、操作频率不高、但业务价值明确的环节 ——比如登录网银下载回单、在税务平台填报申报表。

路线三：混合模式——务实但需要架构设计

纯 API 和纯 RPA 都有明确的边界，现实中大多数企业不会走极端。混合模式的核心逻辑是： 能走 API 的走 API，走不通的走 RPA，然后在 Agent 层做统一编排 。

腾讯云在一篇关于智能体与 ERP 集成的分析中提出了“标准化连接器 + 统一适配层”的思路：在平台侧同时维护 API 连接器、Web 连接器和桌面 GUI 连接器，上层通过统一适配层做协议适配、会话管理、异常重试，屏蔽底层差异 。

这个架构的关键在于 路由决策 。Agent 需要知道什么情况下走 API、什么情况下走 RPA。一个务实的判断标准是：

• 查询类操作优先 API ：拉取订单列表、读取预算余额、查询供应商主数据，API 更快更稳。

• 写入类操作看接口开放度 ：如果 ERP 提供了写入接口且权限可控，优先 API；如果没有或权限受限，降级到 RPA。

• 涉及界面交互的操作只能走 RPA ：网银登录、税务申报、老旧系统的表单填写。

实在 Agent 的实践中有一个典型的混合模式案例：在三单匹配场景中，它通过 API 从 ERP 抓取订单数据，同时通过 RPA 登录银行系统下载流水 Excel，然后在 Agent 内部完成匹配和差异标记 。两条通道各取所长，Agent 负责最后的逻辑判断。

怎么选：一个决策框架

三条路线怎么选，可以从四个维度来判断。

接口开放度 是第一道门槛。如果目标系统的 API 完善且覆盖所需操作，优先 API。如果接口缺失或仅支持查询，直接考虑 RPA 或混合模式。

操作类型 决定了对稳定性的要求。查询类操作对失败容忍度高，RPA 慢一点可以接受。写入类操作涉及数据一致性，API 的事务控制能力更有优势。实在 Agent 在这一点上做了一个值得参考的设计：写 ERP 之前先做 主数据校验 ，确认客户编码、物料版本、金额规则都合规后再执行写入，降低错误写入的风险。

变更频率 影响长期维护成本。ERP 界面频繁调整的场景，RPA 的维护成本会被放大；相对稳定的系统，RPA 的性价比更高。ISSUT 这类语义理解技术能降低界面变更带来的维护负担，但并非完全免疫。

数据敏感度 决定部署方式。财务数据天然敏感，央国企还有信创要求。API 直连需要管理好鉴权和审计，RPA 操作需要在受控环境中运行，Agent 本身最好支持私有化部署。

从工单到凭证：一个完整的链路长什么样

把上面的路线组合起来，一个完整的“工单到凭证”链路大致是这样的：

Agent 通过 API 从 MES 获取完工工单数据，与 ERP 中的生产订单和物料领用记录做核验 ；核验通过后，通过 API 或 RPA 在 ERP 中生成成本归集凭证；涉及付款的环节，Agent 通过 RPA 登录网银完成支付，再获取电子回单，匹配后回写 ERP 完成闭环。

这条链路上，API 和 RPA 交替出现，Agent 的角色是 调度者和判断者 。它不关心底层是走接口还是走界面，只关心“这个任务需要访问哪个系统、需要什么数据、需要执行什么操作”，然后选择最合适的通道。

实在 Agent 在这条链路上的定位是 执行通道之上的智能层 。它提供的不只是 RPA 的执行能力，还包括 TARS 大模型对单据和规则的语义理解、ISSUT 对界面的自适应操作、以及规则引擎对审核逻辑的确定性执行。这三层能力叠加，才让“从工单到凭证”的自动化闭环在真实的企业环境中跑得通。

一句话建议

接口开放的系统用 API，接口封闭的系统用 RPA，但在 Agent 层做统一编排。 不要在项目开始时就追求“全部 API 化”，也不要把 RPA 当成通用替代品。先梳理清楚每个环节的系统条件和操作类型，再决定接入方式。在混合架构中，Agent 的价值不在于它用了哪种技术，而在于它 知道什么时候该用哪种技术 。