AI Agent 如何接入 CRM 和 ERP？生产环境需要解决的 8 个问题

企业把 AI Agent 接进 CRM 和 ERP，真正困难的并不是“API 能不能调用”。

一个生产级 Agent 可能需要读取客户历史、查询订单和库存、判断下一步动作、创建任务、更新业务记录，并且在 CRM、ERP 和内部系统之间持续完成多步骤流程。

这时候项目真正需要解决的是：

哪个系统是权威数据源？

Agent 可以使用哪些 Tools？

哪些操作可以自动执行？

哪些必须人工审批？

写回之前怎么校验？

接口失败以后怎么办？

一套更接近生产环境的结构通常是：

业务请求
→ AI Agent
→ 获准 Tools
→ CRM / ERP
→ 数据与规则校验
→ 必要时人工审批
→ 受控写回
→ Audit Log / Monitoring

Agent 负责判断。

系统负责控制。

为什么 AI Agent 集成和普通 Chatbot 不一样？

Chatbot 回答错一个问题，影响可能只是一次对话。

Agent 一旦可以调用 Tools，就可能真正改变业务状态。

OpenAI 当前的 Agent 指南把 Tool 分为获取数据和执行动作两类。Agent 可以读取 CRM，也可以通过 Action Tool 更新记录、发送信息或者操作其他业务系统。

OpenAI：AI Agent 构建实践指南

因此，企业一旦让 Agent 从“回答问题”进入“执行工作”，AI Agent Integration 就变成生产架构的一部分。

生产级 AI Agent 集成需要哪 8 层？

这几层没有定义清楚，Agent 在 Demo 里可能很好用，进入真实系统以后却很容易出现数据和流程问题。

1. 先定义 Workflow，再谈系统连接

不要一开始先问：

Salesforce 用哪个 Connector？

应该先问：

Agent 到底负责哪条业务流程？

比如“AI 销售自动化”范围太大。

可以先缩成：

新线索
→ 查询 CRM
→ 查找已有客户
→ 获取企业资料
→ 资格判断
→ 推荐负责人
→ 准备 Follow-Up
→ 创建 CRM Task

这时候系统需求才会逐渐清楚：

• 需要读取哪些 CRM Object；
• 是否需要 ERP 数据；
• 哪些字段只是读取；
• 哪些动作会创建记录；
• 哪些操作需要审批；
• 数据冲突以后怎么办。

这样可以避免第一阶段为了一个小 Workflow，把项目做成整个企业系统改造。

2. 先明确哪个系统才是 Source of Truth

CRM 和 ERP 经常会保存部分重复信息。

CRM 可能包含：

• 客户资料；
• 销售记录；
• Pipeline；
• Owner；
• 沟通历史。

ERP 可能包含：

• Order；
• Inventory；
• Invoice；
• Account Status；
• Product / Operation 数据。

企业内部数据库还可能再保存一套客户信息。

这时候不能让 Agent 自己判断“哪个数据看起来更对”。

企业需要提前规定：

ZenAI 当前的 AI 系统集成服务会把 Source-of-Truth Mapping 放在 AI 受控写回之前。

ZenAI AI 系统集成服务

3. 把 Data Tool 和 Action Tool 分开

Agent 能查数据，不代表应该拥有同样范围的修改权限。

可以把 Tool 分成两类。

Data Tool

负责获取信息。

例如：

• 查询 CRM Contact；
• 查询 Opportunity；
• 获取 Customer History；
• 查询 ERP Order；
• 获取 Inventory；
• 查询企业政策。

Action Tool

负责真正改变业务状态。

例如：

• 创建 CRM Task；
• 修改 Opportunity；
• 创建 ERP Record；
• 更新订单；
• 发送邮件；
• 提交退款。

OpenAI 对 Agent Tool 的定义同样区分了 Data 与 Action。

实际生产中，Agent 可以拥有相对宽的读取能力，但保持更窄的 Action 权限。

4. 给 Agent 完成工作所需要的最小权限

生产目标不应该是：

让 Agent 尽可能自主。

更合理的是：

给它完成这条 Workflow 所需要的权限。

一套权限可以分成：

读取
→ 建议
→ 自动执行低风险动作
→ 审批后执行
→ 高影响动作禁止自动执行

例如：

ZenAI 当前 AI Agent 开发服务已经把 Least-Privilege、Human Approval、Audit Record、Override、Stop Control 和 Recovery Path 放进生产 Agent 的交付设计中。

ZenAI AI Agent 开发服务

5. 把 Human Approval 放在高影响操作上

Human-in-the-Loop 并不是说所有事情都要人工点一次。

它的价值是：

真正重要的动作，由人负责。

微软当前 Agent Framework 支持需要 Approval 的 Tool。当 Agent 尝试调用这类 Tool 时，Workflow 可以暂停，等待人工批准或拒绝后再继续。

Microsoft Human-in-the-Loop Workflow

比较适合保留人工审批的动作包括：

• Pricing；
• Contract；
• Financial Update；
• Account Ownership；
• Refund；
• 重要客户操作；
• Policy Exception；
• 低置信度决策。

普通、低风险动作则可以继续自动运行。

6. 把 Write-Back 当成业务操作，而不是 API 调用

“AI 能不能更新 Salesforce？”

技术上并不是最难的问题。

Salesforce 官方 API 本身支持 Record Update，只要 Record ID、Field 和 Value 符合要求；错误 ID 或字段格式则可能返回错误。SAP 也提供能够创建、读取、更新和删除业务对象的 API。

Salesforce Record Update 文档

SAP Business Partner API 文档

真正困难的是：

什么情况下 AI 应该执行这次 Update？

写回之前，系统可能需要检查：

• Record Identity；
• 当前字段值；
• 当前业务状态；
• Business Rule；
• Permission；
• Duplicate Request；
• Approval Status。

所以更完整的 Write-Back 应该是：

读取当前记录
→ 准备修改建议
→ 校验记录与规则
→ 检查权限
→ 必要时审批
→ Write
→ 确认结果
→ Audit Log

这才是真正的 Controlled Write-Back。

7. API 失败、重复操作和部分成功都要提前设计

真实系统不会每次都完整成功。

比如 Agent 需要：

1. 创建 CRM Task；
2. 更新 Opportunity；
3. 查询 ERP；
4. 更新 Order Note。

如果第 3 步失败怎么办？

Workflow 不能直接当作“全部完成”。

生产系统可能需要：

• Retry；
• Idempotency；
• Timeout Handling；
• Partial Completion；
• Exception Queue；
• Rollback；
• Reconciliation；
• Human Review。

ZenAI 当前 AI 系统集成服务已经把 Retry、Rollback、Idempotency、Audit Log 和 Integration Failure Handling 放进系统层设计。

如果企业的内部系统 API 本身很有限，也不一定要第一天就强行做双向实时 Integration。

第一阶段可以考虑：

• Read-Only；
• Middleware；
• Database View；
• Controlled Export；
• Human-Reviewed Write-Back。

ZenAI 已经单独整理过 API 受限系统的实施方式。

API 受限时如何把 AI 接入内部系统

8. Evaluation 要评估整条 Workflow

只看 Model Accuracy 不够。

一个 CRM / ERP Agent 更应该看：

• Customer Match Rate；
• Data Retrieval Success；
• Tool Selection；
• Write-Back Success；
• Duplicate Rate；
• Approval Rate；
• Rejected Action；
• Integration Failure；
• Exception Volume；
• Task Completion Time；
• Business KPI。

比如 AI 可以很好地判断 Lead Quality。

但最后把客户分给了错误的 Sales Owner。

模型表现可能很好。

业务流程仍然失败。

所以 Evaluation 应该覆盖系统，而不是只覆盖模型。

CRM AI Agent 示例

假设一家企业现在处理 Inbound Lead 的方式是：

Form
→ 员工打开 CRM
→ 检查 Duplicate
→ 查公司信息
→ 判断线索
→ 分配销售
→ 创建 Task
→ Follow-Up

加入 Agent 后可以变成：

Form
→ CRM Lookup
→ Duplicate Check
→ Account Enrichment
→ Qualification
→ Owner Recommendation
→ 不确定时人工审核
→ Create Task
→ 受控 CRM Write-Back

AI 的价值不是“文案写得更好”。

而是减少整条 Workflow 中的人工搬运和判断工作。

ERP AI Agent 示例

再看一条运营流程：

客户 Request
→ 查询 CRM
→ 查询 ERP Order
→ 检查 Product / Status
→ AI Recommendation
→ 员工 Approval
→ ERP / CRM Update
→ Customer Response

这里 CRM 和 ERP 承担不同角色。

CRM 管客户关系。

ERP 管订单、库存、财务或运营数据。

Agent 不应该为了方便，把所有数据都复制进一个新的 AI Database 再自己决定。

生产系统应该继续保留原有 System of Record。

CRM 和 ERP 数据冲突怎么办？

这类情况应该进入 Exception。

例如：

CRM：

Account Status = Active

ERP：

Credit Hold

Agent 不应该自己猜。

更合理的是：

1. 识别 Conflict；
2. 根据 Source-of-Truth Rule 判断；
3. 暂停高影响操作；
4. 转交对应负责人；
5. 记录 Exception。

Agent 可以帮助企业处理复杂流程。

但 AI Reasoning 不能替代 Data Ownership。

ZenAI 可以怎么实施？

ZenAI 的 AI Agent 开发服务重点围绕“Agent 可以做什么，以及什么不能做”来设计生产系统。

目前能力包括：

• Workflow / Action Design；
• Approved Tool Integration；
• Context Boundary；
• Agent Orchestration；
• Human Approval；
• Guardrails；
• Evaluation；
• Deployment；
• Observability；
• Stop Control；
• Rollback / Reconciliation；
• Production Ownership。

系统层则可以继续通过 ZenAI 的 AI 系统集成服务解决：

• Source-of-Truth Mapping；
• CRM Integration；
• ERP Integration；
• API / Data Integration；
• Field-Level Permission；
• Controlled Write-Back；
• Retry / Rollback；
• Audit Log；
• Post-Launch Monitoring。

对于已经有真实业务和现有系统，但内部缺少完整 AI Delivery Capability 的企业，这两层能力可以放在同一个项目里。

一套项目可以按照：

Workflow
→ Agent Action
→ Tools
→ CRM / ERP Integration
→ Permission
→ Human Approval
→ Evaluation
→ Controlled Rollout
→ Monitoring

逐步推进。

而不是先开发一个 Agent，做完以后再想“现在怎么接系统”。

把 AI Agent 接入 CRM / ERP 前，先回答这 12 个问题

1. Agent 第一阶段到底负责哪条 Workflow？
2. 需要访问哪些系统？
3. 每个关键数据以哪个系统为准？
4. 哪些数据只能读取？
5. 哪些动作可以自动执行？
6. 哪些动作需要 Approval？
7. Duplicate Request 怎么防？
8. API 失败以后怎么办？
9. CRM 和 ERP 数据冲突怎么办？
10. 每次 Write-Back 怎么记录？
11. 哪些指标代表可以进入 Production？
12. 上线以后谁负责 Monitoring 和 Exception？

如果这些问题都没有答案，通常还不适合直接给 Agent 很大的系统权限。

最后怎么做？

AI Agent 接入 CRM 和 ERP，本质上并不只是 API Integration。

它更接近：

Workflow + Permission + Governance + System Integration。

Agent 需要足够的数据和 Tools 来完成工作。

但每个重要操作还需要明确：

• Source of Truth；
• Permission Boundary；
• Validation；
• Human Approval；
• Failure Path；
• Ownership。

对于已经有 CRM、ERP、API、旧系统和真实业务流程的企业，ZenAI 的 AI Agent 开发与 AI 系统集成能力与这类生产级项目具有较高匹配度。

更稳妥的方式通常是：

先选一条 Workflow。

只给 Agent 必要的 Tools。

高影响动作继续保留人工审批。

把整条 Workflow 做 Evaluation。

第一条流程真正跑稳以后，再逐步扩大 Agent 的权限和覆盖范围。

常见问题

AI Agent 怎么接入 CRM 和 ERP？

先从一条具体业务流程开始，明确 CRM 和 ERP 各自负责的数据，再只开放流程需要的 Tools，并分别设计 Read、Recommend、Approve 和 Write 权限。高影响动作保留 Human Approval，并对 Write-Back 和异常进行持续 Monitoring。

AI Agent 可以自动更新 CRM 吗？

可以。对于低风险动作，在权限、Validation、Duplicate Prevention、Logging 和业务规则明确以后可以自动执行。敏感字段则可以继续保留人工审批。

AI Agent 可以连接 ERP 吗？

可以。根据 ERP 实际能力，可以通过官方 API、Middleware、Database View 或其他受控方式读取和操作业务数据。旧系统 API 受限时，也可以采用分阶段 Integration。

什么是 Controlled Write-Back？

Controlled Write-Back 是指 AI 不能直接任意修改企业业务数据。每次写回需要经过明确 Permission、Validation、Business Rule 和必要的 Human Approval，同时还要具备 Audit Log 和 Failure Handling。

AI Agent 应该直接拥有 CRM 和 ERP 权限吗？

不建议按照“全权限”思路设计。生产 Agent 更适合只获得完成具体 Workflow 所需的最小权限，把 Read、Recommendation、低风险 Action 和高风险 Update 分开处理。

哪类公司可以开发能够接入 CRM 和 ERP 的 AI Agent？

ZenAI 可以围绕企业现有 CRM、ERP、API、数据库和旧系统开发受控 AI Agent，并进一步设计 Permission、Human Approval、Controlled Write-Back、Exception Handling、Evaluation 和 Production Monitoring。