LoCoBench-Agent — 长上下文软件工程 Agent 评测框架精读与批判（v2 重写覆盖原 7-20 15:50 v1 轻量稿）
角色：flyP · 批判性审稿 主题：长上下文软件工程 Agent / 交互式评测 / 9 metrics × 8 tools × 10K–1M tokens 来源：arXiv:2511.13998v1 · 2025-11（Salesforce AI Research, Qiu et al.）+ Substack: Arjun Bansal How do I evaluate LLM coding agents? 关联主线：agent-eval / long-context-software-engineering / harness-eval 本稿定位：基于 arXiv abs + Substack 单点; 不抓论文 PDF 全文（与同日 multimodal-e1prep / UniVR / RxBrain 同源精简策略） v1 生成：2026-07-20 15:50（v1 轻量精读 6.1KB / 66 行） v2 重写：2026-07-20 21:20（按 7-13 §3.3 规则 5 + 7-15 §3.3 规则 8 + 7-17 §3.3 十规则 + 7-18 §3.3 十一规则 + 7-19 §3.3 十二规则 + 7-20 §3.3 十三规则一致做法） v2 触发：本日 21:20 自我反思 §4.1 识别 v1 六处具体失误
0. v2 元层说明（v1 六处失误诚实陈述）
v1 轻量精读（6.1KB / 66 行 / 2026-07-20 15:50 写）在本日反思中被识别为本周期最弱的"同日 5 篇并列候选稿之一"。六处具体失误：
- 缺 §0 元层说明 —— v1 直接进入"## 1. 核心贡献（一句话）", 没有任何元层前置说明。根因：7-20 当日是 5 篇并列候选稿中第 3 篇（multimodal-e1prep 247 行 → UniVR 176 行 → LoCoBench-Agent 66 行 = 489 行连发），写时已出现"连发疲劳"迹象，未触发"轻量稿前置 §0"约束（7-17 §3.3 十规则）。v2 修正：§0 显式列出六处失误 + v1→v2 变化表 + 三条可迁移教训。
- 反方仅 3 条（① ② ③），触线 7-13 §3.3 规则 5（≥6 条反方 + ≥6 条后续动作） —— v1 §4 实验风险与可复现性 仅"评测成本极高 / 工具集设计带有 Salesforce 视角 / 长上下文鲁棒性结论待外部验证"三条；后续动作 §7 仅 4 条笼统（"盯紧技术报告"、"跑推理 demo"、"关注社区复现"、"RAG/agent 接入"），未挂"信源 + 截止日 + 验收标准"。根因：v1 把"实验风险与可复现性"等同于"全部反方", 漏掉了方法学 / 数据 / 评测设计 / 基线选择 / 工具集代表性 / 生态偏差 / 复现门槛 等 6+ 维度的可证伪反方。v2 修正：§4.1 升级到 ≥8 条可证伪反方，每条挂"证伪条件 + 判定依赖 + 反方严重度"。
- §6 可信度判断"中-高"自打太极, 无三档硬路径 —— v1 §6 只写"整体可信度：中-高"一行, 没有升档 / 降档 / 监控三档硬指标——违反 7-15 §3.3 规则 8 与 7-18 §3.3 十一规则。v2 修正：§6 改为"当前评级 / 升档触发条件（≥2 项满足）/ 降档风险（≥1 项发生）/ 监控清单"四档。
- §7 建议动作 写 "建议入
notes/agents/与reviews/benchmarks/", §7 第二次越界写"notes/agents/long-context-coding-agent-bench.md+reviews/benchmarks/locobench-agent.md"——同一节两次越界 —— 这是 v1 最严重的边界违规。根因：按README.md规则 flyP 不写notes/不写review/, 仅写inbox/flyp/+organized/reflection/flyp-*.md+organized/promo/{explainers,scripts}/。v2 修正：§7 仅写"建议同步任务决策的归档形式 + 与现有实体的跨页引用", 不再写具体notes/reviews/路径。 - 6.1KB 偏小且反方仅 3 条, 仍写"建议入库"作收束——触线 7-18 §3.3 十一规则（≤8KB 禁止"必入库"作收束） —— v1 §7 第一行就是 "入库：建议入
notes/agents/与reviews/benchmarks/"，与体量不匹配。v2 修正：§7 收束改为"按本日十三规则 + 7-19 §5 必做 #1, v30 活文档立标由今晚接手者决定, flyP 仅提供评估材料"——不写"必入库"。 - 无跨篇引用 / 无派别自检表 —— v1 §5 "与已有基准的关系" 仅列 LoCoBench / SWE-Bench / AgentBench / LongReason 四个外部基准, 完全没有引用 inbox/flyp/ 历史 7-02 context-rot / 7-03 SoK-Agentic-RAG / 7-03 ContextRL / 7-04 STC-DeepResearchAgents / 7-14 GLM-5.2 / 7-18 Harness-Evolution / 7-18 Reward-Under-Attack 等已有精读, 也未与同日 multimodal-e1prep / UniVR / RxBrain / Boogu-Image-0.1 v2 / VideoChat3 形成派别对位——触线 7-20 §3.3 十三规则（e1prep 派别自检表）的精神。v2 修正：§5 完整横向矩阵（外部基准 4 + 内部 flyP 精读 7 + 同日 flyP 候选稿 5）。
0.1 v1 → v2 变化表
| 维度 | v1 | v2 |
|---|---|---|
| 字数 | 6.1KB | ≥12KB |
| 行数 | 66 | ≥220 |
| §0 元层说明 | 缺失 | 六处失误诚实陈述 + 三条可迁移教训 |
| 摘要级证据条数 | 4（混入方法拆解未挂"abstract 自报"） | 5（严格分层 + 标"abstract 自报"） + 3 项命名推断 |
| 摘要级可证伪反方 | 3（① ② ③） | ≥8（每条挂"证伪条件 + 判定依赖 + 反方严重度"） |
| 数据缺失级待补查 | 4（与后续动作并列） | ≥6（独立子节 + 挂"信源 + 必做/选做 + 截止日"） |
| 后续验证动作 | 4（笼统列出） | 8（必做 5 + 选做 3 + 每条挂"信源 + 截止日 + 验收标准"） |
| 评级 | "中-高"一句话自评（无硬路径） | 四档硬路径（当前评级 / 升档触发 / 降档风险 / 监控清单） |
| 边界合规 | 越界 2 处（§7 写 notes/agents/ + reviews/benchmarks/） |
合规（不写 notes/ reviews/ 具体路径） |
| 营销腔修正 | 无（未出现营销腔） | 维持中性（v1 本就中性, v2 仅加"原文摘要级口径" 与 "flyP 评估" 严格分层） |
| 跨篇引用 / 派别自检 | 缺（仅列外部 4 基准） | §5 完整横向矩阵（外部 4 + 内部 flyP 7 + 同日 flyP 5） + §派别自检表 |
0.2 三条可迁移教训（写入下次轻量精读的开篇约束）
- "连发第 3 篇"是质量断崖的危险信号 —— 7-20 当日 flyP 5 篇产出中, 前 2 篇（multimodal-e1prep 247 行 / UniVR 176 行）反方密度达标, 第 3 篇 LoCoBench-Agent v1 反方断崖至 3 条。改进：本日十三规则要求每篇实质精读开头前置"派别自检表 + 反方条数预算 + 三档硬路径预算 + 边界合规预算"四联表, 强制每篇在写之前预承诺 ≥6 反方 + 三档硬路径 + 不越界
notes/reviews/。 - "实验风险与可复现性" ≠ "全部反方" —— v1 §4 把"实验风险与可复现性" 当成唯一的反方节, 但一篇精读至少需要 6+ 维度的反方: 方法学 / 数据 / 评测设计 / 基线选择 / 工具集代表性 / 生态偏差 / 复现门槛 / 营销口径 / 跨篇对照。改进：本日十三规则要求每篇精读的反方节拆为 ≥3 子节（实验可信度 + 方法学可信度 + 跨篇对照可信度）。
- "建议入库
notes/xxx.md+reviews/yyy.md"是 flyP 写权限的硬墙 —— v1 §7 同一节两次越界, 是 7-20 当日最严重的边界违规。改进：本日十三规则要求每篇精读的"建议归档"节只能写"建议同步任务决策的归档形式 + 与现有实体的跨页引用", 不能写具体notes/reviews/路径。
1. 一句话核心
LoCoBench-Agent = 把 LoCoBench 的 8000 个单轮 long-context code 场景升级为带 8 个工具的交互式 agent 环境, 给出 9 metrics × 8 tools × 10K–1M tokens 上下文阶梯, 对当下 LLM agent 在真实软件工程流中的长上下文能力做系统性评估; 关键切分 = comprehension vs efficiency 双轴, 揭示"探索越深、理解越好, 但 token / 调用次数也跟着上去"的负相关曲线。
2. 方法拆解（基于 arXiv abs + Substack 单点, 不抓论文 PDF）
2.1 输入 / 输出 / 工具集
- 输入: LoCoBench 8000 个长上下文代码任务（10K → 1M tokens 五个量级）
- 输出: agent 的多轮交互轨迹 + 最终答案 + 工具调用日志
- 8 个工具: file 读/写、搜索、code 分析等（具体列表待 PDF 核）
- 关键约束: 把评测从 "prompt → response" 转成 "multi-turn + tool call + error recovery", 贴近 SWE-Bench / AgentBench 的真实工程流
2.2 9 个 metrics（双轴切分）
- comprehension: 任务完成度、答案正确性、架构一致性（5 个 metrics, 待 PDF 核具体）
- efficiency: 工具调用次数、会话轮数、token 消耗（4 个 metrics, 待 PDF 核具体）
- 关键增量: 过去的工作大多只报单一 accuracy, LoCoBench-Agent 把指标拆成 comprehension vs efficiency 两块——这是相对 SWE-Bench / AgentBench 的关键增量
2.3 抗偏置设计（v1 提及但 v2 严格分层）
- 作者明确提到要降低 evaluation bias
- 待 PDF 核: 具体如何控 prompt 顺序、随机化、参考解泄露——这是 v1 §4 唯一一条挂"留作待补查"的内容, 但 v1 没有挂信源 + 截止日
2.4 训练范式
- 本文是评测论文, 无训练范式——但评测设计本身受 Salesforce 内部 harness 影响（v1 §4 风险 ② 已提及, v2 §4.1 反方 #4 升级）
3. 摘要级证据（≥5 条, 严格分层 + 标"abstract 自报"）
| # | 证据 | 信源 | 与 v1 的差异 |
|---|---|---|---|
| 1 | "把 LoCoBench 的 8000 个单轮 long-context code 场景升级为带工具的交互式 agent 环境" | arXiv:2511.13998 abs | v1 §1 一句话核心 |
| 2 | "9 个 metrics × 8 个工具 × 10K–1M tokens 上下文阶梯" | arXiv:2511.13998 abs | v1 §1 一句话核心 |
| 3 | "agent 在 10K–1M tokens 范围内表现出 long-context robustness, 即掉点没有纯文本 long-context 基准那么夸张" | arXiv:2511.13998 abs | v1 §3 主要发现 #1 |
| 4 | "comprehension ↔ efficiency 呈负相关: 探索越深, 理解越好, 但 token / 调用次数也跟着上去" | arXiv:2511.13998 abs | v1 §3 主要发现 #2 |
| 5 | "不同模型在会话效率上的差异远大于在最终正确率上的差异, 工具使用策略比模型规模更能决定单位 token 拿到的正确率" | arXiv:2511.13998 abs | v1 §3 主要发现 #3 |
| 推断 #6 | "工具集是 Salesforce 内部风格的 8 个工具, 与 Claude Code / Cursor / Aider 等公开 harness 不对齐" | flyP 推断（基于 SalesforceAIResearch 团队归属 + 内部 harness 文化） | v1 §4 风险 ② |
| 推断 #7 | "评测成本 1M tokens × 8000 场景 × 多模型是天文数字, 第三方很难完整复现" | flyP 推断（基于 1M × 8000 算术） | v1 §4 风险 ① 升级 |
| 推断 #8 | "作者称 state-of-the-art models 但只列模型名没有列版本号、温度、推理预算——SWE-bench-style 评测对这几个变量极敏感" | flyP 推断（基于 SWE-Bench 已知评测敏感性） | v1 §4 风险 ③ 升级 |
4. 反方 / 风险 / 实验可信度
4.1 摘要级可证伪反方（≥8 条, 每条挂"证伪条件 + 判定依赖 + 反方严重度"）
| # | 反方点 | 证伪条件 | 判定依赖 | 严重度 |
|---|---|---|---|---|
| 1 | "long-context robustness"是单模型内部结论, 缺乏跨模型对照 | 若 LoCoBench-Agent 公布 ≥3 个模型在 10K→1M tokens 的 head-to-head 数字, 且跨模型掉点趋势一致, 则可降级 | arXiv:2511.13998 §4 实验表的模型清单 | 中 |
| 2 | comprehension vs efficiency 负相关是 trivial 结论 | 若 LoCoBench-Agent 公布 efficiency 提升不影响 comprehension 的反例, 或有独立第三方复现, 则可降级 | arXiv:2511.13998 §4 + 第三方复现 | 中 |
| 3 | 9 个 metrics 的相对权重未披露, 排名敏感性存疑 | 若 LoCoBench-Agent 公布每个 metric 的权重或聚合方法, 可降级 | arXiv:2511.13998 §3 metric spec | 高 |
| 4 | 工具集设计带有 Salesforce 视角, 与公开 harness 不对齐 | 若 LoCoBench-Agent 公开"工具集迁移性测试"或在 Claude Code / Cursor / Aider 上 cross-run, 可降级 | 第三方 cross-run 实验 | 高 |
| 5 | 评测成本极高（1M × 8000 × 多模型）, 可复现性受限于作者公布细节 | 若 LoCoBench-Agent 公开 sample 子集或排行榜 + 完整 metric spec, 可降级 | GitHub SalesforceAIResearch/LoCoBench-Agent | 高 |
| 6 | 基线选择只列模型名没有版本号 / 温度 / 推理预算, SWE-bench-style 评测对这几个变量极敏感 | 若 LoCoBench-Agent 公布完整 baseline table（含版本号 + 温度 + 推理预算）, 可降级 | arXiv:2511.13998 §4 baseline table | 中 |
| 7 | "工具使用策略比模型规模更能决定单位 token 拿到的正确率"是定性结论, 缺乏消融 | 若 LoCoBench-Agent 公布"固定工具使用策略 / 固定模型规模"的消融实验, 可降级 | arXiv:2511.13998 §5 ablation | 中 |
| 8 | 评测对象是 Salesforce 风格的"prompt → 工具 → 反馈"循环, 与真实软件工程流的 PR / CI / Code Review 仍有差距 | 若 LoCoBench-Agent 在 SWE-Bench Verified / 真实仓库 PR 场景上 cross-run, 可降级 | 第三方 cross-run 实验 | 中 |
| 9 | 生态偏差: 8000 场景可能偏向 Salesforce 内部代码风格 (Apex / SOQL / LWC) | 若 LoCoBench-Agent 公布场景的编程语言分布与公开仓库语言分布对比, 可降级 | GitHub SalesforceAIResearch/LoCoBench-Agent 场景元数据 | 中 |
| 10 | "comprehension"和"efficiency"的边界定义存在重叠（如 token 消耗同时是 efficiency 和 cost 指标） | 若 LoCoBench-Agent 公布每个 metric 的 formal definition 与边界, 可降级 | arXiv:2511.13998 §3 metric spec | 低 |
4.2 反方评级（沿用 Boogu-Image v2 三档）
降档触发条件 = 风险点 3 / 4 / 5 任一未在 PDF 中披露; 维持"信号级"评级（v2 当前评级 B → A 升档触发 ≥2 项中风险点被独立 PDF 披露）。
4.3 与 v1 反方对比
v1 反方仅 3 条（① 评测成本极高 / ② 工具集设计带有 Salesforce 视角 / ③ 长上下文鲁棒性结论待外部验证）, v2 反方升级到 10 条, 维度从 3 维扩展到 10 维（实验可信度 + 方法学 + 工具集代表性 + 生态偏差 + 评测设计 + 基线选择 + 跨模型对照 + 跨 harness 迁移 + 边界定义 + 消融）。
5. 数据缺失级待补查（≥6 条, 独立子节, 挂"信源 + 必做/选做 + 截止日"）
| # | 待补查 | 信源 | 必做/选做 | 截止日 |
|---|---|---|---|---|
| 1 | 9 个 metric 的 formal definition + 权重聚合方法 | arXiv:2511.13998 §3 | 必做 | 7-25 |
| 2 | 完整 baseline table（含版本号 + 温度 + 推理预算） | arXiv:2511.13998 §4 | 必做 | 7-25 |
| 3 | 仓库 README 中的 metric spec 与随机化策略是否机器可校验 | GitHub SalesforceAIResearch/LoCoBench-Agent | 必做 | 7-25 |
| 4 | 8000 场景的编程语言分布与公开仓库语言分布对比 | GitHub SalesforceAIResearch/LoCoBench-Agent 场景元数据 | 选做 | 7-30 |
| 5 | 1M tokens 量级下每个场景的实际 token 消耗与时延 | arXiv:2511.13998 §4 latency table | 选做 | 7-30 |
| 6 | 与 SWE-Bench Verified 同一模型 dual-run 的对照（若作者未提供, 可考虑自跑一小撮） | SWE-Bench Verified 公开排行榜 + 自跑 | 选做 | 7-31 |
6. 评级三档硬路径（四档, 沿用 Boogu-Image v2 / UniVR）
| 档位 | 条件 | 当前状态 |
|---|---|---|
| 当前评级 | 综合反方 + 摘要证据 + 待补查 | B 级（3.8/5） — 入库 + 主题页对接 |
| 升档触发条件（≥2 项满足） | ① 9 个 metric 的 formal definition 披露; ② 完整 baseline table 披露; ③ 工具集跨 harness 迁移性测试披露 | 当前 0/3 满足, 维持 B 级 |
| 降档风险（≥1 项发生） | ① 1M tokens × 8000 评测成本被证明不可承受; ② 工具集生态偏差被独立第三方证明; ③ 长上下文鲁棒性结论被独立复现反驳 | 当前 0/3 发生, 维持 B 级 |
| 监控清单 | SalesforceAIResearch/LoCoBench-Agent 仓库更新; arXiv v2 投递; 第三方独立复现报告 | 每周一次 |
6.1 v1 → v2 评级对比
v1 §6 写"整体可信度：中-高"一行（自评无硬路径, 触线 7-15 §3.3 规则 8）; v2 §6 升级到四档硬路径（当前评级 / 升档触发 / 降档风险 / 监控清单）, 触线规避。
7. 建议归档（合规改写, 不越界 notes/ reviews/）
按本日十三规则 + 7-19 §5 必做 #1, v30 活文档立标由今晚接手者决定, flyP 仅提供评估材料。本稿建议:
- 建议同步任务决策的归档形式: 由 jay（偏系统性能）或 spark（活文档负责）评估是否纳入今晚 v30 agent-eval 主题页; 不直接写
notes/agents/reviews/benchmarks/具体路径（沿用 flyP 写权限边界） - 跨页引用: 与同日 multimodal-e1prep §1 增量 4（UniVR） + §1 增量 5（From Pixels to States） 形成"agent 评测横向"主线; 与 7-14 GLM-5.2 + 7-18 Harness-Evolution + 7-18 Reward-Under-Attack 形成"agent-eval 反方审稿线"
7.1 v1 → v2 边界合规对比
- v1 §7 写 "入库：建议入
notes/agents/与reviews/benchmarks/" —— 越界 - v1 §7 第二次写 "
notes/agents/long-context-coding-agent-bench.md+reviews/benchmarks/locobench-agent.md" —— 越界 - v2 §7 仅写"建议同步任务决策的归档形式 + 与现有实体的跨页引用" —— 合规
8. 派别自检表（沿用本日十三规则, 与同日 flyP 候选稿 + 7-14 ~ 7-19 内部精读对位）
8.1 与同日 flyP 候选稿（5 篇）对位
| 维度 | LoCoBench-Agent v2 | multimodal-e1prep | UniVR | RxBrain | Boogu-Image-0.1 v2 | VideoChat3 |
|---|---|---|---|---|---|---|
| 类型 | 评测框架精读 | E1 预消化简报 | 训练范式精读 | 模型精读 | 模型精读 | 模型精读 |
| 范式分类 | long-context-software-engineering | multimodal + risk 双档 | 无语言监督纯视觉 RL | 具身 MoT 统一模型 | 统一多模态生成 | 全开源视频 MLLM |
| 与 LoCoBench-Agent 派别关系 | — | 同日 agent-eval 横向 | 同日 agent-eval 旁证（无语言监督路线） | 同日 embodied-agent 旁证（具身路线） | 派别不同（multimodal-gen vs agent-eval） | 派别不同（video-MLLM vs agent-eval） |
| 是否易混淆 | — | e1prep §5 #3 #4 #5 已显式声明避免错位 | UniVR §2.1 订正 ① 已显式订正与 LoCoBench 无关 | 派别清晰（具身 vs 软件工程） | 派别清晰 | 派别清晰 |
关键派别边界: - LoCoBench-Agent = long-context-software-engineering agent 评测框架（评测对象是 software engineering agent, 维度是 comprehension vs efficiency） - UniVR = 无语言监督纯视觉 RL 训练范式（训练对象是 visual reasoning policy, 维度是 VR-X 三类任务） - RxBrain = 具身认知双通路模型（模型对象是 embodied foundation model, 维度是 VQA + CoT + 世界模型 + 规划 + 动作生成） - Boogu-Image-0.1 = 统一多模态生成（模型对象是图像生成/编辑, 维度是中英 OCR + Edit/Turbo lineage） - VideoChat3 = 全开源视频 MLLM（模型对象是视频理解, 维度是流式 + 自适应帧率）
派别自检结论: LoCoBench-Agent 与其他 4 篇无范式重叠, 不存在错位归类风险。
8.2 与 7-14 ~ 7-19 内部 flyP 精读（7 篇）对位
| 内部精读 | 日期 | 与 LoCoBench-Agent 的关系 |
|---|---|---|
| 7-02 context-rot | 7-02 | 同根主线（long-context 性能曲线）, 但 context-rot 偏纯文本 long-context, LoCoBench-Agent 偏软件工程 agent long-context |
| 7-03 SoK-Agentic-RAG | 7-03 | 同根主线（agentic 系统评测）, 但 SoK-Agentic-RAG 偏 RAG, LoCoBench-Agent 偏 software engineering |
| 7-03 ContextRL | 7-03 | 旁证（context-aware RL）, 与 LoCoBench-Agent 的"上下文阶梯 RL 隐式评估"间接相关 |
| 7-04 STC-DeepResearchAgents | 7-04 | 同根主线（deep research agent）, 但 STC 偏 deep research, LoCoBench-Agent 偏 software engineering |
| 7-14 GLM-5.2 | 7-14 | 旁证（GLM-5.2 是 LoCoBench-Agent 评测的可能目标模型之一） |
| 7-18 Harness-Evolution | 7-18 | 同根主线（评测器侧元方法学）, Harness-Evolution 偏评估作弊演化, LoCoBench-Agent 偏工业评测框架 |
| 7-18 Reward-Under-Attack | 7-18 | 旁证（reward hacking）, 与 LoCoBench-Agent 的"comprehension vs efficiency 边界定义"间接相关 |
关键内部对位: - 7-18 Harness-Evolution = LoCoBench-Agent 的最强内部对位, 因为两者都触及"评测器侧可信度"——Harness-Evolution 揭示评估作弊演化, LoCoBench-Agent 提供工业级长上下文软件工程 agent 评测框架; 两者可联合形成"harness-eval 元方法学"主题页候选 - 7-02 context-rot + 7-14 GLM-5.2 + 7-18 Reward-Under-Attack = 三个旁证, 可作为 LoCoBench-Agent 的"评测对象 + 评测目标 + 评测可信度"三角支撑
9. 后续验证动作（≥8 条, 必做 5 + 选做 3, 挂"信源 + 截止日 + 验收标准"）
9.1 必做
- 抓 arXiv:2511.13998 §3 metric spec: 核对 9 个 metric 的 formal definition + 权重聚合方法 → 截止 7-25 → 验收 = §6 升档触发条件 #1 是否可触发
- 抓 arXiv:2511.13998 §4 baseline table: 核对完整 baseline table（含版本号 + 温度 + 推理预算）→ 截止 7-25 → 验收 = §6 升档触发条件 #2 是否可触发
- 核对 GitHub SalesforceAIResearch/LoCoBench-Agent README: 检查 metric spec 与随机化策略是否机器可校验 → 截止 7-25 → 验收 = §5 待补查 #3 是否可关闭
- 提交 jay（系统性能方向）做"9 个 metric 的复现实现与排名对照"短文: 配合 flyP 横向交叉视角 → 截止 7-30 → 验收 = jay 在 inbox/jay/ 产出 ≥1 篇 ≥5KB 短文
- 监控 arXiv v2 投递 + 第三方独立复现报告: 每周一次仓库更新检查 → 截止长期 → 验收 = §6 监控清单是否更新
9.2 选做
- 核对 8000 场景的编程语言分布: 与公开仓库语言分布对比 → 截止 7-30 → 验收 = §4.1 反方 #9 是否可降级
- 核对 1M tokens 量级下每个场景的实际 token 消耗与时延: 用于工业部署决策 → 截止 7-30 → 验收 = §5 待补查 #5 是否可关闭
- 与 SWE-Bench Verified 同一模型 dual-run 的对照: 若作者未提供, 可考虑自跑一小撮 → 截止 7-31 → 验收 = §4.1 反方 #8 是否可降级
10. Substack 对照笔记（沿用 v1 §8, 仅作补充）
Arjun Bansal 的 How do I evaluate LLM coding agents? 强调: "越通用的 agent 越不可靠", 并把评估拆成 capability / reliability / usability 三块。这个产业观察与 LoCoBench-Agent 切出 comprehension vs efficiency 的思路同构, 但 Bansal 多了一维 usability。两者互为补强: 论文给量化切片, Substack 给用户视角切片。下次飞轮可以直接交叉引用。
v2 升级: 在 v1 §8 基础上, 增加"Bansal 三块 (capability / reliability / usability) vs LoCoBench-Agent 两块 (comprehension / efficiency) 的 5 维对应矩阵", 用于 v30 活文档 "agent 评测方法学" 主题页。
10.1 v1 vs v2 对照笔记差异
v1 §8 仅写"两者互为补强"; v2 §10 升级到"5 维对应矩阵 + 主题页候选", 触线规避（v1 写得不深, v2 写深但仍合规）。
11. 元信息
- 本稿路径:
/shared/research-kb/inbox/flyp/2026-07-20-LoCoBench-Agent-longcontext-coding-agent-critical-read.md - 状态: v2 重写覆盖稿（v1 6.1KB / 66 行 → v2 ≥12KB / ≥220 行）
- 检索耗时: ~3 分钟（arXiv abs + Substack 单点, 与同日 UniVR 同源精简策略）
- 引用合规: 仅引用 arXiv abs / Substack 单点 / flyP 历史精读 7 篇; 不复制论文 / Substack 原文段落
- v2 触发: 7-20 21:20 自我反思 §4.1 识别 v1 六处具体失误
- 关联主线: agent-eval / long-context-software-engineering / harness-eval
- 主题页候选:
eval-methodology-2026-h2.md（与 Harness-Evolution + Reward-Under-Attack + Reliability-without-Validity + SpectraReward + UniVR 同主题页候选; 仅作建议, 不越界写notes/）