WorkBuddy连通用友NCC：三步打通，从零到对话查询ERP

“用友NCC不需要等别人写MCP，它自己就有完整的OpenAPI。三步打通，WorkBuddy就能直接对话NCC。

某消费品集团，财务核算在用友NCC上跑。月底财务做账，科目余额得从NCC导出，加上其他系统数据，Excel手工拼完再入账——这场景每个月重复一次。

能不能让WorkBuddy直接对话NCC？一句话把月结对账从半天变成十秒钟。

老丁先去GitHub搜有没有现成的NCC MCP。结果是三个零星项目：一个只查数据字典，一个只做HR模块，一个财务做账。加起来的Star数一只手数得过来。

这容易让人得出一个结论：NCC没有现成的MCP，没法搞。

但结论下早了。

NCC不是没有接口。是接口已经有了，只是还没人把它封成WorkBuddy能用的MCP Server。这是两件事。说到这里，有MCP需求的业内同仁不妨在推文下留言，如果人多的话，老丁可以花些周末的时间搓一个出来。

用友的开放平台明确标注了「预制用友产品 NC/NCC OpenAPI」。但对接之前，先搞清楚你用的是哪个版本。NCC2005/2015 和 BIP2207+ 的 OpenAPI 是两个不同的体验。

如果用NCC2005/2015：注册应用前先确认服务器已启用OpenAPI许可，否则调不通。Token固定2小时不可配置，MCP Server需要在中间层做签名封装和自动刷新。

如果已升级BIP2207+：开放平台原生OAuth更友好，很多场景可以简化中转层。BIP原生支持智友和MCP生态，WorkBuddy对接方案比旧版更轻量。

认证链路：

认证支持两种模式：

- 客户端模式（grant_type=client）：机器对机器，无需用户密码，适合定时任务

- 密码模式（grant_type=password）：带用户身份，适合需要按人管控权限和审计追溯的场景

所有API调用都在企业内网完成，数据不出边界。API路径遵循统一的RESTful规范：nccloud/api/{模块}/{业务组件}/{资源}/{动词}。以销售模块为例，新增销售订单的路径是 nccloud/api/so/saleorder/save。

文档在哪？官方接口定义不在网上，在服务器本地，管理员直接登录服务器就能读到每个模块的完整参数规范。

第一步：注册。

管理员登录OPM页面，创建第三方应用。填应用编码（如 workbuddy_mcp）、关联一个NCC用户、配置IP白名单（限定MCP Server所在机器的IP或内网CIDR段，如 192.168.1.0/24）、勾选需要的API，点保存。系统生成 AppKey 和 AppSecret。

第二步：拿Token（或直接用签名模式跳过）。

Java SDK或Python调用令牌接口。核心是生成签名 sign：参数排序、拼接时间戳和随机数、用 AppSecret 做 AES 加密，服务端验证签名后返回 access_token。

不想管Token刷新？有一条更干净的路径。

客户端模式其实支持两种调用方式：

原生签名模式非常适合 WorkBuddy 的只读查询场景：查库存、查订单、查凭证，每次请求现场签名就行，不需要维护 Token 生命周期。这也是很多 AI 对接 NCC 项目的优选方案。

第三步：调业务接口。

不管用 Token 模式还是签名模式，调业务接口的格式一致：Header 带认证信息，Content-Type: application/json，Body 传查询条件JSON。返回标准JSON。

三步走完，WorkBuddy就能「开口问NCC要数据了」。

先说一个很多人会踩的坑：去公网搜 NCC 的 API 文档，发现零零散散只有几十个，就以为「NCC 的 OpenAPI 不全」。

事实正好相反。

NCC 的 OpenAPI 设计是一套标准化框架。URI 遵循严格的命名规范：nccloud/api/{模块}/{业务组件}/{资源}/{动词}，动词只分 query（查询）、save（新增）、update（修改）、delete（删除）、approve（审批）等。这意味着每个模块下有多少业务单据，就能按这个模板推断出多少接口路径。

从多个信息源交叉验证，NCC 的 OpenAPI 至少覆盖以下12 个业务域，且有实际客户项目中申请了「全模块 API 权限」的案例佐证：

按此推算，即便保守估计每个模块下 5 个标准接口，全量至少在 60 个以上。这还没算消息推送。NCC 支持单据变更实时回调（新增/修改/审核/作废），接口侧是完整的。

很多人担心「开放API给AI，安全怎么做」。先看NCC自身给的基础，它内置了一套三级授权模型，不是粗粒度的开或关，而是每一层都能独立控。

第一级：API白名单。

在OPM里，每个第三方应用需要逐一勾选被允许调用的API。勾了现存量查询的应用，调不了凭证新增接口。BIP高级版进一步做了RBAC角色权限控制，颗粒度更细。

第二级：账套隔离。

NCC的每次API请求，必须传 biz_center 参数（账套编码）。Token有账套边界，集团下有五个法人实体、五套账，一个Token绑一个账套，A账套的Token拿不到B账套的数据。数据隔离是NCC原生做在Token签发环节的。

第三级：IP白名单。

创建应用时可配置IP白名单，支持CIDR格式（如 192.168.1.0/24）。只有来源IP在白名单内的请求才会被处理。这是网络层的最后一道防线，即使Token泄露，攻击者从非法IP也调不通。

NCC已经给了足够的安全基础。

接WorkBuddy时，不需要在NCC层面再做改造。要做的只是在NCC基础上再封两层：

这三层（NCC原生三级+MCP+WorkBuddy）各管各的，不互相替代。NCC原生管数据边界，MCP管调用边界，WorkBuddy管用户边界。

第一，Token生命周期（或干脆跳过它）。

NCC的Token有效期通常2小时。用Token模式的，MCP Server必须封装自动刷新，每次请求前检查有效期，快过期自动续。

不想管Token刷新？有一条更干净的路径。更省事的办法：

直接用原生签名模式（AppKey+AppSecret+时间戳 SHA256 签名），跳过 Token 获取和刷新环节。签名永久有效，适合只读查询和高频调用场景。

调试阶段如果出现签名失败，先排查三件事：服务器与客户端时间是否同步、字符编码是否一致（务必加 -Dfile.encoding=UTF-8）、密钥版本是否匹配。

第二，从哪个模块开始？

NCC的API模块很多，不用一次全开。建议先接数据量最大、手工操作最频繁的那个模块。财务团队天天跟凭证和科目余额打交道，就先开总账(gl)的查询接口；采购每天审几十张单子，就先把采购订单(pu)的查询和审批接上。跑通一个模块、验证两周，再逐步扩展到其他模块。不是技术问题，是先打哪个最痛的点的排队问题。

如果手头已经有NCC服务器的管理员权限，现在就能动手：