R-01AgentBench · ICLR 2024
在交互环境里评估 Agent
AgentBench 用八类交互环境评估 Agent 的推理与决策，并将长期推理、决策和指令遵循列为典型失败来源。评估对象是环境中的行为结果，不是模型自述。
MULTI-AGENT EVALUATION · FIELD GUIDE
Trace
is not
Proof.
协作日志回答“发生了什么”；验收还要回答：结果是否满足原始目标、是否进入真实系统、失败能否被重现和修复。
01EXECUTION一次执行产生候选结果
↓02EVIDENCE环境提供可复算证据
↓03ACCEPTANCE目标端读回 + 责任主体决定
核心判断
Agent 数量、消息数量、工具调用数量和运行时长，都只能说明系统很忙。它们不能单独证明工作已经完成。
01 · WHAT RESEARCH ACTUALLY SUPPORTS
论文支持的是评估方法，
不是某个产品的正确性。
下面只提取原论文或正式会议页面能够支持的一般结论；不把研究结果外推成 Flowness 的能力证明。
R-02SWE-bench · ICLR 2024
让候选改动面对可执行环境
SWE-bench 把真实 GitHub issue、代码库和测试环境组合成任务。候选结果必须在执行环境里改变可观察的测试状态，说明“生成了补丁”和“解决了问题”是两个不同判断。
R-03SWE-bench Verified
验证器本身也需要验证
SWE-bench Verified 通过人工核查任务说明、测试正确性和可解性来提高评估契约的可靠度。自动测试很重要，但测试是否真正对应目标仍然是一个独立问题。
R-04MT-Bench & Chatbot Arena · NeurIPS 2023
LLM 评委有用，但不是无偏真相源
研究发现强模型评委能较好近似人类偏好，同时存在位置、冗长度、自我偏好与有限推理等偏差。单个 judge 的“通过”因此需要与可复算证据和必要的人类判断组合。
R-05Multi-Agent Debate · ICML 2024
多 Agent debate 不是质量保证
一项研究在特定推理与事实性任务中观察到 debate 带来的改善；另一项系统研究发现现有方法不能稳定超过 self-consistency 或 ensemble，且对调参敏感。增加 Agent 数量不能代替验收设计。
02 · THE VERIFICATION LADDER
把“通过”拆成
七种不同证据。
风险越高、改动越不可逆，越需要走到更高层。小而可逆的任务不必套完整仪式。
- 01CLAIM & TRACE证明发生过
自报与事件真相
谁在何时、基于哪个版本声称完成了什么？这是待验证信号，只能证明一次执行发生过。
- 02ARTIFACT IDENTITY证明对象没错
产物与精确身份
候选产物是否存在，并绑定目标、来源、版本、commit 或 hash？它不能在评审途中被静默替换。
- 03MECHANICAL CHECK证明检查通过
可复算后置条件
结构检查、测试、探针、查询或策略门是否显示目标状态改变？验证器本身是否覆盖真实要求？
- 04INDEPENDENT REVIEW证明缺陷闭环
独立证伪与新鲜复验
与生产者隔离的评审者主动寻找反例；Finding 修复后，对后继候选重新取证，不复用旧 verdict。
- 05COMMITMENT支持接入判断
集成读回
产物是否进入真正消费它的代码库、服务、数据库、文档系统或决策流程？需要独立读回证据。
- 06ACTIVATION支持路径判断
代表性激活
真实或有代表性的任务是否走过新路径？是否存在旧入口、缓存或静默旁路让功能看似上线？
- 07ACCEPTANCE支持有界验收决定
责任主体接受结果
目标端权威读回和业务判据是否成立，并由有权责任主体作出显式决定？剩余风险和未覆盖范围是否明确？
03 · FALSE SIGNALS
最危险的不是失败，
而是看起来像成功。
这是执行者报告，不是独立证据。
只说明调用协议成功，不说明业务后置条件成立。
只覆盖被运行的检查与本地环境，不自动覆盖集成、部署或真实使用。
LLM judge 可扩展，但偏差与任务适配仍需控制。
Built、Integrated、Activated 与 Accepted 是不同状态。
可能代表检查太窄、证据缺失，或评审者共享了同一盲区。
04 · FAILURE ATLAS
从“哪一步报错”
转向“哪一种工作病理”。
Flowness 的公开 Failure Atlas 用七个问题组织结构性失败。它不是统计学证明，而是一套可复盘、可寻找反例的诊断视角。
Formation
事件为什么没有形成可执行的工作？
Continuity
工作为什么在没有结论时悄悄停了？
Integrity
身份、版本、证据或解释是否发生漂移？
Adaptation
事实变化后，旧上下文和计划是否仍被误用？
Commitment
产物是否进入了真正消费它的系统？
Closure
“完成”是否对应现实效果与验收？
Learning
同类结构性失败下次是否更难再次发生？
05 · MINIMUM ACCEPTANCE PACKET
一次可交付验收，
至少留下六样东西。
- 01
原始目标与反目标
成功是什么，哪些结果即使看似有效也不能接受。
- 02
候选结果的精确身份
版本、commit、hash、环境或其他不可混淆标识。
- 03
权威后置条件
由目标系统、数据库、测试环境或真实消费面给出的观察。
- 04
评审关系与独立性
谁执行，谁评审，共享了哪些上下文，可能存在哪些共同盲区。
- 05
Finding 与修复血缘
问题落在哪个候选，修复产生哪个后继版本，为什么没有被静默丢弃。
- 06
新鲜复验与剩余风险
对修复后的候选重新取证和给出 verdict，并明确尚未覆盖的环境、用户或条件。
EVIDENCE BOUNDARY
研究解释风险，
运行证据证明实现。
AgentBench、SWE-bench、LLM-as-a-Judge 与 multi-agent debate 研究支持的是：Agent 应在任务环境中评估，结果需要可观察证据，自动评委有价值也有边界，多视角评估值得研究。
这些论文没有验证 Flowness，也没有证明任何 Harness 能自动保证正确性。Flowness 当前公开 Alpha 支持的仍是一条窄链路：执行、独立评审、Finding 保留、定向返工，以及对后继候选的新 verdict；它不等于目标域 Effect 或责任主体的现实验收。
完整的通用 Flow runtime、跨领域效果和长期可靠性仍属于需要继续验证的主张。
06 · PRIMARY SOURCES
所有关键判断，
回到一手来源。
取证日期：2026-08-17。论文支持范围与 Flowness 实现证据在本页中保持分离。
- AgentBench: Evaluating LLMs as AgentsOPEN ↗
- SWE-bench: Can Language Models Resolve Real-world GitHub Issues?OPEN ↗
- SWE-bench VerifiedOPEN ↗
- Judging LLM-as-a-Judge with MT-Bench and Chatbot ArenaOPEN ↗
- Improving factuality and reasoning through multiagent debateOPEN ↗
- When is Society of Mind Superior to Self-Consistency?OPEN ↗
- Flowness public evidence and Failure AtlasOPEN ↗
CONTINUE