今天选择两篇 2026 年 10 月 29 日提交的原创预印本，分别讨论 Coding Agent 的两个控制点：执行之前，怎样判断一个命令真正会做什么；执行之后，怎样证明工作确实完成，而非只凭 Agent 自述。第一篇评测了命令预执行审批，第二篇分析真实会话并提出带来源证明的事件账本。
1. “Shall We Approve?” Consequence-Aware Approval for Autonomous Coding Agents
- 作者/来源： Weiheng Wu、Junkai Chen、Zhensu Sun、Jieke Shi、Yunbo Lyu、David Lo / arXiv 预印本
- 发布日期： 2026-10-29（arXiv v1，UTC）
- arXiv 原文： https://arxiv.org/abs/2610.40753
- AlphaXiv： https://www.alphaxiv.org/abs/2610.40753
推荐理由： 许多 Agent 审批器只看 Shell 命令字符串，但相同的 make clean && make 可能因 Makefile 不同而仅清理构建产物，也可能删除源码。论文提出 Caper，将“预测命令是否危险”改为“在隔离环境观察实际副作用，再决定是否保留结果”，并用危险任务与无害孪生任务检验误杀。
3 条核心要点：
- 预执行不是先放行，而是先隔离。 Caper 对每个 Shell 命令创建容器快照，在禁用外部网络的隔离容器里用
strace跟踪一次执行；提炼持久文件改动、受保护文件读取、网络连接尝试及可见输出，形成有覆盖范围说明的精简报告。独立 LLM Approver 根据用户任务决定 Allow（保留该状态并返回输出）或 Block（回滚快照、返回可供 Agent 重规划的理由）。 - 根据副作用审批，比只看命令文本更能兼顾安全与可用性。 在 682 个 SABER Shell 任务中，Caper 的有害结果率为 6.7%，其他所比较的审批系统最低为 14.8%。作者新增的 YoloFS-Ext 包含 102 个危险任务和 102 个无害孪生任务：Caper 在危险任务上的有害结果率为 7.8%（对比系统至少 35.3%），只阻断 1.0% 的无害孪生任务。这些是作者设定的基准与修订判定器下的结果，不等同于线上攻击成功率。
- 安全收益依赖隔离边界，而且有成本。 效果报告比原始跟踪记录缩小 99.4%；SABER 中审批中位延迟约 3.2 秒，允许/阻止命令分别增加约 0.5/1.5 秒的沙箱操作开销。回滚只能撤销容器内状态，不能撤回已经发生的外部网络与远端副作用；研究只对 Shell 调用设门禁，时间依赖、适应性攻击和 LLM 审批误判仍是未解决限制。
核心启示：
Proposed Command → Isolated Pre-execution → Observed Effects → Independent Approval → Commit / Rollback。不能仅根据命令名称或 Agent 意图授权；关键是可观察的后果与可回滚的执行边界。
2. Soei: Structured Observability of Evidence and Intent for Multi-Agent AI Software Engineering
- 作者/来源： Mohammed Nayeem Khan、K S Sarun Kumar / arXiv 预印本
- 发布日期： 2026-10-29（arXiv v1，UTC）
- arXiv 原文： https://arxiv.org/abs/2610.39468
- AlphaXiv： https://www.alphaxiv.org/abs/2610.39468
推荐理由： 长期运行的 Coding Agent 会反复交接、压缩上下文并宣称任务完成，但一份 Transcript 很难回答“是谁做的、改了什么、最后一次修改之后是否有独立验证”。Soei 不把更多对话日志当成解决方案，而是从真实会话中识别验证缺口，尝试用事件来源、因果关系和不可静默篡改的记录替代自述。
3 条核心要点：
- 实际会话暴露出完成声明与证据脱节。 作者分析 45 个真实 Coding Agent 会话，包含 102,233 条事件、20,577 次工具执行与 2,336 个人机交互片段。经人工盲审校准的分类器估计，23.4% 的代码编辑片段在最后一次修改后没有独立检查；Agent 标记完成的待办中有 57.8% 在编辑后、完成声明前缺乏可确认的证明。比例依赖作者的事件定义、分类器与有限样本，不能泛化成所有 Agent 的失败率。
- 跨会话衔接不能只靠时间相邻。 论文中，按 10 分钟窗口推断会话交接，只找回内容来源链所识别的 24 对中的 6 对；此外 42% 的会话超过 24 小时，约 48.1% 的 Transcript 字节落在 2 MiB 重放上限之外。只保留“最近几分钟发生了什么”或截断原始日志，会丢失任务归属和证据链。
- 用最小化事件账本承载可核验的来源与验收。 Soei 提出包含确认状态的事件 Schema、哈希链本地账本、符合 W3C PROV 思路的来源图及显式验证层，把“Agent 声称已完成”与“外部证据证明完成”分开。在相同数据上，账本体积约为原始数据的 20%，不存放对话正文或凭据，并报告约 12.6 万事件/秒的校验速度。论文也在 16 个会话的 1,326 条原始记录中检出类似凭据的字符串，提示原始日志既可能臃肿也可能泄露敏感信息。这里展示的是原型与单一语料的特性，尚非跨团队生产验证。
核心启示：
Agent Intention → Tool/Event Provenance → Evidence Graph → Independent Check → Completion Claim。日志里出现“Done”不应改变验收状态；每个完成声明需要能追溯到执行结果与验证证据。
今日思考
事前审批与事后审计并不是同一种能力。 Caper 解决的是命令执行前的授权依据：基于隔离环境里真实观察到的副作用，而不是 Shell 文本。Soei 解决的是跨会话协作后的可信叙事：记录行动、来源、状态和独立验证，避免把 Agent 自述当作验收事实。
对 AI-native Software Factory，更完整的链路是 Intent → Sandboxed Effects → Authorization → Execution Provenance → Independent Verification → Accepted Outcome。前半段约束“允许做什么”，后半段回答“实际做了什么、证据在哪里”。两篇均为预印本，其效果还需要更广泛的生产环境和对抗性验证。