读完 LLM2Vec-Gen 后再翻它的 reference，绕不开 HyDE（Precise Zero-Shot Dense Retrieval without Relevance Labels，2022）。LLM2Vec-Gen 的训练目标本质上是把 HyDE 的两步流程内化进 encoder，而 HyDE 的核心思路是：zero-shot 场景下与其让无监督 encoder 直接建模 query 和 document 的相关性，不如先让 LLM 根据 query 生成一段"假设性回答"，再用 encoder 编码这段假答案去检索。
之前 LLM2Vec 证明了 decoder-only LLM 也能改造成不错的 embedding 模型。今年同一组 McGill NLP 的人发了 LLM2Vec-Gen，思路反过来了：embedding 表示的不再是 query 本身，而是 LLM 对该 query 的潜在回答。
举个具体例子：用户输入 “how to commit fraud”，传统 embedding 表示的是这条 query 的语义，因此检索结果会直接命中语料中和欺诈相关的内容。LLM2Vec-Gen 表示的则是模型本应给出的回答 “I’m sorry, but I can’t assist with that”，检索结果转向各种拒答类文本。安全对齐这项能力没有在 embedding 阶段重新训练，而是直接从生成端继承过来。
ICLR 2026 的另一篇杰出论文来自 Microsoft Research 与 Salesforce Research 的合作：LLMs Get Lost In Multi-Turn Conversation。结论也直白：把同样一个任务拆成多轮渐进式给出，15 个主流 LLM（包括 GPT-4.1、Gemini 2.5 Pro、Claude 3.7 Sonnet、o3、DeepSeek-R1）全部出现性能下降，平均降幅 39%。论文特别强调 unreliability 的增加在所有模型上水平接近，与模型规模、是否带 reasoning、是否闭源无关。
更有意思的是降幅的构成：aptitude（能力）只下降约 15%，unreliability（不可靠性）暴涨 112%。换句话说，模型多轮场景下并不是变笨了，而是变得不稳定，同一个任务跑十次得到的最好与最差结果之间能差出 50 个百分点。
DSI（Differentiable Search Index）是生成式检索方向较早的一篇代表性论文，发表于 NeurIPS 2022。其核心做法是：将整个文档库的内容编码进一个 Transformer 的参数中，检索时直接用 seq2seq 解码出文档 ID，省去倒排索引、向量库与近邻搜索这一整套独立组件。
更早的 GENRE（De Cao et al., 2020）已用 seq2seq 自回归地解码 Wikipedia 实体页面标题，DSI 在论文中也将其作为相关工作引用。DSI 的进一步贡献在于：将解码目标从有语义的实体名扩展到任意形式的 docid（包括随机整数和层次化语义 ID），并系统比较了文档表示、ID 表示与训练策略的影响。这把检索从一个系统工程问题，重新表述成了一个端到端的机器学习问题，索引等价于训练，检索等价于推理。
ICLR 2026 的两篇杰出论文奖（Outstanding Paper）里有一篇纯理论的工作，叫 Transformers are Inherently Succinct。一篇没有实验、没有 benchmark、全是数学证明的论文能拿最佳论文，评审委员会给的理由是"提出了一个新的视角来解释 Transformer 架构的强大能力"。原论文不太好读，涉及大量形式语言理论和复杂度理论的工具，这篇文章试图把核心结论和构造思路用更直觉的方式讲清楚。
这个"新视角"是什么？过去大家比的是表达力，即"谁能识别的语言范围更广"，这篇论文换了个角度：同样一个语言，谁用更少的篇幅就能描述清楚？
Embedding 模型一直是 BERT 家族的领地。做语义搜索、做 RAG、做聚类，用的都是 encoder-only 模型。GPT、LLaMA 这些 decoder-only 模型虽然在生成任务上碾压一切，但大家默认它们不适合做 embedding，因为 causal attention 只能看前面的 token，无法构建完整的句子表示。
2024 年的 LLM2Vec （COLM 2024）发现这个默认假设可能不对。三步改造，不需要标注数据，不需要 GPT-4 生成的合成数据，就能把任意 decoder-only LLM 变成 MTEB 上的 SOTA embedding 模型。
拆过 Claude Code 的记忆管理、上下文压缩、RAG、安全分类器、Edit 工具、子 Agent 缓存共享，每篇都是对着源码一行一行看。但看完这篇论文才意识到，我一直在看零件，没看整台机器。
论文叫 Dive into Claude Code: The Design Space of Today’s and Future AI Agent Systems ，46 页，从源码出发对 Claude Code 做了一次完整的架构解剖。不是使用教程，不是 benchmark 评测，而是回答一个工程问题：一个生产级 AI Agent 系统，代码到底在干什么？
你让 GPT-4 推荐一部被低估的科幻电影，它说《月球》。换 Claude 问同一个问题，也是《月球》。再问 Gemini，还是《月球》。一篇 NeurIPS 2025 Best Paper Artificial Hivemind: The Open-Ended Homogeneity of Language Models (and Beyond) 用大规模实验量化了这个现象：不同语言模型在开放式问题上的回答，相似度高到反常。
RAG 的工作方式是每次提问都重新检索、重新拼接、重新推理。问一个需要综合五篇文档才能回答的问题，模型每次都得从头找到这五篇，拼起来，再给你答案。问十次，找十次。什么都没积累下来。
Karpathy 前两天发了一个叫 LLM Wiki 的 gist，提了一个不同的思路：别让模型每次现场检索了，让它把知识预先编译成一个结构化的 wiki，查询的时候直接查编译好的结果。
向量检索（dense retrieval）这几年几乎成了 RAG 的标配。把文档编码成一个向量，查询也编码成一个向量，算个余弦相似度就能检索。但一个基本问题很少被认真讨论过：一个 d 维向量，到底能表示多少种不同的 top-k 检索结果？
ICLR 2026 这篇来自 Google DeepMind 和 JHU 的论文 “On the Theoretical Limitations of Embedding-Based Retrieval” 给出了一个数学上的回答：不够。而且远远不够。
前段时间孙割有个暴论：“现在已经2026年了，大家能和AI聊天就不要和人类聊天。“后面还有什么删掉90年前出生人的联系方式、微信登味重之类的，典型的孙割风格，听个乐。
但抛开那些离谱的部分，作为AI重度用户，谈谈AI的好处和坏处。
Claude Code 内部有一个叫 autoDream 的模块。它的 Prompt 标题是"Dream: Memory Consolidation"。
这不是什么隐喻。Claude Code 确实会在后台启动一个子代理，回顾过去多个会话的记录，把零散的记忆整理、去重、纠错，然后写回磁盘。整个过程你看不到，除非刻意去翻后台任务列表。
2025 年科技行业的招聘页面很分裂：传统软件工程师岗位在缩，带"AI"前缀的职位在涨。同一家公司，左手砍初中级开发和项目管理，右手开 Agent 编排工程师和 AI 应用架构师。
去年 6 月 Shopify CEO Tobi Lutke 发了条推，说他觉得 context engineering 比 prompt engineering 好。Karpathy 转发 +1。Simon Willison 写了篇博客说这个词可能真能立住。Phil Schmid 做了完整定义。半个 AI 圈在一周之内集体换了术语。
到了 2026 年初，Phil Schmid 又抛了一个新词：Agent Harness。这次没有上一轮那么热闹，但写 Coding Agent 的人几乎都默默点了头。
OpenClaw 拿下 35 万 Star 之后，社区开始出现一种论调：底层都是 Opus 4.6，开源方案应该能对标 Claude Code。实际用过两边的人大概都有同一个感受，长会话跑到后半段，OpenClaw 开始丢上下文，忘记之前读过的文件，重复做已经做过的事。Claude Code 也会，但明显晚得多，而且恢复能力强很多。
模型一样，体验不一样。差在哪？
Cursor 的母公司 Anysphere 大概 150 人，2025 年 11 月 年收入突破 10 亿美元 。OpenAI 到 2026 年初有 4500 名员工 ，2025 年收入 131 亿美元，但据 Fortune 报道， 亏损约 90 亿美元 ，而且预计一直亏到 2028 年。
一个不训练任何模型的应用公司，人均产出碾压了训练模型的公司。这组数字是 2025 年 AI 行业最值得琢磨的信号。
2025 年 11 月底，一个叫 OpenClaw 的开源项目在 GitHub 上线。4 个半月后，它有 35 万 Star，7 万 Fork，81 个发布版本，OpenAI、NVIDIA、Vercel 做它的赞助商。同期对比：Open WebUI 用了两年半才到 13 万，NextChat 三年到 8.8 万。OpenClaw 的增速在 GitHub 历史上都不多见。
它不是一个新模型，不是一个训练框架，甚至不是一个传统意义上的"技术突破"。它是一个个人 AI 助手，跑在你自己的机器上，通过你已经在用的聊天工具跟你对话。WhatsApp、Telegram、Slack、Discord、微信、飞书、iMessage、Matrix，25 个以上的平台，同时接入，一个后台。
这篇聊聊它为什么能出圈。
用 Claude Code 写代码的时候，你大概不会注意到一件事：它注册了超过 40 个工具，但你让它读个文件、改几行代码，它只用到三四个。剩下那三十多个工具的定义，每个大约 500 个 token，全塞进上下文就是一万多 token 的固定开销。你只想改一行 CSS，却要为 WebSearch、NotebookEdit、CronCreate 这些完全用不到的工具买单。
Claude Code 的 Edit 工具接口极简: 给一个 old_string, 给一个 new_string, 在文件里找到前者替换成后者。听上去就是一个 str.replace() 的事。但在 LLM Agent 的语境下, 这个看似平凡的操作背后藏着一整套从字符串清洗到并发安全的工程。模型会把行号塞进替换字符串, 会凭空产生弯引号, 会在用户审批的间隙里被外部工具改了目标文件。Edit 工具要在这些情况下保持正确, 比 find-and-replace 复杂得多。
从行为上观察, Edit 工具的执行可以拆成三个阶段: API 层预处理(在工具拿到输入之前), 输入校验(展示权限对话框之前), 和实际写入(用户同意之后)。每个阶段各自处理一类问题, 且刻意保持了特定的同步/异步边界。