上半年我们组在搞一个 Agent 项目目标是让员工直接用自然语言跟公司现有的 OA、ERP 打交道。模型选型、提示词优化、RAG 检索前后折腾了一个多月大家一度觉得难点全在模型身上。结果一上生产问题直接换了个画风真正让人失眠的是把泛微 OA、用友 ERP 这些老系统一个个接进 Agent。今天聊聊我们现在的落地方式——FDE MCP Blade以及这一路踩过的坑。如果你是刚准备在企业里上 Agent 的同行这篇应该能帮你少走不少弯路。1. 项目背景与核心痛点Agent 上生产的真实拦路虎1.1 模型能力不是瓶颈系统集成才是先说结论模型理解能力在绝大多数企业场景里是够用的。我们最初把大量精力花在选模型、调 prompt、搭 RAG 知识库上认为Agent 不够聪明是最大风险。但真正进入生产验证阶段后发现 80% 的时间都在跟接口对接搏斗而不是跟模型对话。举个具体例子。我们第一版原型做得很快模型能准确理解帮我把这个月的报销单审批状态汇总一下这种请求工具调用链路也跑通了。但一接生产数据问题全出来了OA 的接口鉴权需要维护 ticketERP 的接口要按公司代码区分数据范围某些单据查询甚至要走数据库视图而不是 API。模型再聪明也填不上这些系统层的坑。所以我的第一个经验是评估 Agent 项目可行性时别只盯着模型精度先去做系统集成调研。把 OA、ERP、HR、CRM 这些系统的接口文档、认证方式、数据权限梳理一遍你才知道真正的成本在哪。模型选型花两周能定但打通一个老 ERP 的接口可能要两个月。1.2 为什么 OA、ERP 这么难接企业内部系统难接不是技术难度高而是乱和杂。OA 和 ERP 是两类完全不同思路的系统放在一起对接时各种矛盾都会暴露出来。道理也很简单OA 是以人-流程-表单为中心的。你看泛微、致远、蓝凌这几家核心都是审批流、公文、会议、门户接口风格偏向 REST 或 WebService认证方式各家还不一样。泛微有 ecode 和 ticket致远喜欢 sessionIdtoken 一起用蓝凌又是另一套逻辑。更麻烦的是审批流往往是异步的——你发起一个审批后续得轮询流程状态而不是一个接口直接返回最终结果。ERP 又是另一个物种。它是以物料-财务-单据为中心的用友、金蝶、SAP 各有各的体系接口往往更底层有的支持标准 API有的只能通过中间表或者存储过程交互。ERP 的数据还有一个特点事务性强、不可逆。打个比方OA 里发错一个审批可以撤回但 ERP 里创建一个错误的销售订单后面要牵扯到发货、开票、收款一整串链路不能随便删。再加上权限模型完全不同。OA 的权限更多是功能权限和数据范围ERP 的权限要按公司代码、仓库、会计期间来控制。Agent 要替用户操作这些系统就必须把用户的身份和权限映射过去。这一层做不好要么 Agent 什么都查不到要么权限过大造成事故。我整理过一个简单的对照表方便你快速理解这两类系统的差异维度OA以泛微为例ERP以用友 U8 为例核心对象表单、流程、人员、组织物料、单据、存货、财务账常见接口REST、WebService、EcodeAPI、中间表、数据库视图认证方式ticket、token、session账套 用户 密码 / token操作模式偏异步发起审批、轮询状态偏同步事务创建单据、审核风险等级中低可撤回、可转办高单据不可随意删除数据权限按部门、岗位、流程节点按公司代码、仓库、会计期这些差异叠加在一起就是 Agent 接企业系统最头疼的地方。你不可能用一套固定写法兼容所有系统必须有个中间层去做适配和转换这也是我们后来选 FDE MCP Blade 的直接原因。2. FDE MCP Blade 的定位与架构2.1 MCP 协议到底解决了什么问题先花点篇幅聊聊 MCP。MCP 的全称是 Model Context Protocol模型上下文协议。它的目标很简单把大模型怎么调用外部工具这个事情标准化让模型不用为每个系统单独写一套调用逻辑。我常用的类比是 USB-C。以前每个手机厂商都有自己的充电接口出门得带一堆线。现在统一成 USB-C一根线走天下。MCP 对大模型和外部系统之间的关系也是类似的逻辑——它定义了一套统一的接口标准模型通过它去连接不同的工具和数据源而不必在意每个工具底层是什么语言、什么协议。在 MCP 的体系里有三个基本角色宿主Host、客户端Client和服务端Server。宿主通常是 Agent 应用本身它管理整个交互客户端负责跟服务端建立连接服务端负责把外部能力暴露成标准化的工具或资源。FDE MCP Blade 在这套体系里就扮演了一个服务端 管理平台的角色。FDE MCP Blade 可以理解为面向企业系统接入的 MCP 服务中间件。它不是一个简单的示例项目而是一套能直接上生产的集成套件——内置了常见 OA、ERP 的连接器提供了统一的认证管理、权限控制、工具注册和审计能力。通俗点说它把手写每个系统的对接代码这件事变成了在平台上做配置、注册工具、控制权限。2.2 FDE MCP Blade 的核心模块拆解我用了一两个月 FDE MCP Blade整体架构给我最深的感受是它把企业接入的共性难点都抽象成了模块。这里拆几个核心模块说说。第一个是连接器层。它负责跟具体系统打交道。每个连接器内部封装了该系统的认证逻辑、请求签名、错误重试、接口路由。比如泛微 OA 的连接器知道怎么刷新 ecode用友 ERP 的连接器知道怎么处理账套参数。这一层的价值在于上层完全不用关心你连的是哪家 OA都用统一的接口去操作。第二个是认证中心。企业系统上生产后最麻烦的就是凭证管理。一个 Agent 服务可能要给几百个员工用你不能让所有人都拿一个超管账号去调 OA。认证中心做的事情是统一管理每个系统的账号映射支持 token 自动刷新、凭证加密存储、按用户维度代理认证。简单说就是谁在用 Agent就用谁的权限去调 OA/ERP。第三个是工具注册中心。它把 OA、ERP 的 API 重新包装成 MCP 协议下的工具并为每个工具定义好 JSON Schema。这个 Schema 特别重要因为大模型要靠它理解这个工具是干什么的、参数怎么填。工具注册得越清晰模型调用就越准确。第四个是权限网关。系统接口暴露给 Agent 后不能全裸奔。权限网关做了两层控制第一层是接口级的哪些工具允许调用、哪些不允许第二层是数据级的比如一个普通员工查库存只能看自己所属仓库的数据。这两层控制可以在模型调用之前就拦截掉避免越权操作。最后是审计日志。Agent 在生产环境里做的每一次操作都应该有完整记录。谁在什么时候通过 Agent 调用了什么工具传了什么参数返回了什么结果。这块前期看起麻麻烦但一旦出问题它就是定位事故的关键依据。2.3 为什么不自研适配层而是选 MCP 方案在定方案的时候我们内部也讨论过直接自己写一套统一的工具调用层不行吗为什么要引入 MCP 和 Blade 这套东西答案是自研适配层看着简单实际做下去会失控。企业里系统太多OA 一种接口风格ERP 一种接口风格还有可能接数据库、接工单系统、接企业微信。每接一个就写一套自定义封装长期维护成本很高。而且自研的方案会跟具体业务代码强耦合Agent 框架一升级适配层可能就要跟着改。MCP 的价值在于它是一个事实性的标准生态在逐步完善。你基于 MCP 写的工具和服务以后可以复用到其他 Agent 框架上。FDE MCP Blade 则是在标准之上补全了企业级缺失的部分——认证、权限、审计、连接器。它相当于是拿了一个已经帮你踩过一部分坑的半成品再改造比从零开始稳定得多。当然引入 Blade 也意味着要学习和维护这套框架。但对比自研的时间和风险尤其是生产环境对稳定性和安全性的要求这个选择性价比很高。3. 实操用 FDE MCP Blade 把 OA 接进 Agent3.1 先摸清 OA 的接口家底接 OA 的第一步绝对不是打开 Blade 就开始配。先把目标系统的接口家底摸清楚。以我们用的泛微 OAE-cology为例需要确认这几类信息部署版本和地址泛微的版本差异还挺大接口路径和认证方式都不一样接口风格泛微一般有 RESTful API 和 WebService 两种我们优先用 REST因为接入成本低认证方式泛微常用 ecode ticket 的组合ecode 相当于身份凭证ticket 是会话票据有效期通常有限需要处理刷新逻辑。还有一个容易被忽略的接口的调用权限配置。泛微后台一般会控制每个账号能调用哪些接口如果 Agent 用的账号权限不够接口会返回无权限。所以接之前先找 OA 的管理员确认好授权策略。这几个信息建议用表格整理清楚后面配置 Blade 时可以直接对应信息项示例必要程度OA 部署地址http://oa.internal.company.com必填接口基路径/api/ec/dev/auth/applyToken必填认证方式ecode ticket必填可用接口列表获取待办、发起审批、查询流程状态必填账号权限范围指定部门数据审批人权限必填3.2 Blade 上配置 OA 连接的完整流程摸清家底后就可以在 FDE MCP Blade 上配置了。我们的操作路径大致是新建连接器 → 配置认证 → 注册工具 → 权限绑定 → 联调测试。新建连接器时Blade 里有现成的泛微 OA 模板直接填地址、账号、密钥即可。这里我建议先手工在 Postman 里把认证接口调通拿到 token 后再填进去避免配置界面里反复测试导致账号被锁。泛微的登录接口对失败次数有锁定策略连续错误太多次账号会被临时禁掉。认证配置是最容易出问题的环节。泛微企业微信集成或第三方系统接入通常会用到密钥这个参数注意不要把密钥写死在代码里Blade 的凭证中心支持加密存储可以在界面上直接管理。配置好后要重点测试两个场景token 有效期内调用是否正常token 过期后Blade 自动刷新是否能无缝续上。然后是注册工具。我们最先注册的三个工具是查询待办列表、发起审批流程、查询流程进度。每个工具都需要填写清晰的描述和参数 Schema。这一步我强烈建议用心打磨参数描述。比如查询待办列表这个工具参数里往往有一个type字段你写待办类型不够要写成待办类型可选值1-待审批2-已审批3-抄送我模型才能准确选择。最后是权限绑定。Blade 支持按用户维度配置可用的工具和数据范围。比如普通员工只能查自己的待办部门主管能查本部门的流程。这层配置相当于给 Agent 的行为上了缰绳建议先收紧再逐步放开。3.3 与 Agent 联调时的几个细节工具注册完还要跟 Agent 框架联调。这里有几个细节都是我们实测后才发现很重要的。第一工具返回结果必须结构化。OA 原生接口返回的数据通常是嵌套对象有些还有大段 HTML 标签。模型处理这种脏数据非常容易出错。我们在 Blade 里给每个工具加了返回模板统一转成清晰的 JSON 结构只保留模型真正需要的字段解析成功率直线上升。第二审批流是异步的Agent 调用发起审批接口后拿到的只是已创建流程而不是最终审批结果。所以我们在工具设计上加了一个查询流程状态的工具Agent 在发起审批后主动轮询。Blade 里可以配置轮询间隔和最大超时时间超时后给用户提示流程仍在审批中稍后为您查询。第三也是最多人忽视的——工具描述里的参数示例。模型非常依赖示例来理解参数格式尤其是日期、金额、枚举这些类型。比如发起审批的金额字段你只写number模型可能会填一百二十元加上例如120.00准确率就高很多。联调完成后建议在测试环境用真实的 OA 数据跑一遍完整的用户场景不要只测单个工具。比如查看我这个月的差旅报销单审批到哪一步了这个指令背后涉及查询列表、过滤类型、查询进度等多个工具调用链路通了才算真正接好。4. 实操用 FDE MCP Blade 把 ERP 接进 Agent4.1 ERP 接口和 OA 到底差在哪把 ERP 接进 Agent 和接 OA 完全是两种体验。如果说 OA 是流程复杂但数据轻ERP 就是数据重而且操作不可逆。我们接入的是用友 U8 Cloud第一感受是接口文档极其庞大。U8 提供了几百个 API但你要找到查询库存量这个接口得先理解它的领域模型库存组织、仓库、存货档案、计量单位、可用量、现存量这些概念不熟悉的话连参数都填不对。权限模型也麻烦。OA 是按部门和流程节点来控制权限的ERP 呢按公司代码、库存组织、仓库、会计期间。同样一个查询库存的接口A 公司能看到华南仓的数据B 公司只能看华东仓。这个权限如果不做映射Agent 就可能越权查数据。还有一个特点是操作不可逆。OA 里审批流发起错了可以撤回重发问题不大。ERP 里创建一张销售订单如果搞错了你不能删除只能红冲或者反审核后续还要处理库存、应收等一系列连锁反应。所以 Agent 在调 ERP 写操作之前必须加一层确认机制。我建议接 ERP 时先做只读场景等稳定了再逐步开放写操作。毕竟生产环境里一条错误的订单可能比模型回答错误带来的后果严重十倍。4.2 对接 ERP 时最容易踩的三个坑第一个坑账套和公司代码参数容易被忽略。U8 Cloud 有多组织架构很多接口要求传公司代码或者库存组织编码。你单独调用一个查询接口时可能不觉得但 Agent 在自由对话中用户说查下库存时模型并不知道该用哪个账套。我们在 Blade 里做了一个处理把当前登录用户的默认组织信息预填进上下文模型调用工具时自动带上而不是让模型去猜。第二个坑超时和事务。ERP 有些接口响应特别慢尤其是月末结账期间查询汇总单据可能要几十秒。Agent 的模型推理引擎一般有响应超时时间接口慢了整个调用就失败。我们在 Blade 里针对 ERP 连接器单独配置了较长的超时时间和重试策略。但要小心写入类接口不能盲目重试。比如创建销售订单超时了你不确定服务端是否已经创建成功重试可能导致重复下单。解决思路是让接口支持幂等键客户端每次调用生成一个唯一的请求 ID服务端通过它去重。第三个坑ERP 返回的数据里有大量编码而不是中文。比如单据状态返回一个数字模型不知道 1 是什么意思。我们在工具返回模板里做了字段翻译映射把数字转成已审核未审核部分发货这些模型容易理解的中文描述。看起来是小事但对提升整个 Agent 链路的成功率帮助非常大。4.3 串一个完整流程查库存 → 下单 → 走审批当 OA 和 ERP 都接入后就可以开始做真正有价值的场景了。我们落地最成功的一个场景是销售助理用自然语言完成查库存、下订单、走审批的完整流程。用户说了一句帮我查下华东仓 A 型号还有多少库存够的话下一张 100 台的销售订单走常规审批流程。这个指令接收后Agent 开始分析意图规划任务逐一调用工具。第一步调用 ERP 的查询现存量工具带上默认仓库、存货编码、公司代码参数。返回结果是 235 台大于 100条件满足。第二步调用 ERP 的创建销售订单工具把客户、物料、数量、含税单价等参数按 Schema 传进去接口返回订单号。第三步调用 OA 的发起审批工具用预设的审批模板创建一条销售订单审批流程。第四步调用 OA 的查询流程状态工具等审批结束后把结果反馈给用户。整个过程从原来销售助理手动在 ERP 里下单、再跑到 OA 里走审批用时 10 分钟起步现在 Agent 一分钟内能跑完大半用户只需要在最后确认一遍关键单据信息。但这里要特别强调一个安全设计Agent 在创建销售订单之前必须把关键信息以待确认的形式抛给用户确认。我们会在 Agent 的回复里说即将创建销售订单客户 XX物料 AX数量 100总金额 125000 元是否确认用户确认后Agent 再继续执行。这个机制在 ERP 写操作场景里绝对不能省。5. 生产中踩过的坑与排查实录5.1 认证过期与并发复用生产环境跑了一周后第一个事故就出在认证上。OA 的 ticket 有效期是 30 分钟我们最初配置的认证策略是每次请求前检查失效就刷新。听起来没问题但在高并发下出现了连锁问题多个请求同时发现 ticket 失效同时去刷新旧的 ticket 被踢下线然后所有请求都带着新的去调用结果部分请求还是 401。这个问题的本质是凭证刷新没有做互斥。解决方案很简单把 token 刷新逻辑设计成单实例用一个全局锁保护刷新动作其他请求等待刷新完成后再复用新 token。Blade 后续版本也有认证缓存策略但如果你是自己写适配层一定要提前考虑到这个并发场景。还有账号复用的问题。生产初期我们贪方便用一个服务账号调用所有用户的 OA 请求结果发现所有人的审批记录都串了。后来改成按真实用户映射账号每个请求都通过认证中心动态获取对应账号的凭证才算彻底解决。5.2 模型乱传参的治理另一个高频问题是模型在调用工具时传参不规范。比如日期用户说最近一周模型传了一个最近一周的字符串但接口要的是 startDate 和 endDate 两个具体日期。再比如金额模型可能传100 块接口要100.00。解决思路不是反复调 prompt而是从根源上让模型少做不必要的自由发挥。我们做了三件事。第一在工具 Schema 里把参数类型和格式写死并在描述里给具体示例。第二凡是能从用户上下文推导出来的参数比如公司代码、仓库编码都在调用前由 Blade 自动预填不让模型传。第三枚举类型参数改造成让模型从可选列表中选择而不是自己生成。这三招下来工具调用的参数非法率降低了至少一半。有一说一模型的工具调用能力确实在进步但越是大模型越可能脑补参数。把参数选择权尽量收回系统才是生产环境稳的关键。5.3 安全边界与权限控制生产环境的安全问题比想象中更复杂。我们最初把 Blade 部署在内网服务器上Agent 服务通过内网访问认为这样就安全了。实际上一旦 Agent 应用本身有漏洞比如提示词注入攻击者就可能诱导模型调用 OA、ERP 工具去做越权操作。所以我们在 Bladel 外面加了两道防线。第一道是用户确认机制凡是涉及敏感操作写单据、发起审批、修改数据都必须经过用户确认。第二道是操作白名单Blade 工具注册中心默认只暴露读多写少的工具集新增写操作工具必须走审批流程。模型只能调用白名单内的工具超出的请求在权限网关就被拦截掉了。审计日志也是生产环境必不可少的能力。每一个工具调用都有完整的链路 ID谁调用的、传给模型什么内容、模型最终调用了什么工具、返回了什么都能回溯。我们曾经排查过一次数据异常靠的就是审计日志还原了整个操作链路最终定位到是某个测试账号误触发了批量更新。5.4 常见问题速查表把生产环境里遇到的典型问题整理成一个简易速查表给你参考问题现象可能原因排查思路工具调用偶发 401token 刷新并发冲突检查认证中心是否做了互斥刷新模型传参格式错误工具 Schema 信息不足补充参数类型、格式、示例ERP 接口超时月末结账/数据量大调长超时区分读和写重试策略OA 审批状态不更新轮询周期太长缩短单次查询间隔增加最大轮询次数Agent 调用工具被拦截权限网关白名单未放行查看审计日志确认是否有越权操作返回数据包含乱码原系统返回编码或 HTML在返回模板中做清洗和字段翻译这表不算全但覆盖了大多数生产接入的常见问题。如果你在接入时遇到类似现象可以按这个思路快速定位。6. 后续还能怎么扩展FDE MCP Blade 跑通 OA 和 ERP 之后我明显感觉企业内部 Agent 的落地路径清晰了很多。核心思路就一条把模型无关的事情都交给标准化中间层把精力集中在真正复杂的业务理解和流程编排上。下一步我们的计划是把企业微信的机器人回调也接进 Blade让员工直接在 IM 里唤起 Agent再把 BI 报表系统接进来让自然语言直接查经营数据。这个扩展成本相比之前接 OA、ERP 要低很多因为认证、权限、工具注册的框架已经成型新增连接器只是工作量问题。从个人经验看Agent 进生产从来不是技术演示而是一场系统集成和工程治理的持久战。模型能力会越来越强但企业内部系统的复杂性和历史包袱短期不会消失。谁能把模型能力和企业系统之间那层胶水做扎实谁就能真正把 Agent 用起来。最后分享一个小技巧如果你也面临多个系统接入的困境先不要追求一步到位挑一个用户需求最明确、系统接口相对规范的场景比如 OA 待办查询 ERP 库存查询用 MCP 框架从零到一跑通拿到真实的成功率和用户反馈再横向扩展。这个模式的确定性比一上来就搭一个大平台要高得多。