从零配置 GitHub Actions 自动部署 Hexo 博客
Hexo 博客最容易卡住的地方，通常不是 hexo generate 本身，而是生成后的 public/ 怎么稳定发布。手动 hexo deploy 能跑，但它把构建环境、网络、Git 凭据都绑在本地机器上。换一台电脑、换一个网络、换一个 Node 版本，部署结果就可能变得不可预测。 更稳的做法是把部署流程写进仓库：源码仓库只保存 Markdown、主题配置、依赖锁和 workflow；每次 push 到 main，GitHub Actions 在云端安装依赖、生成静态站点，再把 public/ 推送到 GitHub Pages 仓库。 这篇文章记录从零配置这套流程的完整路径。例子以当前博客为准： 源码仓库：magicliang/hexo-blog 站点仓库：magicliang/magicliang.github.io Hexo 版本：8.1.2（Butterfly 5.x 主题） 包管理器：Yarn 1 构建命令：npx hexo clean && npx hexo generate 部署方式：peaceiris/actions-gh-pages@v4 推...
LeCun 视角下的数据瓶颈、电子果蝇与自主学习
LeCun 对 LLM 路线的批评，表面上常被说成“文本数据不够”。这个说法太浅。真正的问题不是网页快不够了，而是数据的形态、训练目标和学习闭环都不对。 更多文本可以让模型更会说，更多代码可以让模型更会写程序，更多用户交互可以让模型更会适应产品场景。但 human-level intelligence 需要的不只是更大的语料池。它需要系统从观察和行动中持续学习，能把失败转成经验，能把经验沉淀为世界模型，而不是部署后基本冻结。 电子果蝇看起来离 LLM 很远，其实刚好提供了一个反面参照：有连接图不等于有智能，有大模型不等于有世界模型。结构必须进入动态闭环，才能解释行为。 系列总纲见：LeCun 关于 LLM 与 AGI 的观点总集成。 文本数据瓶颈说的是什么 Villalobos 等人的《Will we run out of data?》估计，如果 LLM 按既有趋势继续扩大，训练数据需求会在 2026 到 2032 年间接近公共人类文本的可用存量。这个判断不是说“明天模型就没法训练”，而是指出公共高质量文本不可能无限增长。 Chinchilla scaling law 进一步强...
LeCun 视角下的 VLA、机器人与具身智能边界
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 边界：贝叶斯推断与因果问题
LeCun 说 LLM 不是通往人类级智能的主路，最容易被误读成一句情绪判断。真正值得展开的是技术边界：LLM 到底能推断什么，不能推断什么；它的上下文学习为什么像贝叶斯推断；它为什么又不是一台真正的世界后验机器；它能处理因果话语，为什么仍然缺少可行动的因果模型。 这篇把 LeCun 对 LLM 的批评放到三个层面上：语言分布、贝叶斯式上下文学习、因果与规划。这样看，LLM 的强大和边界可以同时成立。 系列总纲见：LeCun 关于 LLM 与 AGI 的观点总集成。 LeCun 批评的不是“统计” 许多反驳 LeCun 的说法会走向一个靶子：LLM 当然不只是背语料，它们会泛化、会推理、会写代码、会在上下文中学新任务。这个反驳本身没错，但它没有击中 LeCun 的重点。 LeCun 并不否认统计学习很强。深度学习本身就是统计学习。LLM 的成功也确实说明，大规模自监督学习能从文本里抽出大量结构。问题在于：这种结构主要落在语言和陈述性知识空间里，而不是落在可行动的世界状态空间里。 换成训练目标，就是这条公式： 1pθ(next token | context) 自回归 LLM 学...
LeCun 的世界模型与 JEPA 路线详解
LeCun 对 LLM 的批评，如果只读成“语言模型不够好”，会漏掉最重要的一半。他真正想推的是另一套智能体架构：系统不以文本续写为中心，而以世界模型为中心；不以生成逼真的表面为目标，而以预测行动相关的未来状态为目标；不靠一句话计划模拟智能，而靠内部模型、成本函数、记忆和动作选择形成闭环。 JEPA，Joint Embedding Predictive Architecture，正是这套路线里最有 LeCun 个人印记的技术部件。它的目标不是替代所有生成模型，也不是给“世界模型”注册一个新名字。它是在回答一个更窄的问题：如果世界本身充满高熵细节，智能体怎样学习那些对行动和规划真正有用的结构。 系列总纲见：LeCun 关于 LLM 与 AGI 的观点总集成。 世界模型不是视频生成器 “世界模型”这个词很容易被误读。近几年许多系统能根据文本生成视频、三维场景或交互环境，于是“world model”常被理解成“能生成一个看起来像世界的东西”。这只是其中一种可能形态，不是 LeCun 关心的核心。 LeCun 语境里的 world model，功能更接近 model-based co...
LeCun 关于 LLM 与 AGI 的观点总集成
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、能选择动...
Deli AutoResearch：从论文流水线到研究品味
调研截至：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：把 YAGNI 写进 Coding Agent 的行为层
Ponytail 带着明显的玩笑式包装：为 AI 编程代理配置一组“懒得过度设计”的资深工程师偏好。再往下看，它解决的是一个更具体的工程问题：当模型默认倾向于多写文件、多引依赖、多造抽象时，怎样在代码生成前插入一层可重复执行的复杂度刹车。 截至 2026-06-17，DietrichGebert/ponytail 的 main 分支最新提交是 45f7d2f，公开 README 已经把项目定位成一个跨宿主的 Agent skill 分发包。它不是传统意义上的库，不提供业务 API；核心资产是一组行为规则、宿主适配器、生命周期 hook、模式切换命令，以及配套 benchmark。 Ponytail 不是少写代码提示词 Ponytail 的核心规则放在 skills/ponytail/SKILL.md。这份 skill 的主线是一条六级阶梯： 123456需求是否必须存在 -> 标准库能不能解决 -> 平台原生能力能不能解决 -> 已安装依赖能不能解决 -> 能否一行完成 -> 末端才写最小可用实现 这条阶梯的意义不在于“让模型懒一点”，而...
Loop Engineering：从 Boris 的 /loops 到持久 Agent 工程
本文的 Loop Engineering 取工程视角：持久 Agent 自动化的工程抽象，包括定时触发、长期运行、多会话并发、可恢复状态、权限边界、验证证据和人工升级路径。Claude 官方在 Getting Started with loops 里给出的 4 种循环分类（Turn-based / Goal-based / Time-based / Proactive）是操作视角的互补坐标系，见后文「循环的 4 种触发形态」。 本文与已有文章的边界 本博客已有 Agent Loop、Ralph Loop、Goal、Harness Engineering、Hook 体系等相邻文章，本文专门讨论 Loop Engineering。和已有文章的边界： 已有文章 主要讨论 与本文的关系 AI Coding Agent 的 Hook、Loop 与插件体系 Codex、Claude Code、OpenCode、OMC 的运行时结构 写到 loop 与 hook，但没有以 /loops 和 Routines 的持久自动化为主线 Goal 模式深度研究 Goal、Ralp...
一次 AI Coding Agent Turn 的上下文生命周期：Hook、Tool、Skill、Compact 与 Subagent
一次 agent turn 不是一次模型调用。用户提交一条消息以后，运行时可能先补项目规则和 Skill 目录，再发起模型请求；模型返回工具调用，权限层批准或拒绝，工具结果追加回历史，模型随后继续判断。这个小循环可以重复很多次，直到验证通过、需要用户输入，或者运行时决定停止。 因此，理解 coding agent 的运行时，不能只看 observe -> act -> observe。还要追踪每一类信息何时进入上下文、以什么身份进入、何时失效，以及 compact 和 subagent 怎样改变信息边界。 讨论范围限定为一次 turn 的上下文生命周期。Skill 的跨产品加载差异见 AI Coding Agent 的 Skill 加载机制深度解析，messages 的追加、裁剪、摘要和外化见 上下文管理全景，MCP、A2A 与 AG-UI 的协议分层见 Agent 互操作协议全景。这里不再重做产品图谱，只保留能解释当前 turn 的官方机制。 Turn 的边界 在本文中，turn 从用户输入进入运行时开始，到主 agent 产生一个对用户可见的最终结果或明确停在阻...
