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

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

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

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

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

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

但结论下早了。

判断事实GitHub上没有NCC MCP确实没有成熟的所以NCC没有开放接口错——官方开放平台明写了得靠浏览器自动化兜底不需要，API完全够用

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

WorkBuddy与用友NCC对接示意图

NCC到底暴露了什么

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

维度NCC2005/2015YonBIP高级版(2207+)OPM入口独立控制台，独立登录内嵌工作台：集成平台→开放平台权限体系独立权限，基础API授权+IP白名单深度融合IUAP统一RBAC，权限/限流/监控精细化许可要求必须确认OpenAPI许可，否则403内置，无需额外许可Token固定2小时，不可配置原生OAuth更灵活对接MCP推荐MCP中间层封装签名+自动刷新原生支持智友和MCP生态，对接更轻量

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

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

NCC OpenAPI架构图

认证链路：

步骤操作关键点① 注册应用管理员登录OPM，创建第三方应用配置IP白名单（CIDR格式）② 获取凭证系统生成 AppKey + AppSecret部分版本还生成RSA公钥③ 关联API勾选需要调用的接口按模块粒度勾选，高敏接口慎重④ 生成签名参数排序+时间戳+密钥拼接，AES加密得sign部分版本支持RSA；确保客户端与服务端逻辑一致⑤ 获取Token携带sign调令牌接口access_token有效期2小时（或用签名模式免Token）⑥ 调业务接口Header: Authorization Bearer或签名Content-Type: application/json

NOTE

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

认证支持两种模式：

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

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

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

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

NCC服务器本地接口文档界面

三步打通：从零到第一次查询

第一步：注册。

管理员登录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刷新？有一条更干净的路径。

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

方式做法优缺点Token模式先调令牌接口拿 access_token，Header 带 Token 调业务API每次请求轻量，但要管2小时刷新原生签名模式AppKey+AppSecret+时间戳 SHA256 签名，免 Token 直接调业务API永久有效，不存在过期；但每次请求都要实时算签名

原生签名模式非常适合 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要数据了」。

WorkBuddy对话NCC查询结果示例

NCC的API到底有多全

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

事实正好相反。

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

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

模块路径前缀来源典型操作库存api/ic/多个已确认路径入库/出库/盘点/现存量采购api/pu/多个已确认路径订单 query/save/approve合同api/ct/已确认采购合同 queryvo/approve销售api/so/路径规则已确认销售订单 save，出库单总账api/gl/已确认凭证 insert，科目余额query资金api/sf/已确认下拨单 save/approve/query应收api/ar/集成方案确认收款单 query/save/approve应付api/ap/同上付款单 query/save/approve资产api/fa/同上资产新增/折旧/处置报销api/er/同上费用报销单 save/approve生产/uapws/rest/ncc/pub/已确认生产订单/备料/发货 query基础档案api/uapbd/路径规则已确认币种/组织/部门/客商/物料

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

NCC API模块覆盖全景图

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也调不通。

控制级机制管住了什么API白名单OPM逐个勾选（BIP版加RBAC）这个应用能调哪些接口账套隔离Token签发时绑定 biz_center这个Token能看哪些账套的数据IP白名单创建应用时配置CIDR白名单请求只能从指定网络来源发起

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

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

层级加什么作用MCP Server层接口白名单+写操作二次确认+签名生成确保不绕过OPM范围，签名正确WorkBuddy层Skill按角色分发财务组看不到采购组的Skill

这三层（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)的查询和审批接上。跑通一个模块、验证两周，再逐步扩展到其他模块。不是技术问题，是先打哪个最痛的点的排队问题。

一键执行清单

WorkBuddy对接NCC执行清单

如果手头已经有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层加接口白名单，只暴露查询类，跑一周再开写操作

JOTO 企业落地观察

• 企业部署此类ERP对接方案时，应优先评估现有NCC版本的OpenAPI成熟度与权限模型，而非等待外部MCP生态完善；BIP2207+版本因原生OAuth与RBAC支持，可显著降低MCP Server的中间层开发复杂度。
• 这类系统的取舍在于：是否采用原生签名模式替代Token管理。对于以只读查询为主的智能体场景，签名模式能规避Token生命周期管理带来的工程负担与潜在失效风险，但需确保客户端与服务端签名逻辑严格一致。
• 在RAG知识工程中，NCC本地服务器上的sign.md文档是高质量结构化元数据源，可直接提取为API Schema注入知识库，支撑LLM自动生成合规调用代码，避免人工整理接口规范的误差与滞后。
• AI安全治理需关注NCC原生三级权限（API白名单、账套隔离、IP白名单）与MCP/WorkBuddy层权限的叠加效应；企业不应将全部权限控制寄托于单一环节，而应利用各层能力构建纵深防御，例如在MCP层强制拦截未授权写操作。