跳到主要内容

FinTecEval FinBayes 臂更新工单——接当前 ReAct δ 生产路径

跨 session 工单：主控会话（FinBayes 侧知识强）供"改哪、怎么调当前生产 agent"，FinTecEval 会话（引擎契约强）做集成。主控不直接改 FinTecEval 仓代码——它是独立活跃 session（今天还跑了 6-arm smoke、STATE.md 是其单一事实源、有待提交批次），并发改同一仓会互相覆盖未提交工作 + 让其 STATE.md 与实际脱节。

§0 一句话 + 为什么现在​

Step 1.7 闸门（阶段 1 唯一交付判据）改走 FinTecEval 新纲领（108 case + 六/八维 + 硬门槛优先 + 相对增量定位）测，比旧 gate_1_7 强。但 FinTecEval 的 FinBayes 臂脚本是旧接线：跑的是认知核裸跑、不是上线的带工具 ReAct δ agent。照现状真跑会严重低估 grounding/工具维、不代表产品，且与 FinTecEval 自己 STATE.md「被测=新 ReAct δ」自相矛盾。这是步骤 5（真三臂 live 跑 108 题）的前置阻塞，必须先修 FinBayes 臂。

§1 问题：FinBayes 臂测错了东西​

FinTecEval 仓 harness/run_finbayes_and_raw.py 与 harness/run_finbayes_structured.py：

  • 调用的是旧 synthesize_cognition 单次认知路径（from finbayes.cognition.synthesis import synthesize_cognition），等于把认知核单独拎出来跑——没有 ReAct 主回路、没有工具调用、没有真实数据 grounding。这正是项目早已 pivot 掉的"一次性问答函数"形态。
  • harness/run_config.example.json 里 FinBayes 臂 cwd 指向已废旧工程仓（Programs/FinBayes），不是当前大驼峰新基线（Programs/CurvatureLabs/FinBayes）。

后果：grounding 深度维（"会填格 vs 有据"）、工具深度维会被系统性压低；轨迹质量、鲁棒恢复维根本无从测（认知核裸跑无轨迹）。裁决会失真。

§2 修法（FinBayes 侧——本工单供给的"料"）​

当前 FinBayes 生产入口已有现成、battle-tested 的函数，直接 port / 复用即可，无需重新发明：

  • 位置：FinBayes 仓（大驼峰 CurvatureLabs/FinBayes）scripts/three_way_compare.py 的 _finbayes_arm(...)。gate_1_7_vs_martin.py 已在用它——走的就是 ReAct δ 生产路径。
  • 它怎么调生产 agent（核心约 50 行）：
    • 构造 AgentLoop(bus=MessageBus(), provider=<tracer>, workspace=<tmp>, model, max_tokens, max_iterations, answer_extraction_mode=mode)（mode="prose_parse" = 生产默认 δ）。
    • 跑 await agent.process_direct(case["prompt"], session_key=..., channel="cli", chat_id=case["id"]) —— 这一行就是带工具的 ReAct 主回路。
    • 跑前 sync_workspace_templates(tmp) 同步 SOUL.md 等模板——关键：人格与判断纪律必须在系统提示里在场（2026-06-12 教训：此前评测跑批的系统提示里都没有 SOUL）。
    • TracingProvider 包真 provider，采集 system_prompt / 每轮工具调用 / finish_reason / message-工具送达的答案（process_direct 可能返回空、真答案在 message 工具里）。
  • imports（当前仓真实路径）：from finbayes.agent.loop import AgentLoop、from finbayes.bus.queue import MessageBus、from finbayes.cli.commands import _make_provider、from finbayes.config.loader import load_config、from finbayes.utils.helpers import sync_workspace_templates。
  • provider/model：_make_provider(config) + config.agents.defaults.model / max_tokens。
  • commit pin：当前 FinBayes = 88f68a6（含 DH 清算 / 数据广度 / 延迟优化①②③）。FinTecEval STATE.md 记的 SUT d16052d 已过期，请一并更到 88f68a6。
  • _finbayes_arm 返回结构（dict）：{arm, case_id, task_type, prompt_raw, system_prompt, inner_loop, llm_calls, tool_calls, answer, elapsed_s, coverage, attempts, trace_path, model, generated_at}。

§3 集成（FinTecEval 侧——你 own 的部分）​

把 _finbayes_arm 的输出映射到 harness/armkit.py 的 make_result(...) ArmResult 契约：

ArmResult 字段来源
idcase_id（← 108-case id）
arm"finbayes-delta"（或 "finbayes"）
role"test"
mode"live"（生产 ReAct 路径；不是 degraded）
okanswer 非空 且非 transient_failed
outputanswer
secondselapsed_s
llm_callsllm_calls
prompt_tokens / completion_tokens缺口：_finbayes_arm 的 TracingProvider 只记 turns、不累加 token。需像旧 run_finbayes_and_raw.py 的 CountingProvider 那样再包一层 provider 累加 usage（口径 prompt+completion、弃上游 total，对齐 armkit 硬规则）
tool_calls（extra）tool_calls（扁平 list，真 ReAct 工具调用，喂工具深度/grounding 维）
其他 extratask_type / coverage（RICH_FIELDS 结构化完整度，喂结构化维） / inner_loop（轨迹，喂轨迹质量维） / system_prompt（核 SOUL 在场）

两个集成陷阱：

  1. 108-case 字段名：_finbayes_arm 读 case["prompt"] / case["id"] / case["task_type"]；108-case schema 是 goal / id / axes.task_type。加一层薄 map（goal→prompt 等）。
  2. 别整模块 import：three_way_compare.py 顶部有 from scripts.ab_alpha_delta import CASES，直接 import 整模块会连带载入无关的 8-case 集。建议把 _finbayes_arm 这段 port 过来（或 import 时容忍/隔离该依赖），而非依赖整模块。

§4 待你决定：martin 臂用降级还是 full​

  • 现状：harness/run_finclaw.py 跑的是降级 martin——monkeypatch _register_default_tools 为 no-op（零工具）、空 workspace、max_iterations=1（单次 LLM）。role=competitor, mode=degraded。
  • 另有现成 full martin：_martin_arm（同在 three_way_compare.py）= subprocess 跑 finclaw.cli.commands agent -m <prompt> --logs，全工具、真 agent，--logs 正则抓工具调用。
  • 判断：相对增量定位的"及格线（vs 竞品）"要回答"这条赛道有没有竞争力"——这需要真竞品 = full martin，零工具降级 martin 答不了这个问题。旧 gate_1_7 用的就是 full _martin_arm。建议 full martin，但带 N2 不对称折扣：martin 工具数取自 --logs 正则、有损、系统性低估 martin / 高估 FinBayes，判工具深度维时按此折扣。最终方法学口径由你定。

§5 其他前置（清单，不替你决定）​

  • 同模型 apples-to-apples：三臂（FinBayes δ / 竞品 martin / 裸基线）必须钉同一个 openai 兼容模型才可比。注意 FinBayes 当前默认是 openai-codex/gpt-5.5（codex α OAuth transport），martin 没有这个 transport——跑 gate 时 FinBayes 臂也要钉到 openai 兼容端点（gpt.ge gpt-5.5，或 kimi-k2.6 对齐 5/26 baseline），与 martin / 裸臂同源。
  • 标答 owner-pending：108 题标答全 reviewed_by: owner (pending)。影响认知质量 / grounding 的 judge 软维；机器判的硬门槛（越权/合规红线/数值/结构）不卡。盲评软维口径见纲领通用框架 §7（三类裁判）。
  • 第二底座阻塞：gpt.ge 这把 key 只暴露 gpt-5.5 一个模型 → FEFM / 底座路由信号产不出（需 ≥2 底座）。不阻塞核心 gate，仅那条信号空缺。

§6 完成判据（步骤 5 = 真三臂 live 跑）​

修好 FinBayes 臂后，跑一次真三臂 = FinBayes 生产 δ + full martin + 裸 gpt-5.5，over 108 题（或 cases.json 10 锚 + 广度子集），过新打分引擎：硬门槛优先（越权/合规红线=0 先过）→ 六+八维 → 相对增量（vs 裸 / vs 竞品）→ 软维盲评。产出裁决 → 主控会话审计（守 §7 三会话分工：FinTecEval 跑、主控审计验收）→ owner 据此签 Step 1.7、阶段 1 收尾。

§7 出处 / 边界​

  • 本工单是 FinBayes 侧知识供给；FinTecEval 仓的代码改动归 FinTecEval session（撞车 + 引擎契约风险，§0 已述）。
  • 关联：本工作流 2026-06-08-finbayes-new-baseline-handoff-eval-tasks.md（旧 handoff，SUT 即记在此）、2026-06-08-step-1.7-audit-checklist.md（审计清单）；纲领正本 commons/frameworks/finteceval/ 两份标准。
  • 当前 FinBayes / martin 两仓 venv 均已就位，模型 key 在 keychain（引擎 runner 从 keychain 取、绝不落盘/打印）。