把回答拆成观察、推断与猜测

在提问”你到底知道什么”时，DeepSeek 的回复方式出乎作者意料：它没有一股脑给结论，而是主动把内容分成”观察””推断”和”猜测”三档。这种自我分层，让作者得以分辨哪些是模型确有依据的陈述，哪些只是基于训练分布的合理推测。

DeepSeek 在对话中自报了若干关键身份信息：它是当前最新版本，知识截止于 2025 年 5 月，并未被标注为推理模型，并提到一次 2026 年 7 月 21 日的导出。它还主动列出了一组结构参数——256 个专家、6710 亿/370 亿的参数量，以及多头潜在注意力（MLA）、混合专家（MoE）、监督微调（SFT）、基于人类反馈的强化学习（RLHF）等技术创新。

模型的认知边界在哪里

这篇”访谈”最有价值的部分，是厘清了模型的盲区。DeepSeek 明确承认：它看不到自己的权重、专家路由、注意力图，也看不到输出的逻辑值（logits）。换句话说，它对自己内部机制的解释，本质是”生成的文字”，而非对真实权重的直接观测。作者据此提醒读者：聊天输出不能当作证据。要核实架构数字，仍须回到 arXiv 上的论文；聊天窗口更适合用来建立对模型行为与提示词直觉的理解。

一套可复用的探查方法

作者把整个流程做成固定模板：提问、模型短答、作者即时点评、结构图示、要点总结，再抛出一个钩子引导读者思考。同一套方法此前已用于 Qwen 3.8-Max-Preview 与 Kimi K2.6——先让模型自述记忆、工具、上下文与幻觉处理方式，再拿已发表研究交叉验证。

对普通使用者而言，这种”自我访谈”思路也有启发：当模型说出”我是怎么想的”时，把它当作一位知识丰富但看不见自己大脑的受访者，而不是一份权威说明书。真正可信的数字，永远写在论文和权重里，而不是对话气泡中。

来源：manish.sh（”Inside LLMs”系列，作者 manish.sh）

这套方案的出发点是一个简单的问题——如何把单次 LLM 调用扩展成一个能规划、能执行、能恢复、能自证的系统。答案是“组合”：用多个小而可测的原语，通过一个很薄的编排层串起来。每个原语都对应一种“幼稚智能体”的典型失败模式。

类型化工具。 LLM 经常会编造不存在的工具参数。与其在提示词里写死参数格式，不如用 Pydantic 这类数据模型给每个工具声明参数结构，让模型输出自动校验。工具注册时还要带上成本提示，方便后续做预算控制。

规划 DAG。 naive 智能体按顺序执行工具调用，但很多子任务其实互不依赖。方案让 Planner 先输出一个依赖图（DAG），把可以并行的节点同时跑起来。以“对比三座城市”为例，人口、时区、城市摘要这九次查询彼此独立，可以并发执行，最后由聚合节点汇总报告。并发能显著缩短等待时间，但方案也加了信号量限制最大并发数，避免一次性触发太多 LLM 调用导致限流或成本暴涨。

分层记忆 + 检索预算。 把所有历史记录、工具输出都塞进上下文，既浪费 token，也会稀释模型对当前目标的关注。方案把记忆分为工作记忆、语义记忆和情景记忆，并设定一个字符预算硬上限。检索时优先拉取与当前目标最相关的情景记忆，预算耗尽时显式截断，而不是悄悄丢掉关键信息。对语义相似度，使用 384 维的句向量，而不是简单的词袋匹配，因为“法国著名地标”和“埃菲尔铁塔”在字面上几乎没有重叠。

多级验证。 不是每个错误都值得让 LLM 当“裁判”。方案把验证拆成两层：先跑廉价、确定性的结构检查（比如报告是否遗漏了请求的城市），只有幸存者才进入昂贵的 LLM 评审。这样可以在零 token 开销的情况下拦截大量常见错误。

角色分离。 同一个提示词既做规划又做执行又做反思，容易互相干扰。方案把任务拆给三个角色：Planner 负责根据目标和工具列表生成 DAG；Worker 负责执行；Critic 负责判断结果是否合格。每个角色有独立的系统提示词和职责边界。

多维预算。 成本、延迟、token 用量都可能失控。方案给每个节点标注成本提示，并在运行时监控多个维度，超过阈值时触发优雅降级，而不是等到账单爆炸才反应过来。

为了让这套系统可测试、不绑定厂商，方案还引入了一个 LLMProvider 抽象层和一个 MockProvider。前者可以接入 Anthropic、OpenAI 等不同后端；后者在测试时返回确定性的伪输出，让开发者分清到底是编排逻辑出错，还是模型本身规划得太差。

这些组件单独看都不算新奇，但组合起来的思路很清晰：智能体的可靠性不是模型的“智商”问题，而是工程的“结构”问题。

来源：Data For Science / Bruno Gonçalves

要让一个 AI Agent 在长对话里保持连贯，它必须记住之前说过什么、做过什么。但传统做法往往依赖大模型本身来整理记忆：把对话压缩成摘要、提取实体关系、判断该记住什么、该忘掉什么。每一步都要调用 LLM，每一调用都要消耗 token 和时间。

arXiv 上一篇刚提交的论文提出了一个反直觉的思路：记忆操作能不能完全不消耗 LLM token？ 这篇名为 *Zero-Mem: Zero-Token Memory Operations for LLM Agents* 的研究给出的答案是：可以。

02 Zero-Mem 的核心思路：别让大模型干“图书馆管理员”的活

研究团队认为，过去的方法之所以昂贵，是因为它们在记忆读取、写入和检索阶段都调用了 LLM。Zero-Mem 的设计原则很直接：除了最终回答问题那一次，记忆相关操作不再调用任何 LLM，也不消耗任何输入或输出 token。

具体怎么做？它把原始交互记录保留下来，并用两种互补的方式组织这些记录。

第一种是实体—上下文图。它用非生成式的命名实体识别，从对话里抽出实体，再基于共现关系构建图。查询时，先对齐实体，再通过 Personalized PageRank 传播相关度，找到与问题相关的上下文片段。整个过程不需要 LLM 生成摘要或关系三元组。

第二种是时间层次结构。它把对话按粒度分成多个层级：原子轮次、短窗口、事件段、局部上下文。检索时从粗到细定位，既保留了会话的时序局部性，也能快速锁定关键片段。

对于一个查询，Zero-Mem 会综合这两个视图，从图结构和时序结构中分别检索，再把结果喂给最终的问答模型。只有最后这一步才调用 LLM。

03 实验结果：性能不降，速度更快

研究在 LoCoMo 和 HotpotQA 两个基准上做了测试。LoCoMo 是专门评估长期会话记忆的基准，包含单跳、多跳、时间推理和开放域四类任务；HotpotQA 则被改造成了 56K、224K、448K 三种上下文长度设置。

在 LoCoMo 上，Zero-Mem 在 GPT-4o-mini 后端取得平均 F1 59.15，BLEU-1 52.96；相比最强基线 GAM 分别高出 5.40 和 5.46。在 Qwen2.5-14B 后端同样领先。

在 HotpotQA 上，三种长度设置中 Zero-Mem 均取得最高 F1，平均领先最强基线 5.52。

更令人意外的是效率。由于记忆操作零 LLM token，对比当前最快的基线 LightMem，Zero-Mem 把记忆操作的总时间从 788.76 秒压到 334.77 秒，延迟降低 57.6%；每查询耗时从 0.51 秒降到 0.22 秒。

04 为什么这值得关注

当前很多 Agent 框架把“记忆”做成了又一个需要反复调用大模型的环节，成本随交互轮数线性上涨。Zero-Mem 提供了一条不同的路径：用结构化索引替代生成式压缩，在保留原始证据的同时，把昂贵的大模型调用留到真正需要推理的地方。

如果这条路径被后续研究和产品验证，未来长记忆 Agent 的部署成本可能会出现明显下降。

研究团队表示，论文经过同行评审后，代码将在 GitHub 上的 Zero-Mem 仓库公开。

来源：arXiv:2607.29377 / *Zero-Mem: Zero-Token Memory Operations for LLM Agents*

他在个人项目的智能体配置里写死三条指令：不许创建、修改、移动、重命名或删除任何项目文件，所有改动只在对话里展示，由他自己录入；不许运行会改动文件、安装依赖或改变仓库状态的命令，同样只给出命令由他手动执行；以及，别解释语法和接口，他是资深开发者。

代价很直接：这么干比完全不用 AI 快，但比放手让机器写的人慢，用他的话说，”不是快 10 倍，大概只有 2 倍”。换来的是什么？手敲逼他慢下来，更容易逮住模型的幻觉和糟糕的设计选择，也方便边敲边重构、改成自己的风格。更重要的是，他因此建立起代码库的”空间地图”——哪个功能在哪个文件里心里有数，下次改动知道去哪改，连提示词都写得更准。

塞西把这套做法类比成少年时学编程的老规矩：书上的例子别复制粘贴，要一个字一个字敲进电脑跑一遍。他真正担心的是行业正在累积”认知负债”——总有一天，没人说得清数字基础设施是怎么拼起来的。他至少能保证完全理解自己发布的软件，”否则就是职业失职”。

说白了，这不是反对 AI，而是拒绝把理解外包出去。下次让助手改一处逻辑，试试只让它在对话里给方案，自己动手落地，看看两周后你还记不记得。

来源：Ankur Sethi’s Lab Notebook「Prevent cognitive debt by manually retyping LLM-generated code」