1. 课程导入
在金融行业，大模型最初的价值多体现在问答、摘要、报告草稿等文本任务上。但真实业务要求远不止“说得好”：客户要转账、投顾要调取持仓、风控要冻结账户、运营要生成对账单。这些动作必须落到具体系统、具体接口、具体权限上。金融智能体（Financial Agent）正是为解决这一落差而生：它以大型语言模型为推理内核，通过函数调用（Function Calling）把自然语言意图翻译成结构化参数，再借助工具编排（Tool Orchestration）完成多步骤、可审计、可回滚的业务执行。
一、核心原理：意图—参数—执行—观测的闭环
金融智能体不是单一模型，而是一个运行时系统。其最小闭环包含四个环节：模型理解用户意图并选择工具；模型按工具声明的 JSON Schema 生成参数；编排层校验参数、鉴权、调用真实接口；执行结果回填给模型，形成可解释的最终答复。函数调用解决“模型如何表达要做什么”，工具编排解决“系统如何安全地按顺序做完”。
下面是一个典型的工具声明与模型返回片段，展示了“意图”如何变成“可执行参数”：
{
"name": "get_account_balance",
"description": "查询指定客户账户的可用余额",
"parameters": {
"type": "object",
"properties": {
"customer_id": { "type": "string", "description": "客户唯一编号" },
"currency": { "type": "string", "enum": ["CNY", "USD", "HKD"] }
},
"required": ["customer_id", "currency"]
}
}
// 模型返回的 tool_call
{ "name": "get_account_balance",
"arguments": { "customer_id": "C10086", "currency": "CNY" } }
二、方法流程：一次合规的智能体调用要经过什么
把上述闭环落到工程，通常需要一条明确的流水线。它既是开发路径，也是排障路径：
- 意图识别与路由：判断用户请求属于查询、交易、咨询还是投诉，决定是否进入工具调用分支。
- 工具选择：在工具注册表中匹配最合适的函数，避免“万能工具”导致参数歧义。
- 参数抽取与校验：补齐缺失字段、校验枚举与格式，必要时向用户追问。
- 权限与合规检查：核对客户授权、交易限额、反洗钱规则，拦截越权调用。
- 执行与重试：调用后端接口，处理超时、幂等与补偿。
- 结果回填与生成：将结构化结果转成用户可读答复，并记录审计日志。
为便于对照，下表给出金融场景中常见工具类型及其编排要点：
| 工具类型 | 典型函数 | 编排要点 |
|---|---|---|
| 查询类 | 余额、持仓、流水 | 只读、可缓存、注意数据时效 |
| 交易类 | 转账、申购、赎回 | 强鉴权、幂等键、限额校验 |
| 风控类 | 冻结、预警、名单核验 | 高优先级、需人工复核兜底 |
| 文档类 | 对账单、合同摘要 | 模板约束、敏感信息脱敏 |
三、案例场景：一次“查余额并转账”的编排
用户说：“帮我看看工资卡还有多少钱，够的话转 5000 给房东。”这句话包含查询与交易两个动作，且第二个动作依赖第一个的结果。编排层需要先调用余额查询，判断余额是否充足，再决定是否发起转账；若不足，则直接生成解释性答复而不触发交易。这正是工具编排相对单次函数调用的价值：它管理的是依赖、条件与顺序，而不仅是单次映射。
四、误区与复盘：新手最容易踩的四个坑
- 把函数调用当执行：模型只输出调用意图，若直接信任其参数而不校验，可能造成越权或错误交易。
- 工具粒度过粗：一个“do_banking”函数包打天下，参数含义模糊，模型极易填错，排障也无从下手。
- 忽略幂等与重试：网络超时后重试，可能造成重复转账；必须引入幂等键与状态查询。
- 缺少可观测性：没有记录工具名、参数、耗时与结果，线上问题无法定位，合规审计也无法通过。
五、整体学习路径与实战目标
本课程后续将沿着“概念—工具—编排—实战—治理”的路径推进：先建立函数调用与工具编排的完整心智模型，再动手定义工具 Schema、实现编排循环、处理多工具依赖与错误恢复，最后进入真实金融场景的综合实战与合规治理。完成本课程后，你应能独立设计一套可运行、可审计、可扩展的金融智能体工具层，并具备定位与修复常见编排故障的能力。