很多团队第一次接 Gemini,都会先做聊天窗口。这个 demo 很快能跑起来,但离生产系统还有一段距离。企业真正需要的不是一个“会说”的 AI,而是一个能读订单、查客户、开工单、写回状态的业务入口。
Gemini 的函数调用就是为这个问题准备的。模型不直接操作数据库,也不绕过业务系统,而是在对话中判断“该调用哪个工具、参数是什么、调用后怎么继续回答”。这层设计把自然语言和企业 API 之间接了起来。
一、函数调用解决的不是聊天问题
以售后场景为例,用户输入:
“帮我看一下订单 A20260610017 为什么还没发货,如果缺货就建一个加急工单。”
普通问答模型只能解释“可能是库存不足、物流延迟”。函数调用可以把它拆成几个动作:
- 查询订单状态。
- 根据订单 SKU 查询库存。
- 如果库存不足,创建工单。
- 把工单号和下一步处理口径返回给客服。
模型负责理解意图和选择工具,业务系统负责执行动作。这个边界很重要。不要让模型直接拼 SQL,也不要让它拥有跨系统的无限权限。
二、一个最小可用的工具列表
生产环境里,工具定义可以先从少量高频动作开始。
[{"name":"get_customer_profile","description":"根据手机号或客户ID查询CRM客户信息","parameters":{"type":"object","properties":{"customer_id":{"type":"string"},"phone":{"type":"string"}}}},{"name":"get_order_status","description":"根据订单号查询订单、支付、发货状态","parameters":{"type":"object","properties":{"order_id":{"type":"string"}},"required":["order_id"]}},{"name":"create_ticket","description":"在工单系统中创建售后或运营工单","parameters":{"type":"object","properties":{"customer_id":{"type":"string"},"order_id":{"type":"string"},"priority":{"type":"string","enum":["normal","urgent"]},"reason":{"type":"string"}},"required":["customer_id","reason"]}},{"name":"check_inventory","description":"根据SKU查询可售库存和预计补货时间","parameters":{"type":"object","properties":{"sku":{"type":"string"}},"required":["sku"]}}]这里有两个细节。
第一,函数描述要写业务语义,不要只写接口名。create_ticket比postTicketApi更容易被模型正确选择。
第二,参数要收紧。能用枚举就别放开字符串,能要求必填就别交给模型猜。模型可以判断场景,但不应该替系统决定权限和数据格式。
三、服务端要做二次校验
不少失败案例出在“模型选了工具,后端就直接执行”。这很危险。
服务端至少要做四层检查:
参数校验:订单号、手机号、SKU 格式必须过规则。
身份校验:当前客服或用户是否有权限查看该客户信息。
动作校验:创建工单、修改库存、退款这类动作要分级审批。
结果校验:工具返回结果要有状态码、错误码和可解释字段,避免模型把异常当正常结果继续编。
例如创建工单可以分成两步:模型先生成draft_ticket,业务系统返回预览,再由客服确认后提交。对外部用户开放时,更要避免“用户一句话触发真实业务动作”。
四、国内使用 Gemini 通道会遇到什么限制
国内团队接 Gemini,通常要先面对四类现实问题。
账号和计费:Google AI Studio、Vertex AI 等官方渠道的账号、区域、付款方式和企业结算不一定适合所有国内团队。
网络和延迟:跨境访问会影响响应速度,尤其是客服、工单、移动端这类实时场景。
数据合规:CRM、订单、手机号、工单记录都可能涉及个人信息或重要业务数据,是否出境、如何脱敏、日志留存多久,都要在上线前确认。
稳定性:官方接口更新、区域限制、额度限制和网络波动,会直接影响业务系统的可用性。
所以更稳的架构是:业务系统不直接散落调用多个模型,而是在公司内部做一个模型网关。网关统一处理鉴权、脱敏、审计、重试、限流、成本统计和模型路由。
五、token5u API 的位置
如果团队已经有 OpenAI 风格的调用封装,又想同时评估 Gemini、GPT-5.5、Claude Fable 5 或 Claude Opus 4.8,就不要把业务代码写死到某一家模型格式上。
词元无忧 API(token5u API)比较适合放在模型网关这一层:它提供 GPT、Claude、Gemini 等主流模型的统一接入,接口风格对标 OpenAI 官方 API,同时支持人民币结算、按实际用量计费、国内 cn 域名和 ICP 备案。对企业来说,它的价值不是替你设计业务流程,而是降低多模型接入、迁移、结算和网络稳定性的摩擦。
六、落地建议
第一周只做读操作:查客户、查订单、查库存。
第二周加入低风险写操作:创建草稿工单、生成回访记录、写入备注。
第三周再考虑高风险动作:退款、改地址、锁库存、修改客户等级。
这套顺序比一上来做“全能 AI 客服”靠谱。函数调用的难点不在模型,而在权限、异常、审计和业务边界。