AI智能体调用企业内部系统：先只读，跑稳了再放开写
能调用，但「连得上」和「改得动」要分开谈
客户问得频率很高的一句话是：你们这个智能体，能不能直接连我们的 ERP 下单、连 CRM 改客户等级？技术上都能。工具调用（tool calling / function calling）的本质，就是让模型输出一段结构化参数，由你的程序去执行一个预先写好的接口。真正难的不是连通，而是出了问题谁负责、能不能恢复原状。
我们在项目里踩过一个挺典型的坑：一开始给智能体开了「查库存」和「改库存备注」两个工具，因为觉得备注字段无关紧要。结果模型在一次多轮对话里把同一个 SKU 的备注连续覆盖了十几次，把仓库同事写的到货时间冲掉了。数据没丢，但排查花了半天。这件事之后我们定了条规矩：任何写操作，先当它一定会出错来设计。
把工具范围钉死成白名单，别给万能钥匙
不要给智能体一个「数据库账号」或者一个「万能 HTTP 请求」工具，那等于把整个内网交出去。做法是每个工具背后对应一个固定接口、固定参数结构、固定权限，多一个参数都不行。
| 系统类型 | 建议接入方式 | 初始权限 |
|---|---|---|
| ERP / 进销存 | 厂商开放 API，或只读视图 | 只读查询订单、库存 |
| CRM | 官方 API，字段白名单 | 只读客户、跟进记录 |
| OA / 审批 | 审批发起接口，不直接改状态 | 可写，但只允许生成草稿 |
| 工单 / 客服 | 内部服务封装 REST | 只读 + 建单 |
| 文件服务器 | 指定目录挂载，不开放全盘 | 只读 |
| 企业微信 / 钉钉 | 机器人 webhook | 只读 + 通知类消息 |
注意最后一行。发消息看着无害，但一个智能体在群里连发几十条通知，同样是事故。通知类工具必须加频率限制，按分钟、按会话双维度卡。
有些需求根本不需要工具
查制度、查产品参数、查报价规则这类，走企业知识库就够了，检索增强比调接口简单得多，风险也低一个量级。只有当答案必须来自实时业务数据，或者必须产生一个动作，才轮到工具上场。这个判断能省掉大约一半不必要的对接工作量。
只读与可写分级：先只读，跑稳了再放开
我们习惯分四级，判断标准不是「这个操作重不重要」，而是「错了以后能不能两条 SQL 改回来」。能改回来的可以早开，改不回来的再急也往后排。
- L0 只读查询：查订单状态、查库存、查余额。无副作用，可以放量。
- L1 只读加聚合导出：生成报表、导出名单。有数据外泄风险，要控字段范围和条数上限。
- L2 受限写：生成草稿、创建待审批单据、写备注但不动主数据。必须人点一下才生效。
- L3 直接写：直接改价、扣库存、发消息、改客户归属。留到最后开，只选可回滚的小场景。
只读阶段要看的不是「能不能查对」，而是三件事：模型选工具的准确率（该查 A 的时候有没有跑去查 B）、参数填错的比例（日期、单号、客户名写错）、空结果时的表现（查不到是老实说查不到，还是编一个）。这三项稳定下来，再谈放开 L2。在AI 智能体私有化部署的项目里，我们一般会给客户配一个「影子模式」：L2 的操作先不真正执行，只记录「如果执行会做什么」，人工对照一周，确认没有离谱的再真开。
失败回滚：按「一定会错」来设计
智能体调用工具失败，多数不是网络问题，是参数不合理。三条硬要求：
- 每个写工具必须幂等。同一请求带同一幂等键重复调用，结果一致；否则模型重试一次就多一条订单。
- 事务边界要短，而且要在你的代码里，不在模型里。模型不知道什么是事务。跨系统操作不要指望它一步完成，拆成「创建—确认—提交」三个工具，每步都能中断。
- 要有补偿动作，不只是回滚。已经发出去的审批、已经推到群里的消息，数据库回滚没用，得准备撤销或更正的工具。
第二个坑：批量改价工具当时没加条数上限，测试环境跑得好好的，生产上一句「帮我把 A 类商品价格下调 5%」匹配到了八百多个 SKU。幸好那一级是 L2 待审批，人没点通过。之后所有批量类工具默认 50 条硬上限，超了就分批或者转人工。
操作留痕：日志要能回答五个问题
出了事得能还原。日志不是记一句「调用了 updateOrder」就算完，它要能回答：谁发起的、模型为什么选这个工具、传了什么参数、返回了什么、谁批的。
| 字段 | 说明 |
|---|---|
| 会话 ID / 用户 ID | 谁问的，从哪个入口进来的 |
| 模型原始输出 | 含工具名与完整参数，不要截断 |
| 参数校验结果 | 通过、被规则拦截、超上限 |
| 执行时间与耗时 | 排查超时与并发冲突用 |
| 外部系统返回码 | 存原始响应，别只记成功失败 |
| 审批人 | L2 及以上必填 |
留痕还有个现实用处：以后要把智能体从「辅助」往流程自动化推进，这些日志就是设计依据——哪个步骤人反复干预，说明那里还不该自动化，硬上只会更乱。
部署形态本身也在划分风险边界
能私有化部署的尽量私有化。不是云端不安全，而是内部系统的接口大多没对公网暴露，私有化之后智能体和业务系统同在内网，少一层穿透，也少一堆安全审批。模型用哪家可以后议，工具调用的执行层一定得是你们自己控制的代码。
一个按周推进的节奏
- 第 1—2 周：梳理 3—5 个高频只读查询，做成 L0 工具，进白名单。
- 第 3—4 周：放真实用户用，重点记录选工具准确率和空结果处理。
- 第 5—6 周：开 L2，影子模式对照，人工复核一周。
- 第 7 周起：挑 1—2 个可回滚的 L3 场景小流量放开，设条数上限和熔断开关。
别一次接十个系统。贪多的项目我们见过，最后每个工具都半通不通，用户试两次就回去了，反而更难推动。
下一步：先写三行字
如果你手上正好有一个系统想接，动手前先把三件事写下来：这个系统有哪些接口、其中哪些是只读的、最坏情况下一条错误数据要多久能修回来。这三行写完，能接不能接、先接哪个，基本就清楚了。想找人一起过一遍清单，把系统列表发过来，我们帮你标一下分级，也欢迎看看我们给本地制造和商贸企业做的其他方案。电话 400-873-2750，或直接在联系我们留个需求。