在企业内部做 AI 自动化，真正决定成败的往往不是模型会不会理解一句话，而是这句话能不能被安全、稳定、可追踪地转化为系统动作。

采购提单就是一个典型场景。用户看到的是“创建订单、生成合同、发起付款”，系统背后却牵涉 OA 流程、主数据、字段映射、附件、审批规则、流程版本和调用审计。通用 AI Agent 可以理解自然语言，也可以模拟人操作页面，但一旦进入生产场景，仅靠“会点页面”很难支撑强规则业务的稳定执行。

围绕这一问题，信也科技建设了采购智能提单机器人，并将它从概念验证推进到实际运行：目前订单和合同模块已上线，订单模块提单效率提升约 20%；付款模块处于灰度验证阶段，全流程提单效率预计提升 50% 以上，累计可节省 0.8～0.9 人力，带动采购业务整体提效约 8%～9%。

这篇文章复盘的不是“如何做一个聊天机器人”，而是一次更有代表性的工程化转向：从让 AI 模拟人点击页面，转向让 AI 通过“企业微信入口 + Dify 编排 + OAX API 执行 + OA 流程系统”的链路接入真实业务系统。注：OAX是我们专门用于对外桥接OA系统能力的子系统。

核心观点可以概括为一句话：不要让 AI 直接点页面，而要让 AI 调用被工程化约束过的系统能力。

本文的实践亮点主要有三点：

• 从探索中抽象边界：浏览器自动化验证了采购自动化方向，也暴露出通用工具接入内部系统时在稳定性、并发隔离和审计追踪上的生产化边界；

• 从工具使用走向系统联动：把 Agent、Dify 工作流、OAX API、OA 系统放在各自合适的位置，形成“模型理解、工作流编排、接口执行、系统沉淀”的分工；

• 从单点提效走向可运营链路：通过接口执行、上下文隔离和调用记录，让采购机器人具备上线运行、问题复盘和持续优化的基础。

一、场景现状：采购提单不是简单的表单代填

在企业采购场景中，采购订单、合同申请、付款申请等流程与内部 OA 系统深度绑定。采购人员日常不仅要录入供应商、采购公司、采购金额、税率、附件、合同编号等字段，还要在采购申请、采购订单、合同、付款单之间反复查询和校验关联信息。

这类工作表面上是“提单”，实际上是一个跨系统、跨流程、跨规则的联动过程：

• 采购申请会影响采购订单的生成；

• 订单信息会继续影响合同创建；

• 合同状态、付款节点和预算规则又会影响付款申请；

• 附件、金额、供应商、采购公司等字段必须有明确来源；

• 任一节点字段缺失、来源不清或校验错误，都可能导致审批无法推进，甚至需要人工回退重做。

从使用体验看，采购人员面对的是多个系统入口、多张流程表单和多轮材料补充；从系统实现看，背后则涉及主数据、流程版本、字段映射、附件处理、审批流转和调用记录。

因此，采购提效的关键并不只是减少几次页面点击，而是降低跨流程信息整理、业务规则复用和系统执行确认的成本。

二、前期探索：浏览器自动化验证了方向，也暴露了边界

采购中心团队希望引入 AI 能力，对采购全链路进行自动化提效。前期探索中，团队曾尝试让通用 AI Agent 通过浏览器自动化模拟人工操作，在 OA 页面上完成提单。

这个方向在概念验证阶段很直观：用户提出诉求，Agent 打开页面、识别字段、点击按钮、提交表单，看起来确实像是“AI 帮人完成了操作”。它证明了采购自动化具备可行性，也让团队更快看到了真实生产场景中的关键约束。

1. 页面入口不稳定

浏览器自动化依赖页面结构、按钮位置、弹窗状态和加载时序。采购订单、合同申请、付款申请都是多步骤流程，Agent 需要等待页面加载、字段渲染、下拉选择、附件上传和审批动作。页面稍有调整，自动化链路就可能失效。

2. 业务规则难复用

采购提单不是简单的表单代填。很多字段需要结合采购申请、采购订单、供应商档案、合同信息、预算与付款规则共同判断。仅靠页面识别和提示词约束，Agent 很难稳定复用内部采购规则，也无法保证字段来源真实可靠。

3. 关键字段来源不可控

合同金额、采购建议、附件、加签人、付款节点等字段，不能由模型自由生成。浏览器自动化看到的是页面展示结果，缺少对后端数据来源、字段映射和校验规则的确定性控制。一旦模型“看起来填对了”，但字段来源不可靠，后续审批风险反而更高。

4. 多用户并发隔离困难

真实采购场景中，多个用户可能同时创建订单、合同和付款单。如果依赖浏览器会话模拟，登录态、页面缓存、临时表单状态和附件上下文都可能互相影响。浏览器实例隔离可以缓解一部分问题，但成本高、链路长、排障复杂。

5. 异常链路难追踪

页面自动化出现异常后，很难快速判断问题来自页面结构、网络、权限、业务规则、字段映射还是模型决策。对于采购、财务、OA 这类具备审计属性的流程来说，“异常后说不清原因”本身就是生产级落地的风险。

这次探索的价值在于，它没有停留在“页面能不能点通”，而是帮助我们识别出通用 AI 工具进入内部系统时的生产化边界：通用工具擅长理解意图和组织动作，但不适合直接承接强规则业务系统的最终执行。

三、目标转向：不让 AI 点页面，而是让 AI 接入工程链路

基于前期问题，后续落地不再把目标定义为“让 AI 像人一样操作 OA 页面”，而是转向一条更适合生产环境的工程化路径：

AI 负责理解诉求和推动流程，Dify 负责业务编排，OAX API 负责确定性执行，OA 系统负责流程审批和业务沉淀。

这个转向背后的核心原则是：

• 入口可以自然语言化，但执行必须系统化

用户可以通过自然语言表达采购诉求，但真正创建流程、校验字段、匹配主数据时，必须走稳定接口。

• 模型可以抽取候选信息，但不能成为关键字段事实源

金额、附件、供应商、加签人、付款节点等关键字段，必须来自用户明确输入、系统查询结果或后端规则判断。

• 工作流可以编排动作，但业务规则要下沉到后端

Dify 工作流适合承接步骤编排和工具调用，流程版本解析、字段映射、主数据匹配和 OA 写入则应由 OAX API 承担。

• 每次执行都要可追踪、可复盘、可优化

机器人创建了什么、谁发起、调用了哪个工作流、成功还是异常、异常原因是什么，都必须沉淀下来。

这也是本文的核心目的：以采购提单为切口，沉淀一套第三方或通用 AI 工具接入内部业务系统的工程化方法。

四、整体方案：企微入口 + Dify 编排 + OAX API 执行

最终方案采用“企业微信统一入口 + Dify Agent 编排 + Dify 工作流承接 + OAX 后端 API 深度联动”的架构。整体设计遵循一个清晰分工：入口自然语言化，过程工作流化，执行接口化，结果可追踪化。

整体链路可以拆成五层：

• 企业微信交互层：采购人员在企微中发起对话、上传材料、接收执行结果；

• 企微桥接服务层：承接企微消息、文件、卡片交互和用户身份信息，完成消息解析与上下文传递；

• Dify Agent 编排层：完成用户意图识别、字段抽取、参数状态维护、工具选择和结果组织；

• Dify 工作流层：将采购相关 API 工具抽象成可复用工作流，分别承接订单、合同、付款、查询、撤单等业务动作；

• OAX API 执行层：对接 OA 系统能力，完成业务校验、主数据匹配、流程字段组装、OA 写入和调用记录沉淀。

这套方案的关键变化是：AI 不直接操作 OA 页面，而是通过 Dify Agent 调用 Dify 工作流，再由工作流触发 OAX API。Dify 负责“理解、编排和流程串联”，OAX 负责“规则、校验和执行”，企微负责“入口和反馈”。

换句话说，模型不再是业务执行的终点，而是系统链路的起点：它负责把用户意图翻译成结构化动作，真正的规则校验、字段组装和流程写入则交给后端接口完成。

相比前期浏览器自动化尝试，这套方案的独特点不在于单独使用了某个工具，而在于把通用工具放回合适的工程边界中：

前期页面模拟方式	后续工程化联动方式
Agent 直接操作 OA 页面	Agent 只负责理解诉求和选择动作
页面结构和加载时序影响稳定性	OAX API 承接确定性执行
模型容易成为事实判断来源	关键字段来自用户输入、OA 查询和后端校验
异常原因依赖人工排查	调用记录沉淀用户、接口、状态和异常原因
单流程可验证，多流程并发困难	通过会话、工作流和接口调用隔离上下文

这也是采购机器人能够从 Demo 走向上线的核心原因：它没有把 AI 当成一个“自动点页面的人”，而是把 AI 放进一条可管理、可追踪、可持续优化的系统链路里。

五、交互设计：把企业微信变成低门槛业务入口

采购自动化如果只能在独立平台中使用，推广成本会比较高。采购人员仍然需要记住入口、切换系统、理解操作界面。为了降低使用门槛，方案选择将企业微信作为前端交互载体。

用户可以直接在企微中描述自己的采购诉求，例如：

帮我根据这几个采购申请创建采购订单。

或者：

根据这个采购订单生成合同申请。

企微入口承担的不只是消息转发，还包括多格式文件接收、用户身份识别、会话上下文维护和结果反馈。对于采购人员来说，整个过程更接近一次自然对话，而不是一次系统填报。

以采购订单创建为例，用户只需要在企业微信里直接说明“帮我创建采购订单”。对用户来说，入口不是一张复杂表单，而是一个可以直接表达业务目标的对话窗口。

真实案例：企微中发起采购订单创建

在联调和测试过程中，企微桥接服务链路，用于验证企微消息收发、回调参数、用户上下文、文件传递和机器人响应是否符合预期。通过这层桥接，企业微信与后端 AI 编排服务之间形成了稳定的数据通道。

 

这种入口设计带来的直接收益是：用户无需理解底层 Agent、工作流和 OA 接口，只需要表达采购目标。复杂的字段抽取、规则判断和单据创建动作，都由机器人在后台完成。

六、编排设计：Dify 负责流程推进，不承接最终业务判断

Dify 在采购机器人中承担的不是简单问答角色，而是面向业务流程的 Agent 编排平台。

如果只把 AI 当成问答机器人，采购自动化很容易退化成大量提示词堆叠：每个场景都要写规则，每个异常都要补充说明，每次流程变化都要修改提示词。短期能跑通，长期会变成难维护的“提示词系统”。

因此，方案没有把所有逻辑都塞进一个大提示词，而是把采购相关 API 能力抽象成多个 Dify 工作流，再基于 Dify 快速搭建 Agent 节点。Agent 节点负责多轮对话中的意图识别、状态管理、参数收集和工作流选择；Dify 工作流负责承接某一个确定性业务动作，例如创建合同、创建采购订单、查询采购订单详情或撤单。

从用户视角看，采购订单创建是一段连续对话：提供采购申请编号、上传附件材料、补充缺失信息、确认提交方式，最后拿到采购订单链接。系统侧实际发生的是多轮意图识别、参数维护、查询补齐、附件解析、提交前确认和接口创建。

当前采购机器人主要覆盖以下能力：

以采购订单创建为例，Dify Agent 的职责不是直接生成一段固定文本，而是推动这条对话链路逐步完成。用户提供采购申请编号后，机器人会先基于编号查询并回填能够确定的采购公司、供应商、采购建议等信息，减少用户重复录入。

真实案例：提供采购申请编号后自动补全部分内容

在这个基础上，Agent 会继续推进后续步骤：

1. 判断用户是否具备采购订单创建诉求；

2. 识别用户提供的是采购申请编号、采购材料、自然语言描述，还是附件消息；

3. 如果缺少必要业务信息，优先触发查询类工作流补充采购建议、采购金额、供应商、附件状态等信息；

4. 根据提示词规则维护多轮对话状态，例如已获取参数、附件数量、是否需要用户确认；

5. 当所有必填参数齐全后，先展示完整参数列表，让用户选择“直接提交”或“创建草稿审核并自行提交”；

6. 收到明确确认后，再调用采购订单创建工作流，并将结果反馈到企微。

当用户继续上传附件材料时，机器人不会只把附件当成普通文件转发，而是会结合当前会话上下文解析附件内容，并把可识别的信息补充到待提交参数中。

真实案例：上传附件材料后自动解析并补齐信息

等采购信息补齐后，机器人会把关键字段集中展示给用户确认，并提供“直接提交”和“创建草稿审核并自行提交”两种选择。下面这张图展示了用户选择直接提交后，机器人返回采购订单结果链接的闭环。

真实案例：信息补充完毕后直接提交并生成采购链接

这套设计有一个关键边界：Dify 负责任务推进，但不成为业务事实源。它可以组织参数、选择工作流、串联查询和创建动作，但金额、附件、供应商、流程版本、字段映射等确定性规则，最终仍由 OAX API 和 OA 数据承接。

七、执行设计：用 OAX API 承接确定性业务逻辑

采购机器人的核心变化，是从“页面自动化”转向“接口自动化”。

浏览器模拟适合快速验证想法，但在企业内部核心流程中存在几个天然问题：

• 页面结构变化会影响自动化稳定性；

• 字段渲染、弹窗、分页、权限提示都会增加执行不确定性；

• 多任务并发时，浏览器上下文隔离成本高；

• 页面只暴露展示信息，无法充分利用后端已有业务能力；

• 执行链路长，异常定位困难。

因此，工程侧针对 OA 系统建设了采购专用 OAX API，将采购流程中需要的校验、匹配、字段组装和流程创建逻辑下沉到后端。

以采购订单创建工作流为例，后端会完成一系列确定性处理：

这类逻辑如果放在浏览器自动化或提示词中，会非常脆弱；放在后端服务中，则可以复用已有业务规则、数据查询、字段映射、异常处理和日志体系。

也正是通过 OAX API，通用 AI 工具和内部 OA 系统之间形成了清晰边界：AI 负责提出意图，Dify 负责编排步骤，OAX 负责把意图转换成受规则约束的系统动作。

八、关键难点：从“能跑通”到“可上线”的六个约束

采购机器人从 Demo 走向可用，真正的难点不在于“能不能让模型回答”，而在于如何让模型在真实业务系统中稳定、可信、可追踪地完成动作。落地过程中主要遇到了以下几类问题。

1. Agent 必须像状态机一样遵守业务步骤

采购机器人不是一次性问答，而是多轮业务办理。以采购订单创建为例，提示词中不仅要描述“要调用哪个工作流”，还要约束 Agent 在多轮对话中如何记住参数、如何处理附件、什么时候追问、什么时候必须拦截提交。

实际难点在于：用户输入经常是分散的，可能先给采购申请编号，再补采购说明和附件材料，随后确认系统自动补齐的字段，最后再决定是否直接提交。如果 Agent 没有严格遵守提示词，很容易出现已经获取过的字段被重复追问、API 报错后丢失历史参数、附件数量被错误重置、用户没有确认就直接提交，甚至把附件 URL 暴露给用户等问题。

解决方式是把提示词写成“状态机式规则”，而不是只写泛泛的业务说明。核心约束包括：

• 已确认参数必须在多轮对话中继承，API 报错后也不能丢失；

• 新建订单或新建合同场景下，未经用户许可不能继承上一单参数；

• 附件只能来自真实上传的图片、文件或图文消息，不能根据用户口头数量计数；

• 追问时只问未知字段，已经识别出的甲方、乙方、金额、说明等字段不能重复要求用户补充；

• 所有必填参数齐全后，必须先展示完整参数列表，并让用户选择“直接提交”或“创建草稿审核并自行提交”；

• 未收到明确确认前，禁止调用创建类工作流。

通过这种方式，提示词不只是“告诉 Agent 怎么做”，而是把 Agent 的可行动作、禁止动作和提交前检查都明确下来，让 Agent 在 Dify 中更像一个受约束的业务办理节点。

2. 采购字段不能依赖模型猜测

采购表单中有很多字段看起来可以由模型从文本中推断，例如采购金额、供应商、采购说明、加签人、附件等。但在企业系统中，这些字段必须有明确来源，不能由模型自由生成。

以采购订单创建为例，采购金额、供应商和采购建议可以优先来自采购申请详情查询结果；附件是否必填，也需要结合采购申请和订单创建规则来判断；加签人必须是明确的域账号列表；附件参数只能来自真实上传消息中的附件地址。

如果让模型直接补全字段，短期看似顺畅，长期会带来数据不一致、流程无法提交、审批信息错误等风险。

解决方式是明确模型、Dify 工作流与 OAX 后端的职责边界：模型负责理解用户意图和抽取候选信息，Dify 工作流负责编排步骤和组织参数，OAX 后端负责依据 OA 数据做查询、匹配、校验和字段转换。关键字段没有可靠来源时，Agent 必须追问用户或调用查询工作流补齐，而不是继续猜测。

3. 用户输入不完整，需要在工作流中逐步补齐

用户在企微中的表达通常不是标准表单输入，可能只发一句话、一个采购申请编号，或者上传一份附件材料。真实输入经常缺字段、缺上下文，甚至存在多种可能解释。

如果 Agent 一开始就直接调用创建能力，容易因为参数不完整导致无法提交；如果每次都追问用户，又会降低体验。下面这张截图体现了这种“只追问缺失字段”的交互方式：当前面信息已基本补齐时，机器人只要求用户补充最后缺少的采购建议，而不是让用户重新填写整张表单。

真实案例：补充最后缺少的采购建议

解决方式是在 Dify 中把 API 能力抽象成多个可组合工作流，并在 Agent 节点中形成“判断—查询—补全—确认—创建—反馈”的路径。能通过查询工作流补齐的信息，优先自动补齐；只有当关键字段无法从系统中确定时，才向用户追问。所有参数齐全后，也不会立即创建，而是先进入提交前确认环节。这样既减少用户输入成本，也降低错误创建的风险。

4. OA 流程版本和字段规则会变化

OA 流程不是静态系统。流程版本可能升级，字段规则可能调整，下拉值和主数据也可能发生变化。如果这些信息写死在 Agent 提示词或 Dify 配置中，维护成本会非常高。

解决方式是把流程版本解析、字段映射、主数据匹配等变化点放在 OAX 后端。Dify 工作流只表达业务动作，不直接依赖具体流程版本。后端根据当前 OA 配置解析最新可用流程，并按实时数据完成字段组装。这样 OA 侧发生调整时，优先由后端吸收变化，上层 Agent 和工作流不需要频繁改动。

5. 多用户、多流程并发下要隔离上下文

采购机器人上线后，同一时间可能有多个用户分别创建订单、合同、付款单。不同用户、不同单据类型、不同工作流之间都需要保持上下文隔离，避免参数串扰和结果错发。

解决方式是将任务隔离从“浏览器实例隔离”转为“会话 + 工作流 + 接口调用隔离”。每一次工作流调用都携带明确的用户、场景、参数和流程标识；Dify 维护对话上下文，OAX 维护业务执行与调用记录，OA 维护流程实例。这样不同用户、不同单据类型之间不会争抢同一个页面状态。

6. AI 执行结果需要可追踪、可复盘

采购和财务相关流程具备较强审计属性。机器人创建了什么、什么时候创建、谁发起、哪个工作流执行、成功还是失败，都需要能够追踪。否则一旦出现问题，很难复盘责任边界和失败原因。

解决方式是在关键调用链路中沉淀调用记录和执行状态。每次创建、查询、撤单等动作都记录用户、接口、状态、时间和失败原因。这样既方便线上问题定位，也能支撑后续统计机器人使用效果、识别高频失败场景，并反向优化 Dify Agent、工作流和后端规则。

九、落地效果：订单与合同已上线，付款模块灰度验证

目前，采购智能提单机器人已经在订单和合同模块正式上线运行，付款模块处于灰度验证阶段。

从已落地场景看，订单模块提单效率提升约 20%。叠加合同模块自动化能力后，已释放部分人力成本。相比原先依赖浏览器模拟的方案，API 直连让流程稳定性、多任务并发处理能力都有明显改善。

同时，企微统一入口降低了采购人员的操作成本。用户不需要进入多个系统理解复杂表单，只需要通过自然语言描述目标、上传材料，并根据机器人反馈进行必要确认。人工校验从“逐字段填写”转向“关键结果确认”，整体认知负担下降。

待付款模块全量上线后，采购 OA 全流程提单效率预计提升 50% 以上，累计可节省 0.8～0.9 人力，带动采购业务整体提效约 8%～9%。这部分收益来自当前订单、合同模块运行效果与付款模块灰度测算，后续还会随着使用量、流程覆盖范围和异常闭环能力继续校准。

十、方法沉淀：通用工具接入内部系统的五条经验

这次实践最有价值的部分，不只是采购机器人本身，而是沉淀了一套通用 AI 工具接入内部系统的方法。对于任何涉及流程、金额、审批、主数据和审计追踪的场景，都可以参考这五条经验。

1. 先判断场景是不是“强规则执行”，再选择接入方式

不是所有 AI 自动化都需要重工程化。如果只是信息查询、知识问答、低风险辅助，通用 Agent 或页面自动化可以快速验证。但只要场景涉及流程创建、金额、供应商、合同、付款、审批等强规则动作，就应该尽早转向 API 联动和后端规则承接。

2. 把模型放在“理解和编排”位置，而不是“最终裁判”位置

模型擅长理解用户表达、抽取候选信息、组织多轮对话，但不应该决定关键业务字段的最终值。字段来源、规则校验和流程写入应由系统数据和后端服务兜底。简单说，模型可以提建议，系统必须给结论。

3. 把工作流做成业务动作单元，而不是提示词补丁

Dify 工作流的价值不是让提示词更长，而是把查询、创建、撤单、状态反馈等动作拆成可复用单元。工作流边界清晰后，Agent 只需要选择动作和组织上下文，后续维护成本会明显下降。

4. 把页面不确定性转成接口确定性

页面自动化最大的问题不是“不能用”，而是不确定性太多。生产级场景需要把页面结构、加载时序、临时状态这些不稳定因素，转换成接口参数、业务规则和调用结果这些可验证对象。能用接口表达的动作，就不要长期依赖页面模拟。

5. 把调用记录当成产品能力，而不是运维附属品

AI 自动化进入内部流程后，调用记录不是可有可无的日志，而是问题定位、责任边界、效果评估和持续优化的基础。没有调用记录，就很难从 Demo 走向可运营。

从这个角度看，采购机器人不是一次简单的 AI 工具接入，而是一次围绕采购业务流程的系统联动改造。它的价值也不只在采购场景本身，更在于验证了一条通用工具接入内部业务系统的工程化路径。

十一、后续规划：从平台化 Agent 走向深度定制 Agent

当前方案已经验证了“企微入口 + Dify Agent + Dify 工作流 + OAX API”在采购提单场景中的可行性。后续会继续从两个方向推进。

一方面，为了支持更多采购场景与更高效的自动化，计划引入深度定制的自研 Agent。相比 Dify 平台化配置，自研 Agent 可以在上下文管理、工具选择、异常恢复、任务状态机、多任务调度和执行轨迹沉淀上做更深入的定制，进一步提升自动化效率。

另一方面，采购链路与财务链路天然相邻。后续将继续拓展财务相关 OA 自动化场景，例如付款、报销、预算校验等，让采购与财务流程形成更完整的 AI 自动化闭环。

 

结语：让 AI 通过工程边界进入业务现场

采购智能提单机器人的价值，不只是减少几次点击，也不只是让 AI 帮忙填写表单。

更重要的是，它验证了一条企业级 AI 自动化的落地路径：当通用 AI 工具要进入内部业务系统时，不能只追求“模型能不能回答”，更要回答“系统能不能稳定执行、结果能不能追踪、责任边界能不能说清”。

这次实践给出的答案是：不要让 AI 直接替代业务系统，也不要把所有规则都堆进提示词，而是为 AI 建立清晰的工程边界。企业微信负责入口，Dify Agent 负责任务理解，Dify 工作流负责流程编排，OAX API 负责确定性执行，OA 系统负责审批和沉淀，调用记录负责追踪和优化。

几者结合后，采购自动化才真正从页面模拟走向系统融合，从单点提效走向全链路提效。未来，随着更多采购和财务场景接入，AI 将不再只是回答问题，而是能够围绕业务目标持续推进流程、调用系统能力、沉淀执行经验，并在关键节点交由人进行判断和兜底。

对企业级 AI 应用来说，真正值得期待的不是“让 AI 像人一样点系统”，而是“让 AI 在清晰边界内调动系统能力”。让机器负责高频、重复、可验证的执行，让人专注规则制定、风险判断和关键决策，这才是 AI 自动化进入业务现场的长期价值。

作者简介