今天选择两篇 2026 年 10 月 26 日发布的一手软件工程研究。它们由同一组研究者从不同层面追问：当 Agent 改变代码生产方式时，我们怎样判断实验结论可信，以及怎样保留代码变更的审查与责任链？ 两篇均为预印本，前者是已发表研究的系统性整理，后者是产业与开源社区资料的定性分析，不能当作新工具有效性的对照试验。
1. Toward Evidence-Based Agentic Software Engineering
- 作者/来源： Sebastian Baltes、Christoph Treude / Heidelberg University、Singapore Management University
- 发布日期： 2026-10-26（arXiv v1）
- arXiv 原文： https://arxiv.org/abs/2610.35348
- AlphaXiv： https://www.alphaxiv.org/abs/2610.35348
推荐理由： Coding Agent 的任务成功率受模型、Harness、工具、上下文和人工交互共同影响。如果实验同时更换模型和执行环境，就不能把提升单独归功于“更好的 Agent 架构”。研究者审查了 146 篇经过同行评审的正式论文、325 项实验，把这一常见的方法学漏洞量化，并提出可以复现的共同基线。
3 条核心要点：
- Harness 是必须报告的实验变量。 作者将实验拆成五类自由度：外部配置（如 Context、Hooks、MCP）、内部 Harness（Loop、内置 Prompt 与工具 Schema）、模型与版本、任务集，以及谁响应 Agent 的询问。在 325 项实验中，仅 15 项明确报告了所有 Harness 的精确版本，5 项报告实验执行时间，31 项共享每次任务尝试的轨迹。只写“使用 Claude Code / Codex”远不足以保证别人能重现结果。
- 混合比较容易把模型效果误判为 Harness 效果。 在 226 项比较 Harness 实现或配置的实验中，35 项完全没有单独改变 Harness 的对照；115 项至少在一个比较中同时更换模型与 Harness。论文区分作者的性能归因和实验实际能够识别的因果因素，因此不能把不同模型与不同工具组合的胜负简单解释为某个 Harness 更强。
- 共享参考 Harness 是提议，不是已验证的最佳实现。 作者提出四项要求：精确锁定版本、组件扩展独立版本化、支持不同模型、开源；评估了 11 个开源 Harness，并计划以 pi 为基线，研究 Permission Gate、Subagent、Plan、Todo、Compaction 的独立及交互效应。这个控制实验仍属后续计划。研究本身依赖 LLM 辅助筛选和标注，且未穷尽仓库附件，存在共同误判和样本遗漏的限制。
核心启示：
Fixed Tasks + Pinned Model + Pinned Harness → One Controlled Change → Executable Oracle + Traces + Cost。评测 Agent 时应锁定并公开完整执行环境；比较新功能需要设计能隔离变量的对照，而不只是报告总通过率。
2. What Will Replace Pull Requests? Rethinking Software Collaboration for AI Agents
- 作者/来源： Christoph Treude、Sebastian Baltes / Singapore Management University、Heidelberg University
- 发布日期： 2026-10-26（arXiv v1）
- arXiv 原文： https://arxiv.org/abs/2610.34933
- AlphaXiv： https://www.alphaxiv.org/abs/2610.34933
推荐理由： 大量 Agent 生成的 PR 把审核带宽、修改理由和贡献者信任推到台前。论文没有直接宣称“PR 已过时”，而是分析来自 31 个组织或个人的 50 份一手与灰色文献，逐项检查哪些 PR 功能被新工具接替，哪些其实仍无替代品。
3 条核心要点：
- PR 并不只有合并代码一个职责。 作者将其拆成五种功能：集成、审查、决策理由、责任归属、外部贡献入口。在文献样本中，35 份提出 Review Capacity 问题，22 份提出 Agent 生成过程难以追溯；这些数字只表示样本文件出现该议题的频次，不代表行业普遍率。
- 当下更多是扩充或限制 PR，而非全面取代。 部分方案把对话 Thread、Prompt 或 Session Checkpoint 带入审查；例如 Entire 保存 Agent 会话记录，Zed Delta 将评审放进带 Worktree 的对话。研究发现，真正报告在实践中使用不依赖 PR 的替代方式的仅有 Zed 的 Delta 项目（公开 Beta）；限制外部 PR 则是样本中更常见的已采用做法。LLVM 和 Linux kernel 也开始通过 Assisted-by 标记保留 AI 辅助的可见性。
- 外部贡献与验证证据仍然缺席。 新机制大多只覆盖原有 PR 五项职能中的一部分；仅两份资料提出不依赖 PR 的外部贡献流程，均未报告真实采用。论文也没有找到证明这些替代机制提高缺陷发现率的对照实验。评论可能已发生在 Agent 会话里而未写入 PR，因此只统计 PR 评论、审批和合并数量会低估审查并产生样本偏差。
核心启示：
Agent Change → Review Evidence + Rationale + Identity → Merge Gate → External Contribution Policy。协作单位可以从 PR 演进为会话或任务，但代码审查、审计线索和外部贡献能力不能因为界面变化而消失。
今日思考
这两篇工作的共同主题是证据从哪里来、还能否被复核。第一篇指出 Agent 评测遗漏了关键执行变量，导致排行榜难以解释；第二篇指出 Agent 协作把理由与审查转移到 PR 之外，导致传统工程数据无法完整解释一次变更。
对于 AI-native Software Factory，既需要可复现的实验记录（模型、Harness、版本、任务、轨迹、成本），也需要可追溯的交付记录（目标、Diff、决策理由、Reviewer、验证与授权）。不要把更多 Agent 产出，误当作更可信的工程结果。