某 80 人规模的鞋服批发企业上个月把钉钉悟空开了一个月，业务一线很兴奋——销售在群里 @ 悟空问「这个客户上个季度发了多少货」，悟空答得头头是道。但开了一周老板就发现，悟空只能基于上传的知识库回答，要查实时库存、查回款、查在途订单，它一概不知。IT 负责人来问：能不能让悟空连进我们自己的 ERP 和 CRM？要走悟空 API 二开吗？投入大概多少？这条路走通了能解决什么？
这是绝大多数开通悟空之后会立刻撞上的问题。原生悟空靠 RAG 啃知识库可以解决「员工手册」「产品参数」「政策法规」这类静态问答，但凡涉及实时业务数据，就必须走 API/二开把 Agent 接到自家业务系统里。这篇把开放度、3 条接入路线、数据和权限的处理方式、调试上线三件套以及一个能直接用的决策清单全部讲清楚，让你看完能判断：自家这套组合，到底是该走原生 Skill 套餐，还是该投入二开。
一、悟空 API 当前开放到什么程度
要先把「悟空开放了什么」这件事看清楚，不然后面所有讨论都是空中楼阁。当前悟空的开放能力大致分三档，从浅到深：
| 开放层级 | 能做什么 | 适合谁 | 改动成本 |
|---|---|---|---|
| 原生 Skill 包 | 调用钉钉已封装的能力（审批、考勤、文档、待办等） | 不写代码、只配置 | 低，按页面配 |
| 自定义 Skill | 写 HTTP 服务，让 Agent 调用自家接口 | 有后端开发能力的 IT 团队/服务商 | 中，按业务接口工作量 |
| 数据源接入 | 把数据库/数仓里的结构化数据按字段、权限暴露给 Agent 查询 | 已经有数据中台的中大型企业 | 中高，需要数据建模配合 |
三档不是替代关系，更像是组合关系。一个真正用得起来的悟空，往往是「原生 Skill 处理标准动作 + 自定义 Skill 接自家业务接口 + 数据源接入解决跨系统报表查询」三件套同时上。
值得注意的是，悟空的能力清单仍在快速迭代，建议在评估前到钉钉开放平台官方文档里对一遍当前可用接口列表，避免按半年前的资料做决策。本文只描述方法论和判断框架，不写死接口名和配额数。
二、把 Agent 接到自家 ERP 的 3 条路线
把悟空和自家 ERP/CRM 接起来，落地形态大致有三条路。哪条合适，要看你想让 Agent 在哪里出现、用户身份怎么管、业务系统能不能改动。
路线 A：原生 Skill 包装。 适合 ERP/CRM 已经有标准开放 API、且你不希望大改的场景。做法是写一层薄薄的中间层，把 ERP 的查询接口包成符合钉钉 Skill 规范的 HTTP 服务，注册成自定义 Skill 挂到悟空里。员工在悟空对话框里问「A 客户的应收账款余额是多少」，悟空识别意图后调用你写的中间层，中间层去 ERP 取数返回。投入小、上线快，但能解决的问题以查询类为主。
路线 B：自定义 Skill 调用业务接口写动作。 这是查询路线的进阶，让 Agent 不仅能查，还能写——提交报销、创建客户、推进商机阶段、生成调拨单。这一档真正吃功夫，因为涉及写动作时必须把权限、审批流、防误操作机制全部考虑进去，不能让 Agent 随便代下游员工签字。具体做法可以参考 AI Agent 在钉钉/CRM/ERP 里跟单的完整路径 里讲过的「读权限和写权限分级控制」。
路线 C：反向把悟空当能力嵌进自有应用。 前两条路线是「让悟空连业务系统」，这一条是反过来——业务系统的某个界面里嵌入悟空对话能力，让员工在自家系统里就能调用 Agent。比如 CRM 客户详情页右侧放一个对话区，业务员在里面问「这个客户最近的拜访记录」「下次拜访建议带什么资料」，背后跑的还是悟空的推理引擎，但用户感知是在自家系统里完成的。这条路线在数据安全策略严格的企业里更有优势，因为对话流可以全程在自家系统里留痕。
三条路怎么选？小结一张判断表：
| 场景 | 优先路线 | 备注 |
|---|---|---|
| 只想让员工能在钉钉里问数 | A | 投入最小，上线最快 |
| 想让 Agent 替员工提交简单单据 | B | 必须叠加审批兜底 |
| 数据敏感度高、要在自家系统留痕 | C | 嵌入成本中等，体验完整 |
| 既要在钉钉用、又要在 ERP 里用 | A+C 组合 | 一套 Skill 服务，两个入口 |
三、数据接入：知识库 RAG 和结构化查询的混合架构
这是悟空二开里最容易翻车的地方。很多团队上来就把所有数据都怼进知识库，结果发现 Agent 答静态文档准，答动态业务数据全是幻觉。原因很简单：RAG 适合非结构化文本，不适合实时业务数据。
合理的分工是：
- 静态、文本型、变化慢的内容走知识库 RAG：产品手册、SOP、销售话术、政策制度、培训资料、历史案例库。这类内容上传到悟空知识库，Agent 通过向量检索回答。
- 实时、结构化、有强一致性要求的数据走自定义 Skill 调业务接口：库存、回款、订单状态、客户档案、考勤记录、报表数字。这类数据让 Agent 通过 HTTP 接口实时查询。
- 半结构化、需要复杂查询的报表走数据源接入：经营驾驶舱、月度业务回顾、销售漏斗分析。这类查询如果硬塞自定义 Skill，每个查询都要单独开发，工作量爆炸。更好的做法是把数据仓库的语义层暴露给 Agent，让它自己拼 SQL。
三种数据通道怎么协同？给一个典型的对话流程例子：员工问「华北区上个月 TOP10 客户的回款情况」，Agent 先去数据源接入档拉销售排行，再针对每个客户去 ERP 业务接口取实时回款，最后从知识库里拉风险等级判断规则做出综合答复。这种「混合架构」才是悟空二开真正发挥价值的形态。具体的混合方案可以参考 企业 AI Agent 数据安全要怎么做 里关于数据分层的讨论。
四、权限映射：悟空里的用户身份怎么和 ERP 对齐
这一节是整个二开里最关键的安全点，做错了轻则数据越权，重则被审计责令下线。
钉钉悟空里的用户身份是钉钉 UserID，自家 ERP 里是 ERP 账号，CRM 里又是 CRM 账号。Agent 调用业务接口时，必须知道「现在是谁在问」，且这个身份要能映射到 ERP/CRM 的权限体系里。
常见的几种做法：
| 映射方式 | 优点 | 风险 |
|---|---|---|
| 服务账号统一调用 | 实现简单，一个 token 走天下 | 越权严重，所有人都能看所有数据 |
| 通过工号字段反查 | 利用已有的工号-账号映射表 | 工号未维护或重复时易出错 |
| OAuth 二次授权 | 用户自己授权，权限最准 | 体验割裂，每次都要点同意 |
| 单点登录账号体系 | 钉钉 + ERP 共用同一套 IdP | 实施前提是已经有统一身份 |
中型企业的稳妥路径是先盘账号体系：销售-CRM、财务-用友/金蝶、HR-自研，一张映射表整理出来才能动手。如果连这张表都梳理不出，硬上 Agent 等于把 ERP 当裸奔接口暴露给悟空，迟早出事。已经做过 钉钉和金蝶打通的实施细节 或 钉钉和用友的对接路径 的团队，这一步会快很多，因为身份映射的脏活已经在第一次集成时清过一遍。
还要补一句：写动作类 Skill（提交单据、修改数据）一定要在 Agent 调用前加一道人工确认，不要相信「大模型理解力强不会做错」。所有写操作都过审批流，对账系统里要能查到「这条记录是悟空 Skill X 在 Y 时刻代用户 Z 提交的」。
五、调试与上线：沙箱、灰度、日志追踪三件套
自研 Skill 不是写完就丢生产，正经的上线流程要走三件套。
沙箱环境。 钉钉开放平台有开发者沙箱，新写的 Skill 先注册成「内测应用」，只开放给开发者本人和测试同事。在沙箱里把对话流跑通——Agent 能不能正确识别意图、参数提取得对不对、错误响应能不能优雅返回——再考虑出沙箱。
灰度发布。 出了沙箱不要全员铺，先开 10% 用户、跑一周、看数据。建议至少观察：Skill 被调用的次数、调用成功率、用户复问率（同一个问题被反复问意味着上一次答得不好）、用户主动给的反馈。这一周里大概率会发现一些上线前没想到的边界情况——比如某种特殊客户编码 Agent 解析不出来，某个老业务接口超时——这些都得先修了再扩大灰度。
日志追踪。 每次 Skill 调用都要落三条日志：Agent 收到的原始问题、Agent 解析后的调用参数、业务接口返回的结果。出问题排查时这三条缺一不可。建议把这套日志直接对接到企业现有的可观测体系（Grafana/Loki/ELK 都行），不要独立成一个孤岛。
整个流程跟传统 IT 项目灰度上线很像，区别在于 Agent 项目的「正确性」很难用单元测试穷举，必须靠灰度期的真实用户反馈倒逼调整。
六、自研 Skill 和悟空 Skill 市场的区别
钉钉开放平台有一个 Skill 市场，里面已经有不少现成的 Skill 包——会议纪要、智能客服、培训问答等。什么时候直接用市场里的、什么时候自研？给一张对照表：
| 维度 | 市场 Skill | 自研 Skill |
|---|---|---|
| 上线速度 | 几小时 | 1-4 周 |
| 适配自家流程 | 通用流程为主 | 完全贴合 |
| 数据安全 | 依赖供应商承诺 | 自己掌控 |
| 持续迭代 | 跟供应商节奏 | 自己排期 |
| 长期成本 | 订阅费随用户数涨 | 一次性投入+运维 |
| 退场难度 | 低，停订就走 | 中，资产留在自家 |
不是非此即彼。常见组合是「通用能力用市场 Skill 起步，业务特异性强的部分自研补」。比如智能客服可以先用市场 Skill 跑 FAQ，复杂工单查询则自研 Skill 直连工单系统。这个组合策略和我们在 SaaS 还是定制开发的边界判断 里讲的混合架构思路是一致的。
七、什么团队/什么场景值得走 API 二开
不是所有企业都该自研 Skill。给一个相对务实的判断框架。
值得走二开的场景：
- 业务系统已经有规范的开放 API，不是裸数据库
- 有 1-2 名能写后端的工程师，且没被日常需求挤死
- 有一个被高频问的业务场景，原生 Skill 解决不了（例如每天都要问的「客户回款」「门店实时库存」）
- 数据安全要求高，不接受敏感数据上第三方 SaaS Skill
- 后续还会有 5-10 个类似场景待接入，单点改造能形成可复用资产
建议先用市场 Skill 凑合的场景：
- 业务系统连开放 API 都没有，要自研 Skill 得先做 ERP 二开
- IT 团队只有 1-2 人，已经在维护一堆系统
- 只有一个孤立场景，做完就用不上别的
- 当前的悟空使用频率还很低，老板自己都没想清楚要它干啥
中型团队（30-150 人）真正适合的姿势是：先用 1-2 周做一个最小可用的自定义 Skill，对接最痛的那个业务接口，看真实使用频率。三个月内如果调用量稳定上升、用户反馈说「离了它干活变慢」，就是该追加投入的信号。如果数据持续低迷，说明这个场景本来就不该 Agent 化。这种「小步快跑」的逻辑和 AI Agent 落地的整体路线 里讲的小切口起步是同一个思路。
八、AI Coding 让二开成本不再等比例贵
要不要做自研 Skill 这件事，过去两年判断标准变了。早期一个工程师 2-3 周才能交付的 Skill，今天用 Cursor、Claude Code、通义灵码这类 AI 编码工具辅助，1-2 周可以出第一版。这不是吹牛，主要省下来的工作量在：
- 接口适配代码：把 ERP 接口的入参出参转换成 Skill 规范，AI Coding 工具能直接读 OpenAPI 文档生成 80% 的胶水代码
- 错误处理：try-catch、超时、重试、降级，这些标准模式由 AI 写比人写更全
- 测试用例：让 AI 根据接口文档生成 mock 数据和测试 case，覆盖率比人工写更高
- 文档：Skill 上线必须配的使用说明、参数说明、错误码说明，AI 帮你生成初稿
我们做过几个悟空 Skill 项目，AI Coding 介入后，单个原子 Skill 的人天投入大约从 8-12 人天降到 4-6 人天，节省的工时主要花在更值钱的地方——业务逻辑梳理、权限设计、灰度复盘。这一点和我们在做 企业 AI Agent 成本控制 时的观察一致：真正贵的从来不是写代码本身，而是搞清楚要写什么。
如果你之前因为「二开太贵」而搁置了悟空 API 路线，现在值得重新算一下账。一个能写后端的工程师配上 AI Coding 工具，覆盖原本需要外采服务商的工作量已经不是难事。
九、悟空二开自检清单
把前八节的判断点收成一张可带走的清单。逐条打勾，能勾上 5 个以上再启动二开项目。
- 业务系统有规范的开放 API，文档齐全（不是「让我去问下原厂」）
- 用户身份映射方案已经想清楚，不是用服务账号一把抓
- 已经识别出至少 1 个高频业务场景，原生 Skill 解决不了
- 有专人负责 Skill 服务的日志和可用性，不是上线就没人管
- 业务接口的 QPS 承压能力评估过，不会被 Agent 触发打挂
- 写动作类 Skill 全部接审批兜底，不让 Agent 裸奔
- 沙箱-灰度-全量的上线流程已经走通，不是一把梭到全员
- 知识库和实时数据分工清晰，不把动态业务数据丢 RAG
- AI Coding 工具链已经在团队里铺开，单 Skill 工时控得住
- 老板对悟空二开的预期是「降本增效」而非「替代员工」
如果勾不到 5 项，建议先把基础建设补齐再启动二开，不然项目大概率半途而废。可以先去 钉钉悟空企业落地指南 把基础场景跑顺，再考虑动 API。
十、写在最后
悟空 API/二开这条路，本质是把通用 Agent 框架和自家业务系统的耦合度推到更深一层。原生 Skill 包是别人定义的能力清单，自定义 Skill 是把自家业务接口翻译成 Agent 能懂的语言，数据源接入是把数据底座暴露给推理引擎。三档能力组合得当，悟空才能从「一个会聊天的工具」变成「一个能帮员工干活的同事」。
这条路不便宜，但也没到吓人的地步。当前的判断框架已经很成熟：先盘自家业务系统的 API 健康度、盘 IT 团队的工程能力、盘真正高频被问的业务场景，再决定是租市场 Skill 还是自研。中间路线永远是最务实的——通用能力用现成的，业务特异性强的部分自己长。剩下的，就是让 AI Coding 把那些原本占大头的胶水代码、错误处理、文档工作量降下来，让工程师把精力花在搞清楚业务逻辑、设计权限映射、复盘真实数据这些机器替不了的事情上。
