AI Agent 骨架范式参考 — 七仓实地核证 + FinBayes 选型建议
⚠️ 已被 v2 重核修正（owner 2026-06-07 晚）：本文档（v1）是模块级静态阅读得出的印象结论，缺内循环 call-graph 实证。owner 指出后做了 6 仓逐层（外循环 + 工具执行 + subagent + 规划态 + 反思 + 输出）call-graph 追踪，发现 v1 三处实质错误：(1) Opencode 是 Plan-and-Solve 不是「最严格 Plan-and-Execute」；(2)「静态流水线/P&E 一律否决」范围过宽——它们作 inner-loop 工具被 Claude Code WorkflowTool / Opencode 实际采用；(3)「结构化与表现负相关」是过度概括——真因是 Chelae 的 router-of-routers 嵌套 LLM，不是「结构」本身。修正后的权威版见 agent 骨架范式参考 v2（内外循环 call-graph 实证）。本 v1 保留作 audit trail，外循环 ReAct 的判定仍成立，但内循环结论以 v2 为准。
0. 这份文档是什么
通过并行派 7 个 sub-agent 实地核证 7 个有代表性的 agent 仓库的骨架结构后沉淀的可复用参考。每仓产出 9 维结构化报告（入口 / 主回路 / 范式判定 / 工具系统 / 状态管理 / 规划层 / 反思 / 输出契约 / 独特骨架元素），所有判定带 file:line 证据。
用途：为 FinBayes 阶段 2 战略对齐提供决策基础——把"应该选什么骨架"从印象推理升级到证据推理。
七仓清单：
- 通用 Agent：Openclaw、Hermes Agent（NousResearch）
- Coding Agent：Claude Code（社区 fork
claude-code-bestv2.6.11，非 Anthropic 官方包，但同形）、Opencode（anomalyco） - 金融 Agent：martinpmm-Finclaw、Chelae-FinClaw、aifinlab-FinClaw
核证方法：每仓由独立 sub-agent 阅读全部相关源文件，按统一 9 维模板输出 ≤800 字结构化报告，所有判定必须带 file:line 证据，不允许编造。本文档是 7 份报告的 synthesis。
1. 核心发现
发现 1：所有 6 个真 Agent 主回路都是 ReAct，无一例外
| 仓 | 主回路文件 | 控制结构 | 范式 |
|---|---|---|---|
| Openclaw | agent-loop.ts:229 | while(true) 嵌套 | ReAct |
| Hermes | agent/conversation_loop.py:814 | while iteration < max_iterations | ReAct |
| Claude Code | src/query.ts:460 | while(true) async generator | ReAct |
| Opencode | session/prompt.ts:1225 | while(true) Effect-TS | ReAct |
| martin-Finclaw | agent/loop.py:318 | while iteration < max_iterations | ReAct |
| Chelae-FinClaw | agent/loop.py:224 | while iteration < max_iterations | ReAct |
| aifinlab-FinClaw | 无主回路 | —— | 非 agent，是 1033 SKILL.md 的 skills 包 |
6 个真 agent 全部 ReAct，无一例外。Plan-and-Solve / Plan-and-Execute / 静态流水线 / Ralph / Reflexion 等范式没有任何一个被任何 agent 用作主回路。这是一个强经验证据——FinBayes 旧版的金融认知模块（代码在 finclaw/cognition/）用一个绕过 ReAct 的旁路当金融问答主路径（finclaw/agent/loop.py:503-565 金融意图命中即进该旁路），是反 7 仓全员实证的孤例。
命名说明（2026-06-07）：本文档全程把这块叫「FinBayes 旧版金融认知模块」，不叫「Codex 的 X」——它是 FinBayes 自己仓库里待重构的旧实现，与 OpenAI 的 Codex coding agent 无关，避免读者误以为在讨论某个外部 agent 的骨架。它是待重构/改造、甚至可能整体抛弃重写的部分。
一处重要更正（2026-06-07）：上一轮把这个旧模块定性为「Plan-and-Execute」是过度褒义。精核后它比 Plan-and-Execute 还低一档，是静态流水线（static pipeline）——见下方 §1.6 的四范式精确分类。Plan-and-Execute 的 plan 是 LLM 运行时产物，旧模块的「plan」是 dispatcher 静态表里人手写死的任务→DAG 映射，编译时固定、运行时不可改、上游结果不影响下游拓扑。
发现 2：Hybrid 的标准答案 = "ReAct 核心 + opt-in 工具层"
Hybrid 不是"主回路选哪个范式"，是"主回路定 ReAct，然后把扩展能力当 tool 暴露给 ReAct"。最干净的表达来自 Claude Code（fork 版可读源码）：
"Everything beyond the ReAct core is just another tool"
Plan mode / Skills / Subagents / Workflows / MCP / Todo lists 全是 ReAct 主回路里 LLM 可以选择调用的 tool。具体实现：
- Skill 即 forked subagent：
packages/builtin-tools/src/tools/SkillTool/SkillTool.ts:336内部调用runAgent（runAgent.ts:257）。Skills 和 Subagents 是同一原语，元数据来源不同 - 28 个 Hook 事件：
src/entrypoints/sdk/coreTypes.ts:25-53定义生命周期事件（PreToolUse / PostToolUse / SubagentStart / PreCompact / ...），settings.json 驱动 shell / HTTP / prompt 三种执行器 - Plan mode 通过权限切换实现：
permissionMode === 'plan'（query.ts:760）限制副作用工具，而非单独的 planner 模块
Opencode 用相似思路：Plan/Build 两 agent 切换（agent/agent.ts:128-165）+ StructuredOutput 合成工具按需注入（prompt.ts:1378-1385）。这是 7 仓里最干净的扩展模式。
发现 3：事后复盘线 / 校准 / 跨任务学习 7 仓全员缺席
最接近的是 Hermes _spawn_background_review（run_agent.py:1403）——回合结束后后台 daemon 改写 memory + skills（agent/background_review.py:417）。但这是"反思写记忆"，不是金融语境下"判断 → 失效条件 → 事后市场验证 → 准确度累积校准"那条事后复盘线。
意义：治理仓 §9 的事后复盘线（§9 原词「慢循环」）要求 7 仓全没做过——这不是 §9 过时，是 §9 在做真创新。FinBayes 在这个维度有合法的 innovation 空间，无现成参照可抄，要自己定义工程实现。
发现 4：结构化输出稀缺，「输出要素规范」是 FinBayes 旧版攒下的稀缺资产
7 仓里 forced structured output 只有 Opencode 按需实现（用户传 format 时注入合成 StructuredOutput tool，prompt.ts:1378-1385），且只针对最终答案而非每个中间产物。其他仓全部停留在"tool 输入 JSONSchema 校验、tool 输出自由字符串"。
没有任何一仓有 FinBayes 旧版金融认知模块（finclaw/cognition/）那种 6.3K 行 taxonomy + EvidencePacket + StructuredCognitionResult + synthesis_validator + projections 的金融领域结构化输出。这套「输出要素规范」（规定每个工具返回什么、最终答案必须含哪些要素——方向/证据/失效条件）承载的产品目的有价值，值得保留——但承载它的旧实现（静态流水线 + 绕过主回路）要抛弃。重构时把这套规范从「绕过 ReAct 的主路径」改为「贯穿 ReAct 工具产出与最终答案的输出格式约束」；具体 schema 代码是复用还是重写，待重构时定，不预先承诺。
发现 5：Pre-router 是反结构化的负证据 —— Chelae 加了「结构」反而弱于 martin
Chelae 是 martin 的金融领域 fork，骨架核心不变，但加了一个 rule-based pre-router（FinancialIntentDetector，agent/financial/intent.py:17）在 LLM 看到用户消息之前做规则分类（price_query / earnings_calendar / financial_analysis / macro_analysis / meme / prediction_market / ...），按结果注入不同的 routing prompt（loop.py:391-415），并把 6 个金融领域的 LLM router 工具（router-of-routers 模式）暴露给外层 ReAct。
owner 实测结论（2026-06-07）：Chelae 的实际使用体验远弱于 martin。这跟结构差异完全咬合，给出一条反结构化的硬证据链：
- 规则 pre-router 是负债不是资产：规则一旦误判意图，就把 LLM 强行推上错误路径，而 LLM 本可自己判断该问题需要什么。预分类墙切碎了统一 ReAct 回路——正是 §9 警告的「墙」。
- router-of-routers 损耗推理：把 martin 30 个扁平工具收成 6 个 LLM 子路由，外层 LLM 失去对细粒度工具的直接推理能力，多一层「传话」损耗。
- 结构化程度与实际表现负相关：martin 纯 ReAct + 扁平工具（强）> Chelae ReAct + 规则 pre-router + router-of-routers（弱）> FinBayes 旧版静态流水线（连 plan 都不是 LLM 决定的）。这条链同时否决了「加 L0 pre-router」和「旧版当前形态」。
对 FinBayes 的意义（修正上一轮）：上一轮我提议参 Chelae 设计「L0 Pre-router」——撤回。正确方向是回归纯 ReAct + 丰富扁平工具，把「结构」只留在输出要素规范上（工具产出与最终答案的格式约束），不留在控制流上（不做预分类、预路由、预编 DAG）。金融意图的识别应交给 ReAct 主回路里的 LLM 自主完成，工具的措辞要诚实到让模型按市场/任务自己选对工具（martin 已验证这条路最强）。
发现 6：四范式独立核证 —— 只有 Claude Code / Opencode 真做了 P&S / P&E，Ralph 全员零例
为避免把多种范式压成「ReAct / 非 ReAct」二分，按 §9（commons/references/2026-06-06-financial-agent-skeleton.md）的四范式精确定义，对 6 个真 agent 做了独立维度核证。
§9 四范式边界：
- ReAct（Yao 等）：走一步看一步，基于观测重新决策下一步，无预先规划。
- Plan-and-Solve（Wang 等，ACL 2023）：先把任务整体分解成子任务序列，再照计划执行——计划是 LLM 显式产物（先谋后动）。
- Plan-and-Execute（LangChain 工程化）：Planner LLM + Executor 角色分离，plan 作为 artifact 在两者间传递。
- Ralph Loop（Huntley 2025）：同一 prompt 放进
while true反复跑，每轮重置 context，状态外置到文件，靠暴力重复 + 末端验证器收敛。 - Governed Ralph：Ralph 的「不过显式验收门不准停」纪律 + 治理。§9 在金融场景否决 Ralph 骨架本身，只保留这条验收门纪律基因。
6 仓四范式核证表（每格带证据，✗ 表示核证后确认无该范式）：
| 仓 | 主回路 | Plan-and-Solve | Plan-and-Execute | Ralph / Governed Ralph |
|---|---|---|---|---|
| Openclaw | 纯 ReAct | ✗ 无 plan artifact | ✗ 无 planner/executor 分离 | ✗ context 累积非重置 |
| Hermes | 纯 ReAct + 后置学习 | ✗ todo 是 scratchpad 非 plan | ✗ | ✗ background_review 不重跑当前任务 |
| Claude Code | 纯 ReAct | ✓ EnterPlanModeTool（plan mode 产 markdown 计划，query.ts:760） | ✓ WorkflowTool（.workflows/*.md|.yaml 步骤运行） | ✗ |
| Opencode | 纯 ReAct | ✓ plan-mode agent 产 plan markdown（agent/agent.ts:128-165） | ✓ plan-mode →plan_exit→ build-mode 接力（tool/plan.ts:53-69） | ✗ |
| martin-Finclaw | 纯 ReAct | ✗ grep plan/reflect/critique 零命中 | ✗ | ✗ |
| Chelae-FinClaw | 纯 ReAct + 规则 pre-router + 嵌套 ReAct | ✗ pre-router 是规则非 LLM plan | ✗ inner router 也是 ReAct 非 P&E | ✗ |
结论：
- 6 仓主回路 100% ReAct，无一例外（跨 Python/TS/JS，跨通用/coding/金融）。
- Plan-and-Solve 与 Plan-and-Execute 只有 Claude Code、Opencode 两个 coding agent 真做了——且都是作为 ReAct 主回路里 LLM 可选的 tool / mode，不替代主回路。
- Ralph / Governed Ralph 全 6 仓零例——印证 §9「金融场景否决 Ralph」的判断，也说明它本就不是主流 agent 的骨架选择。
- 金融三仓（martin / Chelae）连 P&S / P&E 都没做，停在纯 ReAct（+ Chelae 的规则 pre-router，且实测更弱）。
Plan-and-Solve / Plan-and-Execute「作为 tool 嵌入 ReAct」的两种标准实现
这是 FinBayes 该抄的「如何把规划能力优雅嵌入 ReAct 而不绕过它」的标准答案。
Claude Code 模式 —— 规划作为 ReAct 主回路内的可选 tool：
ReAct 主回路 while(true) ─┬─ tool: EnterPlanMode ─→ permissionMode='plan' 限副作用 → LLM 产 markdown 计划 → ExitPlanMode → 切回 build
├─ tool: WorkflowTool ──→ 读 .workflows/*.md|.yaml 步骤表 → 一步一调，步骤间仍回主回路
├─ tool: Skill/Agent ──→ forked subagent（新 ReAct 子循环）
└─ tool: 普通工具 ──────→ 直接执行
要点：进了 WorkflowTool，步骤之间 control 仍回到主 LLM——主 LLM 决定下一步继续 workflow / 切别的工作 / 中止。是「Plan-and-Execute 嵌在 ReAct 里，ReAct 又嵌在 executor 里」的双向嵌套，不是单向流水线。
Opencode 模式 —— 双 agent 接力（最严格的 P&E）：
ReAct 主回路 [agent=build,默认] ──用户/LLM 选切 plan──→ [agent=plan, read-only + plan-writer]
↑ │ LLM 写完 plan markdown
└──── ReAct 执行 plan ←── plan_exit 注入合成 user message ←──┘（显式 control handoff）
要点：用两个不同 primary agent（不同 system prompt、不同工具集），plan 阶段禁用所有副作用工具强迫只产计划，切换走显式 control transfer。比 Claude Code 更严格，但本质仍是「ReAct 主回路 + 可选规划态」，不是静态 DAG。
对 FinBayes 旧版金融认知模块的精确诊断：它既不是 Claude Code 的「规划作 tool」也不是 Opencode 的「双 agent 接力」——它是静态流水线：plan 不是 LLM 任何时刻的产物，而是 dispatcher 字典里编译期写死的「意图→DAG 节点」映射。Plan-and-Execute 至少 plan 是 LLM 跑出来的、可被观测重塑；旧模块的 DAG 拓扑运行时锁死、上游结果不改下游。这是比 P&E 低一档的范式，且放在了绕过 ReAct 的主路径位置——两个错误叠加。这正是待重构/抛弃的核心。
2. 七仓骨架卡
2.1 Openclaw（通用 Agent）
- 入口：
packages/agent-core/src/agent-loop.ts:213runLoop - 范式：纯 ReAct，嵌套
while（outer 处理后续消息、inner 处理 tool 流） - 工具系统：白名单 + TypeBox JSONSchema 校验 + MCP 动态发现，dispatcher 用
find(t => t.name === toolCall.name)（agent-loop.ts:672） - 状态：
Session用 JSONL 存储，支持 分支树（DAG）会话——SessionTreeEntry含 message / model_change / thinking_level_change / compaction / branchSummary（harness/session/session.ts:106）。罕见：会话是 git-DAG 而非线性聊天日志 - 规划层：无。
src/tools/planner.ts:40只是工具描述符过滤器，不产任务计划 - 反思：无 Reflexion 模块。错误反馈通过
afterToolCallhook 注入回 context，让 LLM 自己处理 - 输出契约：tool I/O 用 TypeBox
TSchema强类型，但最终 assistant 输出无 schema 强制 - 独特元素：
- mid-flight steer：
getSteeringMessages（agent-loop.ts:323）允许在 tool 批次之间注入用户文本——可被引导的流式 agent - per-turn 模型切换：
prepareNextTurn（agent-loop.ts:297）可在轮间切 model / thinking level——支持自适应推理预算 - 并行 tool exec + 顺序保证：
executeToolCallsParallel（agent-loop.ts:545-616）并行执行 + 按提交序输出，保证确定性 transcript
- mid-flight steer：
2.2 Hermes Agent（NousResearch，通用 Agent）
- 入口：console script
hermes→hermes_cli/main.py→run_agent.AIAgent - 主回路：
agent/conversation_loop.py:814while iteration < max_iterations，IterationBudget驱动，默认max_iterations=90 - 范式：ReAct 核心 + 4 个扩展层：
- Steer-in-flight（用户
/steer注入下一回合，conversation_loop.py:875-887） - Nudge（周期性提醒 LLM 用 memory / skill，
:565-573） - 后置反思（
_spawn_background_review，run_agent.py:1403——回合结束后开 daemon 改写 memory / skill） - Delegate（
delegate_task工具，tools/delegate_tool.py:80，sub-agent 同形递归）
- Steer-in-flight（用户
- 工具系统：
ToolRegistry单例（tools/registry.py:151）+ Tool-Search 桥（tools/tool_search.py）—— 3 个元工具tool_search/tool_describe/tool_call让 LLM 把工具目录当 RAG corpus 检索，避免一次性把数百工具塞进 context - 状态：SQLite
SessionDB（hermes_state.py:376，4284 LOC，FTS5 全文索引）+MemoryManager（agent/memory_manager.py:244）+ trajectory 压缩 - 规划层：无。
todo工具是回合内 scratchpad，不是 plan-then-execute - 反思：唯一一个有真"后置反思"的 agent——
background_review异步改写 memory / skills，但不影响当前回合输出 - 输出契约：tool schema 是 JSONSchema dict +
coerce_tool_args宽松类型转换。plugin_llm.complete_structured（agent/plugin_llm.py:379）仅给插件用，主回路无强制结构化 - 独特元素：
- Tool-Search 桥（罕见）：工具目录 RAG 化
- IterationBudget 带返还（
agent/iteration_budget.py）：重试 / transient error 返还预算 + 一个 grace call - MCP 双向：既消费 MCP 又自暴露为 MCP server（
mcp_serve.py） - 后置反思：daemon 线程做事后 memory / skill 更新
2.3 Claude Code（fork claude-code-best v2.6.11，Coding Agent）
- 入口：
src/entrypoints/cli.tsx:1→main()at:73 - 主回路：
src/query.ts:460while(true)async generator，每轮 model stream → 收tool_useblocks → 执行 → continue - 范式：ReAct + tool-as-layer——Plan mode / Skills / Subagents / Workflows / MCP 全是 tool
- 工具系统：
- 静态 builtin 列表（~40 tools）+ MCP 动态注入 + feature flag 门控
- 每个 tool 有 Zod
inputSchema/ 可选outputSchema/validateInput预校验 - Skill = forked subagent：
SkillTool.ts:336调runAgent.ts:257 - Workflow tool（fork 版）：
.workflows/*.md|.yaml步骤运行器，feature 门控
- 状态：
State { messages, toolUseContext, autoCompactTracking, turnCount }（query.ts:421）+ AppState reactive store + SessionMemory + CLAUDE.md 自动加载（memdir/memoryTypes.ts:104）+ auto-compact 压缩 - 规划层：主回路不预规划。Plan mode 通过权限切换实现（
permissionMode === 'plan'限副作用工具），TodoWrite 给 LLM 写 todo 的 tool - 反思：无专门 Reflexion。
VerifyPlanExecutionTool/ReviewArtifactTool是工具，要 LLM 主动调用 - 输出契约：Zod 强类型 + 可选
outputSchema。Hooks 事件中心化定义（coreTypes.ts:25-53），28 个事件类型 - 独特元素：
- "ReAct + everything-is-tool" 最干净的实现
- 28 个 Hook 事件（PreToolUse / PostToolUse / SubagentStart / PreCompact / ...），settings.json 驱动 shell / HTTP / prompt 三种 hook 执行器
- MCP 双向（client + server）
2.4 Opencode（anomalyco，Coding Agent）
- 入口：
packages/opencode/src/index.ts:64yargs CLI - 主回路：
session/prompt.ts:1217-1473runLoop，while(true)at:1225，Effect-TS 生成器 - 范式：Hybrid（ReAct shell + Plan-mode agent + subagent fan-out）
- Plan / Build 两 agent 切换（
agent/agent.ts:128-165），plan_exit工具触发切换（tool/plan.ts:53-69） - Task subagent（
tool/task.ts:80）+ general / explore 专用 sub-agent
- Plan / Build 两 agent 切换（
- 工具系统：Effect-TS
Tool.define+ 内置 16 个 + 配置目录 globs + plugins + MCP（tool/registry.ts:225-266）。invalid工具：参数校验失败时把错误路由回 LLM 而非崩溃（tool/invalid.ts:9-20）—— soft validation 通道 - 状态：SQLite + Drizzle ORM，每轮重读 session（不维护 in-memory 主 state），支持跨进程 interrupt / resume。Compaction 子系统 + summary agent + AGENTS.md 注入
- 规划层：默认无。Plan-mode 是独立 agent；TodoWrite 是 in-session 工具
- 反思：无 Reflexion。
invalid工具 + 网络重试 + compaction 替代 - 输出契约：按需 forced structured output：用户传
format: { type: "json_schema", schema }时注入合成StructuredOutputtool 并toolChoice: "required"（prompt.ts:1378-1385, 1429）。7 仓里唯一有 forced structured output 机制的真 agent - 独特元素：
- Effect-TS 生成器骨架（罕见，全仓唯一）
- DB-backed 反应式循环（跨进程 resumable）
- Plan-mode 用权限重塑 agent 而非另起 planner 引擎
2.5 martinpmm-Finclaw（金融 Agent，baseline）
- 入口：Typer CLI
finclaw agent（finclaw/cli/commands.py:676） - 主回路：
finclaw/agent/loop.py:318while iteration < self.max_iterations，默认max_iterations=40 - 范式：纯单层 ReAct——
grep plan|reflect|critique在finclaw/agent/零命中 - 工具系统：
ToolRegistrydict（registry.py:8-66）+ 36 个手工注册 tool（39 个 Tool 类）+ MCP 动态注入。tool 失败时附[Analyze the error above and try a different approach.]提示（registry.py:40）——最原始的自纠正 - 状态：JSONL 按 channel:chat_id 持久化（
session/manager.py），MemoryStore写workspace/memory/MEMORY.md+HISTORY.md，由 LLM 通过save_memory工具触发整合 - 规划层：无
- 反思：无
- 输出契约：tool 入参 JSONSchema 校验，tool 出参全是
str——无结构化产出契约 - 独特元素：
- Channel-as-bus：
MessageBus把 CLI / Telegram / Slack / Discord / Matrix / WhatsApp 全部抽象成同一接口，loop 无关 channel - Subagent 是同形递归 ReAct（
subagent.py:123-167，max_iterations=15），通过 bus 反馈结果——没有 plan/result 契约 - Heartbeat + cron 触发 bus message——产品功能不是骨架
- Channel-as-bus：
2.6 Chelae-FinClaw（金融 Agent，martin 的工程优化 fork）
- 入口：同 martin（Typer
finclawCLI，cli/commands.py，1136 LOC） - 主回路：
finclaw/agent/loop.py:209-284_run_agent_loop，while iteration < self.max_iterationsat:224，默认max_iterations=20 - 范式：Hybrid = ReAct 核心 + rule-based pre-router + 嵌套 ReAct sub-agents
- Pre-router：
FinancialIntentDetector（agent/financial/intent.py:17）规则分类用户意图，按结果注入 MACRO_ROUTING_PROMPT / MEME_ROUTING_PROMPT / PREDICTION_ROUTING_PROMPT（loop.py:403-415）——LLM 看到的不是原文，是按意图预处理的版本 - Router-of-routers：6 个 LLM router 工具（FinancialMetricsRouter / FinancialSearchRouter / EquityValuationRouter / EconomicsRouter / MemeRouter / PredictionMarketRouter），每个内部跑 bounded ReAct（max 4 turns，
llm_router.py:143）+ asyncio.gather 并行取数
- Pre-router：
- 工具系统：继承 martin 工具 ABC + ToolRegistry，但把 martin 30 个扁平 fan-out 金融工具收成 6 个 LLM-routed sub-agent——外层 LLM 看到 ~12 个工具而非 ~30 个
- 状态：继承 martin 5 层（Session / MemoryStore / FinanceProfile / FinancialHistoryManager / FinancialDataCache），新增 per-ticker cache + history 复用层，命中时注入
CACHE_REUSE_CONTEXT_PROMPT短路重复取数 - 规划层：无 LLM planner。规则 pre-router 是 dispatch 不是 plan
- 反思：无。
llm_router.py:204-227synthesis fallback、earnings 表格 hint（agent/financial/router.py:39-59）算 hard-coded 后处理 - 输出契约：弱——只有 hard-coded markdown table hint 提示模型固定格式
- 独特元素：
- router-of-routers + rule-based pre-router：相对 martin 的真骨架 fork
- per-ticker cache + history 复用层：token / 延迟优化
- 新增 meme / prediction_market 领域包
2.7 aifinlab-FinClaw（金融 skills 包，非 agent）
- 入口：
install.sh装finskillshub（外部 PyPI）+ 把 SKILL.md 投到 OpenClaw 用户工作区下的skills/finclaw/ - 主回路：无——本仓没有 agent runtime，由外部 OpenClaw Agent OS 消费
- 范式：Skills 市场 / 能力包，不是 agent
- 规模：1033 个 SKILL.md（"千只金融龙虾"），YAML frontmatter 带中文触发短语（如 "DCF" / "现金流折现" / "内在价值"），skill body 是 prompt + bash/python 调用 + 工作流步骤
- 独特价值：
- 持久化角色文件 SOUL.md（罕见）：persona / 自我边界分离自 SKILL.md
- 大规模 skills catalog（1033 skills × 8 领域）：示范 skill marketplace 形态
- runtime 外包：明确把 agent loop 让给 OpenClaw（
README.md:279）
- 对 FinBayes 的意义：贡献的不是骨架而是 (a) 大规模金融 skill 内容库 和 (b) SOUL.md 持久 persona 模式
3. 七仓骨架光谱图
3.1 martin-Finclaw — 纯单层 ReAct
3.2 Chelae-FinClaw — ReAct + Pre-router
3.3 Claude Code — ReAct + Everything-Is-Tool
3.4 Hermes — ReAct + Steer + Background Review
3.5 Openclaw — ReAct + Branch-Tree Session
3.6 FinBayes 目标骨架（建议形态，2026-06-07 修订：去 L0 pre-router）
修订说明：原图有「L0 Pre-router」，因发现 5（Chelae 实测弱于 martin）已撤回。用户消息直入 ReAct 主回路，金融意图的识别交给主回路 LLM 自主完成。这不是调用栈意义上的分层堆叠，是「即时应答线 + 事后复盘线 + 贯穿其中的输出要素规范」（详见 §5 的重新表述）。
4. 可组合骨架元素对照表
| 元素 | Openclaw | Hermes | Claude Code | Opencode | martin | Chelae | aifinlab |
|---|---|---|---|---|---|---|---|
| ReAct 主回路 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | 外包 |
| Pre-router（规则） | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ | 外包 |
| Subagent fan-out | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ | 外包 |
| Skills 可复用能力 | 插件 | 动态 | ✓ | ✓ | md | ✗ | ✓✓ 1033 |
| Workflow / Plan mode | ✗ | ✗ | ✓ | ✓ | ✗ | ✗ | ✗ |
| Hooks 拦截 | ✓ 前后 | 插件 | ✓✓ 28事件 | ✗ | ✗ | ✗ | ✗ |
| MCP 集成 | ✓ | ✓✓ 双向 | ✓✓ 双向 | ✓ | ✓ | ✓ | ✗ |
| 事后复盘线 / 后台 review | ✗ | ✓ memory/skill | ✗ | ✗ | ✗ | ✗ | ✗ |
| Mid-flight steer | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ |
| 结构化输出契约 | ✗ | ✗ | ✗ | ✓ 按需 | ✗ | hint | ✗ |
| Tool-search 元工具 | ✗ | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ |
| 分支树会话 | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ |
| Per-ticker cache | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ | ✗ |
| 迭代预算带返还 | ✗ | ✓ | ✗ | ✗ | hard cap | ✗ | ✗ |
| SOUL.md persona | ✗ | ✗ | ✗ | ✗ | ✓ | ✗ | ✓ |
✓ = 有，✓✓ = 强壮，✗ = 无。
5. FinBayes 选型建议
5.0 头号设计铁律：不在 ReAct 之外另架控制墙
任何切换/绕过/接管 ReAct 主回路的外部控制结构，都禁止。 这条铁律同时否决三样东西：
- FinBayes 旧版「金融意图命中 → 绕过 ReAct 进静态流水线」的旁路（
loop.py:503-565） - Chelae 式「规则 pre-router 在 LLM 看消息前改写/路由」（owner 实测更弱）
- 任何「LLM 给出答案后由外部 validator 强制重做」的 blocking 墙
允许的扩展只有一种形态：作为工具暴露给 ReAct，由 LLM 自己决定要不要调（Claude Code「everything-is-tool」哲学）。规划、自检、子任务编排、复盘触发，全部走这条路。
5.1 整体形态：快慢两条线，不是分层堆叠
「L0-L4 五层栈」的说法本身有表演成分——它暗示一个自上而下的调用栈，但真实结构是 §9 的快慢两条线（= §9 原词「双时间尺度」）：
┌─ 事后复盘线（独立 daemon，时钟 = 天/季度）──────────────────┐
│ 失效条件监控 → 事后市场验证 → 准确度校准（统计累积） │
│ ▲ │ │
│ │ 写判断 读校准后基准 │
│ ┌───┴──────────────────────────────────────────▼────────┐ │
│ │ 即时应答线（ReAct，时钟 = 秒/分钟） │ │
│ │ 用户消息 → LLM 决策 → 工具调用 → 观测 → 重决策 → 答案 │ │
│ │ ↑ 贯穿：输出要素规范（工具产出 + 最终答案的格式约束） │ │
│ │ ↑ 可选：自检工具（LLM 主动调，非外部强制） │ │
│ └────────────────────────────────────────────────────────┘ │
│ 共享状态 = 判断存储 │
└──────────────────────────────────────────────────────────────┘
术语对照（本文档用白话，括注 §9 原词，防止两边失联）：
| 本文档用词 | = §9 原词 | 意思 |
|---|---|---|
| 快慢两条线 | 双时间尺度 | 即时应答 + 事后复盘两套节奏并行 |
| 即时应答线 | 快循环 | 秒/分钟级，接到问题当场答完的 ReAct 主回路 |
| 事后复盘线 | 慢循环 | 天/季度级，事后回看判断对没对、累积校准 |
| 输出要素规范 | 数据契约 | 规定工具产出与最终答案必须含哪些要素（方向/证据/失效条件） |
要点：
- 即时应答线 = 纯 ReAct + 丰富扁平工具（参 martin + Claude Code）。无 pre-router、无预编 DAG、无绕过主回路的旁路。金融意图识别交给主回路 LLM。
- 规划能力作为 ReAct 内的可选工具（参 Claude Code EnterPlanMode/WorkflowTool、Opencode 双 agent），不替代主回路，LLM 主动选。
- 输出要素规范是「贯穿即时应答线的横切约束」，不是一层——它约束每个工具返回什么、最终答案必须含什么。它更像「类型系统」不像「楼层」。承载它的旧实现要抛弃，规范本身的目的保留；schema 代码复用还是重写待定。定位见本轮 L3/L4 探讨。
- 事后复盘线是「跑在另一个时钟上的独立服务」，不是栈底一层——它和即时应答线只通过判断存储这张表松耦合，不进 ReAct 进程。耦合点「校准 → 基准」怎么落地，见本轮 L3/L4 探讨，尚未定型。
5.2 各部分抄哪个仓
| 部分 | 设计参照 | 关键设计点 | 现状差距 |
|---|---|---|---|
| 即时应答线主体 | martin（纯 ReAct + 扁平工具，实测最强）+ Claude Code（"everything-is-tool"） | LLM 每步基于观测决策；Hooks 拦截在主回路外；工具措辞诚实让 LLM 自选 | 旧版主回路被金融认知旁路绕过（loop.py:503-565），要恢复纯 ReAct |
| 规划作 tool | Claude Code EnterPlanMode + WorkflowTool / Opencode 双 agent 接力 | LLM 在 ReAct 里主动选进入规划态；plan 是 LLM 运行时产物 | 旧版静态 dispatcher 表要废，改 LLM 动态 plan 或预编 workflow 模板 |
| 输出要素规范（横切） | FinBayes 旧版金融认知模块（finclaw/cognition/）攒下的目的 | 规定工具产出与最终答案含哪些要素（方向/证据/失效条件） | 旧实现抛弃；规范目的保留；schema 代码复用还是重写待重构时定。定位待 L3/L4 探讨确认 |
| 事后复盘线（第二时钟） | §9（无现成参照，7 仓全无） | 判断生命周期、失效条件监控、准确度校准；daemon 异步不阻塞即时应答线 | 全新开发。回灌用 feature flag、默认只进 dashboard（见 §6.2）；判断对错定义留阶段 2 专研（§6.3） |
5.3 必须新增的骨架元素
参 7 仓最佳实践，FinBayes 应补但不在当前盘面上的：
- Hook 系统（参 Claude Code 28 事件）：金融场景尤其需要 PreToolUse / PostToolUse 做凭证脱敏（INV-11）、输出审计、判断 lifecycle 触发
- Subagent fan-out（参 4 仓）：复杂金融问题（多市场对比、跨周期分析）需要 fork subagent 用独立 context 跑
- MCP 集成（参 Claude Code 双向）：未来接团队 Web 前端、外部数据源、用户主权系统都走 MCP
- Mid-flight steer（参 Hermes / Openclaw）：用户能在分析中途纠正方向——金融场景的真实需求
5.4 必须放弃的反 best-practice（实测 + 核证双重支持）
- 静态流水线当主路径（FinBayes 旧版形态）→ 6 仓零例，连 Plan-and-Execute 都不如
- 静态 dispatcher 表当 plan 来源 → Claude Code / Opencode 的 plan 都是 LLM 运行时产物
- 「意图分类后绕过 ReAct」旁路（
loop.py:503-565）→ 改成 ReAct 内的 tool 选择 - 规则 pre-router + router-of-routers（Chelae 形态）→ owner 实测弱于 martin 纯 ReAct，反结构化负证据
6. 结论与待决（owner 2026-06-07 拍板）
6.1 已闭合的结论
- 控制流回归纯 ReAct：「6 仓全员 ReAct + Chelae 实测弱于 martin」双重归纳，足以否决一切控制流结构化（pre-router / 静态 DAG / 绕过主回路旁路）。结构只留在输出要素规范，不留在控制流。
- 自检只做 audit，不做 blocking（由 §5.0 头号铁律推出）：原 synthesis_validator 降级为「LLM 可主动调的自检工具 + 不阻断的 audit hook」，不在 ReAct 外架墙强制重做。
- 高危类别走用户主权两步确认，不在 loop 里架墙：涉及具体仓位建议等高危输出，把关放在产品层的用户两步确认（用户拍），而非即时应答线内的 blocking validator。
6.2 已定方向：事后复盘线的回灌用 feature flag（问题 C）
- 默认「只进 dashboard」：事后复盘线算出的准确度校准，默认只展示给 owner，不回灌即时应答线。先把地基（判断存储 + 复盘 daemon + dashboard）做稳。
- 预留回灌开关，默认关：开关打开后才激活「校准 → 即时应答线」的回灌；回灌方式本身可切换（只 dashboard / 注入 prompt 基准 / 改工具策略三档），按实际体验调整优化。
- 理由：§9 自己说「全部难度压在两个验证器诚不诚实上」。在事后复盘线的真验证器还没证明能诚实工作之前，先不让它的输出去改 agent 行为——不在不稳的地基上盖楼。
- (主控对「切换模型」的理解：指切换回灌方式/策略档位 + 可借此试不同模型表现，按实际体验调优；若 owner 本意是别的，回拨修正。)
6.3 留给阶段 2 的研究课题（owner 暂无法判断，不强定）
「一个判断事后算不算对」的诚实定义（问题 B）——这是事后复盘线能不能诚实落地的命门，本身是个该专门研究的子课题。难在：
- 「涨跌方向对」太粗——方向对但因为错误的理由对，算校准成功吗？
- 失效条件没触发、但方向错了，算什么？
- 判断有时间窗口（"未来一季度"），事后什么时点结算？滚动结算还是到期结算？
- 带不确定性的判断（"大概率上行"）怎么对照单次结果做校准？需要的是分布校准（Brier/log-loss）不是单点对错。
起点建议：这块可复用治理仓已有的 14-case 校准研究产物（Phase 2 的历史 case 标注经验），作为"判断对错定义"的素材库；阶段 2 单独开 session 专研，产出一份"判断结算与校准口径"规约再动工程。
本文档状态：§1-§4（七仓核证 + 四范式分类）定稿；§5.0 铁律 + §5.1 即时应答线 + §6.1 闭合结论 + §6.2 回灌开关方向 定稿；§6.3 判断对错定义留阶段 2 专研。骨架主体已稳定，可作为阶段 2 战略对齐的输入；落实到工程前酌情起 ADR。