在数字银行中，一个会编造账户余额的客服机器人不仅是没用的，更是危险的。金融对话需要精确的数字、经过验证的收款人和每一项声明的可审计追踪。大语言模型擅长对话，但它们会产生幻觉。当用户询问“我的账户还剩多少钱？”时，模型必须查询数据库，而不是靠想象。这正是函数调用所强制执行的，也是本次构建的核心。
Google 的 Gemma 4 为开发者提供了一个强大的 310 亿参数模型，它可以遵循复杂的指令并进行自然的对话，包括使用地区方言。结合 Google AI Studio，它变成了一个快速原型设计环境，你可以在接触服务器之前定义工具、测试边缘情况并导出可运行的 JavaScript。这里的目标是开发一个金融科技支持代理，它可以查询账户余额、跟踪交易状态并支付账单。至关重要的是，当用户使用尼日利亚皮钦语时，它也会以尼日利亚皮钦语进行回复，在匹配语气的同时绝不即兴发挥金融事实。
为什么函数调用对金融机器人至关重要
如果没有函数调用，语言模型会将每个问题都视为一次创意写作练习。如果你询问余额，它可能会根据训练数据中的模式编造一个听起来很合理的数字。在涉及真实资金时，这种失效模式是不可接受的。
函数调用反转了这一流程。模型的工作不是“知道”余额，而是识别意图、选择正确的工具并提取参数。当用户输入“查询我的余额”时，Gemma 4 会发出一个结构化的 JSON 请求——类似于带有 account_id 的 get_balance 调用。你的后端会对核心银行系统执行该调用，获取真实数字，并将其反馈到对话中。只有到那时，模型才会生成面向用户的句子。每一个回答都源自对后端的工具调用。由于模型受到外部逻辑的限制，幻觉会在 API 边界处停止。
这种模式还创建了清晰的审计追踪。每个工具请求及其相应结果都会记录在消息历史中。监管机构和风险团队可以精确检查余额是在何时被查询的，以及用户收到了哪个数字。
在 Google AI Studio 中设计代理
工作流从 Google AI Studio 内部开始。选择 gemma-4-31b-it，这是针对对话和指令遵循进行了优化的指令微调版本。
接下来，编写设定硬性边界的系统指令。对于数字银行，语气应该是专业、直接且冷静的。但指令必须更进一步。明确告诉模型：它绝不能估算账户数据，绝不能假设交易状态，且在未确认工具结果之前绝不完成账单支付。如果用户使用尼日利亚皮钦语，模型也应以尼日利亚皮钦语回复。如果用户切换到英语，模型则随之切换。系统提示词（System Prompt）是你用通俗语言编码信任与安全策略的地方。
然后定义工具 Schema。将它们视为模型与后端之间的契约。你至少需要三个：
get_balance
参数：account_id（字符串，必填）
返回：当前余额和币种。get_transaction_status
参数：transaction_reference（字符串，必填）
返回：状态（如待处理、已完成或失败）以及时间戳。pay_bill
参数：biller_code（字符串，必填）、amount（数字，必填）、account_pin（字符串，根据你的流程可选）
返回：确认参考号或错误消息。
每个 Schema 都使用标准的 JSON 格式来描述函数名称、描述和参数属性。描述字段至关重要。编写描述时要确保模型理解何时调用每个工具。模糊的描述会导致错误的工具选择，因此请务必具体：“当用户想要查询当前账户余额时，请使用 get_balance。不要将其用于查询交易历史。”
在浏览器中进行原型设计
在编写任何 Express 路由之前，先在 AI Studio 的聊天面板中测试整个对话流。这可以节省数天的后端重做时间。输入一段尼日利亚皮钦语查询：“Wetin remain inside my account?”。观察 Gemma 4 是正确发出了 get_balance 调用，还是试图根据训练数据进行回答。如果它弄错了参数——例如使用了 account_number 而不是 account_id——你可以在那里直接修复 Schema 描述。
也要测试故障模式。在不提供参考编号的情况下请求交易状态。一个指令明确的模型应该要么向用户询问缺失的参数，要么使用现有信息调用工具并让后端返回验证错误。你希望在沙盒中看到这些行为，而不是在生产环境中。
一旦提示词和 Schema 表现正确，就可以导出 JavaScript 代码。AI Studio 会生成一段简洁的代码片段，利用你的系统提示词、用户消息和工具定义来构建 API 请求。这将成为你后端逻辑的基础。
连接 Express 后端
将导出的代码放入 Express 应用中。架构非常简单，但执行循环是关键部分。
设置一个 POST 端点（例如 /chat），用于接收用户消息和任何会话历史。将这些内容转发到 Gemma 4 端点；根据你的托管选择，你可以通过兼容 OpenAI 的 API 或 Google 自有的推理端点进行访问。
模型的响应分为两类：要么是最终的文本消息，要么是包含请求数据的 tool_call。当你收到工具调用时，在你的后端执行相应的函数。查询数据库以获取余额。调用支付处理器以获取账单状态。将工具结果作为角色为 tool 的新消息追加到对话历史中，然后将整个更新后的数组发回给 Gemma 4。
重复此循环，直到模型返回最终的文本答案。该答案将基于你提供的真实数据。Express 使这种协调变得容易，因为循环中的每一次迭代都只是另一个 HTTP 请求，并且你可以干净地使用 async/await 来处理工具执行。
在开发早期，使用模拟数据来支持这些工具调用。一个简单的 JavaScript 对象（将示例账户 ID 映射到余额）就足以证明循环可以正常工作。重点是在与不稳定的第三方银行 API 集成之前验证交互模式。
从原型到生产
一个可运行的原型并不是生产级别的银行基础设施，但从原型到生产的路径是清晰的。
用真实的银行核心 API 替换模拟数据。通过 REST 或 gRPC 将你的 get_balance 工具连接到账本系统。将 pay_bill 接入实际的支付交换机。这样做时，你不需要更改模型或对话逻辑；你只需要更换工具处理器的实现即可。
添加 Redis 进行会话管理。银行领域的对话状态是敏感且受监管的。你需要安全地存储消息历史，在设定的超时后将其过期，并确保用户的会话不会在请求之间泄露。Redis 可以通过 TTL 策略和快速键查找来处理这一点。
当流量增长时，将推理迁移到 vLLM。AI Studio 非常适合原型设计，但在 GPU 集群上使用 vLLM 进行自托管推理可以让你在大规模情况下控制延迟、批处理和成本。Gemma 4 在 vLLM 下运行高效，且工具调用行为保持不变。
核心启示
构建一个值得信赖的金融科技智能体，重点不在于模型的大小，而在于架构约束。Gemma 4 提供了足够的推理能力来解析混合代码的尼日利亚皮钦语 (Nigerian Pidgin) 并路由复杂的意图，但安全性源于工具循环。每个余额都是实时获取的。每笔账单支付都由外部系统确认。没有任何内容是凭空捏造的。
从浏览器中的 AI Studio 开始，在 Express 循环中强化逻辑，一旦对话流程变得万无一失，就换成真实的银行基础设施。这就是你交付一个能让人们真正放心托付资金的机器人的方法。
来源：Building a Full Gemma 4 Google AI Studio Project: A Fintech Support Agent
可选学习社区：GyaanSetu AI on Telegram