Agent 项目从 Demo 走到生产环境真正让人头疼的往往不是模型选型或 Prompt 调优而是怎么把它跟企业里已经跑了十几年的 OA、ERP 系统接上。我最近刚交付完一个基于 MCP 协议的 Agent 集成项目踩坑无数也积累了一些实战经验。这篇文章就把整个过程中的核心思路、技术选型、实操步骤和避坑心得完整梳理一遍适合正在做 Agent 落地、或者准备把 AI 能力接入企业存量系统的朋友参考。全文围绕 MCP 协议、OA/ERP 集成、FDE 角色定位、Agent 生产化这几个关键词展开不讲虚的只讲能直接抄作业的东西。1. 为什么 Agent 接 OA、ERP 比调模型难十倍1.1 模型能力早已不是瓶颈过去一年我参与过好几个 Agent 项目从最开始的能不能跑通到现在的能不能上生产感受特别深。模型侧的能力进步太快了无论是工具调用、多轮推理还是结构化输出主流大模型基本都能满足企业场景的需求。你让模型去理解一段采购申请、解析一张报销单、判断一个审批流程该走哪个分支它做得比很多初级实施顾问都靠谱。但问题在于模型再聪明它也得能看见OA 里的数据、操作ERP 里的单据。这就好比招了一个智商 180 的新员工结果公司门禁不给他开、ERP 账号不给他建、OA 流程他不知道找谁审批——能力再强也白搭。我见过太多团队在 Demo 阶段用 Mock 数据跑得飞起一接真实系统就全线崩溃。崩溃的原因五花八门OA 的接口文档是五年前的、ERP 的字段命名是拼音缩写、审批流的回调地址配错了、单点登录的 Token 过期策略跟 Agent 的长连接冲突……每一个都能让你调一整天。1.2 OA 和 ERP 的历史包袱到底有多重企业存量系统的复杂度没做过集成的人很难想象。我拿几个真实案例说明泛微 OA 的建模引擎字段类型有几十种明细表里的下拉框变更会触发合计字段重算这个联动逻辑在页面上是前端 JS 控制的但通过 API 写入时如果不按它的规则来合计字段就是错的。更坑的是有些客户在建模引擎里加了自定义的触发脚本你从外部写入数据会绕过这些脚本导致业务数据不一致。通达 OA的 CAS 单点登录Token 有效期默认很短而且不支持刷新。Agent 如果维持长连接Token 过期后所有请求都会 401。你得在 Agent 侧做一个 Token 池或者改用服务账号加 IP 白名单的方式绕开。金蝶、用友这类 ERP接口分好几层有标准的 WebAPI有老版本的 SDK还有直接读数据库的野路子。标准接口稳定但覆盖不全SDK 要装客户端读数据库快但风险高。选哪条路取决于你对数据实时性和一致性的要求。1.3 FDE 这个角色为什么突然火了FDEForward Deployed Engineer前置交付工程师这个概念最近被频繁提起本质上就是懂业务、懂系统、懂 AI的复合型角色。Agent 上生产这件事纯算法工程师搞不定因为他不了解 OA 审批流的业务规则纯实施顾问也搞不定因为他不懂 Agent 的工具调用机制。必须有一个能同时跟业务方、IT 部门、算法团队对话的人把需求翻译成技术方案。我在项目里的角色就类似 FDE上午跟财务总监聊报销流程的合规要求下午跟 IT 部门确认 ERP 接口的权限边界晚上回来改 Agent 的 Tool 定义。这个角色累但价值极高因为他是唯一能把业务语言和技术语言对齐的人。2. MCP 协议到底解决了什么集成难题2.1 从每个系统写一个适配器到统一协议在没有 MCP 之前Agent 接系统的方式是给 OA 写一个 Tool给 ERP 写一个 Tool给 CRM 再写一个 Tool。每个 Tool 的入参格式、返回格式、错误码都不一样。Agent 的 Prompt 里要写一大堆调用 OA 接口时参数是 A 格式调用 ERP 时是 B 格式模型很容易搞混。MCPModel Context Protocol的核心价值是把工具的定义和调用标准化了。它规定了 Server 怎么暴露工具、Client 怎么发现工具、调用时参数怎么传、结果怎么返回。这样一来Agent 侧只需要实现一套 MCP Client所有接进来的系统都通过统一的协议交互。打个比方以前每个系统说自己的方言Agent 要学十种方言现在 MCP 规定大家都说普通话Agent 只需要会普通话就行。方言的翻译工作交给各个系统的 MCP Server 去做。2.2 MCP Server 的三种典型实现方式在实际项目里我见过三种 MCP Server 的实现路径各有适用场景实现方式适用场景优点缺点直接封装 HTTP API系统有完善的 REST API实现快稳定受限于 API 覆盖范围封装 SDK/客户端库系统提供官方 SDK功能全类型安全依赖特定运行环境数据库直连API 缺失或性能要求极高灵活快风险高需严格权限控制我个人的建议是优先用官方 APIAPI 覆盖不到的地方再用 SDK 补数据库直连作为最后手段而且必须走只读账号加视图绝对不能直接操作基表。2.3 MCP 不是银弹它解决的是接口标准化不是业务语义对齐这里要泼一盆冷水。MCP 让工具调用变简单了但它不解决业务语义的问题。比如 OA 里的请假申请和 ERP 里的考勤异常在业务上可能是同一件事但字段定义、审批逻辑、数据归属完全不同。Agent 要正确处理需要你在 MCP Server 里做语义映射或者在 Agent 的 Prompt 里写清楚业务规则。我踩过的一个坑Agent 收到帮我提交一个三天的事假申请它调用了 OA 的请假接口但没注意到这个客户的 OA 里事假和年假走的是不同审批流结果提交到了错误的流程被审批人打回。后来我在 MCP Server 的工具描述里加了详细的业务规则说明才解决这个问题。3. 把泛微 OA 接进 Agent 的完整实操3.1 先搞清楚泛微 OA 的接口体系泛微的接口能力在国产 OA 里算比较强的但文档质量参差不齐。我梳理了一下常用的几类接口标准 REST API/api/workflow/request这类用于发起流程、查询流程状态建模引擎 API/api/formmode/data这类用于操作自定义建模的数据组织架构 API/api/hrm/user这类用于查询人员、部门信息文档 API/api/doc这类用于操作文档中心实际项目里最常用的是流程和建模两类。流程接口负责发起审批建模接口负责读写业务数据。3.2 认证方式的选择与 Token 管理泛微支持多种认证Token 认证、Session 认证、OAuth2。Agent 场景下我强烈建议用 Token 认证因为它是无状态的适合服务端调用。Token 的获取方式# 获取 Token curl -X POST https://oa.example.com/api/ec/dev/auth/applytoken \ -H Content-Type: application/json \ -d { appid: your_appid, secret: your_secret }返回的 Token 默认有效期是 2 小时。Agent 如果长时间运行必须做 Token 自动刷新。我的做法是在 MCP Server 里维护一个 Token 缓存每次调用前检查剩余有效期小于 10 分钟就重新获取。注意泛微的 Token 接口有频率限制不要每次调用都去申请新 Token否则会被限流。缓存是必须的。3.3 流程发起接口的参数构造这是最容易出错的地方。泛微的流程发起接口需要传一个复杂的 JSON包含流程 ID、创建人、表单数据、审批人等信息。我拿一个请假流程举例{ workflowId: 123, creatorId: 1001, requestName: 张三的请假申请, formData: { leaveType: 事假, startTime: 2024-06-01 09:00, endTime: 2024-06-03 18:00, reason: 家中有事 }, nextNodeId: node_approve_1 }坑点在于formData里的字段名不是随便起的必须跟 OA 后台建模时的字段标识完全一致。而且不同客户、不同流程的字段标识都不一样。我的做法是先在 OA 后台导出流程的字段定义然后在 MCP Server 里做一层映射把 Agent 传过来的自然语言参数转换成 OA 需要的字段格式。3.4 建模引擎数据写入的联动陷阱前面提到过泛微建模引擎的明细表下拉框变更会触发合计字段重算。这个逻辑在页面上是前端 JS 做的通过 API 写入时不会自动触发。如果你写入的明细数据涉及金额、数量等需要合计的字段必须自己算好合计值一起写入否则数据就是错的。我遇到过一个真实案例Agent 帮用户提交报销单明细里填了三条费用但合计金额字段是空的。审批人看到合计为 0直接打回。后来我在 MCP Server 里加了一个后处理逻辑写入明细后自动计算合计并更新主表。3.5 审批回调与 Agent 的状态同步流程发起后Agent 需要知道审批结果。泛微支持配置审批回调审批完成后会 POST 一个通知到指定地址。我的做法是在 MCP Server 里暴露一个回调接口收到通知后更新 Agent 侧的任务状态。这里有个坑回调地址必须是公网可访问的而且泛微对回调的格式有要求。如果 Agent 部署在内网需要做端口映射或者用消息队列中转。我一般用消息队列MCP Server 收到回调后丢到队列里Agent 异步消费这样解耦更彻底。4. ERP 集成的特殊挑战与应对策略4.1 ERP 接口的三层结构ERP 系统的接口通常分三层业务层 API如创建销售订单查询库存语义清晰但覆盖有限数据层 API如写入表 A 的记录灵活但需要懂数据库结构报表层 API如查询某报表数据适合读取不适合写入Agent 集成优先用业务层 API因为它的语义跟 Agent 的理解能力匹配。数据层 API 作为补充但必须严格限制权限。4.2 金蝶 ERP 的接口实践金蝶的云星空系列提供了比较完善的 WebAPI。我以创建采购订单为例import requests def create_purchase_order(order_data): url https://erp.example.com/k3cloud/Kingdee.BOS.WebApi.ServicesStub.DynamicFormService.Save.common.kdsvc payload { formid: PUR_PurchaseOrder, data: { FBillNo: order_data[order_no], FSupplierId: {FNumber: order_data[supplier_code]}, FDate: order_data[date], FEntry: [ { FMaterialId: {FNumber: item[material_code]}, FQty: item[quantity], FPrice: item[price] } for item in order_data[items] ] } } response requests.post(url, jsonpayload, cookiesget_session_cookie()) return response.json()金蝶的坑在于它的字段名都是F开头的内部编码而且不同版本、不同模块的字段名可能不一样。你必须拿到对应版本的字段对照表。我的做法是让客户 IT 部门导出一份字段清单然后在 MCP Server 里做映射。4.3 用友 ERP 的接口差异用友的 U8 和 NC 系列接口风格差异很大。U8 比较老很多接口是基于 COM 组件的Agent 直接调用很麻烦。NC 系列有 REST API相对友好。对于 U8我的建议是不要直接对接而是在中间加一层适配服务用 .NET 或 Java 封装 COM 调用然后暴露 REST 接口给 MCP Server。这样虽然多了一层但稳定性和可维护性好很多。4.4 ERP 集成的权限与审计ERP 涉及财务、库存等敏感数据权限控制必须严格。我的做法是MCP Server 使用专用的服务账号只授予必要的权限所有写操作记录审计日志包括 Agent 的调用来源、参数、结果敏感操作如删除、修改金额需要二次确认Agent 不能直接执行提示ERP 的审计要求通常比 OA 高上线前一定要跟客户的财务和内控部门确认权限方案否则后期整改成本极高。5. Agent 生产化的并发、稳定性与安全5.1 并发场景下的 Token 与连接管理Agent 上生产后并发量可能远超预期。我遇到过一个场景月底报销高峰期Agent 同时处理几十个报销申请每个都要调 OA 接口。结果 Token 申请接口被限流大量请求失败。解决方案是Token 池化预先申请多个 Token轮询使用请求队列MCP Server 侧做限流超过阈值的请求排队连接复用HTTP 连接池配置合理避免频繁建连5.2 错误处理与重试策略企业系统的接口不稳定是常态。我的重试策略是网络超时重试 3 次间隔指数退避业务错误如参数错误不重试直接返回给 Agent系统错误如 500重试 2 次仍失败则告警关键是区分错误类型不能无脑重试。无脑重试会导致重复提交比如重复创建了采购订单那就麻烦了。5.3 Agent 的安全边界Agent 能操作 OA 和 ERP意味着它有了很大的权限。安全边界必须划清楚只读操作Agent 可以直接执行写操作需要人工确认或者限制在特定范围内删除、审批等敏感操作禁止 Agent 直接执行我在项目里实现了一个操作分级机制MCP Server 根据操作类型决定是否需要人工介入。这个机制救过我好几次有一次 Agent 误判了一个流程分支差点提交了错误的付款申请幸好被拦截了。6. 从 Demo 到生产的完整交付清单6.1 上线前的检查项OA/ERP 接口的连通性测试覆盖所有用到的接口Token 刷新机制验证模拟长时间运行并发压力测试确认限流和队列生效错误场景测试包括网络中断、接口报错、数据异常权限验证确认服务账号的权限范围符合预期审计日志验证确认所有操作可追溯6.2 灰度上线的节奏不要一次性全量上线。我的节奏是内部测试环境跑通全流程客户测试环境用真实数据验证小范围用户灰度收集反馈逐步扩大范围监控指标全量上线持续监控每个阶段至少观察一周确认稳定后再进入下一阶段。6.3 监控与告警生产环境必须有监控。我关注的指标包括接口调用成功率平均响应时间Token 刷新失败次数队列积压长度Agent 任务完成率告警阈值根据业务重要性设定关键接口的成功率低于 99% 就告警。7. 一些踩坑后的个人体会做 Agent 集成这几年最大的体会是技术方案再先进也得尊重企业存量系统的现实。OA 和 ERP 里沉淀了企业十几年的业务逻辑这些逻辑可能没有文档、可能不合规范但它们是真实运行的。Agent 要融入这个体系不是去颠覆它而是去适配它。MCP 协议确实让集成工作标准化了很多但它不是万能药。真正的难点在于理解业务、梳理流程、处理边界情况。FDE 这个角色的价值就在于能把这些脏活累活扛下来让 Agent 真正能在生产环境跑起来。最后分享一个小技巧每次集成新系统前先花半天时间跟客户的业务人员聊天让他们演示一遍完整的业务流程。你会发现很多文档里没写、但实际运行中必须遵守的潜规则。这些潜规则往往就是 Agent 上线后最容易踩的坑。