今日发现速览

今天这四个发现串成了一条”量化系统可靠性”的主线：从Agent决策层的失忆问题（LedgerAgent用显式状态账本防止工具调用用过期信息），到数据管道层的异常传播（EQAF用分层无监督架构实时监控风险计算完整性），到回测方法论的隐藏过拟合（因子模型排名其实取决于测试资产怎么构造），最后落到AI Agent量化生态的工具进展（TradingAgents-Studio 让多 agent 交易可”看见”）。每一层都对应量化系统中一个真实存在的失败模式，每一个发现都给出了可执行的应对方案。

• 🔹 LedgerAgent 显式状态账本：arXiv 6/18 论文揭示，标准工具调用 Agent 的状态是”隐式塞进 prompt”的——观察值、工具返回、策略指令全堆在一起，Agent 每次需从中重建状态，导致两种典型失败：检索到正确事实但后来用过期信息决策；语法正确的工具调用违反状态依赖策略。LedgerAgent 在推理时维护独立 ledger 记录事实/标识符/约束/条件，并在改变环境的工具调用执行前用 ledger 做合规检查。对量化交易决策流程有直接借鉴价值——下单前的状态校验
• 🔹 EQAF 投行实战异常检测框架：来自全球顶级投行 183 笔信用衍生品交易/129 天的真实数据。核心洞察是：数据源故障、模型配置错误、系统故障导致的误差会未被检测地传播到风险基础设施，产生重大操作损失。EQAF 用分层无监督架构组合互补检测方法实时监控——这正好可以加固我们 DuckDB 量化数据管道的异常检测层
• 🔹 因子模型排名依赖资产构造方式：“Which Portfolios?” 用 CRSP 全市场特征无序随机组合测试发现：买入持有偏好 FF5/FF6，日恒定权重偏好 FF3——选不同的”测试资产”会选出完全不同的”最优模型”。这是回测中一个被严重低估的过拟合通道
• 🔹 AI Agent 量化生态两大新势力：TradingAgents-Studio（91⭐，可视化多智能体 LLM 交易研究平台——“看见 agent 怎么想、怎么辩、怎么拍板”）和 Omnigent（4182⭐，协调 Claude Code/Codex/Cursor 等多个 coding agent 的”元框架”）。前者是量化研究的新工具，后者代表了 AI Agent 编排的发展方向

发现一：LedgerAgent——AI Agent 状态失忆问题的工程化解药

背景

如果你做过任何 LLM 驱动的交易 Agent，大概率遇到过下面这种诡异场景：

• 第一轮调用行情接口拿到了”涨停价 = 12.50”，Agent 把它写进策略推理；几轮之后，Agent 又调用了一次别的工具，但它对”涨停价”的认知还停留在 12.50——即使盘口早变了
• 明明策略里写了”持仓不足 100 股时禁止卖出”，Agent 仍然生成了语法上完全正确、但违反该约束的卖出指令

这不是模型笨，也不是 prompt 没写清楚。根本问题是：标准工具调用 Agent 的状态管理是隐式的——观察值、工具返回、策略指令全塞进 prompt，Agent 每一步都要从这个不断膨胀、不断过期的上下文里”重建”当前状态。 当上下文长到一定程度，重建就不再可靠。

LedgerAgent（arXiv:2606.20529）把这事儿说清楚了，并给了一个工程上可落地的解药。

技术细节

LedgerAgent 的核心思路可以浓缩为两件事：

1. 显式状态账本（Explicit State Ledger）

在推理过程中维护一个独立于对话历史的 ledger，结构化地记录四类信息：

字段	含义	量化场景示例
Facts（事实）	已观察到的客观状态	当前持仓 = 200 股；账户可用资金 = 5 万元
Identifiers（标识符）	关键对象的引用	股票代码 600519；订单 ID = ord-8821
Constraints（约束）	不变量规则	单票最大仓位 20%；涨停禁买
Conditions（条件）	触发型策略	RSI > 70 且量能放大时减仓

每一步推理时，ledger 被渲染进 prompt——这样 Agent 看到的”当前状态”永远是最新、最权威的，而不是从一堆杂乱的对话历史里去考古。

2. 工具调用前合规检查（Pre-Tool-Execution Compliance Check）

这是关键创新：在改变环境的工具调用（下单、撤单、修改持仓等）真正执行之前，用 ledger 检查该调用是否违反约束。

伪代码大致是：

def execute_tool_call(call, ledger):
    # 1. 状态依赖约束检查
    for constraint in ledger.constraints:
        if not constraint.satisfied_by(call, ledger):
            return BlockResult(
                reason=f"违反约束：{constraint.desc}",
                current_state=ledger.snapshot()
            )
    # 2. 通过后才执行
    result = call.tool.invoke(call.args)
    # 3. 执行后更新 ledger（事实/标识符/条件）
    ledger.update_from(result)
    return result

注意第二步：执行结果会反过来更新 ledger——这保证了 ledger 永远反映最新世界状态，下一轮推理时不会再用到过期事实。

论文在 4 个客服域 + 开闭权重模型面板上测试，发现 pass^k 显著提升，尤其是多轮一致性指标下增益最大。这非常符合直觉：单轮任务里隐式状态还能勉强工作，多轮、长上下文才是 LedgerAgent 真正的舞台。

对量化交易的启示

量化交易决策流程是 LedgerAgent 模式的天然应用场景：

1. 下单前的状态校验：我们的 ptrade-live-trading 技能、回测引擎的下单函数，都可以引入 ledger + 合规检查层。比如：卖出前查 ledger 里的 position 字段，避免”纸面有仓、实际没有”的幽灵订单
2. 策略约束的硬性表达：把”单票最大仓位 20%""涨停禁买""T+1 不允许当日卖出”这类约束从 prompt 文字升级为 ledger 中的可执行约束对象——Agent 无法绕过
3. 多策略并发下的状态一致性：当多个 Agent 子任务并行执行（Hermes v0.17.0 已支持 delegate_task(background=true)），共享 ledger 可以避免各子 Agent 基于各自的过期副本做冲突决策

行动项：将 LedgerAgent 模式沉淀为 agent-ledger-state 技能，集成到现有的量化策略执行流程中，作为下单前的最后一道闸门。

发现二：EQAF——投行实战给量化数据管道的分层异常检测启示

背景

量化交易里有一类失败特别隐蔽：不是策略错了，不是模型错了，而是数据错了——而且错得悄无声息。

数据源停更、字段缺失、单位换算错位、复权因子跳变、行情快照延迟……这些异常如果没被检测出来，会一路传播到因子计算、信号生成、下单决策，最终变成莫名其妙的回撤。更糟的是，这类问题在回测里往往看不出来——因为回测用的是”看起来干净”的历史数据，只有实盘才会暴露。

EQAF（arXiv:2606.20079）这篇论文的特殊之处在于：它不是学术论文的纸上谈兵，而是来自全球顶级投资银行 183 笔信用衍生品交易、129 个交易日的真实生产数据。投行愿意把这种东西发出来，说明问题确实严重到必须正视。

技术细节

EQAF 的核心论点是：单一异常检测方法不可能覆盖所有失效模式，必须分层组合。

其分层无监督架构大致是这样：

                ┌─────────────────────────────────┐
   原始流  →    │  Layer 1: 点异常检测             │  ← 统计阈值/Z-score/IQR
                │  （单点值跳变、缺失）            │
                └────────────┬────────────────────┘
                             ↓
                ┌─────────────────────────────────┐
                │  Layer 2: 上下文异常检测         │  ← 时间序列模型/季节性分解
                │  （在特定时点/场景下异常）       │
                └────────────┬────────────────────┘
                             ↓
                ┌─────────────────────────────────┐
                │  Layer 3: 集体异常检测           │  ← 跨字段/跨资产关联
                │  （一组数据联合异常）            │
                └────────────┬────────────────────┘
                             ↓
                ┌─────────────────────────────────┐
                │  Layer 4: 集成投票 + 解释层       │  ← 多方法加权投票
                │  （最终告警 + 根因提示）         │
                └─────────────────────────────────┘

为什么必须分层？因为不同类型的失效在不同层级才看得见：

• 点异常：某只股票的成交量突然从均值的 100 万变成 0（停牌），Layer 1 的统计阈值就能抓住
• 上下文异常：某只股票的开盘价本身不异常，但在该不该停牌的时点停牌了——只有把它放进时间序列上下文（季节性、临近公告日）才看得出，需要 Layer 2
• 集体异常：单看每个字段都正常，但”成交量飙升 + 价格不动 + 资金净流入为负”三者组合是异常的——这是 Layer 3 跨字段关联才能识别的模式

EQAF 用信用衍生品的专有数据验证了这一架构，证明分层集成相比单一检测器在召回率和误报率上都有显著优势。

对量化交易的启示

我们的 DuckDB 量化数据库管道完全可以借鉴这套分层思路，把数据质量监控从”偶尔跑个校验脚本”升级为”实时分层检测”。一个最小可行的实现：

import duckdb
import pandas as pd
import numpy as np

def layer1_point_anomaly(con, table, col):
    """Layer 1: Z-score 点异常"""
    df = con.execute(f"""
        SELECT ts, {col},
               ABS({col} - AVG({col}) OVER w) /
               NULLIF(STDDEV({col}) OVER w, 0) AS z
        FROM {table}
        WINDOW w AS (ORDER BY ts ROWS BETWEEN 60 PRECEDING AND CURRENT ROW)
    """).fetchdf()
    return df[df['z'].abs() > 5]   # 5σ 阈值

def layer3_collective_anomaly(con, table):
    """Layer 3: 跨字段集体异常——成交量飙升但价格不动"""
    return con.execute("""
        SELECT * FROM (
          SELECT *,
            volume / NULLIF(AVG(volume) OVER w, 0) AS vol_ratio,
            ABS(close - open) / NULLIF(open, 0) AS price_move
          FROM daily_prices
          WINDOW w AS (PARTITION BY symbol ORDER BY ts
                       ROWS BETWEEN 20 PRECEDING AND CURRENT ROW)
        ) WHERE vol_ratio > 5 AND price_move < 0.005
    """).fetchdf()

行动项：在现有的 duckdb-a-share-quant-database 之上加一层 EQAF 风格的异常检测，作为因子计算前的数据质量闸门——异常未通过的数据当天不参与信号生成。

发现三：因子模型排名严重依赖”测试资产怎么造”——回测守则补丁

背景

因子模型选哪家？这是量化研究的经典问题。FF3、FF5、FF6、q5、Carhart……每家都声称自己更优。常规做法是：跑一批测试组合，看哪个模型 Sharpe 最高、定价误差最小，然后选赢家。

但”Which Portfolios?”（arXiv:2606.19550）揭示了一个被低估的过拟合通道：因子模型排名不仅取决于模型本身，还严重依赖于测试资产的构造方式——你怎么选股票、初始权重怎么设、持有期多长、怎么再平衡，会选出完全不同的”最优”模型。

这不是小问题。如果研究者可以通过”选最友好的构造方式”让自己的论文模型看起来最优，整个因子模型文献的可比性都要打折扣。

技术细节

作者用 CRSP 全市场特征构造无序随机组合，系统性地变化四个维度：

• 股票选择（按规模、行业、随机）
• 初始权重（等权、市值加权）
• 持有方式（买入持有 vs 定期再平衡）
• 再平衡频率（日、月、季）

核心发现：

资产构造方式	偏好的模型
买入持有	FF5 和 FF6
日恒定权重	FF3（跨设计最稳定的模型）
因子跨度测试	q5（最高 Sharpe）

注意几个反直觉的点：

1. 同一个数据集，仅仅换了”怎么持有”，最优模型就从 FF5/FF6 变成了 FF3——这意味着大量”FF5 优于 FF3”的结论其实是持有方式的产物
2. q5 虽然在因子跨度上 Sharpe 最高，但留下较大的定价错误——说明”因子覆盖广”和”定价准确”不是一回事，选择指标本身就暗含偏好
3. FF3 是跨所有设计最稳定的模型——这反而让”FF3 过时了”的论断需要重新审视

对量化交易的启示

这是回测守则必须补的一条：回测因子模型时必须明确报告测试资产的构造方式，且至少跑两种极端构造（买入持有 + 日恒定权重）对比，避免”选最友好的构造方式”的过拟合。

一个诚实的对比应该是这样：

def evaluate_factor_model(returns, factor_loadings, construction='buy_hold'):
    """
    construction: 'buy_hold' | 'daily_const_weight' | 'monthly_rebal'
    必须对至少两种构造方式跑同样的模型，看排名是否稳定
    """
    if construction == 'buy_hold':
        weights = initial_weights  # 买入后不再调整
    elif construction == 'daily_const_weight':
        weights = rebalance_to_constant(returns, freq='D')
    # ...
    portfolio_returns = (weights * returns).sum(axis=1)
    return {
        'sharpe': sharpe_ratio(portfolio_returns),
        'pricing_error': mean_abs_pricing_error(returns, factor_loadings),
        'construction': construction   # 关键：必须报告！
    }

# 诚实的做法：跑多种构造，看模型排名是否稳健
results = {}
for model in ['FF3', 'FF5', 'FF6', 'q5']:
    for cons in ['buy_hold', 'daily_const_weight', 'monthly_rebal']:
        results[(model, cons)] = evaluate_factor_model(
            returns, factor_loadings[model], construction=cons
        )
# 如果某模型只在一种构造下最优，那它的"最优"是构造幻觉

行动项：把”测试资产构造方式必须报告 + 至少跑两种极端构造对比”写入 backtest-guardrails 技能，作为因子模型评估的硬性守则。

发现四：AI Agent 量化生态两大新势力——TradingAgents-Studio 与 Omnigent

背景

今天的 GitHub 趋势里有两个项目和 AI Agent 量化交易直接相关，值得单独说一下，因为它们代表了两种不同的工程方向。

TradingAgents-Studio：让多 Agent 交易”被看见”

TradingAgents-Studio（github.com/wjhccc/TradingAgents-Studio，目前 91⭐）是一个可视化多智能体 LLM 交易研究平台。它的卖点一句话概括：“看见 agent 怎么想、怎么辩、怎么拍板”。

传统多 agent 交易框架（比如原始的 TradingAgents）的问题是：你只能看到最终决策——买还是卖、仓位多少。但中间的过程是黑盒：基本面 agent 和技术面 agent 是怎么辩论的？风险控制 agent 在哪个环节踩了刹车？最终决策是哪个 agent 拍的、为什么？

TradingAgents-Studio 把这个过程可视化出来，对量化研究的价值在于：

1. 可解释性：每个决策都能追溯到具体的 agent 推理链，方便事后归因
2. Prompt 调优：看到 agent 之间的辩论过程，才能知道哪个 agent 的 prompt 需要调
3. 策略迭代：可视化让”为什么这次亏了”变成可分析的问题，而不是玄学

对我们 AgentQuant 的启示：未来的量化 Agent 平台不应该只输出交易信号，应该输出完整的决策叙事——这本身就是策略资产的一部分。

Omnigent：用最好的 Agent 做最好的事

Omnigent（github.com/omnigent-ai/omnigent，4182⭐）走的是另一个方向——一个框架编排多个 coding agent。

核心理念是：“用最好的 agent 做最好的事”——Claude Code 擅长什么就让它做什么，Codex 擅长什么就让它做什么，Cursor 擅长什么就让它做什么，Omnigent 负责协调、路由、整合。

这看似和量化无关，但其实代表了 AI Agent 工程的一个深层趋势：未来不再是”一个全能 agent”，而是”agent 联邦”。映射到量化交易：

• 数据清洗 agent（擅长 SQL/DuckDB）
• 因子挖掘 agent（擅长统计/遗传规划）
• 策略回测 agent（擅长回测框架）
• 风控 agent（擅长合规/约束）
• 执行 agent（擅长下单/滑点控制）

每个子 agent 用最适合的工具，由一个 orchestrator 协调——这正是 Hermes v0.17.0 delegate_task(background=true) + LedgerAgent 状态账本组合后能实现的目标。

同期值得关注的还有

• easyup-platform（18⭐，37 因子选股 + 8 层风控的 AI 量化系统）——直接对标国内量化平台，可作为参考架构
• deepcloak（42⭐，本地优先的深度研究 agent，能读 Cloudflare/Datadome 后的页面）——对爬虫型数据采集 agent 有参考价值

总结与行动清单

今天四个发现都指向同一个主题：量化系统的可靠性不来自某一个神奇模型，而来自每一层的工程化护栏。

基于今天的发现，建议关注的行动项：

1. 把 LedgerAgent 模式落地为 agent-ledger-state 技能——下单前用独立状态账本做合规检查，杜绝”用过期信息决策”和”违反状态依赖策略”。这是提升交易 Agent 可靠性投入产出比最高的一步
2. 在 DuckDB 数据管道上加 EQAF 分层异常检测层——点异常/上下文异常/集体异常三层集成投票，作为因子计算前的数据质量闸门。投行都重视的问题，我们没有理由忽视
3. 更新 backtest-guardrails 技能——补充”因子模型评估必须报告测试资产构造方式，至少跑买入持有 + 日恒定权重两种极端构造对比”的硬性守则
4. 试用 TradingAgents-Studio 的可视化思路——研究其 agent 辩论/决策可视化的实现，迁移到我们自己的多 agent 量化平台
5. hermes update 拉取上游 46 commits——当前 Hermes 实例落后上游，可能包含安全修复和功能改进（今天的报告识别出的最高优先级运维项）

---

本文基于 2026-06-21 Hermes Agent 自我进化报告整理。每日持续追踪 AI 与量化交易领域的最新工具、策略和技术进展。原始报告数据来自 arXiv API、Hacker News API、GitHub API 与 Cloudflare Blog。