Agent 工具调用（Function Call / MCP）入门：连接 ERP、CRM 的正确姿势

企业 Agent 一旦要「查 CRM 商机」「读 ERP 库存」「创建工单」，就必须走出纯对话：模型提出调用意图，网关按白名单执行工具，再把结构化结果喂回模型生成答复。Function Call（各家模型的 tools / function calling）解决「模型如何声明要调什么」；MCP（Model Context Protocol）解决「工具如何被发现、鉴权与跨运行时复用」。两者都不等于「把 ERP 账号密码写进 Prompt」。GeonAI 按场景设计工具面与人工确认点；/agents 仅为能力参考（363+ 预设非公众全量试用）。评估请邮件 [email protected]。多 Agent 编排见 /blog/multi-agent-vs-single-assistant；交付节奏见 /blog/enterprise-ai-agent-delivery-4-steps。

先对齐名词：Function Call、MCP、自建网关

落地时常见组合是：模型 Function Call → 贵司工具网关 →（可选）MCP Server 或直连 ERP/CRM API。MCP 是可选的标准化层，不是上生产的唯一门票。

什么时候必须上工具，而不是加长知识库？

• 答案依赖实时状态（库存、物流、商机阶段、工单状态）
• 需要写操作（建线索、改地址草稿、提交退款申请）
• 必须可审计到「谁在何时调了哪个 API、参数与结果码」
• 同一问题在不同账号下结果不同（强依赖登录身份与数据权限）

若只是解释制度、报价口径、SOP，优先 RAG + 引用（见 /blog/enterprise-rag-knowledge-base-agent）。把订单 API 当知识库灌进向量库，会同时制造过期数据与合规风险。

连接 ERP / CRM 的正确姿势（硬规则）

1. 工具白名单：只暴露试点所需的 3–8 个动作；禁止「通用 SQL / 任意 REST」
2. 读多写少：默认只读查询；写操作必须另开工具，且默认「草稿 + 人工确认」
3. 身份透传：用企业 SSO / 服务账号 + 用户上下文做数据范围过滤，禁止共用超级密钥给模型自由发挥
4. 参数校验：枚举、金额上限、客户 ID 格式在网关校验；模型输出不可信
5. 幂等与重试：写工具带 idempotency key；超时只查状态不盲目重放
6. 审计字段：sessionId、toolName、argsHash、resultCode、latency、operatorConfirm 进日志
7. 失败话术：工具失败时拒答或转人工，禁止模型编造「已下单成功」

两条路径怎么选：原生 Function Call vs 引入 MCP

多数企业试点从 A 开始：把 CRM 查商机、ERP 查库存做成两个只读工具，验收通过后再评估是否用 MCP 统一暴露。把 MCP 当成「免审万能插座」是常见误解。

算例：售前助手要同时碰 CRM 与 ERP

售前对话设计可参考 /blog/presales-consultation-agent-design；若还要拆路由与专家，见多 Agent 一文。POC 指标见 /blog/poc-to-production-agent-checklist。

反模式（看到就停）

1. 把 ERP/CRM 的管理员 Token 放进系统提示或前端
2. 给模型一个「execute_any_api(url, body)」类万能工具
3. 写操作成功只靠模型自然语言确认，没有网关回执码
4. 工具报错时让模型「合理猜测」业务状态并回复客户
5. 上了 MCP 就跳过白名单、配额与人工确认
6. 用 363+ 预设页演示当成已接通你们的生产 ERP

试点清单（可直接贴进 SOW）

1. 列出必须实时/可写的意图；其余仍走 RAG
2. 画出工具白名单（名称、参数、读/写、确认策略）
3. 选定路径 A 或 B；明确鉴权与环境（测试租户优先）
4. 定义幂等、超时、重试与失败话术
5. 审计字段与抽检表（越权、幻觉回执、漏确认）
6. 灰度一个入口；达标后再扩工具，禁止一次接满所有 API

找 GeonAI 时怎么描述

说明：要接的系统（CRM/ERP/工单）、只读还是含写、是否已有 API/中间件、可接受的人工确认点、试点意图清单。邮件 [email protected]、服务方案 或 Live chat。我们优先「最小可审计工具面」，不推销无边界插件。