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 的持久自动化为主线 持久 Agent：当任务活得比会话长 持久...
一次 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 产生一个对用户可见的最终结果或明确停在阻...
Agent 互操作协议全景：MCP、A2A、AG-UI、ANP 和 Agent Runtime 的分层地图
两篇文章的最终定位 这组文章按一条边界切开：A 文讲外部接口和生态分层，B 文讲内部控制面。A 文回答“Agent 如何和工具、数据、其他 Agent、用户界面、观测评估系统相连”；B 文回答“一个 coding agent 在本机如何循环、拦截、授权、扩展和复盘”。 内容 放在 A 文 放在 B 文 MCP / A2A / AG-UI 作为三类互操作协议，分别解释工具上下文、Agent 间协作、Agent 与 UI 同步 只讨论它们进入 runtime 后如何变成 tool、server、permission、trace ANP / AGNTCY ACP / LMOS / Agora / AITP / agents.json 补全协议生态：去中心化网络、Agent 互联网基础设施、全栈平台、元协议、Agent 经济、Web 发现 不涉及 OpenAI Agents SDK、LangGraph、Google ADK、CrewAI、AutoGen/AG2、LlamaIndex、Semantic Kernel、Pydantic AI、Mastra、Strands...
深翻页的本质：从 RDBMS 到 ES 和 Hive
分页通常是一个很安静的接口参数：page_no、page_size，或者 limit、offset。数据量小时，它几乎没有存在感；等列表长到几十万、几百万行之后，同一条 SQL 只是把 OFFSET 往后挪了一点，延迟却会突然变得难看。 问题不在“翻页”这个动作本身，而在系统被要求从一个有序结果集里跳过很长的前缀。RDBMS、Elasticsearch、Hive 的表现各不相同，底层代价却很接近：先把前面的候选算出来，再把它们丢掉。 这也是深翻页最容易被误解的地方。它不只是 SQL 写法问题，还牵涉访问路径、排序稳定性、产品交互，以及底层系统是否需要跨节点合并结果。一个可用的分页方案，往往先从产品语义开始，而不是从 LIMIT 990000, 1000 开始。 深翻页的成本来自“计算前缀再丢弃前缀”。优化要么把前缀变窄，要么把“第 N 页”改成“从某个锚点继续”，要么提前把结果集物化成可跳转目录。 一个大表实验 有一个很典型的大表实验：表里大约 1000 万行，按 status 过滤后命中约 100 万行。测试环境是本地硬盘，慢查询阈值按 100ms 估算。几条查询的结果很...
Agentic Flow 不是 Harness：控制流、运行时与全栈研究模型
Agentic Workflow 的讨论里，Flow 是一个多义词，比 Harness 更容易被误用。 本文里的 Flow 不是某个框架的官方统一术语，而是一个作者抽象。它把 Anthropic 和 LangGraph 所说的 workflow、OpenAI Agents SDK 所说的 orchestration、CrewAI 的 Flows、Google ADK 的 graph-based workflows，以及研究实验里的循环、路由和门禁，统一放到“控制流规格”这一层讨论。 这个限定很重要。CrewAI 的 Flow 是产品概念；OpenAI 文档谈的是 agent orchestration；LangGraph 和 ADK 更常使用 workflow、graph、node、edge 这组词。它们不是同一个标准术语，但都触及同一个工程问题：任务的入口、路径、分支、循环、状态和终止条件，应该留在提示词里，还是成为可检查、可复用、可恢复的控制结构。 Harness 像运行时底座：它负责把模型、工具、文件系统、权限、日志、状态、检查点和评测装进一个可控环境。Flow 像控制规格...
持久 Agent：当任务活得比会话长
聊天式 agent 的生命周期等于一次会话：用户发起，模型循环，产出结果，上下文丢弃。持久 Agent（persistent agent / durable agent）指的是另一类系统：它承接的工作生命周期长于单次模型调用、长于单个上下文窗口、长于单个进程，甚至长于发起它的那台设备。 一个夜间跑依赖升级的 agent、一个跨三天迁移代码库的 agent、一个每周整理 issue 的 agent，都属于这一类。它们的共同点是：任务的时间尺度和会话的时间尺度脱钩了。这篇文章给「持久」下一个可操作的定义，并整理支撑它的三根支柱。 本文与已有文章的边界 已有文章 主要讨论 与本文的关系 ReAct：推理与行动交织的 Agent 循环原型 单条轨迹内的推理-行动循环 ReAct 是内环，本文讨论内环之外怎么让任务活下去 Agent 全景指南 Agent 范式演化与高可用 提供范式背景，本文聚焦持久性这一个维度 Goal 模式深度研究 完成谓词、循环停止条件 完成谓词决定持久任务什么时候可以死 Harness Engineering：长程 Agent 的工程化底...
