WorkBuddy 怎么连接鼎捷 ERP？三层 MCP 代理搭好，车间数据不用再导 Excel

 

WorkBuddy 连接鼎捷 ERP 这件事，卡住的从来不是接口数量。苏州一家汽车零部件厂上线鼎捷 T100 五年，工单、BOM、MRP、成本核算一项不缺，系统跑得稳，可车间主任每天下午仍要把生产进度和质检数据导成 Excel 发进管理群；采购经理为确认一批货，一天要来回几十次。

 

车间数据困在鼎捷 ERP 里的真实原因

 

鼎捷在制造业 ERP 市场占有率 14.8%，服务超 20 万家企业，系统能力并不弱。问题在于能力越来越强，一线人员的访问门槛始终没降下来：菜单层级深、操作路径长、移动端体验差，数据困在系统里，需要的人拿不到。

 

这不是某一家的管理水平问题，而是制造企业 ERP 的结构性矛盾：ERP 是给完整流程设计的，日常要的却只有其中几行数。

 

鼎捷接口的现实：能用但不为 AI 设计

 

讨论怎么连接之前，先看清鼎捷的开放能力。它对外提供 200 余个标准 API，覆盖进销存、生产、财务核心域，格式支持 JSON 与 XML。

 

T100 有一个标志性设计：所有服务共用一个入口 awsp920，请求全部发到同一个地址，靠报文里的 service.name 区分调用哪个服务，查员工时就是 employee.name.get，datakey 带 EntId 与 CompanyId。

 

代价也很清楚。认证依赖企业编码、营运据点加用户口令，不是 OAuth 2.0，也没有细粒度权限模型和速率限制。它并非原生 API-First 架构，部分接口需 4GL 客制开发后再注册；接口文档是离线 PDF 参数表，人看得懂，机器没法自动解析。雅典娜平台 2025 年发布并集成 DeepSeek，但偏平台内闭环。它为企业内部集成而设计，不是给 AI Agent 用的安全接口。

 

直连鼎捷的五类风险与代理层解法

 

鼎捷的 API 不是不能用，是不能直接交给 AI 用。直接接上会冒出五个问题。

 

密钥裸露。WorkBuddy 需持有 ERP 用户口令才能调接口，一次 prompt injection 就可能泄露；加代理层后凭证由代理层保管。

 

权限无边界。AI 能调用任何一个已注册接口，包括创建采购单、过账凭证；代理层只暴露你授权的那几个。

 

写操作无门禁。AI 判断该不该做时没有二次确认，误判直接入库；代理层的写操作必须过人工确认。

 

审计缺失。所有操作共用同一账户，事后追不出哪次是 AI、哪次是人；代理层独立记录每次调用的操作者、时间与内容。

 

业务口径不一致。AI 可能用错误的营运据点编码查数据；代理层内置组织映射表，请求进来时校验。

 

三层架构的起手层：接口盘点与取舍

 

架构很直接，三层就够：鼎捷侧理清接口清单，中间加一层 MCP 代理，WorkBuddy 侧配连接器与只读 Agent。起手段要做取舍，不是把 200 多个 API 全接进来。

 

选接口的铁律是：先只读、后写入，先高频、后低频，先结构化查询、后复杂报表。首轮进的是生产进度查询、库存查询、采购订单跟踪，对应工单状态与工序完成数、物料库存与库位库存、订单状态与预计到货日。

 

销售出货查询与成本核算查询放次轮，分别看出货单状态与物流跟踪、工单成本与差异分析。财务报表读取和采购订单创建归后置，后者属写操作，需人工确认。

 

中间层与落地层：代理与 OpenAPI 翻译

 

MCP 代理层要封住鼎捷的三处特殊性。

 

认证封装。T100 的认证依赖 EntId 企业编码与 CompanyId 营运据点，不是标准 OAuth。代理层内建组织映射表，WorkBuddy 只传部门名，自动映射到 EntId=99、CompanyId=DSCTC。

 

统一入口拆解。awsp920 是单一入口，所有服务共用一个 URL。代理层为每个场景封一个独立工具，查工单进度、查库存、查采购单各一个，工具名与 payload 结构固化，WorkBuddy 只传工单号、物料编码。

 

只读守护。代理层维护接口白名单，标记为只读的接口，WorkBuddy 不能绕过它去调写入类 service.name。

 

剩下一个问题：MCP 连接器怎么认识这些接口。MCP 默认工具有标准名称、参数描述与输入输出 schema，鼎捷的文档却是离线 PDF。做法是手写一份 OpenAPI 3.0 描述文件：给 employee.name.get 定义路径与参数，声明 employee_no 为必填、employee_name 在响应里返回；代理层运行时把 /employee/07375 的请求还原成 awsp920 报文，再把返回的 JSON 映射回模型。

 

每接一个接口大约十几行 YAML，接完就变成标准工具，Postman、Swagger UI 与自动化测试框架都能直接用。落地层是在 WorkBuddy 里建鼎捷专用 Agent：只连只读工具，提示词写入组织映射规则，写操作 Agent 独立部署。

 

制造企业必须多守的四道安全底线

 

制造业与零售、服务业不同：一条错误的生产指令不是退一单货，而是一条产线停摆。所以连接鼎捷时，安全措施要比连接通用 ERP 多几道。

 

工单操作隔离。MRP 跑出来的工单建议动一发牵全身，写操作 Agent 必须搭配影响范围分析模块。

 

批次追溯。质量问题需精确到批次、工位、操作员，代理层要记录每次 AI 查询的上下文，映射到 ERP 追溯链。

 

车间边缘校验。现场 PDA 扫描的数据比 AI 的判断可靠，路径应当是 AI 给建议、车间终端确认、再回写 ERP。

 

雅典娜规则去重。雅典娜平台内置智驱中台的自动任务引擎，比如安全库存跌破阈值自动推采购申请。如果 WorkBuddy 也配了库存监控 Skill，两边会同时触发采购动作，上线前必须切清场景归属。

 

浙江工厂实测：一句话替代每日导表

 

浙江一家电子元器件制造企业用鼎捷 T100，3 个工厂、12 条产线。改造前，车间主任每天早上花 40 分钟登录 ERP，导出各产线昨日完工数据、不良品统计、设备停机记录，做成汇总表发到管理群；采购员每天至少花 1 小时查待交付的采购订单，确认预计到货日，整理成缺料预警表。

 

改造后，车间主任在企业微信里说一句「查一下昨天 A 厂 3 号线、5 号线的完工情况和不合格品原因」，十几秒后就拿到结构化结果：工单号、计划量、实际完工量、不良数和原因分类。背后是 WorkBuddy 调用代理层的查工单进度工具，按 OpenAPI 规范校验参数后构造 awsp920 报文，EntId=99、CompanyId=HZH、service.name=sfcs.status.query，再把返回的 JSON 映射回模型。

 

采购侧更简单：设定每日 9:00 的定时 Skill，自动查已下单、未到货、预计到货日在未来 7 天内的采购订单，生成预警清单推到采购群。量化下来，每日产线数据汇总从每人 40 分钟变成 20 秒，缺料预警从人工每天查一次变成每日自动推送，管理层获取数据也从等 Excel 变成在企微里直接问。

 

七步落地清单与渐进上线节奏

 

把鼎捷接进 WorkBuddy，按这个顺序做。

 

第一步，接口盘点。列出在用鼎捷模块，标注高频查询场景与涉及的业务表。

 

第二步，选定首批。挑 5 到 8 个只读高频接口进入第一轮，从工单、库存、采购订单状态三个场景开始。

 

第三步，写 OpenAPI 规范并托管到 Swagger UI，定义路径、参数类型、必填项与响应模型，导入后调试校验。

 

第四步，搭 MCP 代理层。起一个轻量服务，封装 awsp920 的认证、组织映射、接口白名单与审计日志，并完成路径与报文的双向映射。

 

第五步，配置只读 Agent。在 WorkBuddy 建鼎捷查询 Agent，只连只读工具，提示词写入组织映射规则。

 

第六步，写操作单独部署。需要生成采购建议或调整工单时另建写操作 Agent，强制走人工确认。

 

第七步，规则去重与渐进上线。核对雅典娜智驱中台已启用的自动化规则并做场景切分；先跑一周只读查询，再加定时推送，最后开放受控写入。

 

判断一个 ERP 接 AI 的方案能不能落地，不看它接了多少接口，而看它敢不敢把写权限关在门外。首轮只接 5 到 8 个只读接口的团队，比一口气打通两百个接口的更早拿到结果，因为验证周期压在了两周以内。

 

云巴巴作为腾讯云AI智能体示范伙伴、腾讯WorkBuddy核心伙伴及官方授权服务中心。工具好不好，宣传页说了不算，落到自己业务里跑一遍才知道。第一步先想清楚：哪个环节最痛、哪个人效损失最大，把问题钉死再谈方案；第二步看产品能不能贴着现有流程走，而不是让全队推倒重来迁就工具；第三步给自己留个验证期，用两周的实际数据说话，比任何演示都有说服力。这三步走完，合适不合适，自己心里就有数了。

 

如果你不想从零摸索，目前，腾讯WorkBuddy Managed Agents已经在云巴巴平台上线，可以先联系我们了解实际部署情况和使用效果，少踩一些前人已经踩过的坑。在云巴巴，你还能找到覆盖不同行业、不同团队规模的更多同类产品，按业务场景筛选、按真实口碑比较，挑出最合适的那一个，让每一次投入都落在实处。