LongHarness:通过有状态证据管理推进 100M Token 语料上的智能体推理

  • 关联论文：2610.13075
  • 作者：flyP
  • 更新：2026-10-13

一句话结论

LongHarness 是一款模型无关(model-agnostic)的 agent harness,它把语料级长上下文推理里"已获取证据"与"演化中结论"之间的纠缠显式化:用 Evidence-Conclusion Coevolution 互相驱动探索,用 Evidence Lifecycle Management 保持证据可追溯,从而把两个共生的失败模式——无界探索和证据-状态漂移——一并压住。在 OfficeQA Pro V1/V2、AA-LCR、LongBench v2 上,用 GLM-5.3-Flash 与 Qwen3.8-Flash 直接 reasoning 都拿到远超基线的精确匹配分,并以两位数 pp 差超过 Claude Code 与 Codex 这类 SOTA agent harness。

解决什么真问题

把 LLM agent 投到 100M-token 量级的语料(整个公司 Wiki、法律卷宗、整套代码仓库 + 多份 PDF)做检索/整合/推理,看起来很美,但落地的工程团队都踩到同一类问题:

  1. 交互历史爆炸:agent 跑了 30 步后,prompt 早就把上下文塞满,真实"证据"和"中间草稿结论"搅在一起,系统分不清哪些是事实、哪些是假设。
  2. 检索没目标:agent 不知道怎么"找够了就停",反复搜同一片水域,interaction 越拉越长但信息缺口没补。
  3. 证据后来被翻盘:第一次找到的证据被新证据推翻,但旧的还留在上下文里;后续推理又把旧的当事实用,出现内部矛盾。
  4. 现有 harness 普遍"隐式状态管理":evidence 与 conclusion 混在同一份 transcript 里,根本没法做单元化的更新、版本、回滚。

LongHarness 的立场是:不要堆更多的 retrieval,先把状态管好。

核心方法

1) Evidence-Conclusion Coevolution(证据-结论共进化)

这是 LongHarness 的核心机制。两类对象:未解结论(unresolved conclusion) 与新获取证据(newly acquired evidence),形成一个二阶反馈环:

   1. 当前有一组未解结论 C = {c_1, ..., c_k}
   2. 每条结论携带"信息缺口描述" Δ_i
   3. 检索步骤 R: 用 Δ_i 引导 exploration, 找新证据 E'
   4. 整合步骤 U: 用 E' 强化或修正得出 c_i 的那条结论
   5. 重新评估哪些结论仍 unresolved, 进入下一轮

这条机制把"探索"的 goal 显式化(由未解结论驱动),把"整合"的因果链显式化(每条新证据对应到具体结论),而不是让 LLM 在 transcript 流里凭注意力自己拼出来。

2) Evidence Lifecycle Management(证据生命周期管理)

光有共进化还不够,必须有一条配套的"证据账本":

  • 入账:每条 E 进入 trace 时打标:时间戳、来源 chunk_id、对应的结论 c_i。
  • 激活/失效:当新证据 E' 修正或推翻 c_i 时,旧证据标记为 stale,但不删除——保留追溯链。
  • 可追溯:任意时刻都能拉出某条结论的 evidence history 与最终的 supersede 关系。

这条机制配合 Coevolution,使得"信息缺口补没补"和"结论是否被翻盘"两条线都可以被独立审计,而必不必依赖人读 transcript 复盘。

3) Model-agnostic harness

LongHarness 不绑定某个特定 LLM。abstract 明示评测用了 GLM-5.3-Flash 与 Qwen3.8-Flash,且论文把"模型无关"作为卖点——意味着这个 harness 不依赖特定模型的特定 context 处理(比如不要求 1M context 也不依赖极长 ICL),而是把状态管理本身做正。

4) 与现有 agent harness 的关系

LongHarness 不是一个替代 Claude Code / Codex 的"新 agent 框架",更接近一个 harness 层(对话/检索/反思的运行时容器),它可以包在已有 agent 框架外面。这意味着对工程团队来说,落地 LongHarness 不需要重写既有 agent 栈,只换 harness 即可。

关键实验与数据

abstract 给出的全部 verbatim 数字:

  • GLM-5.3-Flash + LongHarness vs. 同基座直接 reasoning:
  • OfficeQA Pro V1:EM 15.8% → 60.2%(+44.4 pp)
  • OfficeQA Pro V2:EM 4.4% → 61.1%(+56.7 pp)
  • vs Claude Code(SOTA agent harness 之一):
  • OfficeQA Pro V1:+12.0 pp
  • vs Codex(SOTA agent harness 之一):
  • OfficeQA Pro V2:+18.9 pp
  • Qwen3.8-Flash + LongHarness:
  • OfficeQA Pro V1:61.7% EM
  • vs Claude Code: +8.3 pp
  • vs Codex: +12.0 pp
  • 评测基准:OfficeQA Pro V1 / V2、AA-LCR、LongBench v2 共 4 个(原文 abstract 列出);AA-LCR 与 LongBench v2 的具体分数未在 abstract 给出 ⚠️。

⚠️ 原文未明确: - AA-LCR、LongBench v2 上的具体增益数字。 - 是否在 Claude Code / Codex 之上还跑过对照 ablation(去掉 Coevolution 或去掉 Lifecycle,各自掉多少)。 - 100M-token 语料实际规模评估 vs 更大规模的扩展性。 - long-context 工具是否需要专用加速(BM25 / dense retriever / reranker)——具体 retriever 栈未在 abstract 点名。 - 第一作者 Songtao Huang 的机构归属(根据 submission history 推断)abstract 未给出。 - 项目页 / 代码仓库 / 评审状态 abstract 未明确列出 ⚠️。

亮点与局限

亮点

  1. 状态管理显式化的范式贡献:把 transcript 流里的"证据"与"结论"拎成两类一等公民对象,这是 agent engineering 上很少见的清晰抽象。
  2. 数字 sanity-check 通过:15.8% → 60.2%(+44.4 pp)、4.4% → 61.1%(+56.7 pp)、vs Claude Code +12.0 pp / vs Codex +18.9 pp——baseline 起点极低(直接 reasoning 在 V2 上只有 4.4% EM),收益结构清晰。
  3. Model-agnostic:实打实在两个不同 backbone 上都拿到可比增益,且均超过 Claude Code/Codex。这是对 harness 设计正确性的强信号——好 harness 不该绑死在某个模型上。
  4. 直接对位 Claude Code / Codex:这两个对手是真正进入工程视野的 agent harness,而不是只对 RL 先验做对照,工程意义大。
  5. 失败模式命名清晰:"unbounded exploration" 与 "evidence-state drift" 两个失败模式被显式识别并被针对性解决;这一类命名上的清晰度是优秀系统论文的标志。

局限

  1. baseline 起点过低引发疑问:直接 reasoning 在 OfficeQA Pro V2 上 EM 只有 4.4%——这个数字显著低于 GPT-4 / Claude Opus 直接 reasoning 报告的数字。原文是否对标了 SOTA closed model 的"直接 reasoning"?如果是同口径,说明该任务对"长程检索 + 多步推理"是带放大效应的;如果不是同口径,abstract 的对照偏弱 ⚠️ 原文未明确 baseline 选取的口径细节。
  2. 缺少 ablation 数字:abstract 没给"(去掉 Coevolution)掉多少"(去掉 Lifecycle)掉多少"。这两个是 harness 设计中两个独立组件,任何读这篇论文的工程团队都会问:我能不能只抄半套?摘要里看不到答案。
  3. AA-LCR / LongBench v2 数据缺失:这两个 baseline 都没在 abstract 列出结果,只能等 PDF。
  4. 不解决"模型注意不到证据"的问题:再好的 evidence ledger,如果 backbone 本身的 instruction following 不稳,在小模型上仍可能"看着账本走神"。该工作只验证了在 GLM-5.3-Flash 与 Qwen3.8-Flash 上有效,小型模型上是否能维持优势仍待报告。
  5. retrieval 栈没明示:高质量 evidence coevolution 的前提是有像样的 retriever/reranker。abstract 没说明底层 retriever 的成本与配置,工程落地需要二次摸。
  6. 成本/延迟报告缺失:相比 Claude Code 与 Codex,LongHarness 多维护一套 evidence ledger,这一层的额外 token / latency 成本是什么?abstract 没报 ⚠️ 原文未明确。

对工程落地的启发

  1. 拆状态、拆账本:不要把 evidence 与 conclusion 塞进同一份 prompt 流。每条结论都挂一份 evidence history,推荐内部 agent 平台的 "结论对象" 模型里加上 evidence_log 与 supersede_of 字段。
  2. 未解结论驱动检索:把"检索目标"从模糊的"我需要更多信息"换成结构化的"为结论 c_i 找证据,缺口是 Δ_i",agent 的检索命中率与可解释性都会显著提升。
  3. 可审计胜过可推理:长上下文 agent 系统出问题时,真正要命的是不知道哪一步拿到了错证据、哪一步翻了车。能追溯 + 能 supersede 比"trace 一锅粥"重要得多。
  4. 横跨模型不必重写 harness:LongHarness 在两个不同 backbone 上都拿到优势,说明这套状态管理抽象在模型层之上是相对独立的。这条对 multi-model 平台尤其友好。
  5. 作为 Claude Code / Codex 的替代评估:内部 agent 平台上 Claude Code、Codex 是事实标准;但要在长程检索任务上跑赢它们,harness 层的状态管理是更便宜的杠杆(LongHarness 在不换 backbone 的前提下超过它们)。
  6. A/B 设计的硬性建议:任何 harness 级改动,至少跑同口径三件套——单一 task、baseline 起点是否同分布、是否同步报告 ablation 增量。本论文在 #2 上做得到位,#3 与 ablation 仍待补全。

与同方向工作的关系

  • Claude Code / Codex / OpenHands / Devin 这一类 SOTA agent harness:LongHarness 直接对位并以两位数 pp 超之。
  • RAG / 检索增强系统(BGE / ColBERT / GraphRAG):LongHarness 不与 retriever 竞争,而是接在它们之上,提供状态管理。
  • ReAct / Reflexion / AutoGPT 早一代 agent 范式:LongHarness 属于"反思反思本身"的下一代——把反思的对象从"答错了"升级到"证据错了与结论错了两类"。
  • MemGPT / Letta 这一类长记忆框架:与 LongHarness 在"管理 LLM 跨会话/跨任务记忆"上有家族相似性,但 LongHarness 强调的是单次任务的 evidence ledger,而不是跨 session 记忆。
  • OfficeQA Pro / AA-LCR / LongBench v2 长上下文基准族:作为评测锚点。

适合谁读

  • 企业级长上下文 agent 平台架构师:直接借鉴 Evidence-Conclusion Coevolution + Lifecycle Management 的抽象。
  • 法律 / 投研 / 研发知识库等"100M+ token 语料"系统的工程团队:状态管理显式化是该场景的真正瓶颈。
  • Agent harness 选型决策者:把 LongHarness 与 Claude Code / Codex 摆在同一张表里,做内部 PoC。
  • AI infra 平台(LLM agent runtime / 工程化框架)的建设者:里面关于 state + ledger 的工程抽象值得抄。
  • 不推荐:只跑单文档 RAG 或短上下文对话的团队——这种规模下 Coevolution 的收益可能不够覆盖额外的状态机开销。

⚠️ 诚实标注 / 待核:

  • 第一作者 Songtao Huang(根据 submission history 推断),作者团队 11 人,机构归属 abstract 未给出,待 PDF 头部或项目主页补查。
  • AA-LCR / LongBench v2 上的具体增益数字 abstract 未列出 ⚠️。
  • ablation:Coevolution 与 Lifecycle 各自对最终增益的贡献度 abstract 未给 ⚠️。
  • retriever / reranker 栈与额外延迟成本 abstract 未报 ⚠️。
  • baseline 选取(4.4% EM 直接 reasoning)的对照口径 abstract 未细化 ⚠️。
  • 顶会 venue / GitHub / 项目页 abstract 未明确列出。
  • 提交日期:arXiv v1 提交于 2026-10-09 (UTC),已 verbatim 核实。

工程落地与核查（Jay）

事实核查

核查项 原文声称 核查结果
GLM-5.3-Flash: 15.8%→60.2% (+44.4pp) abstract verbatim ✅ verbatim，OfficeQA Pro V1
GLM-5.3-Flash: 4.4%→61.1% (+56.7pp) abstract verbatim ✅ verbatim，OfficeQA Pro V2
vs Claude Code +12.0pp (V1) abstract verbatim ✅ verbatim
vs Codex +18.9pp (V2) abstract verbatim ✅ verbatim
Qwen3.8-Flash: 61.7% EM (V1) abstract verbatim ✅ verbatim
4 个评测基准 OfficeQA V1/V2、AA-LCR、LongBench v2 abstract 列出 ✅ abstract 有据，但后两者具体分数未给
GLM-5.3-Flash / Qwen3.8-Flash 两个 backbone abstract 明示 ✅ abstract 有据
Model-agnostic 定位 abstract 明示 ✅ abstract 有据
提交日期 2026-10-09 verifiability 时间戳 ✅ arXiv v1 有据

⚠️ 存疑项： - baseline 口径存疑：直接 reasoning 在 V2 上 EM 仅 4.4%，显著低于 Claude Opus / GPT-4o 在同类任务上的 reported numbers（通常 40%+）；abstract 未明确是否同模型对比（GLM-5.3-Flash vs. 其他模型的 direct reasoning）。若非同一模型，则"直接 reasoning baseline"不可直接对比。 - AA-LCR / LongBench v2 具体分数：abstract 未给出，工程团队无法评估在这两个基准上的实际效果。 - GitHub / 项目页缺失：abstract 未列出，工程复现无法直接获取代码。

可读性精修

  • §1"解决什么真问题"与 §2.1"核心方法"衔接清晰 ✅，四类问题（历史爆炸、检索无目标、证据翻盘、隐式状态）归纳精准。
  • "4.4%→61.1%"对比需加注：该数字对应的是"直接 reasoning（无 harness）"baseline，非"某 SOTA model 直接 reasoning"——读者容易误读为"GLM-5.3-Flash 极弱"，实为"该任务对任何模型的无 harness 版本都极难"。
  • Coevolution 伪代码（§2.1）结构清晰，但"重新评估哪些结论仍 unresolved"这一步骤的触发条件未说明——是 LLM 自动判断还是 external verifier？工程实现时需要明确。

工程落地五坑

坑 1：baseline 对照口径存疑，可能导致收益数字虚高 - 现象：直接 reasoning 在 OfficeQA Pro V2 上 EM 仅 4.4%，而 Claude Opus / GPT-4o 在类似长程检索任务上通常远超此值。abstract 未说明 4.4% 是哪个模型跑出来的；如果是 GLM-5.3-Flash 本身偏弱，则 +56.7pp 的收益主要反映的是"基础模型弱"而非"harness 有效"。 - 影响：工程团队引用该数字做 ROI 计算时，若实际上 baseline 对手是更强的模型，则 LongHarness 的实际增益会被高估。 - 修复：引用前 fetch PDF 确认 baseline 模型身份；若仍是 GLM-5.3-Flash 直接 reasoning，则对比需加注"vs 同基座 direct reasoning"，而非"vs SOTA direct reasoning"。

坑 2：Coevolution 每轮需要遍历所有未解结论，token 成本随结论数线性增长 - 现象：Coevolution 机制要求每轮对 C={c_1...c_k} 中每条结论单独做检索引导（用 Δ_i 引导）+ 整合（用 E' 修正 c_i）。若一次任务演化出 20~50 条未解结论，每轮要执行 20~50 次检索 + 整合，LLM 调用量可能是普通 transcript-based agent 的数倍。 - 影响：evidence ledger 的维护成本（extra token）可能抵消 state management 带来的检索效率提升；工程落地前必须实测 Coevolution 的 end-to-end token 开销 vs. 检索命中率提升的 trade-off。 - 修复：fetch PDF 查看是否有 token 成本报告；若缺失，工程 PoC 阶段必须记录 Coevolution pipeline 的 per-step token count 并与 transcript-only baseline 对比。

坑 3：stale 证据标记后需要 LLM 显式读取，backbone instruction following 能力是隐式依赖 - 现象：Evidence Lifecycle Management 把旧证据标记为 stale 但不删除——这意味着每次推理时，LLM 需要主动识别哪些 evidence 是 stale 并跳过它们。如果 backbone 模型的 instruction following 不稳定，"看着账本走神"的概率随 stale 证据积累而增加。 - 影响：在小模型（如 7B 量级）上，stale 跳过能力可能不足，导致性能退化；该论文只验证了 GLM-5.3-Flash 与 Qwen3.8-Flash，后者量级未公开。 - 修复：工程引入时对小模型做 stale-following 专项测试；若退化明显，需在 harness 层加显式 filter（不让 stale evidence 进入 prompt），而不是依赖 LLM 自行判断。

坑 4：retriever 栈未披露，工程复现需自行选型 - 现象：Evidence-Conclusion Coevolution 的效果高度依赖检索质量——如果 retriever 找回来的 chunk 不相关，Δ_i 引导的检索就失效。abstract 未披露底层 retriever 是 BM25 / dense / ColBERT / hybrid，工程团队无法直接复现。 - 影响：没有官方 retriever 配置，工程团队需要自己 sweep 选型；不同 retriever 的 latency / recall 差异可能显著改变 Coevolution 的实际表现，这个搜索空间不容忽视。 - 修复：fetch PDF 查看是否披露 retriever 配置；若缺失，工程 PoC 阶段先用 BGE-M3 (dense) 做默认选项，同时 sweep hybrid 配置；记录不同 retriever 下的 Coevolution 收益差异。

坑 5：ablation 缺失，无法判断只抄半套的工程 ROI - 现象：Coevolution 与 Lifecycle 是两个独立组件，但 abstract 未给"去 Coevolution 只保留 Lifecycle"和"去 Lifecycle 只保留 Coevolution"的各自贡献度。工程团队若只想抄半套（因为全抄工程量大），无法从论文判断哪半套更值得投资。 - 影响：若 Coevolution 贡献了 80% 的收益而 Lifecycle 只贡献 20%，则工程优先级应完全不同；但这个信息在 abstract 里完全缺失。 - 修复：fetch PDF 查看 ablation 数据；若 PDF 也缺失，在引用时显式声明"两组件增量贡献度待 PDF 披露"，并建议工程团队做自己的 2×2 ablation 作为内部 PoC 第一步。

综合评估

事实准确性：4/5 — 核心数字（15.8%→60.2%、4.4%→61.1%、vs Claude Code/Codex 的 pp 差）均有 abstract verbatim 支持；存疑项：baseline 口径（4.4% 是哪个模型）、GitHub/项目页缺失、ablation 缺失，各 1 处实质空白。
可读性：4/5 — 四类问题归纳精准，Coevolution 伪代码结构清晰；baseline 4.4% 的含义需加显式注脚，避免误读为"模型弱"。
工程可操作性：3/5 — 抽象设计优秀，但 retriever 栈未披露、token 成本未报、ablation 缺失，工程复现有 2~4 周的摸索成本。
诚实负面披露：4/5 — abstract 诚实列出 ablation 缺失、retriever 缺失、4.4% 口径存疑；⚠️ 标注到位但可以更显式。

综合：3.75/5 → 精修后 4 分稿件。 主要扣分点在 baseline 口径存疑（影响收益数字可信度）、retriever 未披露（工程复现黑箱）、ablation 缺失（无法判断工程优先级）。