ber，ERP × WorkBuddy居然这么简单，这么好用？！

技术团队验证 ERP 与 Agent 的协作路径

企业的ERP系统已经覆盖订单、库存、生产、采购、财务和审批，功能通常已经覆盖公司信息化运营所需，但从最终使用者视角看，完成一项工作仍然要先理解系统结构：进入哪个模块、选择哪张报表、哪些字段需要组合、下一步该找谁确认。

本次测试不基于某个特定场景，也不预设“Agent 一定更好”。我们使用匿名 ERP 测试数据，对传统页面操作与 WorkBuddy + Lovrabet 的使用路径进行对照，重点观察三个问题：

• 最终用户是否可以从业务目标出发，而不是从ERP系统菜单寻找表单出发；

• AI 返回的是一个数字，还是包含业务口径、权限和依据的结果；

• 从查询到执行，系统是否保留人工确认、ERP 写回和审计边界。

  
  

我们的测试结论是：Agent 化的价值不只是减少点击，而是把“人适应系统”逐步改成“系统围绕任务组织能力”。

我们怎样测试：同一份 ERP 数据，两种完成方式

测试环境包含销售订单、库存占用、质检状态、生产工单、客户信用和发货审批六类数据。测试任务固定为：检查本周需要交付的订单，识别风险，追溯原因，并生成等待人工确认的处理预览。

传统路径以系统结构为中心。使用者需要知道订单在哪个模块、库存余额与可用库存有什么区别、质检和信用状态去哪里查，再把多个页面的结果拼成判断。

测试对象为在该岗位上工作2年经验的员工，符合公司普遍用户画像

Agent 路径以任务为中心。使用者在 WorkBuddy 说明要完成什么；Lovrabet 在后台按业务模型和权限关联 ERP 数据与功能；结果、依据和动作预览回到 WorkBuddy；需要承担责任的动作仍由人确认。

这并不意味着 ERP 页面失去价值。稳定录入、批量维护、专业配置和例外处理仍然适合页面。变化主要发生在高频的查询、分析、协调和任务发起环节。

第一个观察：会查数据，不等于会回答业务问题

为了验证 AI 是否只是在“查表”，技术团队构造了一组容易误判的数据：账面库存 1200 件，待交订单需要 800 件；其中 500 件已被其他订单锁定，300 件尚未通过质检，同时客户发货状态处于信用复核。

如果只调用库存余额接口，系统很容易给出“库存充足”的答案。但按业务口径计算，这张订单当前可用库存只有 400 件，而且即使后续补齐库存，也不能绕过信用复核。

账面库存- 已锁定数量- 待检、冻结与已拣未出库数量= 当前订单可用库存

可用库存满足+ 生产时间满足+ 信用状态通过+ 发货审批完成= 可以承诺交付

测试中最关键的差别，不是 AI 有没有拿到 1200 这个数字，而是它知不知道这个数字在当前订单里能不能用。

在 WorkBuddy 中，测试任务被拆成三轮

我们没有使用一段大而全的提示词，而是模拟最终用户真实的连续工作：先发现问题，再核对依据，最后生成可确认的处理方案。

第一轮：检查交付风险

使用提示词：

检查本周五前需要发货、且在当前账号数据权限内的销售订单。排除已取消、测试和已完成订单；关联订单行、可用库存、质检、生产工单、信用状态和发货审批。按延期风险排序，列出阻塞节点和判断依据。只生成风险清单，不修改 ERP 数据。

第二轮：核对最高风险订单，证据追溯

使用提示词：

继续分析刚才风险最高的测试订单。区分账面库存与订单可用库存，拆分锁定、待检、冻结和已拣未出库数量；追踪生产补齐时间，并核对信用与审批状态。返回原始记录和所使用的企业口径，不得只用库存余额下结论。

观察结果：返回内容从“库存不足”进一步拆成可核验的证据，测试人员可以看到数字来自哪里、哪条规则影响判断。

第三轮：生成处理动作预览

使用提示词：

基于已确认的缺口，生成处理方案预览。比较补产、分批交付和调整承诺日期三种方案，列出数量、日期、影响订单、责任人和所需审批。相关负责人确认前，不得改交期、重新分配库存、创建工单或通知外部人员。

观察结果：WorkBuddy 展示方案和影响范围，但不直接越过审批边界，由人确认后， Lovrabet 才调用 ERP 已有功能完成写回与留痕。

WorkBuddy 中的匿名 ERP Agent 测试结果

ERP到Workbuddy中间的转化，是由Lovrabet串联完成的

ERP 的功能、数据库、接口、账号权限和业务流程，最初都是围绕页面和固定流程操作设计的，而WorkBuddy 面向的则是自然语言任务，两者之间如果只做 API 连接，AI 虽然有了“手”，仍然未必知道应该调用什么、怎样组合、结果是否符合企业口径。

测试中，Lovrabet 主要完成四类转化：

从表和字段转成业务对象。AI 看到的不再只是订单表、库存表和状态码，而是客户、订单、物料、可用库存、信用与审批之间的关系。

从系统账号转成 Agent 权限。当前用户能看哪些组织、客户和订单，哪些字段需要脱敏，哪些动作可以发起，继续沿用企业已有边界。

从 ERP 功能转成可调用的业务能力。查询、校验、生成单据、提交审批和写回状态被组织成稳定能力，而不是让 Agent 临时猜接口。

从一次处理转成可复用的 Skill。企业确认过的口径、提示词、人工门禁和执行顺序可以沉淀下来，供后续同类任务复用。

因此，Lovrabet 不是简单的数据中转层，而是把 ERP 资产和数据资产转化为 AI 能理解、能调用、受权限控制、可审计、可以持续复用的企业业务能力。

从最终用户角度，我们观察到四个变化：

任务入口更自然。用户先说要完成什么，不必先判断功能属于销售、库存、生产还是财务模块。

结果更容易核验。答案同时带回业务口径、来源记录和风险依据，用户不必把多个页面抄到一起重新证明。

跨模块工作更连续。发现风险、追溯原因、生成方案和发起审批可以围绕同一上下文继续，不必每换一个模块就重新开始。

关键责任没有被 AI 隐去。改交期、占库存、创建工单、提交审批和外部通知仍有明确的人、权限和审计记录。

最终用户感受到的便利，不是 ERP 突然消失了，而是不用再把 ERP 的结构背在脑子里。从而大大降低了员工的培训成本和上手门槛。

测试也暴露了三个前提：

第一，Agent 化不是零配置魔法。ERP 数据关系、字段含义、业务口径和权限边界仍需要在初始关联阶段让熟悉企业业务的人员确认，这样模型才会越准确。

第二，写操作必须建立在可靠能力上。库存分配、财务状态和审批流转不能靠大模型自由发挥，需要靠Lovrabet的 API、SQL、BFF 或 Backend Function 来承接。

第三，高风险动作不应为了“全自动”而取消人工审核过程。Agent 可以准备数据、生成预览和执行建议，但企业必须明确谁有权限确认、谁承担结果，并对AI执行动作进行确认和留痕。

以上分析是本次测试没有用“ERP 将被 Agent 替代”作为结论的原因，更谨慎的判断是：ERP 可继续提供可靠记录与管理能力，WorkBuddy 改善最终用户的工作入口、上手难度与工作效率。

通过Lovrabet 负责把ERP和Workbuddy串联在一起，组织成可理解、可执行、可治理的运行体系，过程意外的简单。

值得关注的是：企业系统的Agent化趋势，不是对话框有多聪明，而是员工能否从一句业务目标出发，得到有依据的结果，并在正确的权限内能把事情办完。