Agent Learning Daily Digest #87 — 2026-08-20

周四（285 条采集，arXiv 4 查询全部成功；跨天去重跳过 ~15 条 #85/#86 已覆盖项：CompoSkill、ATP、Coherence Debt、ECK、Workspace Topology、When Agents Coordinate、CAPO、Risk-free 立场文、Vibe 工具质量对比、Twin、Agentic Transaction、StateBridge、LoongReflect、FlowScout、WebCompat 等）。今日主题：harness 侵入训练栈——Agent Lightning v1.0 与 LEGO-RL 同日定义"harnessed agentic RL"范式（不 hack harness 即可对 Claude Code/OpenCode 做 +6~9.4pp 的策略梯度训练）；知识工作的版本化工作区——StagedWorkspace 把 coding agent 早已用 git 解决的"视图-状态绑定"推广到 Office/办公 agent；测试生成的前后置契约化——Spec-Driven Test Generation（Google 生产 bug +9.8pp）与 TDD-Agent（双轨代码/测试协同精炼）同框；问责落点测绘——4 工具×18 政策文档的实证分析发现"平台控制"与"提供商条款"互不引用且相互矛盾；警示日——Opus 4.8→5.0 语言风格退化 issue（HN 162p）实为标题升级、正文 90% 谈 4.8 文风，Anthropic 已回应"合理但归模型调优"。

今日高信号

1. Agent Lightning v1.0 — "harnessed agentic RL" 范式定名：3,500 LOC 让 harness 自己参与训练（arXiv:2608.17528）

现代 agent 运行在管理工具、上下文与控制流的 harness 里，但 RL 训练器与 harness 的接缝一直是训练栈的裂缝。v1.0 正式论文把其解耦架构（LLM endpoint proxy 把任意 agent 连到 RL 训练）定名为 harnessed agentic RL——harness（而非训练器）拥有环境交互循环，训练器只看到 LLM 请求-响应对；该范式已被 verl Uni-Agent、AReaL 2.0、slime、Polar 采纳。量化：~3,500 LOC 实现、仅 6K 训练样本，Qwen3.5-9B SWE-bench Verified 41.8%→56.4%（+14.6pp）；论文坦列四大工程挑战（retokenization、sample merging、advantage 计算、loss 归一化）。对 coding-agent-harness 是范式定名级贡献——vibe coding agent 的 harness 若按此接口设计，未来可零改造接入 RL 自我改进——"harness 即训练基础设施"从口号变成有名字、有 adopter、有数字的范式。

• 来源: arXiv:2608.17528
• 信号: arXiv cs.AI/cs.SE · v1.0 定名 · 4 框架采纳 · +14.6pp · ~3,500 LOC
• 关键词: coding-agent-harness · agent-evaluation

2. LEGO-RL — 不改 harness 控制流的训练原生桥：Claude Code 62.4→68.2%（arXiv:2608.17393）

harness 原生执行环境与策略梯度训练天然错位：环境崩溃与 reward hacking 污染结果信号、训练-推理不一致使 rollout 与策略更新脱钩。LEGO-RL 三支柱桥接：进程内 LLM 代理（token 级对齐）、沙箱编排（staged 反 reward-hacking 防御）、可观测性插件 + Live UI——全程不修改 harness 控制流。量化：Qwen3.5-35B-A3B + GSPO，SWE-bench Verified 上 OpenHands SDK 64.0→70.4%、Claude Code 62.4→68.2%、OpenCode 57.2→66.6%；rollout-训练概率相关性 >0.99（训练保真度硬指标）。对 coding-agent-harness 是工程落地级贡献——与 #1 同日出现构成"范式+工程桥"组合拳：Agent Lightning 定名范式，LEGO-RL 证明主流闭源 harness（Claude Code）也能被训练——训练权正在从模型方外溢到 harness 方。

• 来源: arXiv:2608.17393 · lego-rl.pages.dev
• 信号: arXiv cs.AI · 三 harness +6.0~9.4pp · rollout-训练相关 >0.99 · 不改控制流
• 关键词: coding-agent-harness · Coding Agent Verification

3. StagedWorkspace — 知识工作 agent 的 workspace-state contract：OfficeQA 29.3%→63.9%（arXiv:2608.18050）

知识工作 agent（产出/修改代码库、文档、表格、幻灯片等持久数字工件）有一个未被命名的隐患：它们检索的解析视图、编辑的原生文件、评审的变更、提交的工件可能指向同一工作产物的不同版本。论文将其形式化为 workspace-state contract——每个视图显式绑定到演化中工作区状态的某个版本；coding agent 通过 git 部分解决了它，但办公场景 agent 没有。实现 StagedWorkspace（staged 解析/原生双通道访问，内容哈希绑定）+ SW-AGENT。量化：OfficeQA Pass@1 +8.3~12.1pp、APEX 评分 +4.7~9.2pp；SW-AGENT 达 63.9% OfficeQA（Gemini 3.1 Pro，对比已发表 29.3%）与 42.1 APEX（GPT-5.4 Nano，对比 25.5）。对 Agent Memory 是状态管理级贡献——"视图必须绑定版本"是 git 之于 coding agent 的等价物在知识工作域的缺失件——任何操作文件双表示（解析缓存+原件）的 harness 都该检查自己是否已违约。

• 来源: arXiv:2608.18050
• 信号: arXiv cs.AI · OfficeQA 29.3%→63.9% · contract 形式化 · Under Review
• 关键词: Agent Memory · Context Engineering · coding-agent-harness

4. Spec-Driven Test Generation — 先写契约再生测试：Google 生产 bug 检出 +9.8pp（arXiv:2608.17177）

直接提示 agent 生成测试时，agent 常常无法推理代码的底层契约，漏掉边界行为。Spec-Driven Test Generation：让 agent 先把前置条件/后置条件/未定义行为文档化为半形式化 spec 作为"认知脚手架"，再生成测试。量化（Google 生产 bug）：bug 检出 +9.8pp（p=0.0352）、分支覆盖 +2.5pp（p=0.0034）；LLM-judge 下 spec 驱动测试集在 77.8% 案例胜过基线、56.7% 胜过人类工程师测试。⚠️ 头条指标是检出率与分支覆盖（边界案例仅出现在 judge 次级发现）。对 Coding Agent Verification 是方法论级贡献——"先写契约再生测试"把 TDD 的理念前移到 spec 层——比 TDD-Agent 的执行反馈回路更轻、可在任何 harness 里用纯提示词实现。

• 来源: arXiv:2608.17177
• 信号: arXiv cs.SE · Google 生产 bug · +9.8pp（p=0.0352）· 胜过 56.7% 人类测试
• 关键词: Coding Agent Verification · coding-agent-harness

5. TDD-Agent — 代码与测试的双轨协同精炼（arXiv:2608.16742）

现有方法把生成测试当静态事后验证器，既不能引导实现，还可能因测试自身不完整/错误而引入误导性反馈。TDD-Agent 把 TDD 范式操作化为基于执行反馈的迭代双轨精炼——代码轨与测试轨同步演化；另附纯提示词变体 TDD-prompt。⚠️ 摘要无头条数字（仅定性"持续超越基线"）；基准：TDD-prompt 上 LiveCodeBench、完整框架上 RepoEval，报告更高通过率/覆盖率/mutation 分数（量化待正文，待验证）。对 Coding Agent Verification 是机制互补级贡献——与 #4 构成"测试生成"的两条路线：spec 先行（轻、可移植）vs 双轨执行反馈（重、自适应）——vibe coding agent 的验证层两条都该试。

• 来源: arXiv:2608.16742
• 信号: arXiv cs.SE · 双轨精炼 · 摘要无头条数字（定性）· 代码开放
• 关键词: Coding Agent Verification · agent-evaluation

6. Where Accountability Lives — 4 工具×18 政策文档：平台控制与提供商条款互不引用（arXiv:2608.15678）

coding agent 写 commit、开 PR、推代码——但"谁负责"沉淀在互不引用的两处：平台控制（gate agent 能做什么）与提供商条款（分配产出责任）。论文对 4 个 agentic coding 工具、7 家提供商的 18 份政策文档做事件级测绘，在每个工作流事件上记录谁持权限、谁担责任。关键发现：两层相互矛盾——一家提供商禁止任务指派者审批 PR，另一家却让 agent 在低风险阈值下自动审批 PR；agent 署名至今没有定义好的 git trailer。方法论贡献：用"是否强制检查 vs 谁执行检查"网格取代陈旧的 enforced/advisory/absent 三分法；118 份归档文档 + 12 个处理脚本已存 Zenodo。对 Agent Safety 是治理测绘级贡献——问责在 stack 各层间存在真实缝隙——企业落地 agent coding 前应先做这张"事件×权限×责任"表。

• 来源: arXiv:2608.15678 · Zenodo
• 信号: arXiv cs.SE · 4 工具/18 文档/7 提供商 · 两层矛盾 · 30 页
• 关键词: Agent Safety · coding-agent-harness

7. When Agents Act on Web3 — MCP 工具 27%→65% 改状态：现有防护拦截 <30%（arXiv:2608.17275）

agent 从"读"转向"做"：部署的 MCP 工具中修改外部状态者占比从 27% 升至 65%。当这类权限落在公链上，攻击后果由区块链执行层的四个性质决定：不可逆性、签名授权、持续自治、序列级组合。综述给出 Web3 风险映射矩阵（攻击类→放大影响→放大器→缓解→残余缺口）。量化警示：实测防护拦截 <30% 的攻击；模型级安全拒绝 <3%。对 mcp-security 是攻击面测绘级贡献——"工具从读到写"的结构性迁移意味着 prompt injection 的最坏情形从"信息泄露"升格为"不可逆资金动作"——任何接链上工具的 harness 都应默认假设注入会成功。

• 来源: arXiv:2608.17275
• 信号: arXiv cs.CR/cs.AI · 27%→65% · 防护拦截 <30% · 模型拒绝 <3%
• 关键词: mcp-security · Agent Safety

8. DOCSCHISEL — 工具文档本身可优化：任务成功率相对 +95.89%（arXiv:2608.10037）

工具文档是 agent 工具使用的接地资源，但一直被当作固定输入。论文先实证：没有任何固定文档写法能跨领域/骨干模型/范式泛化；继而提出 DOCSCHISEL——分析失败执行轨迹，按工具迭代增删/精炼文档字段。⚠️ 数字为相对提升：任务成功率较原始文档相对 +95.89%、较 EasyTool/DRAFT 基线平均相对 +75.15%（非百分点——措辞注意）。对 Context Engineering 是输入侧优化级贡献——上下文工程不只管理"放什么进上下文"，还管理"每个工具占多少上下文"——文档即提示词的一部分，可被数据驱动地重写。

• 来源: arXiv:2608.10037
• 信号: arXiv cs.LG · 相对 +95.89%（非 pp）· 轨迹驱动 · 跨域不泛化实证
• 关键词: Context Engineering · coding-agent-harness

9. Opus 4.8→5.0 语言风格退化 issue — "incoherence" 是标题升级，正文 90% 谈 4.8 文风（HN 162p）

Claude Code issue #77136（2026-07-13 开启，237 👍、HN 162p/147c）标题为"Opus 5.0 drives incoherence into the stratosphere"——但核实显示该短语仅存在于标题（OP 于 07-29 追加），正文不含 "5.0/incoherence"，90% 内容是 Opus 4.8 的语言风格报告：生造术语（"load-bearing"）、强行隐喻、"It is not X, it is Y" 句式、密码学式伪简洁、好斗人设、长会话 tone 漂移（风格指令数轮后失效）、清理返工最高 2× token 成本。Opus 5.0 仅出现在个别评论（"way worse with Opus 5"）。Anthropic 回应（bcherny，08-17，46 👍）：保持开启；非交互环境无法复现；归类为模型行为反馈转模型调优（非 Claude Code bug）；建议 custom output styles 作为最接近的 workaround，"诉求合理"。对 strained-coherence 是现象追踪级信号——所谓"incoherence"实为输出语域退化（register drift）而非事实矛盾——与 vault 追踪的 coherence debt 是两种不同的失稳：一个是事实通道断裂，一个是风格通道漂移；长会话下风格指令衰减是两者共性的实证。

• 来源: issue #77136 · HN 162p/147c
• 信号: 237 👍 · Anthropic 官方回应 · 标题升级（语义放大）· 转模型调优
• 关键词: strained-coherence · Claude Code Skills · coding-agent-harness

10. OneCLI（YC S26）— 从凭证网关到团队沙箱 harness：密钥永不触达 agent（Launch HN 47p）

YC S26 公司 OneCLI 的开源（Apache-2.0 + ee/ 目录企业例外）团队沙箱 agent harness：每员工沙箱化 agent、Rust 网关做 MITM 凭证注入——密钥永不进入 agent 进程、IdP 开通、中央策略、确定性人工审批、每 agent Slack 应用、出站-only runner。演进史信号：v1（2026-07 HN 110p）只是 Rust 凭证网关，v2 转型完整团队 harness——"凭证边界先行、harness 后成"的路径本身就是架构启示。3,160 stars。对 coding-agent-harness 是企业级参照——"agent 永远拿不到密钥"的 MITM 注入模式 + 确定性审批门是企业 agent 落地的最低配置——比权限弹窗流派（pi）更保守、比沙箱流派（microsandbox）更聚焦身份层。

• 来源: GitHub · Launch HN（47p/14c）
• 信号: YC S26 · 3,160 stars · Apache-2.0+ee 例外 · MITM 凭证注入 · 凭证网关→harness 转型
• 关键词: coding-agent-harness · Agent Safety

11. ratel — 无向量库的上下文工程层：进程内 BM25 + 渐进披露（425 stars，MIT）

ratel（TypeScript + Rust core，MIT；core 引擎 Apache-2.0）：面向 agent 的上下文工程层——工具/技能的渐进披露（progressive disclosure，search_capabilities）、技能与记忆的进程内 BM25 检索（语义/混合可选）、无向量库、无基础设施依赖。⚠️ 核实警示："~80% fewer tokens" 仅出现在 GitHub description 字段，README 无此数字——README 只说"cuts token usage and recovers accuracy"，数字需去自托管的 benchmark.ratel.sh 复核（自报营销口径，待验证）。425 stars、活跃维护。对 Context Engineering 是工具参照级信号——"BM25 优先、向量可选"与本周 OpenViking 的三级摘要加载同属"轻检索"路线——对 skill manager 的启示：检索层可以不引入向量库，先用进程内 BM25 起步。

• 来源: GitHub · benchmark.ratel.sh（自报）
• 信号: 425 stars · MIT/Apache-2.0 · 无向量库 · 80% 为描述字段自报（README 无）
• 关键词: Context Engineering · Coding Agent 成本优化

观察清单