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 层预处理(在工具拿到输入之前), 输入校验(展示权限对话框之前), 和实际写入(用户同意之后)。每个阶段各自处理一类问题, 且刻意保持了特定的同步/异步边界。
Claude Code有一个从未出现在任何文档中的模式,在这个模式下,它会系统性地抹除一切AI参与的痕迹。不写Co-Authored-By,不写Generated with Claude Code的footer,甚至连system prompt里都不告诉模型它自己是什么型号。这个模式叫Undercover Mode,只存在于Anthropic内部构建版本中,外部用户永远看不到它,因为整个功能在公开构建时会被dead code elimination彻底剔除。
从行为推断,这个机制的存在意味着Anthropic员工日常使用Claude Code向公开仓库提交代码。如果没有某种保护措施,commit message里可能出现未发布模型的代号,PR描述里可能暴露内部项目名称,system prompt里的模型标识可能通过某种方式泄露。Undercover Mode就是为了堵住这些口子。
Claude Code 执行复杂任务时会并行派生多个子 agent，每个都需要父对话的完整上下文。假设父对话积累了 100K token，并行 3 个子 agent，朴素实现要付 300K 的输入费用。
熟悉 LLM 推理优化的人会立刻想到：这不就是 KV Cache 共享的问题吗？多个请求如果前缀相同，Attention 层的 Key/Value 可以复用，省掉重复计算。Anthropic 把这个能力以 Prompt Cache 的形式暴露给了 API 用户，对缓存命中的前缀部分打一折。但前提是多个请求的前缀字节完全一致。Claude Code 的 fork 子 agent 被刻意构造成彼此之间 99% 以上的字节相同，3 个子 agent 的实际输入成本大约只有 120K 等价（100K 全价 + 2 × 100K × 10%）。