![路程图1.jpg](https://developer.qcloudimg.com/http-save/yehe-12807933/77a351711efbc4efec12164837cd2642.jpg)
>我们是一家做 ERP 的小公司，过去两年一直在试一件事：
把「实施服务」和「二次开发」这两件人力密集的事，尽可能交给 AI 智能体去做。
这篇不讲愿景，只讲我们实际跑通的链路、踩到的坑，以及目前还做不到的部分。

部署形态上我们对比过两条路：托管方案重点评估了 **腾讯云 ADP**，自部署方案用的是 Dify。本文第三节保留了这次取舍的过程与理由。
## 一、先给结论：哪些能做，哪些短期别指望

很多人问「AI 能不能替代 ERP 实施顾问」。我们跑下来的答案是：**不能替代，但能吃掉实施里最耗人的那一半。**
**已经能稳定交付的三件事**：

| | | |
|:-:|:-:|:-:|
|能力|说明|效果|
|**操作/配置问答**|「这张单据怎么审核」「这个字段在哪配」→ AI 直接答，还能顺手查库确认|客户不用等顾问回消息|
|**实施步骤与流程草案**|调研问卷、实施计划表、蓝图方案、基础资料导入清单 → AI 按行业生成初稿|顾问从「从零写」变成「改一稿」|
|**数据查询自证**|「我本月有多少未审核销售单」→ AI 调接口查真实数据回答|减少"我帮你查一下"的往返|
**短期不要指望的三件事**：
- **需求判断**：客户说的和他真正要的往往不是一回事，这需要现场经验

- **跨部门协调**：上线推进本质是项目管理，不是知识问题

- **数据对错的兜底**：AI 说「已保存成功」不等于业务上真的对，必须有校验

**一句话总结：AI 把「知识检索 + 文档初稿 + 数据查询」这三块吃掉了，但「判断」和「担责」还在人身上。**
## 二、ERP 实施为什么是门人力密集生意

做了十几年 ERP 实施，痛点就三条：
1. **知识全在顾问脑子里**：一个成熟的实施顾问要 3–5 年才能带项目，人一走知识就断

1. **同一个问题答一百遍**：「怎么新增用户」「为什么审核不了」「报表在哪导出」——90% 的客户咨询是重复的

1. **文档从零写**：调研问卷、蓝图方案、导入模板、培训课件，每个项目都重写一遍，但 80% 内容是共通的

这三条恰好都是**「知识密集 + 高度重复」**——正是大模型最擅长的场景。所以问题不是「AI 有没有用」，而是「怎么把它接进现有的系统里，且不出事」。
## 三、选型：托管方案 vs 自部署

做 ERP 智能体，绕不开一个选择：**用云厂商的托管智能体平台，还是自己部署一套（比如 Dify）。**

| | | |
|:-:|:-:|:-:|
|维度|托管方案（如腾讯云 ADP）|自部署（如 Dify）|
|**上手速度**|快，控制台配好插件就能用|慢，要自己起服务、配模型、调向量库|
|**知识库**|平台自带，文档解析省事|自建，可控但需维护|
|**工具调用**|插件机制，写个 HTTP 接口就能挂|工作流/工具节点，灵活但要自己写编排|
|**数据主权**|文档要上传到厂商侧|**完全在自己机器上**（对 ERP 很关键）|
|**成本形态**|按调用量计费，用得多不一定便宜|服务器固定成本，量大更划算|
|**可控性**|受平台限制（模型版本、超时、并发）|全部可控|
**我们的实际做法**：**两条都跑**。用托管平台快速验证链路（先证明「能跑通」），同时按自部署的架构设计，避免以后迁移时推倒重来。
**结论性建议**：如果客户数据敏感度不高、想两周内看到效果，先上托管；如果是 ERP 这种「客户数据就是命」的场景，**最终一定要能自部署**——这不是技术偏好，是合规和信任问题。
下面讲的部分，是我们已经实测跑通的链路（托管方案形态）；涉及自部署的部分，我讲的是架构设计，不假称已经上线。
## 四、整体链路：一次提问背后发生了什么

很多人以为「AI 问答」就是「把问题发给大模型」。真接进 ERP 之后，一次提问实际是这样的：
```

```这条链路里有三个设计决策值得单独说，也是我们踩过坑才想明白的。
## 五、五个关键实现点

### 5.1 多租户隔离：一个 AI 服务多家客户，绝不能串数据

一套智能体服务多个客户账套时，最容易出的致命事故是「A 客户问到了 B 客户的数据」。
我们的做法是**两段式隔离**：
**第一段：会话级 token**。ERP 后端在用户登录时调 `/register`，把该用户所属账套的数据库连接信息注册到平台，换回一个 `tenant_token`，存在用户会话里。之后每次提问都带上这个 token，平台据此路由到正确的账套。用户登出时调 `/unregister`，**token 立即失效**——不留长连接、不存常驻凭证。
**第二段：数据级分支隔离**。这是 ERP 侧自己的机制：所有业务表按 `FHBranchID`（分支=机构）隔离，每个注册账号有自己的分支，查询条件一律带上当前会话的分支值。
两段叠加的结果是：**即使 token 泄漏，拿到的也只是某一个账套、某一个分支的只读数据**，不会横向穿透。
>**经验**：多租户 AI 的隔离不能只做一层。会话 token 解决「路由到哪个库」，数据分支解决「库里能看到哪些行」，缺任何一层都是事故隐患。

### 5.2 给 AI 只读连接，写操作走业务接口

这是我们最坚持的一条设计原则：**不要给 AI 数据库写权限。**
AI 拿到的数据库连接**永远是只读的**：
- 本地部署：账套的 `bin` 目录下有一个只读连接配置文件（`RealOnlyConnectstring.ini`），里面存的就是只读账号

- 云端账套：只读连接由云端自动下发，客户端不需要也无法自行指定

那 AI 想「帮客户新建一张销售单」怎么办？**走业务接口，不走 SQL。**
ERP 暴露的是一组业务动作接口：取号、保存、审核、反审核、删除…… AI 只能「调用动作」，不能在数据库里直接改数据。这样做有三个好处：
1. **天然的权限边界**：AI 能做的事，就是它被允许调用的那几个动作，不会越权

1. **业务规则仍然生效**：单据编号规则、审核校验、必填校验全在原有链路里，AI 绕不过去

1. **可审计**：所有变更都留下单据操作痕迹，事后能追到「哪次是 AI 触发的」

>**一条通用原则：给 AI「业务动作」比给 AI「数据库权限」安全一个数量级。**
前者的最坏结果是「多建了一张单」（可撤销），后者的最坏结果是「数据被改坏了」（不可逆）。

### 5.3 不要给 AI 裸 SQL，给它模板和参数

第二个关键设计：**AI 不直接写 SQL。**
ERP 里所有的 SQL 都集中存在一张表里（每个 SQL 有唯一编号），业务代码和插件都通过编号引用它。AI 要查数据时，做的是：
```

```也就是说，**AI 只能在「已经写好、验证过的查询」里选，然后填参数**。这带来三个实际好处：
- **不出乱 SQL**：模型偶尔会写出全表扫描、笛卡尔积甚至删库语句，这条路直接堵死

- **权限可控**：能查什么由「有哪些查询模板」决定，而不是由模型的心情决定

- **性能可预测**：模板里的 SQL 都是人工优化过的，不会因为模型写法不同而雪崩

**这里踩过一个很隐蔽的坑**：这套接口的「执行动作」参数有四种取值，其中一种传的是纯编号，另一种传的是「模板编号,查询动作,,参数」这样的复合编号。
我们一开始把复合编号传给了「纯编号」那个动作，结果**接口没报错**——它把整串复合编号当成了单据编号去查，于是生成了一条 `where 单据编号 = '10,查询动作,,1'` 的查询，**静默返回空结果**。
排查花了小半天，因为日志里一切正常、接口返回 200、只是永远查不到数据。
>**教训**：**静默失败比报错危险得多。** 凡是「查不到数据」的情况，先怀疑参数形态不匹配，再怀疑数据本身不存在。
后来我们给这类接口加了「结果为空 + 条件里出现非法字符」的告警——宁可误报，也不要静默。

### 5.4 知识库要分两套，而且必须先结构化

ERP 的知识分两类，性质完全不同：

| | | |
|:-:|:-:|:-:|
|知识库|内容|使用者|
|**实施服务库**|产品架构、模块功能、实施 SOP、调研问卷、导入规范、培训课件、售后 FAQ|售前 / 实施 / 客户|
|**二次开发库**|插件开发规范、表结构、接口说明、代码模板、典型场景实现|开发（人和 AI）|
**为什么必须分两套**：混在一起的直接后果是检索污染。客户问「这张单据怎么审核」，系统可能会召回一段插件开发代码；开发问「插件怎么读子表」，系统可能召回一段客户培训话术。**两套知识混库，等于两套都变差。**
分类之外，**更重要的是结构化**。我们整理实施知识库时，最有价值的一份不是产品文档，而是**标准实施流程的环节拆解**：
```

```把这条链拆成结构化阶段后，AI 才能回答「第几步该做什么」「这一步需要客户提供什么」。**如果只扔一堆散文档进去，AI 能做的只是「检索段落」，做不了「生成实施步骤」。**
>**经验**：知识库的价值不在于「喂了多少字」，而在于**有没有把流程拆成机器可用的结构**。一份 3000 字的 SOP 拆解，胜过 30 万字散文档。

### 5.5 动作要有「读回自证」，不能信 AI 的嘴

这是最后一条，也是我们后来补上的：**AI 说「已经保存成功」不算成功。**
所有会改数据的动作，都要有一个**可核验的返回**。我们用的办法是：动作执行后返回一个结果字段（例如审核动作返回结果为空表示成功、非空表示失败原因），AI 必须拿到这个返回，并且**再查一次**确认数据真的变了，才能说「完成」。
做法很朴素，但解决了一个很现实的问题：**模型会自信地报告成功，包括它其实失败了的时候。**
>**原则**：凡是有副作用的动作，**必须「执行 + 读回 + 断言」三步**，断言失败要如实告诉用户失败。宁可说「我不确定是否成功，请你确认一下」，也不要谎报成功。

## 六、我们踩过的四个坑

**坑 1：知识库越堆越差**
一开始什么都往里塞（幻灯片、截图、会议纪要、过期文档），结果检索质量反而下降。**对策**：知识库要设「版本」和「失效标记」，过期文档必须标死——AI 没有时间观念，它会平等地引用三年前和昨天的内容。
**坑 2：AI 用「通用 ERP 常识」回答我们的产品问题**
问「你们的审批流怎么配」，模型会用它训练语料里的通用审批流知识作答，听起来很对，但和我们系统的实际路径不一致。**对策**：回答必须能落到具体文档/接口/数据的引用上，落不到就明确说「文档里没写」——这比编一个像样的答案有用得多。
**坑 3：同一个问题，不同客户得到不同答案**
改了知识库之后，老客户的答案变新、新客户的答案变旧，出现口径不一致。**对策**：把关键口径（价格、模块边界、功能有无）做成**固定事实表**而不是散在文档里，让 AI 优先引用它。
**坑 4：把「能答」当成「能交付」**
AI 能答出「怎么配置权限」，不代表它知道「这个客户的组织结构适合哪种权限模型」。**对策**：分清「知识型问题」（AI 直接答）和「判断型问题」（AI 给选项 + 顾问拍板），并在提示里明确标注当前这条属于哪类。
## 七、边界：我们不做什么

- **不做「全自动上线」**：AI 出草案，人审后再执行。实施出错的代价远高于顾问省下的时间

- **不让 AI 直接改数据库**：写操作一律走业务动作接口（见 5.2）

- **不让 AI 代替顾问做承诺**：工期、价格、定制范围，必须由人确认

- **不做没有返回值的动作**：凡执行必读回，读不回就说「无法确认」

## 八、跑下来什么感觉

最大的变化不是「省了多少人」，而是**回答速度**：
- 以前客户提个操作问题，等顾问看到消息再回，半天到一天

- 现在基础操作问题当场答，还能顺手查到真实数据自证

对顾问来说，省下的是**被反复打断的时间**——这部分其实是最值钱的，因为实施顾问最贵的成本是「上下文切换」。
至于「能不能省一个人」，我们的实测结论是：**能省掉的是「重复答疑 + 文档初稿」这部分人力，省不掉项目实施本身的推进工作。** 对小微软件公司来说，这已经够划算了——因为这两块恰好是最难招人、最容易流失的部分。

我们是一家做 ERP 的小公司，过去两年一直在试一件事：把「实施服务」和「二次开发」这两件人力密集的事，尽可能交给 AI 智能体去做。这篇不讲愿景，只讲我们实际跑通的链路、踩到的坑，以及目前还做不到的部分。

用 AI 智能体做 ERP 实施服务：多租户隔离与 Text2SQL 的边界

技术

人工智能

架构设计

数据库

AI智能体在ERP实施中可承担知识检索、文档初稿与数据查询等重复性工作，但不能替代人工判断与责任承担。通过只读连接、业务接口调用、SQL模板化及多租户隔离等设计，可实现安全可控的AI辅助。知识库需分类结构化，动作必须读回自证。托管与自部署双轨运行，最终需支持自部署保障数据安全。

代码解释

服务器

智能体

路由

让每一个 Agent，都跑在云上

tdata

lexiang

mmdp

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

用 AI 智能体做 ERP 实施服务：多租户隔离与 Text2SQL 的边界-腾讯云开发者社区-腾讯云

用 AI 智能体做 ERP 实施服务：多租户隔离与 Text2SQL 的边界

用 AI 智能体做 ERP 实施服务：多租户隔离与 Text2SQL 的边界

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐