上半年我们组在搞一个 Agent 项目，目标是让员工直接用自然语言跟公司现有的 OA、ERP 打交道。模型选型、提示词优化、RAG 检索，前后折腾了一个多月，大家一度觉得难点全在模型身上。结果一上生产，问题直接换了个画风：真正让人失眠的，是把泛微 OA、用友 ERP 这些老系统一个个接进 Agent。今天聊聊我们现在的落地方式——FDE MCP Blade，以及这一路踩过的坑。如果你是刚准备在企业里上 Agent 的同行，这篇应该能帮你少走不少弯路。
1. 项目背景与核心痛点：Agent 上生产的真实拦路虎
1.1 模型能力不是瓶颈，系统集成才是
先说结论：模型理解能力在绝大多数企业场景里是够用的。我们最初把大量精力花在选模型、调 prompt、搭 RAG 知识库上，认为"Agent 不够聪明"是最大风险。但真正进入生产验证阶段后，发现 80% 的时间都在跟接口对接搏斗，而不是跟模型对话。
举个具体例子。我们第一版原型做得很快，模型能准确理解"帮我把这个月的报销单审批状态汇总一下"这种请求，工具调用链路也跑通了。但一接生产数据，问题全出来了：OA 的接口鉴权需要维护 ticket，ERP 的接口要按公司代码区分数据范围，某些单据查询甚至要走数据库视图而不是 API。模型再聪明，也填不上这些系统层的坑。
所以我的第一个经验是：评估 Agent 项目可行性时，别只盯着模型精度，先去做系统集成调研。把 OA、ERP、HR、CRM 这些系统的接口文档、认证方式、数据权限梳理一遍，你才知道真正的成本在哪。模型选型花两周能定，但打通一个老 ERP 的接口，可能要两个月。
1.2 为什么 OA、ERP 这么难接
企业内部系统难接，不是技术难度高，而是"乱"和"杂"。OA 和 ERP 是两类完全不同思路的系统，放在一起对接时，各种矛盾都会暴露出来。
道理也很简单，OA 是以"人-流程-表单"为中心的。你看泛微、致远、蓝凌这几家，核心都是审批流、公文、会议、门户，接口风格偏向 REST 或 WebService，认证方式各家还不一样。泛微有 ecode 和 ticket，致远喜欢 sessionId+token 一起用，蓝凌又是另一套逻辑。更麻烦的是，审批流往往是异步的——你发起一个审批，后续得轮询流程状态，而不是一个接口直接返回最终结果。
ERP 又是另一个物种。它是以"物料-财务-单据"为中心的，用友、金蝶、SAP 各有各的体系，接口往往更底层，有的支持标准 API，有的只能通过中间表或者存储过程交互。ERP 的数据还有一个特点：事务性强、不可逆。打个比方，OA 里发错一个审批可以撤回，但 ERP 里创建一个错误的销售订单，后面要牵扯到发货、开票、收款一整串链路，不能随便删。
再加上权限模型完全不同。OA 的权限更多是功能权限和数据范围，ERP 的权限要按公司代码、仓库、会计期间来控制。Agent 要替用户操作这些系统，就必须把用户的身份和权限映射过去。这一层做不好，要么 Agent 什么都查不到，要么权限过大造成事故。
我整理过一个简单的对照表，方便你快速理解这两类系统的差异：
| 维度 | OA（以泛微为例） | ERP（以用友 U8 为例） |
|---|---|---|
| 核心对象 | 表单、流程、人员、组织 | 物料、单据、存货、财务账 |
| 常见接口 | REST、WebService、Ecode | API、中间表、数据库视图 |
| 认证方式 | 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 接进 Agent
3.1 先摸清 OA 的接口家底
接 OA 的第一步，绝对不是打开 Blade 就开始配。先把目标系统的接口家底摸清楚。
以我们用的泛微 OA（E-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 接进 Agent
4.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 常见问题速查表
把生产环境里遇到的典型问题整理成一个简易速查表，给你参考：
| 问题现象 | 可能原因 | 排查思路 |
|---|---|---|
| 工具调用偶发 401 | token 刷新并发冲突 | 检查认证中心是否做了互斥刷新 |
| 模型传参格式错误 | 工具 Schema 信息不足 | 补充参数类型、格式、示例 |
| ERP 接口超时 | 月末结账/数据量大 | 调长超时，区分读和写重试策略 |
| OA 审批状态不更新 | 轮询周期太长 | 缩短单次查询间隔，增加最大轮询次数 |
| Agent 调用工具被拦截 | 权限网关白名单未放行 | 查看审计日志，确认是否有越权操作 |
| 返回数据包含乱码 | 原系统返回编码或 HTML | 在返回模板中做清洗和字段翻译 |
这表不算全，但覆盖了大多数生产接入的常见问题。如果你在接入时遇到类似现象，可以按这个思路快速定位。
6. 后续还能怎么扩展
FDE MCP Blade 跑通 OA 和 ERP 之后，我明显感觉企业内部 Agent 的落地路径清晰了很多。核心思路就一条：把模型无关的事情都交给标准化中间层，把精力集中在真正复杂的业务理解和流程编排上。
下一步我们的计划是把企业微信的机器人回调也接进 Blade，让员工直接在 IM 里唤起 Agent；再把 BI 报表系统接进来，让自然语言直接查经营数据。这个扩展成本相比之前接 OA、ERP 要低很多，因为认证、权限、工具注册的框架已经成型，新增连接器只是工作量问题。
从个人经验看，Agent 进生产从来不是技术演示，而是一场系统集成和工程治理的持久战。模型能力会越来越强，但企业内部系统的复杂性和历史包袱，短期不会消失。谁能把"模型能力"和"企业系统"之间那层胶水做扎实，谁就能真正把 Agent 用起来。
最后分享一个小技巧：如果你也面临多个系统接入的困境，先不要追求一步到位，挑一个用户需求最明确、系统接口相对规范的场景（比如 OA 待办查询 + ERP 库存查询），用 MCP 框架从零到一跑通，拿到真实的成功率和用户反馈，再横向扩展。这个模式的确定性，比一上来就搭一个大平台要高得多。
