摘要：长文本推理的瓶颈不是上下文窗口，是证据的组织方式。LongHarness用状态化证据管理，让同一个GLM-5.3-Flash模型在100M-token语料上的准确率从4.4%拉到61.1%，模型一行没改。扩大窗口解决"能装多少"，证据管理解决"找不找得到"。
一、一个真实的失败案例
在OfficeQA Pro测试中，Codex需要从历史财政部报告中找到80个数字再计算答案。第22步，它找到了正确值4400。第166步，它甚至写下"Need use 4400"。但第170步，最终答案用的是错误值4100。
它找到了正确答案，然后把它弄丢了。
这不是个例。OfficeQA Pro V2包含1,435份文档、约1亿token，直接推理准确率仅4.4%。
当前主流叙事是"等上下文窗口变大就好了"。但1亿token的语料，即使窗口扩到1000万也装不下。更关键的是：即使把相关段落全部塞进256K窗口，准确率最高也只有23.2%。
问题不在于"能不能装下"，在于"装了之后找不找得到"。
二、两个耦合的失效模式
LongHarness论文（上海AI Lab与复旦大学）指出了一个根本问题：现有Agent harness把"已获取的证据"和"正在演化的结论"混在同一个不断增长的交互历史里。这种隐式状态管理导致两个耦合的失效模式：
无界探索：检索不断扩展交互历史，但没有解决决策相关的信息缺口。Agent在不停地搜，但真正需要的信息一直没找到。
证据-状态漂移：之前获取的证据或后续修正无法影响当前结论。Codex在第22步找到4400、第166步写下"Need use 4400"，但第170步用的是4100------这就是典型表现。
三、核心机制：证据与结论显式分离
LongHarness的做法是把证据和结论显式分离，然后让它们互相驱动。
Evidence-Conclusion Coevolution（证据-结论共演化）是双向的：
未解决的结论驱动探索。不是让Agent"自由搜索"，而是让当前尚未解决的结论告诉Agent"你还缺什么信息"。每个结论有明确状态：已确认、待验证、有冲突。检索的目标是"关闭未解决的信息缺口"，而不是"找到更多相关内容"。
新证据强化或修正结论。每一条新获取的证据都会回溯到它支持或反驳的结论上，持续影响结论的置信度。
Evidence Lifecycle Management（证据生命周期管理）解决的是"证据-状态漂移"。每一条证据有生命周期状态：活跃、被修正、被推翻。当一条证据被后续发现推翻时，所有依赖它的结论收到通知，置信度重新计算。修正可以向下传播，不会"改了一个地方，其他地方还是旧值"。
四、效果数据
V2提升幅度：14倍（4.4%到61.1%）。用Qwen3.8-Flash作为骨干时，LongHarness在V1上达到61.7%，比Claude Code高8.3个百分点，比Codex高12个百分点。
五、三个检验问题
打开你的Agent客户端，让它执行一个需要从多个文档中提取信息的长任务。观察：
第一，检索步骤是在关闭信息缺口，还是在扩大搜索范围？如果Agent在不停搜索但没有明确"我在找什么、找到之后要干什么"，它就是处于无界探索状态。
第二，修正是否能传播？如果你告诉Agent"之前找到的那个数字是错的"，它的最终答案是否真的会改变？还是它只是在对话历史里"知道"了修正，但结论仍然依赖旧值？
第三，证据是否与结论显式绑定，还是只存在于聊天记录里？
如果三个问题的答案都是"否"，你的Agent只是在聊天记录里"看过"证据，没有真正"管理"它。
你不需要换模型，不需要等更大的窗口。你需要在harness层加一个证据管理系统。
查看原文
以上仅为核心速览。完整版包含：LongHarness完整架构拆解、证据-结论共演化代码级分析、证据生命周期管理实现细节、与Claude Code/Codex的完整对比实验数据、边界条件与后续验证方向。
本文首发于微信公众号「阿Q的AI笔记」，点击下方链接阅读全文：