没有 API 的老系统，可以先按具体工作拆分接入方式：查数据用已授权的报表或只读视图，批量录入看导入模板，少量页面动作再评估界面自动操作。是否可行要逐项确认，不能把“能打开软件”当成所有业务都能交给 Agent。
盘点从一张业务表开始。每行写清谁需要处理什么、多久处理一次、允许数据延迟多久、需要读取还是修改。这样可以把月底汇总与实时库存占用分开，避免为低频报表做过大的改造。
接入方式的适用条件
| 可用条件 | 可设计的工作 | 必须核对的限制 |
|---|---|---|
| 有固定报表导出 | 日度核对、清单分析 | 筛选范围、导出时间、漏页与字段变化 |
| 可提供只读数据视图 | 按条件查询业务记录 | 字段解释、数据范围、作废与删除口径 |
| 有批量导入模板 | 生成待导入单据 | 模板版本、失败明细、重复导入处理 |
| 仅能通过页面操作 | 少量固定步骤办理 | 登录、弹窗、对象定位、保存结果 |
| 原维护方可补接口 | 高频业务查询或提交 | 接口范围、维护责任、交付测试 |
表中的方式可以组合。例如用报表找出缺项，由员工补齐后生成导入文件，再用系统导入结果核对每行处理情况。组合方案仍须逐段写明负责人，不能只在图上画几条箭头。
盘点时请维护方现场演示候选入口，并保留脱敏样本。对方说“可以导出”，还需要看能否导出全部所需字段、是否受当前账号范围限制，以及跨页记录是否完整。对方说“支持导入”，则要检查新增、修改和部分失败分别怎样返回结果。这些证据决定接入范围，不能只凭产品介绍勾选可用。
对于只需每周分析一次的工作，人工按规范导出也可以作为明确的交接环节。把提取人和提交时间写入操作表，报告出现缺数时才能知道应补哪份文件。
关于不同技术承担的工作，可先了解RPA 与 AI Agent 的适用场景。本次盘点更需要关注现有软件实际允许的出入口。
导出文件的接收标准
每个导出文件建议附带四项信息：系统与报表名称、提取时间、筛选条件、应有记录数。文件名可以方便人识别，但不能只靠文件名判断数据日期；同一份文件被重复上传时，应识别为同一批次。
接收后先检查必需列是否存在、编号是否为空、合计行是否混入明细、日期与数量是否可读。列位置变化但字段名不变时按字段识别；字段含义发生变化时暂停处理，交给维护人员更新映射。
还应区分全量文件与增量文件。昨天导出的订单今天没有出现，可能只是今天筛选范围不同，不能据此判定订单已经删除。需要做连续跟踪时，必须先约定哪些情况代表退出范围、作废或取消。
读取数据库的业务边界
若获得授权使用只读数据视图，应让原系统维护方说明业务状态和关联关系。相同编号在主表、历史表、临时表中可能承担不同含义，不能凭表名直接合并统计。
查询交付资料应给出有效记录条件、金额单位、状态解释和样本核对结果。写入动作仍通过原系统认可的业务入口办理；不把读取数据的通道顺手扩成直接修改底表的工具。字段治理可参考为 Agent 准备业务事实源。
示例：老采购系统的到货核对
以下为接入示例：采购员每天下班前导出未到货采购单，文件含采购单号、行号、物料、数量与到货日期。Agent 将其与仓库当天的收货记录比较，输出待核对行，注明两份文件的提取时间。
出现“已收货但采购报表未更新”时，任务留给采购员查原系统，暂不自动补收货单。若核对后需要批量修改备注，则生成系统认可的导入模板，由负责人确认后导入。
导入后收回成功记录和失败明细，按采购单号加行号逐条核对。处理报告列出已匹配、缺编号、部分到货和无法判断的记录，不能只汇总“本次处理多少条”。示例中的输入、输出与异常类别都可以直接放入验收表。
页面操作的维护约定
只剩页面入口时，建议先选对象明确、步骤固定、可查询结果的动作。测试除了正常填写，还包括窗口大小变化、搜索结果多条、登录过期、临时弹窗和保存后无反馈。缺少确定结果时，停在待核对状态。
同时约定谁通知页面更新、谁维护操作流程、暂停期间谁接手。每次改版用保留样本重新验证，不让维护责任落到实际使用人员临时摸索。
方案最后应交付一份能力清单：可直接接、需人工交接、需补接口、暂不开放。每项注明数据时间、输入输出、责任人和验收样本。需要补充查询视图或业务接口，可通过定制开发服务按这份清单确定改造范围。
