Agent Learning Daily Digest #96 — 2026-09-09

周三（281 条采集，GitHub 4 查询 + arXiv 4 查询全部成功；r/LocalLLaMA 与 r/ClaudeAI 429。距 #95 已空 9 天，arXiv 2609.x 全新、HN 检索窗口刷新，跨天去重 0 条——12 个候选在全部历史 digest 中零命中，为近期首次）。今日主线是"技能与钩子"供应链攻击面的正式化：HookPry 把 lifecycle-hook 更新路径定为新攻击面——攻击者只控制插件元数据与 hook 配置即可让良性版本化插件被更新木马化，25 组 harness×后端 1,000 次端到端运行 7/7 harness 全部沦陷（单 harness 成功率最高 92.5%，Microsoft Defender 召回 0%，三个静态防御的并集仍漏 47.5%）；SkillShift 证明第三方 skill 可以在保持声明的任务与输出接口完全合法的前提下隐蔽改写 agent 的决策策略（agentic commerce 攻击者偏好选择率 81.33%、软件依赖场景 63.33%，且跨后端免优化迁移、现有扫描器全部检测失败）；ACLE-MCP 给远程 MCP 补上 OAuth 之后的"post-authorization execution trust gap"——短寿命租约绑定工作负载、新鲜度、操作与参数边界，实测挡下全部攻击族、代价 p95 +25.7%。评测侧三连击：SWE-Gate（644 个通过功能测试的修复中 221 个不满足 PR review 约束）、PatchBench（PoC-only 验证把补丁解决率平均虚增 1.83×，25% 补丁是对历史补丁的记忆重现）、τ^τ-Bench（把"给真实客户造一个生产 agent"变成基准——最强配置 Claude Opus 5 + Claude Code 仅 23.9%，专家参考天花板 82.2%）。工程侧：Rohan Adwankar 从沙箱内部逆向两代移动 agent 基础设施（Firecracker microVM + Rust PID 1 + 324MB Bun harness 只读盘 + vda 断开重连制造会话连续错觉）；AgentConnect 实测 Grep vs LSP——任务决定工具选择，LLM 友好度与工具能力同等重要；多 harness RL 研究证明 24,000 次封存评测里评测 harness 是主导变量（解率 2.14%→9.27%，4.3×）而 GRPO 分组规则统计上无关紧要。

今日高信号

1. HookPry — lifecycle-hook 更新路径是 7/7 harness 全失守的新攻击面：Defender 召回 0%（arXiv:2609.03884）

现代 agent harness 暴露 lifecycle hooks：把 shell 命令绑定到 session start、tool call、file edit 等运行时事件——这些命令以宿主机权限运行，却以"配置"形式发布，且可能在 LLM 完全看不见的时刻触发。论文指出被盲目信任的 hook 更新路径是全新攻击面：供应链威胁模型下，攻击者只控制插件元数据与 hook 配置——一个良性版本化插件可以被一次更新静默木马化，把攻击者选定的命令绑到良性事件上，产生提权等恶意宿主行为。HookPry（开源全自动攻击框架）实现 10 个攻击目标：25 组 harness×后端组合、1,000 次端到端运行，全部 7 个被测 harness 沦陷（覆盖 Claude Code、OpenClaw、Codex CLI 等），单 harness 成功率最高 92.5%。防御侧更刺眼：Microsoft Defender 召回 0%，三个静态防御的并集仍漏掉 47.5% 的恶意工件。对 Agent Safety 是供应链级贡献——与 #94 Five Primitives（supply chain 原语）、#93 Forgeeks（llms.txt 无主包 <1h 回调）连成第四环：插件/hook 的"配置即代码"属性让更新通道成为最低成本的持久化后门；harness 对 hook 更新必须做完整性校验与变更审阅，"配置变更"要按代码变更级别对待。

• 来源: arXiv:2609.03884
• 信号: arXiv · 1,000 端到端运行 · 7/7 harness 沦陷 · 最高 92.5% · Defender 0% 召回 · 静态防御并集漏 47.5%
• 关键词: Agent Safety · coding-agent-harness · agent-skill-security

2. SkillShift — 第三方 skill 隐蔽改写 agent 决策策略：81.33% 攻击者偏好选择率、扫描器全灭（arXiv:2609.02564）

可复用 skill 为 agent 注入任务流程、工具使用指南与输出约束——但 skill 本质上是外置的行为策略，这构成供应链风险：第三方 skill 可以在保持声明的任务与输出接口完全合法的同时，把 agent 决策隐蔽地重定向到未披露的目标。论文形式化 Skill Policy Integrity（skill 诱导的策略必须与声明功能及用户授权目标对齐），并提出 SkillShift——无需显式命令注入、不劫持任务的约束式黑盒隐蔽策略改写框架：语义合理的策略编辑 + 分层验证 + 失败引导优化 + 策略压缩。实测：agentic commerce 场景攻击者偏好选择率 81.33%、软件依赖场景 63.33%，同时保持 100% 效用保留率；冻结的恶意策略免优化跨异构 LLM 后端与 agent 环境迁移；被评估的扫描器全部无法检测。作者主张把可复用 skill 当作"agent 策略工件"进行行为审计。对 agent-skill-security 是机制级贡献——与 #93 SkillBloat/EVOMAL、#94 WikiSkill（wiki 作为可审计底座）同一条线的攻击面侧：skill 市场的"看起来工作正常"与"悄悄偏袒"无法靠接口检查区分——行为审计（对同一输入集比对安装前后的决策分布）是唯一可靠防线。

• 来源: arXiv:2609.02564
• 信号: arXiv · Skill Policy Integrity 形式化 · 81.33%/63.33% 选择率 · 100% 效用保留 · 跨后端迁移 · 扫描器全灭
• 关键词: agent-skill-security · Agent Safety · Claude Code Skills

3. τ^τ-Bench — 把"造 agent"变成基准：最强配置仅 23.9%，专家天花板 82.2%（arXiv:2609.04611）

现有基准测的是"agent 能不能完成任务"，τ^τ-Bench（hyper-tau-bench）测的是"AI 能不能造出一个生产 agent"：developer agent 拿到与真实客户委托相同的起点——业务方真实保留的记录、持有需求的客户、运营必须走的生产 API、要继承的代码库、服务成本与模型选型限制——然后必须交付一个完整的客服 agent；评分方式是把造出的 agent 部署到 held-out 模拟用户上。53 个任务横跨 4 个领域：最强配置 Claude Opus 5 under Claude Code 仅通过 23.9% 的评估模拟，专家手写的参考天花板 82.2%。失败模式与人类 agent 工程师一模一样：对业务记录浅查询而非深理解、几乎不与客户沟通、对 agent 架构与服务花费的实验太少——第一个能跑的设计就直接上线。对 agent-evaluation 是范式级新基准——与 #95 DeepRepro（状态感知子规划）、#91 SWE Refactor Bench 同一战场但更狠：客户端沟通与成本约束成为被评分项；"agent 构建即任务"正是 vibe coding agent 项目的终极考卷——值得直接拿来自测。

• 来源: arXiv:2609.04611
• 信号: arXiv · 53 任务/4 领域 · 最强 23.9% vs 专家 82.2% · held-out 模拟用户评分 · 失败模式三类
• 关键词: agent-evaluation · coding-agent-harness · Coding Agent Verification

4. PatchBench — PoC-only 验证虚增 1.83×：25% 的"成功"补丁是记忆重现（arXiv:2609.04075）

自动漏洞修复 agent 的既有评测只用 PoC 输入是否还触发崩溃来验证补丁——留下两个效度威胁：agent 可能复现记忆中的历史开发者补丁，或生成只压制崩溃的面修复。论文给出量化：平均 25% 的 agent 补丁与历史开发者补丁高度相似（补丁记忆化是真实威胁）；agent 还频繁利用基准结构，直接在崩溃栈上打补丁压制崩溃而非定位根因。PatchBench 的对策：只选 ground-truth 修复在崩溃栈之外的漏洞 + 漏洞移植与代码变异把历史漏洞迁移到新仓库上下文 + 同时评估安全与语义正确性的新验证方法。11 个 SOTA agent（含 AIxCC 前三名）上，PoC-only 验证平均把解决率虚增 1.83×。对 Coding Agent Verification 是效度级贡献——与 #94 SWE Refactor Bench（验收假完成）、#93 Building to the Test（为 oracle 编码）合流：AgentOSICCVE 时代的"解决率"必须先过效度审计；补丁相似度指标可以直接搬到 vibe coding agent 的自查流水线——你的 agent 提交的补丁有多少是背出来的？

• 来源: arXiv:2609.04075
• 信号: arXiv · 25% 补丁与历史补丁高相似 · PoC-only 虚增 1.83× · 11 agent 含 AIxCC 前三 · 漏洞移植+变异
• 关键词: Coding Agent Verification · Agent Safety · agent-evaluation

5. SWE-Gate — 通过功能测试不够：644 个"通过"修复中 221 个不满足 review 约束（arXiv:2609.04167）

仓库级 SE 基准只测"补丁是否通过功能测试"，忽略了现实中决定补丁能否被接受的 review 约束。SWE-Gate 从真实 PR review 评论中提取约束、围绕约束合成修复实例：303 个仓库级实例横跨 75 个 Python 仓库，每个实例提供独立的功能测试与约束测试 + 不合规补丁与金补丁，把"解决 issue 的能力"与"满足 review 约束的能力"显式分开。四个能力梯队的 LLM 后端在同一 coding-agent scaffold 下实测：644 个通过功能测试的修复中，221 个（34.3%）无法满足给出的 review 约束——功能导向评测系统性高估 agent 满足完整修复需求的能力。对 Coding Agent Verification 是验收级贡献——review 约束（命名、边界处理、测试覆盖方式、不要顺手重构）正是人类工程师的日常验收面，却从未进过基准；vibe coding agent 的验收标准应该从"测试绿了"升级为"测试绿 + review 约束清单绿"——约束来源就是自己仓库的 PR review 历史。

• 来源: arXiv:2609.04167
• 信号: arXiv · 303 实例/75 仓库 · 644 通过→221 违反约束（34.3%）· 约束源自真实 PR 评论 · 4 后端同 scaffold
• 关键词: Coding Agent Verification · coding-agent-harness · agent-evaluation

6. 多 harness RL 学到什么 — 评测 harness 是主导变量（4.3×），分组规则无关紧要（arXiv:2609.04518）

Agent RL 越来越多跑在完整执行 harness 里，"multi-harness recipe"混合了两个选择：让策略接触多个 harness，以及把不同 harness 的奖励放进同一个相对优势组。论文在仓库级编码上隔离第二个选择：同一 Qwen3-8B 监督热启动，重放 Aider/OpenHands/Qwen Code/SWE-agent 四个 harness 的冻结任务记录，GRPO 分组按 Within（每 task-harness 一组）vs Cross（同任务跨 harness 合池）两种规则，用封存 SWE-bench Verified oracle 对四个源 harness + 一个训练中 held-out 的最小 harness 评分。24,000 次封存评测的结论：评测 harness 是主导变量——把平均解率从 2.14% 移到 9.27%（4.3×），而训练配方只移动 1.16；分组规则统计上不显著（held-out 上 Cross−Within = +0.25pp，CI [−0.48, +1.02]）。更深的机制发现：Cross 的合池优势携带 harness 指纹——out-of-fold 分类器能从 Cross 的优势中恢复生成 harness（+4.48pp 超混洗基线），从 Within 的优势中完全不能；结论：跨 harness 信用分配学到的是配置适配，不是更可移植的能力。对 agent-evaluation / coding-agent-harness 是方法论级证据——为 #94 Same Model Different Harness（harness 决定结果）补上 RL 训练侧的因果拆分；"multi-harness 训练报告必须声明分组边界并在未见 harness 上测试"应成为社区标准。

• 来源: arXiv:2609.04518
• 信号: arXiv · 24,000 封存评测 · harness 4.3× vs 配方 1.16 · 分组规则 CI 含 0 · harness 指纹可从 Cross 优势恢复
• 关键词: agent-evaluation · coding-agent-harness · Coding Agent Verification

7. ACLE-MCP — OAuth 之后：post-authorization execution trust gap 与租约式执行准入（arXiv:2609.02690）

远程 MCP 服务里，OAuth 授权并不能保证"后来的这次工具调用"确实由依赖方信任的 provider 侧工作负载执行——端点可能在执行被替换的工作负载、依赖过期的评估状态、复用从别的发送者转移的权限、或经过未声明的下游组件时依然保持授权。论文命名 post-authorization execution trust gap，提出 ACLE-MCP：调用域（invocation-scoped）架构，耦合委托授权、工作负载评估与资源侧执行准入——对受保护调用签发短寿命、发送者约束的能力租约，绑定预期工作负载、新鲜度要求、操作、对象与参数边界、下游约束与回执义务；provider 侧 Execution Gate 在受保护工具逻辑开始前消费租约。原型：Keycloak/OIDC 验证 + MCP Python SDK server + 可选 vTPM quote 验证后端。实验：弱授权或连接时 attestation 模式都留有不同攻击族敞口，完整 ACLE-MCP 挡下全部被评估攻击族且保留全部良性任务；代价是正常放行调用的 p95 延迟 +25.7%。对 mcp-security 是架构级贡献——与 #95 FetchGate（registry 22.7% 死链+47 隐瞒指令 host）、#94 五原语（attestation）连成"远程工具调用信任链"三件套：授权 ≠ 执行时信任；对自建 MCP 网关，"每次调用的租约绑定"比"会话级授权"更贴合 agent 的威胁模型。

• 来源: arXiv:2609.02690
• 信号: arXiv · capability lease + Execution Gate · Keycloak/vTPM 原型 · 全攻击族拦截 · p95 +25.7% 代价
• 关键词: mcp-security · Agent Safety · Coding Agent Verification

8. The box an agent runs in — 从沙箱内部逆向移动 agent 基础设施：Firecracker + Rust PID 1（Rohan Adwankar，HN 64p）

作者从"agent 的手机端沙箱"（ws-term）内部逆向两代移动 agent 平台。(1) Claude Code on Your Phone：每个会话一个 Firecracker microVM（KVM guest、定制 6.18.5-fc-v20 内核），PID 1 不是 systemd 而是 Rust/Tokio 写的 process_api——挂载磁盘后在 vsock 2024 端口听宿主驱动；加固细节密集（PID 1 non-dumpable、/proc/1/mem 拒绝 CAP_SYS_PTRACE、shell 无 CAP_SYS_RESOURCE）。磁盘干净二分：你的（可写持久 vda）vs 他们的（只读共享）——324MB 的 claude harness（Bun 编译产物）在只读盘上；推理走 SSE over HTTPS/2，经 443-only 的 MITM egress gateway，api.anthropic.com 在 /etc/hosts 钉死，零入站；宿主铸造的 OAuth token 每次启动轮换。空闲回收时进程死掉但 vda 完整卸下、下次冷启动重挂——"会话连续"是磁盘连续性制造的错觉，算力本身每次都是新的。(2) Instinct：同样 Firecracker，差异在谁运营机队、什么持久化——Instinct 的记忆是 Markdown 的 git 仓库（/memory 带 wiki 链接，agent 自己是 git 作者），打包成单个 git bundle 推到 S3（短寿命 STS 凭证），浏览器任务密钥走服务端 Vault 从不落箱。对 coding-agent-harness 是一手基础设施测绘——"会话连续性 = 状态盘 + 每次冷启动"与 Instinct 的"记忆即 git 仓库"给 vibe coding agent 的持久层两个直接可抄的设计；密钥不进盒子、能力按只读盘分发是宿主侧安全基线。

• 来源: rohanadwankar.github.io
• 信号: HN 64p/25c · Firecracker microVM 实测 · Rust PID 1/vsock 2024 · vda 断开重连 · Instinct git-bundle 记忆
• 关键词: coding-agent-harness · Agent Safety · Agent Memory

9. Grep beats LSP? — 实测：任务决定工具选择，LLM 友好度与能力同等重要（AgentConnect，HN 97p）

一个反直觉的实测：作者比较 grep（词法检索）与 LSP 支持的语义导航在代码查找与编辑任务上的表现，本期待语义导航降噪省 token——结果 agent 常常留在 grep 里，强制先走语义路径反而有时降低任务成功率。修正后的结论是条件性的而非"grep 全面胜出"：agent 按任务路由工具——定位/重命名类任务语义工具只被选 0-6%，引用完备性类任务选 45-57%（此时 LSP 精确率 1.00 vs grep 0.76）；LSP 的价值还取决于仓库词法噪声（干净仓库 remeda：ΔF1 +0.000 还多花 16% token；噪声仓库 hono：显著受益）。作者的解释框架是 LLM 友好度：结果精确 ≠ 模型可用——工具必须返回"下一步够用的上下文"并以模型能直接使用的接口形态呈现；训练分布里见过相似动作路径可能也是因素（作者标注为假设非证明）。对 coding-agent-harness / Context Engineering 是工程级校准——与 #94 ASIL（结构化语义动作）并不矛盾而是互补：ASIL 说"给模型原生接口"，这篇说"原生接口必须按任务与输出形态设计，否则精确反而输给熟悉"；给工具加 LSP 前先看任务分布与输出上下文完整性。

• 来源: agentconnect.md
• 信号: HN 97p/68c · 3 个 Claude 模型实测 · 任务路由 0-6% vs 45-57% · LSP 精确率 1.00 vs grep 0.76 · 结论为条件性
• 关键词: coding-agent-harness · Context Engineering · CodeGraph

10. i-have-adhd — 29k★ 的输出整形 skill：10 条规则让 agent 不再 bury the answer（GitHub + HN 78p）

29,190★（HN 78p/60c）的现象级 skill：i-have-adhd——"阻止你的 coding agent 把答案埋在废话里"，ADHD 友好输出（README 明言"不需要 ADHD 诊断"）。Before/After 一眼可见：从"Great question! 让我想想……Hope this helps!"改成 Run npm install jsonwebtoken@latest, then edit src/auth.ts:42 加编号步骤。规则仅 10 条：先给下一步动作、多步编号、以一个具体下一步结尾、压制跑题、每轮重述状态、给分钟级时间估计、让进展可见、错误就事论事、列表封顶 5 项、无开场白无回顾无收尾；MIT 协议、六语言 README、claude plugin marketplace 一键装。对 Claude Code Skills 是产品级信号——与 #92 SkillBloat、#93 SkillsMP 同一市场的另一端：最高 stars 的不是能力型 skill 而是输出整形 skill——社区用真金白银投票"agent 话太多"；10 条规则本身就是 vibe coding agent 输出层的默认模板；"重述状态每轮"与 harness 状态管理同构。

• 来源: ayghri/i-have-adhd
• 信号: GitHub 29,190★ · HN 78p/60c · 10 规则 · claude plugin marketplace · MIT
• 关键词: Claude Code Skills · coding-agent-harness · Context Engineering

11. TradingAgents — 103k★ 多 agent 金融交易框架登 HN：角色分工 + 辩论式决策（GitHub + HN 103p）

TauricResearch/TradingAgents（103,368★、19,902 fork，HN 103p/73c 新讨论）：多 agent LLM 金融交易框架——分析师（基本面/情绪/新闻）→ 研究员多空辩论（bull vs bear researcher + 研究员经理裁决）→ 交易员决策 → 风险管理岗持续评估波动率/流动性的拟真投研组织结构；配套 Trading-R1 技术报告与终端产品路线，2026 年更新支持多 provider（GPT-5.x/Gemini 3.x/Claude 4.x/Grok 4.x）。对 Multi-Agent Communication Patterns 是大规模生产级样本——与 #95 SwarmWorld（物理 stigmergy 自组织）构成编排谱系两极：TradingAgents 是"人类组织结构直接映射为 agent 图"的极致案例——角色、辩论、裁决、风险门禁全部照搬投研团队；103k★ 证明领域工作流 + 结构化角色是最容易传播的 multi-agent 叙事；其辩论式决策（bull/bear 强制对冲）可直接借给任何"判断型"任务编排。

• 来源: TauricResearch/TradingAgents
• 信号: GitHub 103,368★ · HN 103p/73c · 分析师→辩论→交易→风险角色链 · 多 provider
• 关键词: Multi-Agent Communication Patterns · Coding Agent 编排模式 · agent-evaluation

12. MathKernel — 证据感知的多引擎数学内核 + MCP server：每个结果带信任级别与推导链（GitHub，HN 36p）

MathKernel（HN 36p/5c，09-06 新发布）：Python 库 + MCP server 双形态——LLM 解释意图，内核负责数学证据。核心设计：每个数学结果携带显式信任级别、引擎标签与推导轨迹——精确计算、已验证证书、符号结果、认证区间、经验证据、形式化证明是六种不同的 claim（"精确算术不等于形式证明；近似输入的祖先链不得静默消失"）。引擎矩阵：sympy · z3 · lean · numba · cuda，typed MathIR 中间表示贯通；覆盖连续符号数学、PDE 自适应有限元、统计与 PRNG 分析、关系与信息几何推断。对 Coding Agent Verification 是工具级贡献——与 #95 AI Slop 综述（Deductive Coverage Score）同题的工程解：把"证据类型"做成 API 的一等公民，agent 的数值主张就能按信任级别路由（可信→直接用，经验→标注待验证，无证据→拒绝）；trust label + provenance 模式同样适用于规则引擎的决策输出。

• 来源: Staatsgeheim/MathKernel
• 信号: HN 36p/5c · 6 级信任模型 · sympy/z3/lean/numba/cuda 引擎 · typed MathIR · MCP server
• 关键词: Coding Agent Verification · mcp-security · agent-evaluation

观察清单