最近把一个Agent项目推到生产环境我才真正理解了那句话模型选型、推理参数、编排框架这些事在真正的企业环境下只占两成工作量剩下八成全是“接系统”的活。我们的Agent要处理OA待办、ERP库存和合同审批结果接泛微、接致远、接金蝶几乎每个系统都有自己的一套认证、一套接口、一套历史遗留的“脾气”。这篇文章想写写我们这一路踩过的坑以及为什么MCP成了我们团队的解法——顺带讲讲“FDE MCP Blade”这个落地工程包的设计思路。内容适合正在做企业级Agent交付的开发者、FDE解决方案部署工程师也适合所有想搞明白“AI怎么真正进业务系统”的人。1. 从“模型很强”到“接不进去”生产环境给我上的第一课1.1 模型侧早就卷成“标品”了先说结论模型已经不是瓶颈。去年大家还在比谁能写出更花哨的提示词今年吴恩达那套Agent实战课出来之后“Agentic Design Patterns”基本成了共识——规划、工具调用、反思、多Agent协作这些套路已经被各大Agent框架做成了基础设施。再加上Pi、Hermes这些迭代很快的开源模型基座能力已经溢出到小团队也能轻松跑通一个“会调用工具的Agent”。我自己跟过的几个项目也都是这个路径刚开始用LangChain或Dify把框架搭起来模型选个中等参数量的开源模型半天就能做出一个Demo——你在对话框里问它“帮我查下今天OA待办”它能煞有介事地列个流程出来。可一到生产环境就原形毕露待办数据在泛微e10里库存数据在金蝶里审批流在致远A8和蓝凌里这些系统压根没有给AI准备的接口。模型很强但接不进去等于零。1.2 OA、ERP才是那个“隐藏的硬骨头”我在负责交付的那段时间最头疼的就是OA和ERP这对老搭档。OA这边常见的是泛微e10、致远A8、蓝凌和通达ERP那边则是金蝶、用友各占半壁江山。这些系统有几个共同点第一技术栈普遍偏老。有的客户核心业务模块还跑在十多年前的JDeveloper 10g加OA Extension上我一度以为这种组合早就该进博物馆了结果在国企和制造业客户那里见了好几次。老系统意味着什么接口文档大概率是残缺的很多接口要靠抓包和翻配置文件去逆向理解而且你敢动它生产业务就敢断。第二认证体系各自为政。通达OA喜欢走CAS单点登录泛微有自己的身份体系金蝶又有另一套用户权限模型。你做一个Agent等于要把三套认证逻辑全部吞下去再映射成一个统一身份。这个工作在技术上是纯消耗但绕不过去。第三流程引擎和业务表结构长得都是“定制脸”。泛微有建模引擎致远有自定义控件蓝凌的管理员培训手册厚得能砸死人——每家的表单、流程、数据模型都不一样。更折磨人的是这些业务语义比如“会签”和“非会签”这种审批规则在OA里有明确含义但你想让Agent理解“当前节点是会签必须所有人都同意才能流转”就得把OA的流程定义翻译成提示词和工具参数。ERP那边也一样“进销存”里的采购入库、销售出库、库存调拨每个动作都牵扯单据状态和操作权限Agent如果只是简单调一个查询接口很容易把业务上下文搞错。所以我一直觉得集成难的本质不是谁做得不好而是“时间差”业务系统是二十年资产的沉淀AI是今年刚上线的概念两边之间隔着一条很宽的护城河。2. MCP凭什么是这轮集成的答案2.1 MCP的定位给工具调用定一个“公共插座”MCPModel Context Protocol是Anthropic推出来解决“模型怎么标准地调用外部工具和数据源”问题的协议。有人把它比作AI世界的USB-C我觉得这个类比特别准。在MCP出现之前一个Agent接一个系统就要给这个系统写一套专用的工具调用代码系统一换代码就废。MCP出现之后模型侧只认标准协议系统侧只要实现一个MCP Server把自己内部的能力暴露成统一的工具、资源和提示词两边就能像USB设备插到Type-C口上一样即插即用。协议本身有三层角色MCP Server提供能力和数据、MCP Client挂在Agent运行环境里负责发现和调用、以及它们之间传输的协议消息。工具Tool是最核心的一层——每个工具带名字、描述和JSON Schema参数定义模型根据这些描述自己决定何时调用、传什么参数。正是这个“工具自描述”的机制让Agent具备了动态发现能力而不是靠人肉硬编码。所以建库选型时我一看MCP生态就踏实了这已经是事实标准各家Agent框架都在原生支持它就不用自己造轮子了。2.2 MCP生态只有想不到没有接不了在实际使用MCP的这半年里我最大的感受是生态起得太快了。浏览器自动化有Playwright MCP和Chrome DevTools MCP——后者直接在谷歌浏览器扩展设置里启用“MCP连接”就能让Agent看到当前页面内容、操作DOM这个对调试OA界面特别有用。安全测试侧有BurpSuite MCP和Yakit MCP前者可以让AI直接驱动Burp抓包、看代理流量很多同学喜欢在Trae这类IDE里把它配起来做接口检查。工业软件侧还有Blender MCP和NXOpen MCPCAD建模、NX二次开发都能被模型调起来。这些例子说明一件事MCP不是只属于前端程序员的小众协议它正在变成整个工具链的统一接口层。对我们做企业交付的来说这意味着客户不管想接什么系统大概率都能在生态里找到对应实现或者用官方SDK自己写一个成本比从零给每个系统定制要低得多。2.3 为什么不是直连API、不是RPA、也不是ESB有朋友问我你们为啥不直接调OA的REST接口或者干脆上RPA脚本抓界面我一开始也纠结过但在生产环境被教育完之后我给这三个方案排了个对比表方案优势致命短板直连API性能好、可控性高每个系统一套接口Agent的代码里全是if-else分支维护到崩溃RPA脚本能对付没有开放接口的老系统界面一改脚本就废而且模型无法感知脚本内部状态出错难排查ESB/消息总线企业级成熟集成方案太重配置流程长不适合Agent这种“动态决定下一步调什么”的工作方式MCP协议标准、工具自描述、模型自动发现生态还在完善老系统适配仍要自己动手MCP赢在“把每个系统的差异封装在Server里Agent眼里只有一组标准化的工具”。以前接一个新系统要改Agent核心逻辑现在只需要在MCP Server层加一个适配器Agent侧一行代码不用动。3. FDE视角MCP Blade到底是什么3.1 FDE是干什么的FDE全称是Field/Forward Deployment Engineer也就是解决方案部署工程师。这个岗位在企业级软件交付里特别关键——产品到客户现场方案能不能落地、系统能不能跑起来、客户能不能用顺手全靠FDE兜底。我们团队内部有轮岗、晋升和社区分享机制每周都会把客户现场踩过的坑沉淀成案例库这也是我写这篇文章的底气。现在AI Agent项目越来越多FDE的工作也随之变化。以前我们是在客户那儿部署报表、配权限、做培训现在还要负责把Agent接进客户的OA、ERP、CRM里。有些大厂已经上了FDE课程甚至有FDE证书体系说明市场对这个角色的需求已经细分化了。说白了模型是产品经理和算法工程师的“作品”而让模型真正在客户机房活下来是我们FDE的活。3.2 Blade一组即插即用的MCP Server工程包“FDE MCP Blade”是我们团队内部给一组MCP Server工程包起的代号取“刀片”的意思——每个Blade负责一个系统域像一个刀片插进Agent运行时的刀架上单刀可替换整组合拳。举个例子OA-Blade封装泛微、致远、蓝凌、通达的待办、已办、流程发起、审批操作ERP-Blade封装金蝶、用友的库存查询、进销存单据读取、订单状态跟踪CRM-Blade封装客户信息、合同、回款记录等查询能力。每个Blade的核心是“收敛差异”对外向Agent暴露统一、整洁的工具集对内把各系统的认证、接口版本差异、异常处理全部隔离在Blade内部。Agent不用关心它调的是泛微还是致远它只需要看到统一的“获取待办列表”工具。Blade这个名字还暗含另一个原则轻量、单一职责、可热插拔。我不喜欢那种装一个要花三天、配置好几本手册的重型集成平台。Blade要的就是快速部署到客户环境写一个配置就能多接一个系统。这套思路跟MCP本身的理念是天然契合的让集成变轻让Agent变聪明让交付变快。3.3 Blade与厂商定制生态的关系很多人会问泛微、致远这些厂商不也提供API和定制开发吗为什么还要自己做Blade这个问题我踩过坑得仔细说。厂商的开放平台比如泛微的建模引擎、致远的自定义控件、蓝凌的管理员后台确实能力很全但那是面向“人来操作”的。它们的接口要么是SOAP老式风格要么是内网私有协议要么文档跟实际返回参数对不上。你去查泛微建模引擎的资料十篇里有八篇是讲表单配置的真正能让Agent直接调用的REST接口往往要自己抓包去摸清结构。自己做Blade相当于在厂商的“原始能力”之上加一层“AI友好层”把接口返回的XML或复杂JSON整理成模型更容易理解的扁平结构把错误编码翻译成自然语言描述把分页逻辑藏进参数。这个封装过程厂商不会替你考虑所以它反而是FDE最有价值的工作之一。4. 实操把一个OA待办和ERP库存接到Agent4.1 前置准备与工具选型动手之前先把要用到的东西列清楚。我们团队的标配是这样的语言和SDKPython 3.11 FastMCP库也可以用官方Python SDKFastMCP能把工具定义和注册做得很简洁OA侧先用泛微e10做试点拿到一个具备查询和审批权限的服务账号确认REST接口可用ERP侧用金蝶的库存查询接口做试点验证进销存数据能否读到Agent运行时我们用的是自研Agent框架支持MCP Client标准协议配置MCP Server地址即可。这里提一个关键心得集成OA/ERP时不要一上来就接所有接口挑两个最核心、最常用的动作先打通——OA是“获取待办列表”ERP是“查询库存量”。这两个动作跑通整个链路的结构就清晰了后面加接口就是复制粘贴扩展。4.2 编写一个MCP Server核心代码用FastMCP写一个最小可用的Blade代码结构是这样的仅示意公司内部实现做了简化from fastmcp import FastMCP mcp FastMCP(enterprise-blade) # 模拟的OA和ERP连接器 oa_client OAAuthClient(base_urlhttps://oa.example.com/api, token_storeVault()) erp_client ERPClient(base_urlhttps://erp.example.com/api) mcp.tool() def get_oa_todo_list(user_id: str, include_done: bool False) - list[dict]: 获取指定用户在OA系统中的待办事项列表。 参数说明 - user_id: 用户在统一身份系统中的标识 - include_done: 是否同时返回已办事项默认只返回待办。 todos oa_client.fetch_todo(user_id, include_doneinclude_done) return [normalize_oa_todo(t) for t in todos] mcp.tool() def get_erp_inventory(material_code: str, warehouse: str 主仓) - dict: 按物料编码查询ERP系统的实时库存返回可用库存量、锁定量和预警状态。 参数说明 - material_code: 物料编码支持精确匹配 - warehouse: 仓库名称默认主仓。 inv erp_client.query_inventory(material_code, warehouse) return { material_code: material_code, available: inv[on_hand] - inv[locked_qty], locked: inv[locked_qty], warehouse: warehouse, is_alert: tkinter_keeper if inv[available] inv[safety_stock] else False } if __name__ __main__: mcp.run()有人看到这里会说这不就是普通的函数吗关键在FastMCP背后做的事——它把这些函数自动转换成MCP协议的工具定义生成JSON Schema包括名字、描述、参数结构然后通过stdio或wss暴露给MCP Client。从Agent的视角看它就是两个可用工具get_oa_todo_list和get_erp_inventory调用时模型会根据自然语言描述和参数说明自行判断传什么值。这里要特别强调“工具描述”的写法。我见过很多Bug就是因为描述写得稀烂模型根本不知道该什么时候用这个工具。后来我们总结了一个标准把工具描述写成“给新同事看的操作说明书”——包含这个工具是干什么的、什么场景用、参数含义、返回值是什么、有没有权限限制。描述越接近业务语言模型的调用准确率越高。4.3 让Agent跑通配置与联调代码写完接下来是把MCP Server接到Agent上。在Agent配置里加一段{ mcpServers: { oa-blade: { url: wss://mcp.internal.example.com/oa, headers: { Authorization: Bearer ${OA_BLADE_TOKEN} } }, erp-blade: { url: wss://mcp.internal.example.com/erp, headers: { Authorization: Bearer ${ERP_BLADE_TOKEN} } } } }注意几个生产环境的关键点MCP Server可以本地stdin/stdout启动也可以走wss远程暴露。本地模式适合开发调试生产环境我们一般走远程模式方便多个Agent实例共享连接地址和token绝对不能写死在代码里更不能跟着热词一样出现在外部文档中——我们一律走密钥管理服务轮换和审计都靠它每个Blade的Service账号只给最小权限。比如OA待办查询账号只读待办表和审批基础信息ERP库存账号只读库存和物料主数据绝不给写权限。这样即便Agent被提示词注入恶心到也不至于把生产数据改坏。联调时先跑一个最朴素的对话测试。我在控制台问Agent“帮我查一下张三的OA待办顺便看下物料A001的库存。”它会自动决定先调哪个工具、传什么参数然后把结果整理成一句话回给我。到这一步链路就通了。接下来才进入针对并发、超时、异常的重构阶段。4.4 生产环境并发与稳定性AI Agent怎么扛Agent上生产之后第一个来的问题就是并发客户那边是全公司几百号人同时用每个对话可能同时触发多个MCP工具调用每秒甚至会有好几十个工具请求打到OA和ERP上。老系统哪扛得住这种流量直接就把连接池压垮了。我们试了几个办法现在这几个方案是组合着用的连接池复用OA和ERP支持长连接的话优先复用不支持就把连接池调小避免瞬间轰垮老系统超时降级给每个MCP工具调用设置合理的超时时间我们一般设5秒超过就直接给Agent返回“系统繁忙请稍后再试”不让模型傻等限流队列外部请求按账号维度限流比如单账号QPS控制在老系统安全区间的1/3左右留足余量幂等设计查询类工具天然幂等但如果有写操作比如Agent代替用户提交审批就要在Blade里做请求ID去重防止用户点两遍就提交两遍。这几个问题不解决Agent再聪明也扛不住生产环境一秒钟的真实流量。可以说“怎么扛并发”这一题答得好的Agent才真正从Demo走向了产品。5. 生产现场常见问题与排查技巧实录5.1 让Agent“精神崩溃”的报错们干集成这行最大的乐趣就是跟各种莫名其妙的报错作斗争。我把最近在现场遇到的几个典型问题整理在这里按出现频率排序1agent execution terminated due to error.这是最常见、也最让人懵的报错。表面上它是Agent执行器说“跑崩了”但真正原因往往藏在工具调用链里——有可能是某个MCP Server超时有可能是运行环境内存占用过高甚至可能是沙盒在等待外部反馈时被回收了。我的排查顺序是先看Agent执行日志里的工具调用记录确认是哪个环节挂了再看MCP Server那一侧的访问日志看有没有收到请求、有没有返回异常最后看资源监控确认是不是内存或并发把进程压垮了。这三步走完百分之七八十的“terminated”都能定位。2Codex / Agent沙盒无法发送消息提示更新Agent沙盒这通常发生在Agent运行环境升级后旧沙盒与新版本之间的兼容性出现了问题。我们遇到过一次所有Agent实例都发不了消息排查了一圈发现是沙盒镜像版本和MCP Client SDK版本不匹配。解决办法是把环境版本统一锁定升级前先在预发环境跑一遍回归测试。3泛微OA添加外部地址作为目录报错连接被阻止因为它是由公共页面启动的意图连接到这个报错是前端浏览器安全策略搞的鬼不是后端接口问题。OA的公共页面比如门户首页想跳转到外部系统地址但被浏览器安全机制window.open拦截策略或CSP限制拦住了。我们做Agent集成时如果涉及OA内部链接跳转需要让OA管理员在可信站点里配置目标地址或者调整页面的弹窗策略。这类问题看着是报错其实是流程和配置的问题排查时要跳出“代码肯定错了”的惯性思维。4OA审批链路的语义陷阱会签与非会签这个问题不报错但比报错更坑。在授权“Agent代替用户处理OA审批”时如果某个节点是会签意味着所有会签人都同意流程才会继续而非会签或签是指任何一个会签人同意即可。如果我们给Agent配置了“自动同意”的权限而它恰好处于会签节点且它代表的是其中一位审批人那么“用户本人同意”这个动作语义上是对的但流程状态仍然是等待中——这在业务上没问题可如果Agent在回答用户“审批已通过”时就把结果说死了业务方就会误判。所以我在Blade的工具描述里必须写明当前节点的审批规则让模型在输出结论时带上“流转状态”避免误解。5.2 排查方法论先定位是Agent的问题还是系统的问题在集成现场踩坑多了我总结出一个黄金法则遇到报错先分锅再修锅。先判断错误发生在哪一层报错特征大概率的问题层处理动作Agent对话中断工具调用记录里没有请求发出Agent运行时或MCP Client配置检查MCP Server地址、token、协议版本MCP Server日志显示请求进来了但返回超时目标系统OA/ERP或网络链路检查系统负载、接口响应时间、防火墙策略目标系统返回业务异常码但Agent搞不清楚含义Blade适配层解释不足在Blade里补充错误码到自然语言的映射Agent拿到的数据和界面看到的不一致接口语义理解偏差抓包比对确认接口字段含义再修正Schema描述我始终觉得排查问题的核心不是查代码而是理解数据的流转路径。数据从OA/ERP出发经过Blade的转换变成MCP工具的结果再进到模型上下文最后变成用户看到的回答——这条链路上任何一个环节脱落Agent都会出问题。顺着链路逐个环节验证是最快的办法。5.3 避坑清单与生产经验速查最后分享一组我们整理给团队新人的避坑清单全都是真金白银换来的不要直连生产数据库很多ERP没有好用的APIFDE容易想当然地“连库直查”。但生产数据库的表结构和权限模型非常复杂一旦Agent的查询写得不严谨轻则锁表重则影响业务。方案是先包一层只读适配接口再暴露给Blade。token和密钥必须走密钥管理这一点前面提到过但我愿意重复三遍。把生产环境的密钥打出来发到群里基本就是“通关文牒变通缉令”的剧本。工具描述要跟实际Schema一致模型的调用是基于描述的不能描述里说“支持按日期查询”Schema里却没有日期参数——这会导致模型幻觉式传参然后突然调不通。先只读后写操作新接一个系统前两周只开放查询类工具等Agent调用稳定了再逐步放审批、提交等写操作权限且写操作一律做人工确认兜底。定期回归测试OA、ERP系统一升级接口结构随时可能变。我们每个季度跑一遍工具的回归用例确保Agent发现和调用都正常。6. 最后再说两句个人体会按惯例文章结尾我不爱做总结就想聊点实际的感受。这套“FDE MCP Blade”的思路真正让我觉得值是因为它把交付从“代码工程师一对一调试”变成了“配置Blade、插上刀架、跑通验证”的标准化流程。客户那边新上一个系统我们最紧张的不再是写多少行胶水代码而是业务语义要不要重新梳理、认证能不能走统一通道——这两件事恰恰是MCP帮我们收敛掉的。还有一个我压箱底的小技巧写MCP工具描述时可以试着让业务方比如OA管理员、ERP实施顾问先按自己的话说一遍这个功能是干嘛的然后你再把这段话翻译成工具描述。因为业务方对场景的描述一定比技术文档更贴近真实使用逻辑模型看到这样的描述理解准确率会高非常多。这个小习惯帮我少做了好几轮“为什么工具调用率这么低”的优化。希望你们也能少踩几个坑。