Agent 项目一旦进到生产真正让人失眠的就不再是模型的能力了而是怎么跟 OA、ERP 这一堆企业存量系统握手。我们内部把一套折腾了很久的 MCP 接入方案命名为 FDE MCP Blade这篇文章就把它完整拆开讲讲包括为什么要这么设计、生产环境里哪些细节必须处理以及我们踩过哪些坑。如果你也正在做 Agent 落地尤其是要接泛微、致远、蓝凌这类 OA或者用友、金蝶、SAP 这类 ERP那这篇文章应该能帮你省下不少摸索时间。比起讨论大模型选型、Prompt 调优真正决定 Agent 能不能在企业里跑起来的往往是系统接入层的工程能力。1. 上了生产才明白真正卡住 Agent 的不是推理是接管系统的能力1.1 POC 阶段的环境“太乖了”我们最开始做 Agent 项目时POC 演示非常顺利领导看了很满意客户也觉得效果惊艳。原因很简单POC 环境是干净的。测试账号提前开好、数据是脱敏后的样例、系统接口文档坐在工位上就能拿到甚至某些系统还专门给 POC 开了白名单。那种环境里Agent 的表现几乎完美——你问它“华东区这个月的报销单审批到哪一步了”它能准确回答还能顺便把下一步的处理人给你列出来。但上了生产第一周就翻车了。同一个 Agent连最基本的“拉取 OA 待办列表”都做不好。登录这一关就把我们干趴下了生产环境的 OA 有统一的登录门户要过验证码、要二次认证有的子公司还会强制定期改密码。我们的 Agent 第一次调用就遇到 Token 过期接着连续三次尝试触发风控账号直接被锁定。这类问题在 POC 里根本不会出现。POC 给的是虚拟测试号生产环境可不会迁就你。然后就是页面操作。生产 OA 的自定义控件比测试环境多得多很多表单是可视化设计器拼出来的DOM 结构完全不一样。用 Playwright 去抓元素有的控件压根没有标准 name 或 id只能靠坐标点有些旧系统甚至还在用 ActiveX 控件浏览器自动化脚本拿它一点办法都没有。那段时间我们内部复盘经常说一句话模型本身从来没拖过后腿真正拖后腿的是“连接企业系统的最后一公里”。1.2 模型负责“想做什么”接入层负责“怎么做到”现在的 LLM Agent 本质上是“意图决策器”它理解用户需求规划行动步骤然后输出需要调用的工具和参数。但工具从哪来OA 的审批接口没有现成的ERP 的库存查询没有标准 SDK这就成了最大的瓶颈。很多团队会陷入一个误区以为 Agent 调用工具就是“后端接口 Function Calling”。结果一接才发现企业系统根本不是“接口即服务”。老 OA 的很多功能只有 UI 没有 APIERP 的接口又分散在几十个模块里参数规则、鉴权方式各不相同。如果硬要全部用代码封装工作量巨大几乎等于重写一套中间层。所以我们的结论是模型只负责“想做什么”真正决定“怎么做到”的是接入层。接入层能不能把企业系统的各种操作——查询、创建、审批、驳回、导出——转化成 Agent 可调用的工具这才是生产级 Agent 项目成败的分水岭。正是在这个认知下我们开始设计 FDE MCP Blade一套面向存量 OA/ERP 系统的 MCP 接入层。接下来我讲下 OA/ERP 到底难在哪以及 Blade 是怎么解决这些问题的。2. 老 OA、ERP 到底为什么这么难接2.1 OA 的真实构成审批流、公文、控件、会签很多人对 OA 的理解停留在“看个待办点个同意”。真实企业的 OA 远不止这些。以我接过的泛微、致远、蓝凌为例常见模块包括流程审批、公文管理、会议管理、车辆预订、用章申请、人事流程、知识库。每个模块的页面和操作模式都不一样。最麻烦的是自定义控件。致远 OA 支持在表单里放自定义控件泛微也有自己的表单设计器蓝凌的某些版本会用到 ActiveX 上传控件。这些控件不是标准 HTML 元素浏览器自动化工具抓不到可用的选择器你看着是个“日期选择框”实际它是整个系统自己渲染的一坨 canvas 或 iframe。审批逻辑也不是简单的一键通过。一个流程里可能有会签、非会签、或签、流程分支。会签要求所有相关人批完才往下走非会签则是任意一人批完即可。Agent 要去操作这种流程不能只看“现在到谁了”还要理解这个节点的会签规则否则很容易做出错误判断。更现实的问题是OA 的权限体系非常分散。不同子公司、不同部门的人能看到的流程不一样管理员账号五花八门有的地方用钉钉扫码登录有的地方走 CAS有的地方还在用老式密码 动态口令。这些细节轻则让 Agent 无法登录重则在权限边界上产生严重风险。2.2 ERP 不是数据库是一个带权限状态机的业务系统ERP 比 OA 更难接因为它不是简单的“查一张表”。ERP 背后是一整套业务状态机一个采购订单从草稿到审批、到下发供应商、到收货、到入库、到生成财务凭证每一步都涉及多个模块的数据联动。以 SAP 为例虽然有 RFC/BAPI 这种成熟接口但调用 BAPI 往往需要先处理一套前置参数业务对象之间还有依赖关系。你用中文问“帮我查一下某订单现在能不能收货”模型可能觉得这很简单但实际调接口时你要先检查订单状态、再检查是否已做过收货过账、还要确认有无质量拦截标记。国内部分 ERP 更麻烦。有些老版本系统只有界面操作路径没有公开 API。数据存在 SQL Server 里但业务逻辑散在前端代码里直接改库就是找死。我们曾尝试绕过界面、直接调 ERP 内部服务接口结果发现服务地址在不同环境下配置完全不同跑起来完全不可靠。ERP 的权限矩阵也是一座山。一个操作员能做什么、不能做什么不是简单地“加个角色”就能解释清楚。有的账号能看库存但看不到成本价有的账号能建单但不能审批。Agent 如果拿到一个权限过大的账号风险会很高如果权限太小又很多操作做不了。生产环境里让 Agent 的账号权限正好覆盖业务操作范围本身就是一件需要反复调试的工程。2.3 安全策略和浏览器交互很多操作根本没有 API 路径标题里那个“泛微 OA 添加外部地址作为目录报错连接被阻止因为它是由公共页面启动的”搜索词就是我们在生产上遇到过的真实问题。场景是这样的Agent 要从某个外部页面跳转去访问 OA 的目录服务结果浏览器直接阻止了这次连接。原因不是网络不通而是企业安全策略规定从公共页面启动的连接不能访问内部系统目录。在 POC 环境没人配这个策略自然测不出来到了生产安全团队默认开启所有拦截规则Agent 就被卡死在这一步。这类问题的本质是OA/ERP 的交互层实际上是一个“人眼识别 鼠标键盘操作”的系统。人看着页面知道哪些按钮能点、哪些跳转被限制而 Agent 作为一个自动化程序既没有“人眼”也没有“鼠标”只能靠浏览器自动化一层层摸。企业安全策略、页面脚本、浏览器插件都会让这个过程异常脆弱。在这样的背景下传统“一个接口接一个系统”的思路根本走不通。必须有一种更系统化的接入方式把 UI 操作、API 调用、权限控制、会话管理等全部纳入统一管理。这就是 FDE MCP Blade 出现的直接原因。3. FDE MCP Blade 的核心设计把“能说话”变成“能干活”3.1 MCP 到底解决了什么问题MCPModel Context Protocol是模型上下文协议它定义了一个标准化的“工具调用”接口Agent 可以通过 MCP 协议发现有哪些工具可用、每个工具的参数是什么、然后发起调用、拿到结果。很多人觉得 MCP 只是个“函数调用协议”其实它解决了一个更深层的问题让 Agent 的工具资源可以像插件一样被动态挂载。不同系统、不同团队开发的工具只要遵循同一套 MCP 规范就能被 Agent 统一发现和调用。这就相当于给 Agent 装了一个“万能插座接口”。没有 MCP 之前我们每个系统都要写一套自定义的 Function Calling 适配。例如同样是一个“查询待办”操作OA-A 需要传 userId 参数OA-B 需要传 account 参数ERP-C 又需要先登录拿 session。每次对接新系统都要改 Prompt、改代码、改参数映射。有了 MCP我们只需要把系统能力封装成标准工具Agent 端逻辑几乎不用动。FDE MCP Blade 就是沿着这个思路搭建的但它不是简单的 MCP SDK 封装而是解决了一个关键问题MCP 协议规定的是“怎么调用工具”企业系统里并没有现成工具可调。Blade 要先把 OA/ERP 的操作翻译成 MCP 工具然后才是协议层的调用。3.2 Blade 的三层结构FDE MCP Blade 按三层结构设计层与层之间互相独立这样单个系统出问题不会拖垮整体。第一层是接口适配层。凡是系统有公开 API、或者我们能拿到稳定接口的优先用接口方式对接。SAP 的 RFC/BAPI、部分 OA 的 REST API、数据库视图等都归在这一层。接口方式的好处是稳定、可控、性能高。模板消息、审批查询这类高频操作一定要走接口不能靠页面模拟。第二层是浏览器执行层。对于没有接口、或者接口覆盖不全的系统Blade 用浏览器自动化的方式去操作。这一步我们基于 Playwright 做了二次封装而不是直接用现成工具。原因很简单企业系统里的自定义控件、复杂交互、页面跳转限制都需要专门的逻辑去处理。直接拿一个通用浏览器自动化工具上去50% 的场景会失败。第三层是语义工具层。前面两层都是“能操作系统”但 Agent 需要的是“能理解业务”。比如“发起一笔差旅报销”这个动作在 OA 里可能涉及新建流程、选表单、填明细、上传凭证、选审批人。如果 Agent 只知道“点按钮”不知道这些动作之间有依赖关系那它在真实流程里就会出错。所以 Blade 在两层之上封装了一层业务语义把多步操作编排成单个工具。这三层组合起来的效果是Agent 调用 Blade 暴露的工具Blade 根据工具定义自动选择走接口还是走浏览器执行然后返回结构化的结果。整个调用链可以用一句话概括Agent Host → MCP Client → FDE MCP Blade → [接口适配 | 浏览器执行] → OA/ERP。3.3 为什么是“API 优先、RPA 兜底”而不是反过来有人会问既然浏览器执行能覆盖所有系统为什么不统一用浏览器自动化反正模型都能“看懂页面”。这里有个性能问题也有个稳定性问题。浏览器操作一次动辄几秒到几十秒图片渲染、控件加载、页面跳转都很耗时如果 Agent 一个任务需要连续操作十几步用户体验会非常差。而接口调用通常几百毫秒就能返回结果两者差距在十倍以上。稳定性更是关键。页面只要改一行 CSS坐标选择器就可能失效一个弹窗遮挡就会导致点击失败。接口只要传参正确几乎不会因为 UI 变化而翻车。所以 Blade 的策略很明确优先走接口接口覆盖不到的场景才启用浏览器执行。这种“双通道”策略还带来一个额外好处监控和告警可以分层。如果某一天接口调用量突然下降、浏览器操作量上升我们就能立刻知道是不是有接口出了问题然后优先排查 API 通道而不是面对一堆模糊的“Agent 执行失败”日志。4. 生产环境细节登录态、控件识别、权限隔离一个都不能少4.1 登录态怎么管生产环境第一个绕不开的问题就是登录态。企业系统不像公网 SaaS 产品那样支持 OAuth 静默授权很多老旧系统的登录逻辑非常原始账号密码 动态口令 验证码甚至有的还要在特定网段下才能登录。Blade 的登录态管理思路是“初始化登录 凭证托管 会话续期”。系统部署时由管理员通过受控流程完成一次初始化登录把会话信息加密存储在凭证库里Blade 负责定期刷新和续期。每次 Agent 调用工具时Blade 从凭证库取出有效会话而不是让 Agent 自己去碰密码和验证码。这个设计要特别注意一点不要为了省事把账号密码以明文形式写进配置。生产环境里凭证库要用加密存储访问受审计保护。Agent 的账号权限应该是独立分配的专用账号最小化到只覆盖业务所需操作绝对不能复用某一个管理员账号。实际对接泛微、蓝凌这类系统时登录还可能涉及扫码、企业钉钉账号绑定等流程。我们的做法是做一个“登录辅助页”需要扫码时由管理员打开页面扫码完成授权之后会话自动被 Blade 接管。整个过程 Agent 只知道“登录已就绪”它接触不到密码也接触不到二维码背后的细节。4.2 自定义控件和复杂页面的操作浏览器自动化接老 OA最难的一类问题就是自定义控件。普通下拉框抓不到选项日期控件点不动人员选择器打不开弹窗。这不是 Playwright 或 Selenium 的问题是这些控件根本就不是标准 HTML 元素。我们一度以为“让模型直接读页面、然后通过坐标点击”能解决所有问题结果发现不可靠。页面布局一变坐标就偏了弹窗一出现坐标点到的就是另一层。Blade 对控件识别采用多路方案。第一路是标准 DOM 解析能用 id/name 定位的就直接定位第二路是坐标定位对没有语义属性的控件结合 OCR 和模板匹配找目标位置第三路是无障碍树解析某些系统虽然界面花哨但底层会暴露 accessibility 信息可以借此拿到按钮含义。三路结果互相校验再把“实际上点没点中”作为反馈回传给 Agent。这里一定要强调任何时候都不要让 Agent 在“没有反馈”的情况下决策。很多失败案例都是模型自认为操作成功了其实页面已经在报错。Blade 在每次浏览器操作后都会抓取页面状态、截屏、收集 DOM 变化如果发现操作结果与预期不符立刻把“页面提示”转发给模型让它重新规划。这一步极大地减少了 Agent 的“幻觉式成功”。4.3 权限模型最小权限、操作复核、数据脱敏权限问题不能靠模型自己判断必须在接入层做硬约束。Blade 的权限模型分为三个维度可见、可执行、可变更。“可见”控制的是 Agent 能获取哪些数据。比如财务模块的成本数据、员工薪资数据默认不返回给 Agent。哪怕模型想查Blade 也会在返回前拦截“可执行”控制的是 Agent 能调哪些工具。有的系统对某个流程只允许查询不允许发起那就别把这个工具暴露给 Agent“可变更”控制的是 Agent 是否可以直接写操作。凡是发起审批、提交订单、删除记录这类动作Blade 默认配置为需要人工二次确认。这套权限模型的好处是即使模型出现了意图偏离最终动作能不能执行还是由接入层说了算。很多团队把安全希望寄托在“模型对齐”上这在生产环境里并不够。模型可以被诱导系统接入层必须是一个硬边界。数据脱敏也要在 Blade 这一层做。OA 里的姓名、电话、身份证号ERP 里的采购价、毛利率这些敏感字段在 MCP 工具返回前就应该被加工或打码。否则 Agent 虽然不会乱说但日志会被审计团队翻出来到时候麻烦的是整个项目组。4.4 稳定性与可观测企业集成场景下Agent 调用一次业务操作最怕的是“卡住不动”和“静默失败”。Blade 给每个外部调用都设置超时和重试策略。不同系统差异化配置接口通道超时一般 10 秒浏览器执行超时 60 秒重试不超过 2 次。超过阈值就向 Agent 返回明确的错误信息让它能及时调整策略。可观测更是重中之重。我们的生产经验是和 OA/ERP 的连接问题几乎是常态一天不出点问题都不正常。没有链路追踪排查成本会高得离谱。Blade 会记录每一次 MCP 调用Agent 发来的工具名、实际走的通道、调用了系统哪个接口、页面上点击了哪个元素、系统返回了什么、耗时多久、有没有重试。这些日志拼接起来就是一条完整的操作链路。更重要的是日志里要区分“模型原因”和“接入层原因”。模型调用了不该调的工具是模型问题Blade 登录态过期导致调用失败是接入层问题。区分开之后我们才能知道该调 Prompt 还是该调系统配置而不是一刀切地怪模型。5. 我们在生产上踩过的坑和复盘5.1 一个典型排错链路OA 目录连接被阻止前面提到“连接被阻止”的问题这里把完整排查链路写出来方便大家参考。当时 Agent 执行“查询合同台账”任务需要从 Blade 的浏览器会话里加载 OA 的目录服务地址。Agent 调用后返回“连接被阻止因为它是由公共页面启动的”。刚开始我们还以为是网络问题测了服务器到 OA 的通路完全正常页面手工访问也没问题。接着扒浏览器控制台才发现是浏览器安全策略拦截了跨上下文连接。OA 系统在配置里只信任企业内部门户页面发起的连接而 Blade 的浏览器实例打开的是一个空白起始页这个“公共页面”不允许启动到受保护目录的连接。定位到根因后解决分了两步第一在浏览器策略中把 OA 所在的内部地址加入可信域第二调整 Blade 的启动流程让浏览器实例先从企业内部门户进入再从门户页面跳转到目标系统。这个坑提醒我们生产环境的浏览器自动化不能只考虑“控件好不好抓”还要考虑企业安全策略对页面跳转、跨域请求、混用 HTTP/HTTPS 的各种限制。部署前的环境勘察项目清单里一定要加一条“检查浏览器策略和页面信任关系”。5.2 常见坑对照表坑典型现象根本原因处理思路登录态频繁失效Agent 隔一段时间就调不通会话过期、Cookie 未持久化初始化登录 凭证库托管 自动续期自定义控件点不到下拉框/日期控件操作失败非标准 HTML 元素DOM 解析 坐标定位 OCR 多路识别外部页面跳转被阻止“连接被阻止”类报错浏览器安全策略限制配置可信域从受信入口启动会话Agent 幻觉式成功实际没保存成功却返回成功缺少操作结果反馈抓取页面状态、截屏校验并回传真实结果接口调用报错但页面正常部分接口在特定环境不可用接口配置、许可限制接口通道降级为浏览器执行保证操作能完成权限越界能查到不该查的数据账号权限过大或缺少脱敏独立专用账号 最小权限 返回前数据脱敏5.3 哪些钱不能省给正在做 Agent 落地的团队一个建议系统接入层不要省尤其不要为了赶进度把“接口直连 手工写死”当长期方案。OA 和 ERP 的接口可能随时调整写死的逻辑修起来比重做还痛苦。接入层至少要有三件事不能省登录态托管、操作结果校验、全链路日志。这三样合在一起决定了你的 Agent 在真实生产环境里是“可维护的工程”还是“一个脆弱的 Demo”。如果团队还没有成熟的MCP接入方案完全可以从自己的第一套 OA 或 ERP 系统开始先做接口通道再逐步补齐浏览器执行。我们做 FDE MCP Blade 的过程也是一步步从“只通一个系统”演进到“多个系统统一接入”的。前期花点时间把基础设施打好后续每接一个新系统成本会直线下降。最后再分享一个个人的体会很多 Agent 项目不是死在模型能力上而是死在集成粗糙上。生产环境里一次登录失败、一个控件点不到、一条安全策略拦截都足以让整个项目停滞。与其纠结哪个大模型更强不如先把“能稳定操作企业系统”这个基础打牢。