logs/

关于我的技术报告的构建笔记：在一套冻结的 LoRA 协议下，把一个十样本试点与 61 个任务上的全量微调配对，追问试点到底能不能决定哪些任务值得微调。完整 PDF 已内嵌。

takeaway: 试点是一个有预算价值的排序器，而不是 go / no-go 门禁——这个负结果之所以可发表，是因为诚实条款是预注册的。

关于在 RAG 与 LLM 模型权重编辑之间路由个人记忆、再在禁用检索的情况下验证归因的构建笔记。

takeaway: 记忆系统需要溯源，而不只是召回。

三篇论文表明，可验证奖励训练的上限由验证器而非 RL 循环决定：随机奖励就能推动 Qwen 数学模型，一个样本几乎追平 1.2k，有噪验证器会悄然偏置 GRPO；我的 VerifierForge 对照臂证实增益不是安慰剂。

takeaway: 先审计验证器、修正它的噪声、跑一个随机奖励对照臂，再去相信任何 RLVR benchmark 增益

以第一人称把 GRPO 及其后代变体读成一棵家族树：每个后代变体修补一个具体病理——clip 坍缩、长度偏置、熵、轨迹级信用分配。我实现过该算法并在程序化验证器上运行过，本文由此写成。

takeaway: 每个 GRPO 变体都点名自己修复的一个病理，所以把它们当变更日志读，而不是当动物园看。

一张从 ROME 到 UnKE 的 LLM 知识编辑领域地图，再深读我那篇针对困难版本的论文：让事实扛过改写的 LLM 序列化模型编辑。

takeaway: 把改写后的查询路由到正确的编辑只解决了问题的一半；存储的值还得能把同一事实用新形态说出来。

关于 RLVR 验证器设计的阅读笔记：规则式的脆弱、模型式作弊、过程奖励的信用分配、OpenAI 对 RFT 的关停，最终落在带证伪臂的程序化分层验证器上。

takeaway: 验证器就是产品本身，而证伪臂是对奖励质量唯一诚实的检验

关于 token / 参数 / 潜在三类记忆的分类体系、从 ROME 到 HoReN 的 LLM 知识编辑谱系、以及持久知识何时应写入权重而非检索上下文的路由规则的阅读笔记。

takeaway: 当知识持久、且必须在检索关闭时仍能存活，就写入权重。

关于 s1 预算强制、LIMO 的 817 样本引出，以及那项展示多想何时失效的 ICLR 2026 多轮研究的阅读笔记。

takeaway: 多想只有在模型仍能纠正自身路径时才有回报。

Agent 循环是一串短而结构化、延迟受限的步骤，共享一个不断增长的前缀——这是一个与对话不同的服务问题。精读 DistServe、Mooncake 与 EAGLE，加上前缀缓存与 KV 压缩方面的工作，最后落在 PiPlan.ai 的本地 + 前沿两层服务设计上。

takeaway: 优化的是运行而不是单个请求——让共享前缀跨轮保持温热、把阶段拆开、让准入与路由决策显式化

关于 2026 on-policy 蒸馏浪潮的阅读笔记：领域综述、黑盒对抗蒸馏与校准危机，并把校准危机框定为小模型路由的门禁。

takeaway: 没有校准的能力比不蒸馏更糟，所以路由必须在此设门禁

精读 ICML 2026 杰出论文「The Flexibility Trap」以及它平息的 dLM 推理论战：任意顺序生成损害数学与代码推理，而并行解码与填充仍是真正的收益。

takeaway: 让推理链保持自回归，把扩散用在并行解码、填充与可控生成上。

精读 DeepSeek-V3（MLA、DeepSeekMoE）、DeepSeek 的 Native Sparse Attention 与 Qwen3.6 的 Gated DeltaNet 混合架构：注意力不再是单体式的，FFN 成了一个路由器。

takeaway: 2026 年的模型块是压缩、稀疏与循环注意力在专家路由 FFN 之上的逐层混合，所以要按负载成本选配比。

关于 Muon 一线工作的阅读笔记：Keller Jordan 的文章、Moonshot 的 Moonlight scaling 论文、Kimi K2 的 MuonClip，加上我会在哪里采用、在哪里暂缓。

takeaway: 优化器重新成为一个训练配方决策，而算力对齐的比较加上两个诊断量（更新条件数、注意力最大 logit）决定 Muon 在哪里胜出。

关于一个函数 + agent 公路旅行规划器的构建笔记：agent 核验世界，但从不变更路线。

takeaway: 让 agent 做传感器；把路线决策留在确定性代码里。

关于沙箱化 agent 变更的设计笔记：模拟执行、有状态的评测沙箱、先验证后变更的姿态，依次读 ToolEmu、ToolSandbox 与 Voyager，再落到 PiPlan.ai 的模拟沙箱与 SafeRoutes 的 compute-then-commit 不变量门禁上。

takeaway: 在变更落地之前先沙箱化；无法模拟世界时，就让提交本身可逆

提案先行的变更门禁，依次读 MAST、InferAct 与 Agent-as-a-Judge，对照那篇谈 harness 设计与后训练的种子论文展开论辩，再落到 PiPlan.ai 的草稿 → diff → 人工提交流程与 SafeRoutes 的数据面正确性上。

takeaway: 审查门决定哪些轨迹根本存在，所以它是数据质量特性，而不只是安全特性

一次案头分析式的精读：Grok Build，SpaceXAI 的开源 coding-agent harness——内核级沙箱化、分层工具权限门、session JSONL 状态——并基于我自己的 harness 工作给出采用/拒绝的判定。

takeaway: 在事件日志上设门禁，而不是在工具名上；并给轨迹定类型，让它可评分、可回放

精读 BFCL V4、tau-bench 与 ToolSandbox，把它们当作 function calling 四个隐藏决策的 oracle：选择、填参、调用判断与链式调用。

takeaway: 分开评测每个 function calling 决策——先用确定性 oracle，LLM 裁判只用于它们覆盖不到的部分

精读 MAST——第一个有实证基础的多 agent 失败模式分类——加上为什么结果级检查是错误的粒度、运行时监督必须捕捉什么。以 Loop Supervision 构建和它真实抓到的静默样本丢失事件收尾。

takeaway: 多 agent 失败是结构性的，所以监督必须以进程粒度检查世界状态、对事件做分类，而不只是记录停滞。

读 2025-2026 记忆浪潮：形态/功能/动态综述、MemoryAgentBench 的四项能力、Mem0 的 pipeline、RL 训练的记忆管理，映射到 Engram 与一个 Hopfield 重排器设计。

takeaway: 记忆如今是一个有共享词汇表的动作空间，开放问题是评估选择性遗忘

精读 Focus（主动上下文压缩）、AgentFold 与 IterResearch 关于自主上下文管理的工作：长时间的 agent 运行中什么该留、该折叠、该丢，以及压缩在哪里无声地丢失状态。

takeaway: 给模型折叠与剪枝操作，保护不变量，审计每一次压缩。

领域地图加精读：Search-R1、ReTool 与 iStar，以 Landscape 综述（TMLR 2026）与 SFT 记忆、RL 泛化的结果为框架，收尾于一个 agentic RL harness 的设计。

takeaway: 提示暴露能力，RL 改变策略；在奖励可定义、rollout 可负担、差距是策略性而非知识性的地方，采用 agentic RL。

关于 MCP 作为标准化信任边界的阅读笔记：规范到底对安全说了什么，以及工具结果注入的已核实攻击文献（InjecAgent、MCPTox、MCP safety audits）。

takeaway: 标准化把信任边界移到工具层，所以把每条工具描述与工具结果都当作不可信输入。

关于 agent 的应用层空跑 vs 系统级隔离的阅读笔记：从 ToolSandbox 与 ToolEmu 到 Firecracker microVM，最终落在哪一层防御哪种失败模式。

takeaway: 按失败模式选沙箱层——坏计划用空跑，恶意代码用 microVM 隔离。

关于记忆投毒与记忆控制流攻击的综述笔记：写入时注入、休眠载荷、记忆驱动的工具劫持，每一项背后都有已核实的 2026 年研究。

takeaway: 记忆内容在读取时与合法上下文在结构上无法区分，所以防御应放在写入时和工具边界

关于 GLM-5.2、结构化动作信用的 CLI agent 与 SKILL0 的阅读笔记，映射到状态/技能/恢复栈，并谈 PiPlan.ai 的规划器–执行器工作走向何方。

takeaway: 长程能力是一个栈，随着状态与技能变得更持久，运行时产物应该收缩。

关于对照知识图谱检查 agent 输出的综述笔记：从上游的 GraphRAG 到下游的图作裁判验证，落到 GraphJudge——Jerry 的 HackwithBay 3.0 项目。

takeaway: 判定应该由图而不是 LLM 做出，而缺失的拓扑本身就是证据

关于规划中神经符号分工的深读——LLM 处理不适定部分（解析、建模、偏好），经典求解器处理适定的组合核心。精读 LLM+P、ToT/LATS 与约束建模一线（DCP-Bench-Open、CP-Agent），最后落在与 PiPlan.ai 图原生规划相连的提案/审查循环，以及一个进行中的 learned scheduling 对比 CP-SAT 的 benchmark。

takeaway: 把求解器放在规划 agent 的中心，让 LLM 掌管求解的上游与下游的一切。