金融智能体落地实录：Spring AI + Skill 架构如何扛住千万级实时调用
不是把大模型接进系统就叫“金融智能体”。真正能上线的金融智能体，必须同时解决四件事：边界清晰、调用可靠、风险可控、过程可审计。
本文从真实生产落地视角，系统拆解一套基于 Spring AI + Skill 架构的企业级方案：既讲原理，也讲架构；既讲并发治理，也给出生产级代码；既能解释“为什么这样设计”，也能回答“出了问题怎么兜底”。
一、先把问题说透：金融智能体难的从来不是“接模型”
很多团队做金融智能体，第一版通常都很顺：
- 接一个大模型
- 暴露几个
@Tool - 写一个 Prompt
- 前端接上 SSE 流式输出
Demo 很快就能跑起来，但只要一进生产，问题会立刻变得尖锐：
- 用户问“帮我分析贵州茅台最新财报”，智能体却调了汇率查询工具
- 开盘高峰时，Python 量化服务被打满，整个对话链路级联超时
- 风控部门要求追溯“模型为什么做出这个回答”，结果系统只能翻散落日志
- 同一个用户请求跨了 6 个服务，出了问题却没有统一 traceId
- 某个 Skill 短暂异常，LLM 连续重试，最终把下游行情接口打崩
这类问题的本质不是模型不够聪明，而是系统没有把大模型当成“高不确定性组件”来治理。
在金融场景，大模型必须被放进一个受控框架里：
- 它可以推理，但不能直接越权执行
- 它可以选择工具，但不能绕过领域约束
- 它可以组织答案，但不能污染事实来源
- 它可以提升效率，但不能破坏审计闭环
换句话说，金融智能体的核心不是模型能力，而是模型能力的工程化约束能力。
二、什么叫“扛住千万级实时调用”？
标题里“千万级实时调用”如果不解释清楚，很容易被误解成单机每秒千万次，这既不现实，也没有工程意义。
本文讨论的“千万级”是指：
- 日调用规模达到千万级
- 峰值流量集中在开盘、午间、收盘等交易窗口
- 对话请求、Skill 调用、行情查询、风险计算共同构成混合负载
- 系统依赖多种异构能力：LLM、向量检索、Redis、Kafka、Python 计算、内部交易或行情服务
一个更接近真实生产的量级拆分可能是：
- 日活用户：20 万
- 人均日交互：15 次
- 日对话请求：300 万
- 单次请求平均触发 Skill：3 到 5 次
- 日 Skill 调用：1000 万到 1500 万
所以这里的目标不是“某个接口有多快”，而是：
- 在峰值时段保持核心链路稳定
- 对慢依赖和异常依赖具备隔离与降级能力
- 对状态、审计、调用成本和风险有全局治理
- 可以水平扩展，而不是靠单体堆线程硬扛
三、为什么金融场景比普通 AI 应用更难
3.1 业务复杂度高
金融用户提出的问题天然是复合型的：
“白酒板块还值得拿吗？结合我当前持仓，给我一个风险和收益的平衡建议。”
这不是单轮问答，而是组合任务：
- 行情分析
- 财报解读
- 持仓读取
- 风险暴露计算
- 投资建议生成
其中一半是领域计算，一半是自然语言推理。
3.2 正确性要求高
电商场景里，推荐错一个商品通常只是体验问题；金融场景里，调错一个 Skill、引用错一份数据、漏掉一个风险提示，都可能变成合规问题。
3.3 时效性要求高
市场数据、公告、舆情、组合风险都是强时效数据。静态 Prompt 无法解决实时性，必须有外部工具和事件驱动链路。
3.4 审计要求高
金融系统不是“回答对了就行”，而是必须能回答：
- 它用了哪些数据
- 触发了哪些工具
- 每一步参数是什么
- 哪一步触发了人工审核
- 最终回答由哪些中间结果拼装而来
因此，金融智能体必须天生具备：
- 领域边界
- 风险护栏
- 状态管理
- 事件留痕
- 可观测与可回放
四、核心设计原则：先定约束，再谈智能
在项目真正落地时，我们把架构原则收敛为五条。
4.1 Skill 是第一公民，不是零散 Tool
@Tool 适合快速验证，但不适合大型金融系统。原因很简单：Tool 只是“函数暴露”，而 Skill 才是“领域能力封装”。
Skill 至少应该包含：
- 清晰的业务语义
- 输入输出契约
- 权限和风控约束
- 幂等与超时策略
- 结果元数据与审计标签
4.2 Agent 只做编排，不直接承载业务细节
Agent 的职责应该是：
- 理解用户意图
- 规划调用步骤
- 选择合适 Skill
- 汇总中间结果
- 决定是否升级到人工审核
而不是直接深入数据库、RPC、量化引擎、规则库。
4.3 高风险动作必须显式建模
凡是涉及：
- 资产查询
- 风险评估
- 交易建议
- 账户敏感操作
- 合规判断
都不能只是“让模型自由发挥”，必须有显式的领域规则和审批节点。
4.4 状态外置，执行无状态
如果会话状态只保存在应用内存里，Pod 一旦重启，整个对话上下文就断了。生产环境必须把会话状态外置到 Redis 或持久化存储，执行节点尽可能无状态。
4.5 可用性靠治理，不靠运气
真正支撑高并发的不是“模型很强”，而是这套治理组合拳：
- 超时
- 重试
- 熔断
- 舱壁隔离
- 限流
- 缓存
- 异步解耦
- 降级兜底
五、整体架构：从对话入口到审计闭环
下面是一套更适合生产环境的金融智能体架构：
┌────────────────────────────────────────────────────────────┐ │ Client / App │ │ Web / App / 投顾工作台 / 内部客服系统 │ └──────────────────────────┬─────────────────────────────────┘ │ ┌──────────────────────────▼─────────────────────────────────┐ │ API Gateway / BFF │ │ 鉴权 / 租户隔离 / 限流 / SSE 转发 / 灰度路由 / Trace 注入 │ └──────────────────────────┬─────────────────────────────────┘ │ ┌──────────────────────────▼─────────────────────────────────┐ │ Agent Orchestrator (Spring AI) │ │ Intent Parser / Planner / Skill Router / Risk Guard │ │ Conversation Memory / Result Synthesizer / Review Flow │ └───────────────┬────────────────┬───────────────────────────┘ │ │ ┌──────────▼───────┐ ┌────▼────────────────────────┐ │ Skill Mesh │ │ Context & Knowledge Layer │ │ 投研 / 风控 / 客服 │ │ Redis / RAG / Milvus / ES │ └───────┬──────────┘ └─────────────────────────────┘ │ ┌────────────▼───────────────────────────────────────────────┐ │ Domain Services / Infra │ │ 行情服务 / 财报服务 / 持仓服务 / Python 量化引擎 / Kafka │ │ 规则引擎 / 审计中心 / 监控告警 / OpenTelemetry │ └────────────────────────────────────────────────────────────┘这套架构有三个关键点：
5.1 接入层负责“治理前移”
网关不只是转发请求，它还负责：
- 用户身份解析
- 交易日、租户、渠道等上下文透传
- 对高成本智能体路由做流量控制
- 注入
traceId、sessionId、requestId - 流式连接的超时和断链处理
5.2 Orchestrator 负责“智能受控编排”
它是整条链路的大脑，但不是万能大脑。它要把模型能力和规则能力结合起来：
- LLM 负责意图理解和自然语言生成
- Planner 负责生成可执行步骤
- Router 负责匹配 Skill
- Guard 负责规则约束和越权拦截
5.3 Skill Mesh 负责“能力可插拔”
Skill Mesh 可以理解为一层能力总线。任何新的业务能力，不是往 Agent 里继续塞 if-else，而是注册成新的 Skill 节点。
这样做的收益非常大：
- 新能力上线不必修改 Agent 核心
- 不同 Agent 可以复用同一批领域 Skill
- Skill 可以独立扩缩容
- 每个 Skill 都可以单独做 SLA、限流和审计
六、领域建模：为什么 Skill 必须建立在 DDD 边界上
很多智能体项目后期失控，根因不是模型，而是边界。一个没有边界的 Skill 体系会迅速演变成“什么都能查、什么都能调”的大泥球。
6.1 先识别限界上下文
以券商投研助手为例，至少可以拆成这些上下文：
| 限界上下文 | 职责 | 典型 Skill |
|---|---|---|
| 投研分析 | 财报解读、行业比较、估值分析 | ReportAnalysisSkill ValuationSkill |
| 风险控制 | 组合风险、敞口计算、敏感度分析 | PortfolioRiskSkill ExposureSkill |
| 客户服务 | 业务问答、开户进度、常见咨询 | FaqSkill AccountStatusSkill |
| 合规治理 | 敏感词校验、输出约束、审计标注 | ComplianceCheckSkill |
| 公共能力 | 数据查询、缓存、异步任务、文件解析 | MarketDataSkill DocumentParseSkill |
6.2 Skill 的本质不是“函数”，而是“受约束的领域能力”
一个生产级 Skill，至少应具备这些属性：
public interface SkillHandler<I, O> { SkillDefinition definition(); Class<I> inputType(); SkillExecutionResult<O> execute(SkillExecutionContext context, I input); }配套的 SkillDefinition 需要描述清楚：
public record SkillDefi
配置详解与调试技巧)
