选择理由代价纯 C / 无脚本体积小、启动快、可控开发体验不如 Python非流式 LLM解析简单、状态机少首字延迟较高历史固定 20 条防 OOM、防 token 爆长期上下文需依赖 MEMORY.md 总结Markdown 当数据库用户可读、可手动 git 化没有索引/查询能力双核硬绑定I/O 与推理真并行灵活性下降Tool 静态注册启动确定性高、便于审计不支持运行时插件两层配置一份固件多场景

我的第二本书终于顺利出版了。这次是和清华大学出版社合作，本书的策划编辑是黄爱萍，正是因为她专业又用心的全程打磨，才让这本书得以圆满落地。黄编辑的极致耐心与细致严谨，不仅让书稿的打磨过程高效顺畅，更让我在创作中收获良多、受益匪浅。接下来是一些碎碎念。

本系列是论文和博客笔记 + 源码学习笔记，主要是关于 基于 LLM 的 GPU 内核代码生成。随着AI辅助开发的模式的流行，大家开始尝试通过LLM来进行算子的生成和迁移，最近发现，PyTorch 发布了 KernelAgent，其尝试利用 Agent 来端到端实现torch模型优化及 Triton算子自动生成，关键做法是：多agent + 静态路由 + 子图分解 + 严格PASS验证 + 硬件pr

我们接下来看看显式PRM和 OPD teacher log-prob 之间的比较。显式PRM+OPD的结合是理论上最优的密集信号方案：PRM负责步骤级诊断和级联阻断，OPD负责步骤内的token 级精细处方。这正是Combine方法的自然延伸方向，但工程成本和PRM训练数据是主要障碍。

一句话总结：advantage = “应该怎么调” (正=增大, 负=减小)；loss = “优化器要最小化的目标” = -advantage。两者符号相反，是 RL 的标准做法: maximize(advantage) ↔ minimize(loss = -advantage)。Step 2中错误"fork"的处理Sequence 级： advantage=+1.0 Policy强化了这个错误↓

这个设计的核心是信号有效性门控: 只有当 hint 可信时才启用 OPD, 只有当 eval 可信时才启用 RL, 两者独立判定, 不互相干扰。_opd_evaluate() 返回:accepted: True/False, <- Hint Judge 多数投票结果teacher_log_probs: [...], <- 教师 forward pass (仅 accepted=True 时有值)

在 AReal 上，OpenClaw 例子默认跑的是 PPO (async + decoupled loss + group/batch reward normalization), 并已预接 GRPO 开关 — 把 n_samples 调高就是 GRPO。算法不是为 OpenClaw 单独设计的，OpenClaw 仅充当 rollout 数据来源；训练侧复用 AReaL 通用的 PPOTrain

这个设计的核心是信号有效性门控: 只有当 hint 可信时才启用 OPD, 只有当 eval 可信时才启用 RL, 两者独立判定, 不互相干扰。_opd_evaluate() 返回:accepted: True/False, <- Hint Judge 多数投票结果teacher_log_probs: [...], <- 教师 forward pass (仅 accepted=True 时有值)

本文基于进行整理和拓展。KernelFalcon 是PyTorch 提出的一个Deep Agents架构系统，该框架主要尝试利用Agent端到端 实现torch模型优化及 Triton算子 自动生成，是首个在全部 250 个 L1/L2/L3 KernelBench 任务上达到 100% 正确率的开源智能体系统。KernelFalcon 代码库位于 github.com/meta-pytorch/

orchestrator 是 KernelAgent 系统中的一个核心组件，负责协调和管理多个工作进程(worker)，实现并行执行任务并从中选择最优结果。Fuser/orchestrator.py 文件实现了 Orchestrator 类，用于多进程协调任务执行。其功能用一句话概括：fork N 个Worker竞赛，首个 PASS胜出，其余终止，产物打包返回。动词选择差异Rewrite：重新编写