设计思路
2026/5/9...大约 15 分钟
设计思路 —— 架构决策与权衡
一句话：技术原理讲"怎么做"，这一章讲"为什么这样做"——这些项目背后的设计哲学和取舍。
1. 为什么是多 Agent？
1.1 单一 Agent 的认知负荷问题
一个 Agent 要从零开始分析一只股票，需要同时处理：
市场数据（价格、成交量、技术指标）
+ 基本面（财报、估值、财务比率）
+ 新闻（政策、行业、公司动态）
+ 社交情绪（Reddit、Twitter、StockTwits）
+ 宏观（利率、CPI、GDP）
+ 风险评估
↓
一份决策问题：LLM 的上下文窗口是有限的，一次性塞入所有信息会导致：
- "中间迷失"（lost in the middle）——长文本中间的信息被 LLM 忽略
- 推理混乱——不同维度的信息混在一起，LLM 难以形成清晰的因果链
- 成本爆炸——一次塞入 50K token 的上下文，API 费用很高
1.2 分工的价值
多 Agent 系统的核心洞见：人类交易公司之所以用团队，不是一个人不够聪明，而是一个人无法同时精通所有维度。
一个人的大脑 一个交易团队
┌──────────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│ 一个 │ vs │ 市场 │ │ 基本面│ │ 新闻 │ │ 社交 │
│ LLM │ │ 分析师 │ │ 分析师 │ │ 分析师 │ │ 分析师 │
│ 处理一切 │ └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘
└──────────┘ └───────┴───────┴───────┘
│
┌─────┴─────┐
│ 研究员辩论 │ ← 多角度审视
└─────┬─────┘
┌─────┴─────┐
│ 决策层 │ ← 综合判断
└───────────┘核心原则：每个 Agent 只关注自己擅长的维度，上下文窗口被"专有化利用"——市场分析师只看技术指标，基本面的只读财报，不会互相干扰。
2. Agent 角色的分解原则
如何把"分析一只股票 → 做交易决策"分解成合理的 Agent 角色？以下是生态系统中的共识模式。
2.1 信息收集层（平行）
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 市场分析师 │ │ 基本面分析师│ │ 新闻分析师 │ │ 情绪分析师 │
│ (技术指标) │ │ (财报/估值)│ │ (事件驱动)│ │ (社交媒体)│
└────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │ │
└────────────┴────────────┴────────────┘
│
平行执行，互不依赖设计原则：信息收集层的 Agent 应该平行执行——它们之间没有依赖关系，可以同时启动。
TradingAgents 早期是串行的（分析师一个接一个执行），AlpacaTradingAgent 改进为并行（5 个分析师同时跑），大幅缩短了等待时间。
2.2 分析辩论层（对抗）
研究员-A（多头） 研究员-B（空头）
"应该买入" "应该卖出"
│ │
└────────┬─────────┘
│
研究主管（裁决）设计原则：辩论不是为了"谁赢"，而是用对立视角暴露认知盲区。多头研究员会忽略的风险，空头研究员会指出来。
2.3 决策执行层（收敛）
交易员（制定方案）
│
┌─────────────┼─────────────┐
▼ ▼ ▼
激进风控 中性风控 保守风控
(接受高风险) (平衡视角) (极度保守)
│ │ │
└─────────────┼─────────────┘
│
投资经理（最终决策）设计原则：信息从"发散"（信息收集）到"收敛"（决策），越往后越窄。最后一层必须是一个人做决策——避免"委员会式"的无限讨论。
3. 通信模式：Agent 之间如何对话
3.1 三种模式对比
| 模式 | 机制 | 优点 | 缺点 | 代表 |
|---|---|---|---|---|
| 共享状态 | 所有 Agent 读写同一个 State 对象 | 简单、可追溯 | 状态膨胀、耦合 | TradingAgents (LangGraph State) |
| 消息传递 | Agent 之间通过消息队列通信 | 解耦、可扩展 | 消息格式需要标准化 | AI-Trader (信号发布) |
| 黑板模式 | 一个公共"黑板"，Agent 在上面写/读 | 灵活、适合协作 | 并发控制复杂 | 较少使用 |
3.2 为什么 LangGraph 选了共享状态
TradingAgents 的设计者选择了共享状态而非消息传递，原因是：
# 共享状态的好处：调试时可以看完整的状态快照
state = {
"analyst_report": {...}, # 分析师看到了什么
"debate_transcript": [...], # 研究员怎么辩论的
"trader_plan": {...}, # 交易员提了什么方案
"risk_assessment": {...}, # 风控怎么说
"final_decision": {...}, # 最终决定
}
# → 整个决策链的完整审计追踪，一步到位对于研究/模拟场景，可审计性比性能重要——你需要知道"为什么做了这个决定"。
但 AI-Trader（Agent 交易平台）选了消息传递（信号发布），因为它的场景是多个独立 Agent 在公开市场上竞争，不需要共享内部状态。
4. Human-in-the-Loop 的设计
4.1 什么时候需要人？
┌─────────────────────────────────────────────────────┐
│ AI Agent 自主决策 │
│ ┌─────────────────────────────────────────────────┐│
│ │ 数据分析 ✅ │ 信号生成 ✅ │ 策略制定 ✅ │ 风险评估 ✅ ││
│ └─────────────────────────────────────────────────┘│
│ │ │
│ ┌────┴────┐ │
│ │ 人类审批 │ ← 什么时候介入？ │
│ └─────────┘ │
└─────────────────────────────────────────────────────┘不同项目的选择：
| 项目 | 人类介入时机 | 哲学 |
|---|---|---|
| TradingAgents | 无（纯研究/模拟） | "反正是模拟，不需要人" |
| OpenAlice | 每笔交易需要 push → approve | "Trading-as-Git"，每笔都有 commit 记录 |
| Swarm Trader | 风控线写死在代码里（硬止损），日常不干预 | "安全层自动化，人类只设规则" |
| AI-Trader | Agent 自主交易，人类可以跟单/撤单 | "用市场机制筛选好 Agent" |
4.2 核心权衡
人介入太少 → Agent 的错误决策可能造成真实损失
人介入太多 → 失去 AI 自动化的意义，变成"人在看 AI 的推荐"最佳实践（来自这些项目的共识）：
- 日常分析决策 → AI 自主
- 资金划转 / 大额交易 → 人类审批
- 风控硬止损 → 代码强制执行（人类设定，AI 无法覆盖）
5. 成本-性能权衡
5.1 Agent 不是越多越好
Agent 数量与决策质量的关系（实际数据来自学术研究）：
质量
↑
│ ★★★★★
│ ★★
│ ★
│★
└──────────→ Agent 数量
1 3 5 7 9
↑ ↑
最优区间 边际递减TradingAgents 的论文和 QuantAgents 的实验都表明：4-7 个 Agent 是最优区间。超过这个数量，新增 Agent 带来的信息增益被 LLM 调用成本和上下文噪音抵消。
5.2 各项目的 Agent 数量和成本
| 项目 | Agent 数 | 单次分析 LLM 调用 | 估算成本 (GPT-4o) |
|---|---|---|---|
| Dexter | 1（自主规划） | 5-15 次 | ~$0.5-1.5 |
| FinRobot | 8 | 12-20 次 | ~$1.0-2.0 |
| TradingAgents | 7 | 15-25 次 | ~$1.5-2.5 |
| AI Hedge Fund | 18 | 30-50 次 | ~$3.0-5.0 |
| Swarm Trader | 20 | 40-60 次 | ~$4.0-6.0 |
成本优化策略（各项目的共识）：
- "快速思考"用便宜模型（GPT-4o-mini / Claude Haiku），"深度分析"用贵模型（GPT-5 / Claude Opus）
- 辩论轮数可配置（TradingAgents 默认 1 轮，你可以设为 2-3 轮获得更深入的辩论）
- 支持本地 LLM（Ollama）—— Swarm Trader 和 FinceptTerminal 都支持，零 API 成本
6. 模拟 vs 实盘：两种架构哲学
6.1 模拟交易（Simulation）
数据源 → Agent 分析 → 模拟交易所 → 记录结果
↑ │
└────────── 反馈循环（可选）──────────┘代表：TradingAgents（纯模拟）
设计目标：验证 Agent 架构是否有效，不是赚真钱。
架构特点：没有券商对接、没有实盘风控、没有订单路由——一切在内存中完成。
6.2 实盘交易（Live）
实时行情 → Agent 分析 → 信号 → 风控 Pipeline → 券商 API → 订单确认
↓
审计日志（不可篡改）代表：OpenAlice、Swarm Trader
新增的架构挑战：
| 问题 | 模拟环境 | 实盘环境 |
|---|---|---|
| 数据延迟 | 无所谓 | 必须处理（过期行情=错误决策） |
| 订单失败 | 不会发生 | 必须重试/回退 |
| 部分成交 | 不存在 | 必须处理 |
| 网络断连 | 不影响 | 必须有断线重连+状态恢复 |
| 资金不足 | 不存在 | 必须在发单前验证 |
| 监管合规 | 不需要 | 可能需要（取决于地区） |
这就是为什么 OpenAlice 设计了"Trading-as-Git"模式——每笔交易像代码提交一样有版本历史，出了问题可以审计每一步。
7. 技术栈选择哲学
7.1 Python 阵营
TradingAgents, AI Hedge Fund, FinRobot, Dexter(使用Python数据工具)选择理由：
- 金融数据科学生态（pandas, numpy, ta-lib, Qlib）
- LangGraph/LangChain 生态成熟
- 快速原型开发
代价：类型安全弱，实盘交易中的 bug 可能到运行时才发现。
7.2 TypeScript 阵营
OpenAlice, Dexter(主体), FinClaw, Ghostfolio选择理由：
- 类型安全——实盘交易容错率极低
- 全栈统一——前后端同一种语言
- Bun/Node 生态对 WebSocket 实时数据支持好
代价：金融数据科学生态不如 Python 成熟（但 OpenAlice 解决了这个问题——自研了 TypeScript 版的 OpenBB 数据引擎）。
7.3 原生性能阵营
FinceptTerminal (C++20/Qt6)选择理由：
- 桌面端需要低延迟 UI
- 嵌入式 Python 兼顾数据科学生态
- 单二进制分发（用户无需安装 Python/Node）
代价：开发门槛高，社区贡献者少。
8. 测试哲学
测试 Agent 系统和测试传统软件有本质区别。传统软件的测试是"给定输入 X，期望输出 Y"，但 Agent 的决策依赖于 LLM 的推理，同样的输入可能产生不同的输出。
8.1 为什么 Agent 测试不一样
传统软件测试 Agent 系统测试
┌─────────────┐ ┌─────────────────────┐
│ 输入 → 输出 │ │ 输入 → 推理 → 决策 │
│ 确定性 │ │ 概率性 │
│ 100% 通过 │ │ "合理即正确" │
└─────────────┘ └─────────────────────┘核心挑战：
- 非确定性：同一个市场信号，Agent 今天说"买入"，明天可能因推理路径不同说"观望"
- 环境依赖：Agent 的决策质量高度依赖外部数据质量（行情接口是否延迟、新闻源是否可用）
- 长期反馈：一个交易决策是否正确，可能要数周才能验证——单元测试的"即时反馈"模式失效
8.2 Mock 策略模式
真实环境 测试环境
┌──────────┐ ┌──────────────┐
│ 行情 API │ Mock 成 │ 固定价格序列 │
│ 新闻 API │ ─────────→ │ 预定义事件 │
│ 财报数据 │ │ 历史回测数据 │
└──────────┘ └──────────────┘各项目的 Mock 策略对比：
| 层级 | Mock 对象 | 策略 | 目的 |
|---|---|---|---|
| 数据层 | 行情/新闻/财报 API | 录制真实响应，测试时回放 | 保证输入一致，可复现 |
| LLM 层 | GPT/Claude 调用 | 用确定性规则引擎替代 | 测试流程逻辑，不受模型随机性干扰 |
| Agent 层 | 单个 Agent 的行为 | 用固定输出模拟（stub） | 测试多 Agent 协作流程 |
| 券商层 | 交易所 API | 内存中模拟订单簿 | 测试风控和订单逻辑 |
关键洞察：TradingAgents 在单元测试中对 LLM 全量 Mock——不是测试"模型是否聪明"，而是测试"Agent 协作流程是否正确"。模型质量交给 Eval 数据集评估。
8.3 Eval-Driven Development（评估驱动开发）
定义评估集 → 运行 Agent → 计算分数 → 调优 Prompt/架构
↑ │
└──────────── 分数不达阈值 ──────────┘闭环逻辑：没有 Eval 分数的优化是盲目的。Dexter 和 FinRobot 都维护内部 Eval 集，每次代码变更后自动跑一遍，确保"优化"没有导致退化。
评估集设计：100 个历史场景，人工标注"期望决策"。指标不只是"对不对"，而是盈亏比、最大回撤、夏普比率——和真实交易一样的标准。
8.4 生产环境持续评估
Agent 决策 → 实际执行 → 结果反馈 → 决策质量看板 (7 天滑动)
│
├─ 胜率 < 50% → 自动降级模型
└─ 回撤 > 阈值 → 触发人工审查最佳实践：
- 模拟阶段用历史回测评估（已知结果，可批量验证）
- 实盘阶段用滑动窗口评估（最近 N 笔交易的胜率、盈亏比）
- 不要只看单次决策对错，要看决策分布是否偏移（突然从保守变激进可能是 Prompt 漂移）
9. 可观测性设计
金融 Agent 的可观测性不只是"服务有没有宕机"，而是要回答："这个 Agent 今天为什么做了这个决策？它有没有变蠢？"
9.1 该观测什么：不只是延迟
传统系统监控 金融 Agent 监控
┌─────────────┐ ┌─────────────────────┐
│ CPU / 内存 │ │ 决策质量指标 │
│ 请求延迟 │ + │ 推理路径完整性 │
│ 错误率 │ │ 信息源覆盖度 │
└─────────────┘ │ 风控触发频率 │
└─────────────────────┘Agent 特有的核心指标：
| 指标类型 | 具体指标 | 为什么重要 |
|---|---|---|
| 决策质量 | 胜率、盈亏比、夏普比率 | 直接反映 Agent 是否"变蠢" |
| 推理完整性 | 每个决策是否有完整的推理链 | 发现"幻觉"决策（无依据的买卖） |
| 信息覆盖 | 信息收集层 Agent 的完成率 | 新闻 API 挂了，Agent 可能在信息不全时做决策 |
| 模型漂移 | 输出分布的熵值变化 | LLM 升级后，Agent 的行为模式是否突变 |
| 成本效率 | 每次决策的 Token 消耗 | 成本失控是真实的生产事故 |
9.2 仪表盘设计哲学
┌─────────────────────────────────────────────────────────────┐
│ Agent 决策仪表盘 │
├─────────────────┬─────────────────┬─────────────────────────┤
│ 今日决策流 │ 决策质量趋势 │ 系统健康状态 │
│ 09:30 买入AAPL │ 胜率: 62% ↑ │ 行情 API: ✅ │
│ 09:45 卖出TSLA │ 盈亏比: 1.8 │ 新闻 API: ✅ │
│ 10:02 观望META │ 最大回撤: -3% │ LLM 延迟: 1.2s │
│ │ (7天滑动窗口) │ 成本/决策: $0.03 │
└─────────────────┴─────────────────┴─────────────────────────┘设计原则：
- 决策级可视化：每个决策是可点击的卡片，展示完整推理链（分析师观点、辩论记录、风控意见）
- 对比视图：Agent 决策 vs 基准策略（如买入持有）——跑赢基准才有意义
- 异常高亮：某个 Agent 连续 N 次与多数人相反时标红（可能是新信息，也可能是它坏了）
9.3 告警哲学：少即是多
告警金字塔
/\
/ \ 紧急：资金回撤超过硬止损线
/ ⚠️ \ → 立即停机，人工介入
/──────\
/ \ 重要：API 故障 / 模型响应异常
/ ⚡ \ → 自动降级，通知运维
/──────────\
/ \ 提示：成本上升 / 延迟增加
/ ℹ️ \ → 记录日志，非工作时间不打扰
/──────────────\金融 Agent 的告警原则：
- 不要对单次亏损告警——交易本来就有亏损，noise 太多会导致告警疲劳
- 对"模式突变"告警——胜率从 60% 突然掉到 40%，说明系统出了问题
- 对"信息缺失"告警——新闻 Agent 返回空结果时，后续决策可信度大幅下降
- 分级响应：P0（停机）→ P1（降级）→ P2（记录），只有 P0 需要半夜叫醒人
9.4 审计追踪设计
每笔交易的完整审计链
┌─────────────────────────────────────────────────────────────┐
│ 交易 ID: TX-20260509-001 │
│ 时间戳: 2026-05-09 09:30:05 UTC │
├─────────────────────────────────────────────────────────────┤
│ [输入] 行情: AAPL $185.20 | 新闻: "Apple 发布新芯片" │
│ [市场分析师] RSI=65，建议观望 │
│ [新闻分析师] 正面事件，信心度 0.8 │
│ [辩论] 多头: "买入" | 空头: "观望" → 主管裁决: "轻度买入" │
│ [风控] 仓位检查通过，风险暴露 2% │
│ [决策] 买入 100 股 @ $185.20 │
│ [执行] 订单 ID: ORD-9987，状态: 完全成交 │
└─────────────────────────────────────────────────────────────┘不可篡改原则：审计日志一旦写入，只追加不修改。OpenAlice 用 Git 提交记录每笔交易，天然满足这一要求。监管问你"为什么当时做这个决策"，你必须能拿出完整上下文。
10. 迁移策略
从一个简单的模拟 Agent 走向生产级的多 Agent 实盘系统，不是一蹴而就的。以下是生态中项目验证过的迁移路径。
10.1 四阶段迁移：模拟 → 纸交易 → 小资金 → 全量
阶段 1 阶段 2 阶段 3 阶段 4
模拟交易 → 纸交易 → 小资金实盘 → 全量实盘
(零风险) (零资金) (有限损失) (正常运营)
│ │ │ │
▼ ▼ ▼ ▼
验证架构 验证券商接口 验证心理/执行 正常运作
调参优化 验证延迟影响 验证风控逻辑 持续优化各阶段的核心任务：
| 阶段 | 目标 | 关键验证点 | 常见陷阱 |
|---|---|---|---|
| 模拟 | 证明 Agent 架构能跑赢基准 | 回测夏普比率 > 1.0 | 过拟合历史数据 |
| 纸交易 | 验证与真实市场的接口 | 数据延迟、订单格式 | 模拟成交 vs 真实滑点差异巨大 |
| 小资金 | 用真实金钱测试执行链路 | 风控是否真生效 | 小资金下的心理压力和模拟完全不同 |
| 全量 | 正常运营 | 系统稳定性、成本可控 | 规模扩大后，之前没发现的瓶颈暴露 |
TradingAgents 的启示：它长期停留在阶段 1（纯模拟），恰恰是负责任的做法——没解决实盘基础设施（延迟处理、断线重连、订单管理）之前，不应拿真钱冒险。
10.2 单 Agent → 多 Agent 的迁移
阶段 A: 单一 Agent 阶段 B: 多 Agent
┌─────────────┐ ┌──────────┐ ┌──────────┐
│ 全能型 │ → │ 分析师-A │ │ 分析师-B │
│ (什么都管) │ │ (技术面) │ │ (基本面) │
└─────────────┘ └────┬─────┘ └────┬─────┘
└─────┬─────┘
决策层迁移路径：
- 先拆分信息收集：把"数据获取"从决策 Agent 中拆出，独立成分析师 Agent
- 保持决策层单一：初期不搞辩论，多个分析师报告汇总到一个决策 Agent
- 引入对抗视角：系统稳定后加入"空头研究员"，暴露认知盲区
- 逐步增加 Agent：从 2-3 个开始，每次增加后观察 Eval 分数变化
10.3 单市场 → 多市场的扩张
美股 (AAPL) 验证通过后 美股 + 港股 验证通过后 全球市场
单市场 ─────────→ 双市场 ─────────→ 多市场
新增复杂度： 新增复杂度：
- 交易时间不同 - 货币兑换
- 数据源不同 - 监管差异
- 基本面分析框架相似 - 基本面逻辑差异巨大扩张原则：
- 同类优先：先做另一个美股（AAPL → TSLA），再跨市场（美股 → 港股）
- Agent 复用："技术面分析师"可跨市场复用，"基本面分析师"需针对市场重新训练
- 独立风控：每个市场独立风控线——不要把港股和美股的风险暴露混在一起
10.4 技术栈迁移模式
早期验证 生产化
┌─────────────┐ ┌─────────────────────┐
│ Python 原型 │ ───→ │ TypeScript / Go │
│ (快速迭代) │ │ (类型安全 + 性能) │
│ Jupyter │ │ 单元测试 + CI/CD │
│ 手工执行 │ │ 自动化部署 + 监控 │
└─────────────┘ └─────────────────────┘生态中的实际案例：
- AI Hedge Fund 从 Python 原型开始，验证策略有效后，核心执行引擎用 Go 重写（低延迟订单处理）
- OpenAlice 直接选了 TypeScript，因为团队判断"金融系统没有类型安全是致命的"
- FinceptTerminal 用 C++ 做 UI，但把策略逻辑嵌入 Python——各取所长
迁移决策树：
延迟 < 10ms? ──→ Rust/C++
团队 > 5 人? ───→ TypeScript（类型安全）
快速迭代? ─────→ Python + 类型注解
个人项目? ─────→ Python 足够核心原则：不要在验证策略有效之前，纠结技术栈。能在 Python 赚钱的策略，比 Rust 里不赚钱的策略有价值得多。
延伸阅读
- 这些设计思路的技术实现 → 07 技术原理
- 用 TradingAgents 验证这些原则 → 03 多智能体交易 - TradingAgents 深度剖析
- 回到全景地图 → 金融 AI 生态全景