守株阁

Hexo 博客最容易卡住的地方，通常不是 hexo generate 本身，而是生成后的 public/ 怎么稳定发布。手动 hexo deploy 能跑，但它把构建环境、网络、Git 凭据都绑在本地机器上。换一台电脑、换一个网络、换一个 Node 版本，部署结果就可能变得不可预测。 更稳的做法是把部署流程写进仓库：源码仓库只保存 Markdown、主题配置、依赖锁和 workflow；每次 push 到 main，GitHub Actions 在云端安装依赖、生成静态站点，再把 public/ 推送到 GitHub Pages 仓库。 这篇文章记录从零配置这套流程的完整路径。例子以当前博客为准： 源码仓库：magicliang/hexo-blog 站点仓库：magicliang/magicliang.github.io 包管理器：Yarn 1 构建命令：npx hexo clean && npx hexo generate 部署方式：peaceiris/actions-gh-pages@v4 推送 public/ 目标结构 最终结构不是在一个仓库里同时维护...

LeCun 对 LLM 路线的批评，表面上常被说成“文本数据不够”。这个说法太浅。真正的问题不是网页快不够了，而是数据的形态、训练目标和学习闭环都不对。 更多文本可以让模型更会说，更多代码可以让模型更会写程序，更多用户交互可以让模型更会适应产品场景。但 human-level intelligence 需要的不只是更大的语料池。它需要系统从观察和行动中持续学习，能把失败转成经验，能把经验沉淀为世界模型，而不是部署后基本冻结。 电子果蝇看起来离 LLM 很远，其实刚好提供了一个反面参照：有连接图不等于有智能，有大模型不等于有世界模型。结构必须进入动态闭环，才能解释行为。 系列总纲见：LeCun 关于 LLM 与 AGI 的观点总集成。 文本数据瓶颈说的是什么 Villalobos 等人的《Will we run out of data?》估计，如果 LLM 按既有趋势继续扩大，训练数据需求会在 2026 到 2032 年间接近公共人类文本的可用存量。这个判断不是说“明天模型就没法训练”，而是指出公共高质量文本不可能无限增长。 Chinchilla scaling law 进一步强...

Vision-Language-Action，VLA，是 LLM/VLM 路线进入机器人之后最自然的形态：模型看见图像，读懂指令，然后输出动作。RT-2、OpenVLA、π0、FAST 这一串工作证明，大规模视觉语言预训练确实能把语义知识迁移到机器人控制里。 但从 LeCun 的标准看，VLA 还不是完整答案。它解决了一部分“语言如何接到动作”的问题，却没有彻底解决“系统如何预测行动后果、如何在内部比较多个未来、如何从失败中更新世界模型”的问题。 这篇把 VLA 放到 LeCun 的世界模型路线里看：它很重要，但更像 actor、接口或快速反应层，不像具身 AGI 的中枢。 系列总纲见：LeCun 关于 LLM 与 AGI 的观点总集成。 VLA 为什么突然重要 机器人长期有一个老问题：低层控制可以很强，但语义泛化很弱。传统机器人系统可以把一个固定零件从固定位置抓到固定盒子里，却很难理解“把苹果放到数字 3 上”“拿起能当锤子的东西”“把桌面收拾干净”这种开放语言指令。 大规模 VLM 改变了这件事。互联网图文数据里包含大量对象、属性、关系、用途和场景知识。VLA 的基本想法是...

LeCun 说 LLM 不是通往人类级智能的主路，最容易被误读成一句情绪判断。真正值得展开的是技术边界：LLM 到底能推断什么，不能推断什么；它的上下文学习为什么像贝叶斯推断；它为什么又不是一台真正的世界后验机器；它能处理因果话语，为什么仍然缺少可行动的因果模型。 这篇把 LeCun 对 LLM 的批评放到三个层面上：语言分布、贝叶斯式上下文学习、因果与规划。这样看，LLM 的强大和边界可以同时成立。 系列总纲见：LeCun 关于 LLM 与 AGI 的观点总集成。 LeCun 批评的不是“统计” 许多反驳 LeCun 的说法会走向一个靶子：LLM 当然不只是背语料，它们会泛化、会推理、会写代码、会在上下文中学新任务。这个反驳本身没错，但它没有击中 LeCun 的重点。 LeCun 并不否认统计学习很强。深度学习本身就是统计学习。LLM 的成功也确实说明，大规模自监督学习能从文本里抽出大量结构。问题在于：这种结构主要落在语言和陈述性知识空间里，而不是落在可行动的世界状态空间里。 换成训练目标，就是这条公式： 1pθ(next token | context) 自回归 LLM 学...

LeCun 对 LLM 的批评，如果只读成“语言模型不够好”，会漏掉最重要的一半。他真正想推的是另一套智能体架构：系统不以文本续写为中心，而以世界模型为中心；不以生成逼真的表面为目标，而以预测行动相关的未来状态为目标；不靠一句话计划模拟智能，而靠内部模型、成本函数、记忆和动作选择形成闭环。 JEPA，Joint Embedding Predictive Architecture，正是这套路线里最有 LeCun 个人印记的技术部件。它的目标不是替代所有生成模型，也不是给“世界模型”注册一个新名字。它是在回答一个更窄的问题：如果世界本身充满高熵细节，智能体怎样学习那些对行动和规划真正有用的结构。 系列总纲见：LeCun 关于 LLM 与 AGI 的观点总集成。 世界模型不是视频生成器 “世界模型”这个词很容易被误读。近几年许多系统能根据文本生成视频、三维场景或交互环境，于是“world model”常被理解成“能生成一个看起来像世界的东西”。这只是其中一种可能形态，不是 LeCun 关心的核心。 LeCun 语境里的 world model，功能更接近 model-based co...

Yann LeCun 近几年关于 LLM 和 AGI 的所有争议，核心不在“LLM 有没有价值”。他的判断一直更窄，也更尖锐：大语言模型会成为重要工具，会进入编程、写作、搜索、办公和人机交互，但把下一个 token 预测继续放大，不能自然推出人类级智能。 这个判断背后有一整套架构观。LeCun 不喜欢 AGI 这个词，更偏好 human-level intelligence、advanced machine intelligence 或 AMI。原因是“general”容易把问题说空，好像一个系统只要在足够多的文本任务上胜出，就已经接近通用智能。LeCun 真正在意的是另一组能力：理解物理世界，形成可预测的世界模型，拥有工作记忆和长期记忆，能推理，能分层规划复杂行动，并且能在部署后从观察和行动中继续学习。 LeCun 的观点不能压扁成“LLM 没用”，也不能压扁成“JEPA 必胜”。它更像一张系统架构图：LLM 是强大的语言接口、知识压缩器和工具层；完整智能体还需要能预测行动后果的 world model、能比较未来的 cost module、能保存经验的 memory、能选择动...

调研截至：2026-06-19。这里追踪的是 Deli Chen 在 2026 年 6 月公开展示的 AutoResearch / paper_writing 项目材料，包括 X 更新、AutoResearch 框架页、V2 博文、paper_writing skill group 页和论文索引页。文中所有页数、引用数、评分和耗时均按项目页面自述记录，不视为独立外部评测。 Deli Chen 这次公开出来的东西，确实可以拆成两个可复用组件，但它们不是两个完全同形的 skill： 组件 更准确的定位 公开状态 核心用途 Deli_AutoResearch 长程自主研究框架协议 公开完整 SKILL.md 约束多天到多周任务里的状态、停滞、看护、方向切换和子 agent 编排 paper_writing 科学论文写作 skill group 公开方法页 把文献召回、结构写作、实验设计、图表、模拟审稿串成论文生产流水线 V2 博文写的是“三篇论文、941 条引用、190 页、平均模拟评审 8.5/10、约 38 小时”。论文索引页在 2026-06-17 又...

Ponytail 带着明显的玩笑式包装：为 AI 编程代理配置一组“懒得过度设计”的资深工程师偏好。再往下看，它解决的是一个更具体的工程问题：当模型默认倾向于多写文件、多引依赖、多造抽象时，怎样在代码生成前插入一层可重复执行的复杂度刹车。 截至 2026-06-17，DietrichGebert/ponytail 的 main 分支最新提交是 45f7d2f，公开 README 已经把项目定位成一个跨宿主的 Agent skill 分发包。它不是传统意义上的库，不提供业务 API；核心资产是一组行为规则、宿主适配器、生命周期 hook、模式切换命令，以及配套 benchmark。 Ponytail 不是少写代码提示词 Ponytail 的核心规则放在 skills/ponytail/SKILL.md。这份 skill 的主线是一条六级阶梯： 123456需求是否必须存在 -> 标准库能不能解决 -> 平台原生能力能不能解决 -> 已安装依赖能不能解决 -> 能否一行完成 -> 末端才写最小可用实现 这条阶梯的意义不在于“让模型懒一点”，而...

调研截至：2026-06-14。公开检索没有找到 Boris Cherny 对 “Loop Engineering” 的完整定义文本；可核实材料集中在他对 Claude Code /loops 和 Routines 的展示与推荐。这里把 “Loop Engineering” 限定为这类持久 Agent 自动化的工程抽象：定时触发、长期运行、多会话并发、可恢复状态、权限边界、验证证据和人工升级路径。 查重结果 本博客已有 Agent Loop、Ralph Loop、Goal、Harness Engineering、Hook 体系等相邻文章，但还没有专门讨论 Loop Engineering 的博文。关键词检索覆盖了： Loop Engineering loop engeering loop engineering 循环工程 反馈回路 Agent Loop Ralph Loop 相邻文章有这些： 已有文章 主要讨论 补位关系 AI Coding Agent 的 Hook、Loop 与插件体系 Codex、Claude Code、OpenCode、OMC 的运行...

内部控制面边界 把 AI coding agent 理解成“会写代码的模型”，很容易低估真正的工程难点。模型只是运行时里的一个决策器；让它长时间稳定地改代码、跑命令、处理错误、收敛到可验证结果，靠的是更外层的控制面。 这层控制面通常由五件东西组成： Agent loop：一次任务怎样从观察、计划、行动、再观察，走到验证和停止。 Hook：在关键生命周期点插入确定性规则、审计、阻断、上下文补充和通知。 Plugin / Skill / MCP server：把工具、上下文、工作流、文档、浏览器、团队协作能力装进运行时。 Sandbox / Permission：决定哪些动作可以自动执行，哪些必须询问，哪些直接拦截。 Trace：把循环、hook 决策、工具调用、错误、重试和验证证据留下来，供复盘和调试。 协议层和运行时层要先分清。MCP、A2A、AG-UI 这类协议主要回答“对外怎么互通”：客户端、服务器、工具、资源、提示词、传输、能力协商和界面事件如何标准化。Hook、loop、plugin、sandbox 和 trace 回答的是“内部怎么行动”：一个 agent 何时调用...