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

NCC没有MCP？你只是没找对地方

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

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

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

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

但结论下早了。

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

NCC到底暴露了什么

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

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

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

认证链路：

NOTE

签名设计值得留意。核心流程是「参数排序→拼接时间戳与随机数→用密钥AES加密得到sign」，不是简单拼字符串。部分版本支持RSA公钥签名（SHA256验签）。不管哪种，本质都是验真不加密载荷，既控制传输开销，又建立不可抵赖的证据链。

认证支持两种模式：

- 客户端模式（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。

PROMPT
用 WorkBuddy 帮我写一个 Python 脚本，调 NCC OpenAPI 获取 Token。
参数：ip、端口、账套编码、app_id、app_secret、grant_type=client。
签名按 AES 方式：参数排序+时间戳+密钥拼接后 AES 加密生成 sign。
Token 有效期 2 小时，脚本需自动维护有效期并在过期前刷新。

WARNING: AppSecret 不要提交到版本库。放环境变量或 .env 文件，.gitignore 加排除。

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

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

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

PROMPT
用原生签名模式：AppKey+AppSecret+时间戳 SHA256 签名。
帮我生成一个查 NCC 现存量的请求，org编码 10040003。
免 token，直接签名后 POST 到 nccloud/api/ic/onhand/onhandQuery。

第三步：调业务接口。

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

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

NCC的API到底有多全

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

事实正好相反。

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

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

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

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必须封装自动刷新，每次请求前检查有效期，快过期自动续。

MCP 服务本地缓存 access_token

提前 30 分钟主动预刷新 token

（距离过期剩余 1800s 时，调用获取新 token）

增加并发锁：避免多线程同时调用获取 token 触发 NCC 限流

捕获接口 401（token 失效）兜底重新获取，应对极端情况（NCC 服务重启、缓存清空）

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

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

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

第二，从哪个模块开始？

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

一键执行清单

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

1. 确认NCC版本，找到对应OPM入口（独立URL或系统运维菜单）
2. 登录OPM，创建第三方应用，配置IP白名单（CIDR格式）
3. 记录 AppKey、AppSecret、公钥（如有）
4. 关联需要的API（从查询类开始，写操作后加）
5. 先用OPM内置「接口测试」工具验证连通性和签名
6. 登录服务器查看 sign.md，了解接口参数规范
7. 用Python或WorkBuddy写签名脚本（Token模式或原生签名模式二选一）
8. 调一个查询接口（比如现存量），确认返回JSON正常
9. 把认证链路封装成MCP Server，注册到WorkBuddy
10. MCP层加接口白名单，只暴露查询类，跑一周再开写操作