综合推荐方案

这一章是什么

本章把前面 9 章的调研发现综合成一份可落地的推荐方案，作为 ADR-004 任务识别策略的核心输入。每条推荐都标明理由与对应的调研章节。

整体架构

用户输入（多模态）
  → 多模态预处理（归一化为：主文本 + 结构化上下文 + 元数据）
  → 边界保护 hook（凭证 / 执行类输入拦截，规则路径）
  → L3 缓存 + 规则路径（高频确定性查询直接返回）
  ↓ 未命中或低置信度
  → LLM 路由层（按用户配置 / 系统默认选 Provider）
  → 注入 system prompt + 工具池 schema + 用户画像 + 对话状态
  → LLM Function Calling 决定调用哪些工具
  → 工具执行
  → 事后回填任务类型标签到审计 trail
  → 结果回流 → 下一轮

推荐方案的 12 个具体决策

决策 1：主架构采用业界标准

做什么：LLM Function Calling 主导意图识别 + 澄清作为工具 + 工具池注册。意图本体作为事后任务类型标签（合规元数据），不是前置分类管道。

理由：调研发现业界 4 个主流 Agent（Claude Code / Hermes / OpenClaw / Claude Code 源码）统一采用这个范式。FinBayes 之前提议的多阶段管道有过度设计。

对应章节：01-agent-frameworks.md

决策 2：L1 主力 LLM 用 Claude Sonnet 4.x

做什么：默认 Provider 是 Claude Sonnet 4.x（或 Opus 4.5 if 用户付得起）。

理由：BFCL 顶部 + 多轮 function calling 稳定 + prompt caching 控成本 + 已在用户工作流。

对应章节：02-llm-function-calling.md

决策 3：L1 备选按场景动态路由

做什么：按区域 / 任务 / 成本动态切换备选 LLM：

场景	推荐
低延迟实时	GPT-4o / GPT-5
国内合规 / 成本敏感	DeepSeek V3.2
中文金融特化	Qwen2.5-72B API

理由：避免单一厂商锁定 + 各 Provider 各有所长。

对应章节：02-llm-function-calling.md

决策 4：L2 本地兜底用 Qwen2.5-7B / 14B 量化版

做什么：通过 Ollama 部署 Qwen2.5-7B-Instruct 或 14B-Instruct 量化版作为 L2 离线兜底。不用金融专用 LLM。

理由：

• Qwen2.5 中文好 + Function Calling 训练充分
• Mac M2 Ultra 上 20-40 tok/s
• 金融专用 LLM（FinGPT / FinLLaMA / XuanYuan）缺 Function Calling 训练

对应章节：04-financial-specialized-llms.md、05-multi-tier-degradation.md

决策 5：L3 缓存 + 规则路径的具体技术栈

做什么：

组件	选型	用途
L3a 精确缓存	Redis + SHA256(query + user_id)	行情 / 持仓 / 重复问
L3b 语义缓存	Redis Vector + bge-small-zh，threshold 0.88	同义改写
L3c 规则路由	正则词典 + 股票代码识别器	高频术语 / 命令式查询
L3d 意图分类器	logistic regression on bge embedding（≤8 顶层意图）	兜底分流
L3e 置信度门	predict_proba < 0.7 触发 L4	控错

预期命中：18-22%。

理由：业界真实数据显示对话类系统命中 5-15%，FAQ 类 40-60%。金融认知混合两者，加权预估 15-25%。Break-even 15-20%，所以这是合理设计目标。

对应章节：03-cache-and-rules.md

决策 6：L4 受限菜单 UI 借鉴 Alexa FROST 模式

做什么：所有 LLM 与缓存都不可用时显示受限菜单 + fallback recommendation（"试试这些常用查询：X / Y / Z"），不留空白。

理由：Amazon Alexa 已验证的模式（FROST 论文）。

对应章节：03-cache-and-rules.md、05-multi-tier-degradation.md

决策 7：用户自配置 Provider 作为 first-class 场景

做什么：

• Provider Registry 含内置 Provider 列表（OpenAI / Anthropic / DeepSeek / Qwen / Ollama / vLLM / LM Studio / Hugging Face TGI / 等）+ 用户自定义 Provider（OpenAI-compatible endpoints）
• 用户级配置：用户本机的 FinBayes 配置目录下的 providers 配置文件（具体路径按 OS 约定，key 走 OS keychain）
• 两层路由：系统默认（按区域 / 任务 / 成本）+ 用户覆盖
• 能力匹配：路由前检查 Provider 支持 Function Calling / 上下文长度 / 等能力
• 配置 UI / CLI：finbayes config provider add ...

理由：本地优先 + 用户主权是 FinBayes 的产品定位，用户应能自主选择 Provider。

对应章节：06-provider-configuration.md

决策 8：多模态预处理管道

做什么：

输入类型	处理
自然语言文本	直接传
财报 / 研报 / 公告 PDF	unstructured.io / LlamaParse
URL（新闻 / KOL 帖子 / 报告）	trafilatura / Firecrawl
语音	Whisper / 腾讯云 ASR
表单	结构化数据直传
多语种	langdetect 检测，语种作为元数据

归一化输出为「主文本 + 结构化上下文片段 + 元数据」。

理由：业界部分项目（OpenClaw 等）已有这类管道。FinBayes 的金融场景需要专门解析（财报数字、链上数据等）。

对应章节：07-multimodal-preprocessing.md

决策 9：边界保护用 before-LLM hook

做什么：凭证类 / 执行类输入由确定性规则在 LLM 调用前拦截，不让 LLM 处理。借鉴 OpenClaw 的 before_agent_reply plugin hook 模式。

理由：合规硬约束（战略不变量），不能让 LLM 自由发挥。规则路径保证可重复。

对应章节：01-agent-frameworks.md、05-multi-tier-degradation.md

决策 10：多轮 / 复合任务在意图层显式拆解

做什么：用户输入命中复合任务（如"NVDA 财报后我的判断要不要更新 + 现在该不该加仓"）时，FinBayes 在意图层显式拆为单工具任务，串行 / 并行调度。不依赖 LLM 原生处理。

理由：FinMCP-Bench 显示头部 LLM 在金融多轮工具调用上 exact match 仅 3.08%。这是已知工程挑战。

对应章节：02-llm-function-calling.md

决策 11：高风险任务用 self-consistency 评估置信度

做什么：交易决策辅助 / 交易准备 等高风险任务，LLM 调用做 N≥3 次采样投票（self-consistency），不依赖 verbalized confidence。成本由 L3 缓存部分抵消。

理由：业界 calibration 研究确认 verbalized confidence 与实际正确率脱钩。

对应章节：02-llm-function-calling.md

决策 12：金融专用 LLM 用作 RAG 知识源而非主路由

做什么：金融专用 LLM（XuanYuan / FinGPT / 等）的合理位置：

• RAG 知识源：用 XuanYuan / FinGPT 生成金融术语向量库 / 金融 QA 训练数据
• 特定子任务辅助：情感分析专门走 FinGPT，结果回流给 L1
• 离线训练数据生成：合成金融场景对话数据用于评估

不进主路由。

理由：金融专用 LLM 缺 Function Calling 训练。

对应章节：04-financial-specialized-llms.md

推荐方案的"不做"清单

ADR-004 应明确这些边界：

不做	理由
不引入金融专用 LLM 作为 L1 / L2 主路由模型	function calling 训练缺位
不指望 L3 命中率超过 30%	业界真实数据上限
不依赖 LLM verbalized confidence	与实际正确率脱钩
不依赖单一 LLM 厂商	路由 + 多 provider failover
不指望 LLM 原生处理多轮复合任务	FinMCP-Bench 显示崩塌
不预设"意图分类管道"作为前置阶段	业界默认信任 LLM Function Calling

与现有 ADR 的关系

ADR	关系
ADR-001 工程范式（Harness Workflow + 里程碑 + 走通骨架）	本调研的推荐方案需要按里程碑切片落地。M0 走通骨架先实现 L1 + 1 个任务工具，后续里程碑加 L2 / L3 / L4
ADR-002 架构文档结构	本调研的推荐方案需要在架构文档的多个章节承接（系统全景 / 横切关注点 / 部署形态 等）
ADR-003 工程实施栈与协作模式	工具栈兼容（OpenSpec + Archon）
ADR-004 任务识别策略（待起草）	本调研是 ADR-004 的核心输入

实施分阶段建议

里程碑	内容
M0 走通骨架	L1（单一 LLM，如 Claude Sonnet）+ 1 个任务工具（如分析类）+ clarify 工具 + 边界保护 hook
M1 First-screen Cognition Quality	L1 多任务工具（覆盖 7 类任务）+ 多模态预处理（基础：文本 + 简单 URL）+ 用户上下文注入
M2 Multi-task Runtime	TaskGroup（多任务并发执行）+ 事后任务类型标签 + 用户配置 Provider 基础
M3 Evidence Depth and Active Cognition	L3 缓存 + 规则路径 + 多模态预处理扩展（财报 / 复杂 URL）+ 主动信号触发
M4 Local-first Deployment	L2 本地嵌入式 LLM（Ollama + Qwen2.5）+ 完整用户 Provider 配置 UI
M5 Reliability Hardening	self-consistency 评估 + L4 受限菜单 UI + 完整 fallback 链 + 审计 trail