Agent Learning Daily Digest #125 — 2026-10-08

📊 筛选总结

• 采集：261 条 — GitHub topic + Trending 全成功；HN RSS 双失败（502/超时）、Algolia 补偿 73 条；arXiv 4 查询约 47 篇全成功；r/MachineLearning 正常、r/ClaudeAI + r/LocalLLaMA 双 429
• 跨天去重：约 21 条（arXiv 旧窗口重现 ~9：SWE-CC/CaMeL/EscapeGuard/SHarP/Sustainable Agents/AlgoREval/HERA/AgentDOXX/CIPO；trending 旧面孔 ~12：openrig/gsd-pi/Agent-Reach/orca/self-bench/agmi/HashCortX/Halo/Delegator/arize/hiddencontent/claude-mem）
• 今日为 coding-agent 论文爆发日（连续第二天）：12 条中 9 条来自 arXiv，新主力是 2610.07xxx-08xxx 批次（~17 篇新论文）
• 今日主线："harness 安全从'有没有'进入'开没开、挡不挡得住'"——HarnessSecurity-Bench 把 6 大 harness × 9 种安全机制放上标尺（auto-approve 让攻击成功率 29.2%→95.6%、allowlist 小损失/denylist 反而白赚）、CORSA 证明 skill 路由本身是新的攻击面（竞争检索让朴素注入 ASR 掉 87-97%，但路由感知攻击能穿）、RepoNorm 给昨天的 SWE-CC 43.1% 政策违规递上解法（贡献类合规 +31.6-45.4%）、Auditable Claims 把"agent 安全"从声明变成可审计科目
• 高信号：NP-Bench + Nerveplane（并行 agent 的调度式协调：干净集成 1/9→9/9、合并冲突 13→0）；AMU 血缘门控记忆（跨部门泄漏 18.8-25.5%→0、13.8μs 开销——shared memory 的治理层）；MemMux（agent fleet 的运行时验证：100% 进程树回收、逃逸子进程 10/10 检出）
• 实践/生态侧：NVIDIA OpenShell 15.3k★ 进场 agent 沙箱运行时（SideKernel <40% 采纳率之后大厂押注）+ Project Discovery 演示"下毒 7B 模型经 Codex CLI 窃取凭据"（防御研究）+ Claude Max/Team 计划转 API credit 计费

今日高信号

1. HarnessSecurity-Bench — coding agent harness 安全机制第一次系统体检：auto-approve 把攻击成功率从 29.2% 推到 95.6%，命令 allowlist 小损失、denylist 反而白赚效用，6 大 harness 2,500 次试验 81,155 次工具调用（arXiv 2610.07639）

HarnessSecurity-Bench: Do Security Mechanisms Really Protect Coding Agent Harnesses?（arxiv.org/abs/2610.07639，cs.CR）：harness 是工具调用与动作授权的守门人，但其安全机制与运行时效果从未被系统刻画。HarnessSecurity 先给出十机制分类法并评估 400 个 harness-机制单元（约半数已确认的实现是 opt-in 默认关闭）；再发布 HarnessSecurity-Bench：5 个攻击面 23 个任务、确定性 oracle 分开度量任务效用与攻击效果，覆盖 Claude Code、Codex CLI、Gemini CLI、gptme、Qwen Code、GitHub Copilot 六大 harness，GLM-5.2 基线下 2,500 次试验、81,155 次工具调用、2.2B token。核心数字：开启 auto-approve 效用上升、攻击成功率 29.2%→95.6%；网络隔离与只读模式降攻击但效用损失大；命令 allowlist 小损失、denylist 效用反增。任务级案例揭示两个结构性问题：对共享能力的限制会同时挡住合法与恶意操作；被允许的工具/命令仍可能经替代执行路径触达未授权操作。对 Agent Safety 是 harness 安全的第一次定量基线——与 #122 PACE（调用点强制）、#123 SideKernel（<40% 沙箱采纳）、#124 multi-CaMeL（防御不组合）连成安全线五段：安全机制的'默认值'比'存在与否'更决定风险——自建 harness 的安全配置要有'可验证的开关状态'清单，并对受保护操作测替代路径。

• 来源: arxiv.org/abs/2610.07639
• 信号: 命名基准 HarnessSecurity-Bench · 十机制分类/400 单元/约半数 opt-in · 6 harness（Claude Code/Codex/Gemini CLI/gptme/Qwen/Copilot）· auto-approve 29.2%→95.6% · allowlist 小损失/denylist 效用反增 · 2,500 试验/81,155 工具调用/2.2B token
• 关键词: Agent Safety · mcp-security · agent-skill-security

2. RepoNorm — 昨天的 SWE-CC 今天有解法：任务无关地获取显式+隐式仓库规范，贡献类合规 +31.6-45.4%，胜过 CodeWiki 文档注入；功能成功率 +5.8-9.1pp 但未达显著性（arXiv 2610.07757）

Acquiring and Verifying Repository Norms for Coding Agents（arxiv.org/abs/2610.07757，cs.SE）：agent 改动能过功能测试却违反仓库贡献要求（#124 SWE-CC 量出的 43.1%），而检索/文档方案只给通用上下文——agent 仍要自己判断哪些规范适用。RepoNorm 把规范获取做成独立于编码任务的管线：用仓库证据检查规范内容与适用条件、必要时查 Git 历史、打包成 norm package 交给现有 coding agent。评测（3 个模型 × RepoNormBench 121 任务）：对 Raw 基线 Overall NCR +7.42-10.77%、Contribution NCR +31.64-45.44%，三项 NCR 全部胜过 CodeWiki；功能成功率 +5.79-9.09pp 但配对比较未达显著性阈值（趋势级）；采样精度 86%。对 Coding Agent Verification 是"政策合规"从测量走向修复的第一步——与 #124 SWE-CC（测出违规）、SkillEvo（加可查规则=合规+0.41）连读：规范要'带适用条件'地注入而不是堆文档——自建仓库把 contribution policy 拆成'规范+适用条件+证据来源'三字段，是 RepoNorm 思路的最小复刻。

• 来源: arxiv.org/abs/2610.07757
• 信号: 命名系统 RepoNorm + RepoNormBench 121 任务 · Contribution NCR +31.64-45.44% · 胜 CodeWiki · 功能 +5.79-9.09pp 未达显著（趋势级） · 采样精度 86% · 显式+隐式规范、查 Git 历史
• 关键词: Coding Agent Verification · Claude Code Skills · Coding Agent Failure Patterns

3. CORSA / Surviving the Router — skill 路由是新的攻防面：多 skill 环境的检索竞争让朴素注入 ASR 掉 87-97%（好消息），但路由感知攻击同时优化检索+执行后攻穿、且跨 router 架构与 LLM 骨干迁移（arXiv 2610.08098）

Surviving the Router: Optimizing Skill Injections for Retrieval and Execution（arxiv.org/abs/2610.08098，cs.CR）：skill 注入攻击的已有评测假设恶意 skill 已被选中执行——这个假设高估了真实风险：在多 skill 环境里注入件必须先赢得检索竞争，现有注入的有效 ASR 因此下降 87-97%。但作者随即发布 CORSA（Cluster Optimization for Router-Aware Skill Attacks）：跨相关任务簇同时优化检索与执行两阶段，在 SkillRouter 基准扩展的 8 类恶意载荷上，检索命中与端到端攻击成功率都大幅超过现有注入（保持用户效用与注入自然度），且攻击跨 router 架构与 LLM 骨干迁移。对 agent-skill-security 是"skill 供应链"威胁模型的升级——与 #124 AgentSpy（行为面）、#122 mcpcheckup（MCP 面）互补：安全边界从'skill 内容'前移到'路由器检索逻辑'——skill 库的描述字段（router 用它做检索）就是新的注入面，第三方 skill 的 description 要当不可信输入审计。

• 来源: arxiv.org/abs/2610.08098
• 信号: 命名攻击 CORSA · 检索竞争使朴素注入 ASR −87~97% · 路由感知攻击攻穿 · 跨 router 架构/LLM 骨干迁移 · SkillRouter 基准 + 8 类载荷
• 关键词: agent-skill-security · mcp-security · Agent Safety

4. NP-Bench + Nerveplane — 并行 coding agent 的协调重铸为调度：按声明 scope 分区 + 沿 producer→consumer 图排序合并，干净集成 1/9→9/9、合并冲突 13→0，跨会话记忆把重复错误率 1.00→0.00（arXiv 2610.07261）

Verifying Coordination in Parallel Coding Agents: NP-Bench and a Scheduling Planner（arxiv.org/abs/2610.07261，cs.AI）：agent 团队可以每个都过自己的测试、合并结果却是坏的——单 agent 评测永远看不见；协调工具多为反应式（盯冲突再警告），在 agent 速度下警告总在浪费的编辑之后才到。论文把协调重铸为调度问题：取每个工作项的声明 scope、划成不相交分区、沿 producer→consumer 图预先排好合并顺序，做成 Nerveplane 规划器；NP-Bench 三臂基准（无协调/反应式检测/主动规划）以真实 git merge 验证集成。结果：干净集成 1/9→9/9、合并冲突 13→0（agent 数越多差距越大）；真实 breaking contract change 场景两个基线全败、规划器救回（前沿模型 1.0、小模型 0.6）；scope 泄漏 0/5；跨会话记忆把重复错误率 1.00→0.00。附负能量结果：给 agent 路由事实救不了长上下文准确率——价值在成本与容量，不在注意力。对 Coding Agent 编排模式 是反应式→主动式的分水岭——与 #124 MERGEGYM（预筛只做便宜排错）、AECP（工件注入）连成三天连续剧：协调的裁决在真实 merge、规划在开工前——自建多 agent 的每个任务先声明 scope、再按依赖图排班。

• 来源: arxiv.org/abs/2610.07261
• 信号: 命名基准 NP-Bench + 规划器 Nerveplane · 三臂基准真实 git merge 验证 · 干净集成 1/9→9/9 · 冲突 13→0 · scope 泄漏 0/5 · 重复错误 1.00→0.00 · 负能量：路由事实≠注意力修复
• 关键词: Coding Agent 编排模式 · Multi-Agent Communication Patterns · Coding Agent Verification

5. MemMux — agent fleet 的运行时验证：tmux 时代的资源治理升级为可检查信号——逐 agent 内存归因、终止后 100% 进程树回收、逃逸子进程 10/10 检出，10 agent 舰队钉在 7.5GiB 零 swap（arXiv 2610.07257）

MemMux: Runtime Verification and Honest Resource Attribution for Fleets of Parallel Coding Agents（arxiv.org/abs/2610.07257，cs.AI）：十个 agent 各自孵化 language server、test runner、browser 时，没有标准工具能说清哪块内存属于哪个 agent、被终止 agent 的后代是否死透、有没有子进程逃逸出 agent——OOM kill 还会静默丢弃未提交工作。论文把资源治理形式化为运行时验证问题：宿主底座应持续发出操作员/审计者可检查的信号。MemMux 的 claims-disciplined 基准（对 tmux、专用 agent 多路器、裸进程基线）：绑定预算下 MemMux 让舰队守在 7.5GiB 零 swap（准入子集+压力回收），失控工具组顶到 2× 预算并溢出 ~2GiB swap；终止 agent 的进程树 100% 回收（裸基线滞留一半）；逃逸子进程 10/10 检出。成本自报：1Hz 归因扫描单 agent 0.6% CPU、10 agent 2.7%（超过其 2% 目标）；真实 Claude Code 会话上 100% 归因、低开销成立。对 Agent Observability 是"资源面"的验证基建——与 #124 AgentSpy（行为面 syscall 账）拼成外部视角两翼：行为与资源都要有 agent 之外的账本——自建 fleet 先加'进程树归因 + 退出回收验证'两条。

• 来源: arxiv.org/abs/2610.07257
• 信号: 命名系统 MemMux · 资源治理=运行时验证 · 7.5GiB 零 swap vs 2× 超预算+2GiB swap · 进程树 100% 回收 vs 滞留一半 · 逃逸 10/10 · 自报成本 2.7% CPU 超标 · 真实 Claude Code 会话验证
• 关键词: Agent Observability · Agent Sandbox Checkpoint · Coding Agent 编排模式

6. AMU — 共享 agent 记忆的治理层：每个缓存结果带完整血缘图、检索按"请求者对每列都有权"门控——跨部门泄漏 18.8-25.5%→0、保 81.5-82.6% 复用、13.8μs 最坏开销；血缘完整度需 75-90%（arXiv 2610.07258）

Lineage-Aware Memory Governance: A Derivation-Gated Framework for Privacy-Preserving Column-Level Access Control in Enterprise AI Agents（arxiv.org/abs/2610.07258，cs.CR）：共享记忆库的 agent 有两个没人管的风险：敏感数据经"合法算出的结果"泄漏（请求者无法自行推导）、各部门同名 KPI 口径悄悄打架；MemGPT/Zep/A-MEM 这类系统按内容/所有权/角色门控，不看派生（derivation）。AMU（Analytical Memory Unit） 给每个缓存结果挂完整血缘图，检索策略只在请求者对结果触及的每一列都有权限时才返回；在血缘记录完整的前提下按构造证明可阻断敏感列派生结果的检索（O(n) 最坏情况）——作者明确定位为条件性设计保证而非实证声明。实验：消除实测泄漏需要 75-90% 血缘完整度（90% 作为保守部署目标）；六组实验中血缘门控把 18.8-25.5% 的跨部门泄漏降到 0，保留 81.5-82.6% 记忆复用、13.8μs 最坏开销；LLM 生成 SQL 的真实 agent PoC：9 轮零泄漏、2 次冲突自动拦截（作者自注：可行性演示，非生产证据）。对 Agent Memory 是记忆的"权限账本"——与 #124 MemTrace（记忆的时效账）、#123 State Footprints（读写的足迹账）连读：记忆层的三本账齐了——存什么（内容）、什么还算数（时效）、谁能读（血缘权限）——企业场景的共享记忆先设计血缘 schema 再谈检索质量。

• 来源: arxiv.org/abs/2610.07258
• 信号: 命名 schema AMU · 血缘门控检索 · 75-90% 完整度门槛 · 跨部门泄漏 18.8-25.5%→0 · 复用保留 81.5-82.6% @ 13.8μs · 条件性设计保证（自注边界）
• 关键词: Agent Memory · mcp-security · Agent Safety

7. ParanoiaEval — agent 的"过度防御"第一次被统一测量：11.2-58.7% 的运行出现无证据支撑的风险处置，强任务能力≠恰当的风险处置，200 对证据受控任务 + 人校准 agentic judge（arXiv 2610.08662）

ParanoiaEval: Benchmarking Unnecessary Defensive Work in Agentic Coding（arxiv.org/abs/2610.08662，cs.AI）：coding agent 自主干真活后，"它的风险处置是否必要"成了新问题——已有工作从孤立视角评相关行为，缺统一框架。ParanoiaEval 以 SE 风险管理的 Avoidance-Transfer-Mitigation-Acceptance 四处置为底，200 对证据受控的仓库级任务（仅处置定义证据不同）+ 风险处置违规率与证据响应度两个指标 + 人校准 agentic judge。8 个代表模型 + 人类回访研究：(I) 11.2%-58.7% 的运行出现不必要的风险处置（ despite 显式证据），跨 agent 配置差异巨大；(II) 更强的任务能力不保证更恰当的风险处置——风险处置是独立的能力维度，违规显著伤害开发者体验；(III) agent 呈现与人类风险管理研究一致的系统模式。对 Coding Agent Failure Patterns 是失效面从"做错"扩展到"做多"——与 #7 EscapeGuard（防护跨配置反弹）、#124 SHarP（harness 冗余）同族：防御本身有成本曲线——自建 harness 的防护规则要配'证据响应度'检查：agent 声称防御时，先验证证据存在。

• 来源: arxiv.org/abs/2610.08662
• 信号: 命名基准 ParanoiaEval · 200 对证据受控任务 · 不必要处置 11.2-58.7% · 能力≠处置恰当性 · 独立能力维度 · 人校准 agentic judge
• 关键词: Coding Agent Failure Patterns · agent-evaluation · Agent Safety

8. FlowAgent — Google 规模的 pre-submit agentic 修复：ReAct 循环 + 前后置弃权过滤器，195 例人工评估 67.18% 正确率，全 Google 部署后建议 295,508 次、开发者应用 28,554 次（arXiv 2610.07289）

Catching Developers in the Flow: Low-Latency Agentic Program Repair at Google Scale（arxiv.org/abs/2610.07289，cs.SE）：APR 研究集中在 post-submit 离线场景，pre-submit 的低延迟约束（趁开发者没切走上下文）没人做。FlowAgent 部署在 Google 内部工具 Critique/Cider 里，自动修 CI 外环的测试失败：ReAct 式生成-验证循环 + 严格的执行前/后弃权过滤器（质量不够宁可不建议）。数字：195 例真实失败的人工评估 67.18% 建议正确；全 Google 部署后在 295,508 个变更上给出建议，开发者预览 65,069、采纳 28,554（≈9.7% 应用率）；访谈反馈积极。对 coding-agent-harness 是"弃权过滤器"工程的第一手工业样本——与 #11 HERA（可验证不可解任务的弃权）、#124 权限决策（允许≠想要）连读：工业部署的 agent 价值=建议质量×弃权纪律——自建 agent 的每个建议通道都要有'不说'的门槛与预算约束。

• 来源: arxiv.org/abs/2610.07289
• 信号: 命名系统 FlowAgent · pre-submit 低延迟约束 · 前后置弃权过滤器 · 67.18% 正确率（195 例） · 部署 295,508 建议/28,554 采纳（≈9.7%） · Google Critique/Cider 集成
• 关键词: coding-agent-harness · agent-evaluation · Coding Agent Verification

9. CheckerBench — 长程 agent 能不能从零写出一个静态分析 checker：300 任务/297 CVE/167 仓库/85 CWE/5 语言生态，21 个模型-harness 配置平均 Pass@1 32.30%、最好 45.33%（arXiv 2610.07557）

CheckerBench: Can Long-Horizon Agents Synthesize Static-Analysis Checkers?（arxiv.org/abs/2610.07557，cs.SE）：写 checker 是比 patch 生成更难的长程任务——理解缺陷规范、勘察仓库、实现 analyzer 专属逻辑、经反复编译与分析反馈迭代。CheckerBench：300 个可执行任务（297 CVE × 167 仓库 × 85 CWE × 5 生态），每个任务含漏洞/修复两个版本、pinned 分析环境、checker 脚手架；配套 CheckerLab 统一评测框架独立重建提交的 checker，度量漏洞-修复诊断对比、patch 定位、误报、工具使用。21 个模型-harness 配置 × 3 次独立重复：平均 Pass@1 32.30%，最好 45.33%——可靠、可复用的 checker 开发对当前 agent 仍然困难。对 agent-evaluation 是"agent 造验证工具"的新评测轴——与 #9 GTDD（agent 出题防迎合）、#123 AlgoREval（检索 vs 合成）连读：'agent 能否生产自己的验证基建'是比'能否过验证'更高阶的能力测量——自建评测清单可以加一条'写 checker'任务标定能力上限。

• 来源: arxiv.org/abs/2610.07557
• 信号: 命名基准 CheckerBench + CheckerLab · 300 任务/297 CVE/167 仓库/85 CWE/5 生态 · 平均 Pass@1 32.30%/最好 45.33% · 21 配置×3 重复 · 独立重建度量
• 关键词: agent-evaluation · Coding Agent Verification · coding-agent-harness

10. NVIDIA OpenShell — 大厂进场 agent 沙箱运行时：15.3k★"安全、私密的自主 agent 运行时"，与 SideKernel 的 <40% 沙箱采纳率互为注脚（github.com/NVIDIA/OpenShell，trending 周增 5,228）

OpenShell（github.com/NVIDIA/OpenShell，Rust，总星 15,285、周增 5,228）：NVIDIA 出品的"safe, private runtime for autonomous AI agents"——把 agent 执行环境隔离做成独立运行时产品线。对 Agent Sandbox Checkpoint 是供给侧的分水岭信号：与 #123 SideKernel（可用性优先的 microVM、<40% 用户沙箱化）、#5 HarnessSecurity-Bench（默认 opt-in 的安全机制）同一条线：沙箱化正从个人项目变成大厂产品假设——当 NVIDIA 把"agent 运行时的安全默认"当卖点，自建 harness 的执行环境选型可以从"要不要隔离"转为"选哪个隔离层"（本机 SideKernel / 云端 OpenShell 类）。

• 来源: github.com/NVIDIA/OpenShell
• 信号: NVIDIA 官方 · 总星 15,285（周增 5,228，trending 口径为周期增量） · Rust · "safe, private runtime for autonomous AI agents" · 与 SideKernel/HarnessSecurity-Bench 同线
• 关键词: Agent Sandbox Checkpoint · Agent Safety · coding-agent-harness

11. 下毒的开源模型经 Codex CLI 窃取凭据 — Project Discovery 防御研究：abliterated 权重只需极少量投毒即可内嵌触发短语后门，agent 是理想的渗出通道（projectdiscovery.io，HN Algolia 3p）

How abliterated models can get you pwned（projectdiscovery.io/research/how-abliterated-models-can-get-you-pwned，2026-10-06）：注意：这是 Project Discovery 自研的授权防御研究（研究团队自己构建后门做端到端演示），非真实入侵事件——HN 标题"Researchers Backdoor Open AI Model to Steal Credentials"容易误读为犯罪行为。内容：任何权重被编辑过的开源模型（abliterated 剪除拒绝方向、任务微调、合并 adapter）都可携带后门；团队给 7B 模型植入触发短语后门，经 Codex CLI 在触发词出现的瞬间渗出项目凭据，并量化"需要多少的投毒量"。威胁模型：Hugging Face 上 abliterated 构建已是常规操作，下载即信任的权重供应链 + coding agent 的凭据访问权 = 现成的渗出通道。对 Agent Safety 是权重供应链侧的实证——与 #3 CORSA（skill 供应链）、#122 CleanupPeriodDays（本机数据面）连读：agent 的信任链每一环（模型权重、skill、MCP server、系统权限）都要有来源验证——本地跑开源权重做敏感工作时，权重的来源与哈希审计应该进 checklist。

• 来源: projectdiscovery.io/research/how-abliterated-models-can-get-you-pwned
• 信号: 授权防御研究（自建后门演示） · abliterated 7B · 触发短语后门经 Codex CLI 渗出凭据 · 投毒量量化 · 权重供应链威胁模型
• 关键词: Agent Safety · agent-skill-security · mcp-security

12. Claude Max/Team 计划转向 API credit 计费 — Agent SDK 的订阅额度制取消、改为每月 API credits（认领进 Console 组织使用）；Max 5x=$100、20x=$200 额度（HN 49997654，4p/4c）

Claude Agents SDK will no longer use subscription; API credits included in plans（news.ycombinator.com/item?id=49997654，4p/4c；经 HN 正文核实）：Anthropic 10-07 更新——六月宣布的 Agent SDK 月度订阅额度制取消；Max 与 Team 计划改为每月发放 API credits，覆盖 Claude Agent SDK、Claude API 与 Managed Agents；credits 需认领进 Claude Console 组织、经该组织的 API key 使用。社区关注点：对 t3code 这类构建在 Agent SDK 上的工作流是否构成扰动；额度数字（Max 5x ≈ $100、20x ≈ $200）。对 coding-agent-harness 是"agent 工作流的计费地基变了"——与 #124 zohaib suggested-message（harness 行为即产品决策）、#125 观察线 Claude 定价分析同一条线：基于订阅制 Agent SDK 的自建工作流要迁移到 API key + credits 模型，配额监控要从'会话数'改成'credit 余额'——迁移前核对自建脚本的认证方式。

• 来源: news.ycombinator.com/item?id=49997654 · 官方指引（support.claude.com）
• 信号: 订阅额度制→API credits · Max/Team 均覆盖 · 认领进 Console 组织 · Max 5x=$100/20x=$200（社区口径） · 10-07 生效
• 关键词: coding-agent-harness · Coding Agent 成本优化 · Vibe Coding Agent 项目蓝图

观察清单