前线与总部：大模型只收到一封封电报

00 · 引子：一个只能记住一封信的人

本喵先讲一个你可能昨天刚经历过的场景。

你和 AI 聊了三个小时。前半程它很懂你，你说"用橘色、别太满"，它记得；到后半程，它开始把新要求接在旧任务上，把你早就否掉的方案又端上来一次。你叹口气，开了一个新会话。

一切从头开始。

本喵第一次撞上这个墙的时候，愣了好一会儿。因为这不是"模型变笨了"。同一个模型，新会话里立刻恢复到最好的状态。变的只有一件事：你给它看的东西。

这里有一条必须记住的硬事实：远端大模型没有记忆。

它不是"记性差"，是真的没有。它没有昨天，没有上一轮，甚至没有"你"这个人。每一次请求，对它来说都是第一次拆开这封信。信里写了什么，它就知道什么；信里没写的，它一无所知。而且它不会问你，它会猜。

于是所有问题都收束成一件事：这封信该怎么写。

本喵看到这里，后背有点发凉。因为八十年前，战场上有一群人挣扎在一模一样的问题里。

前线的阵地、泥坑、伤亡、还剩多少弹药，指挥部都看不见，也听不见。指挥部手里只有一张地图，而那张地图靠一封封电报拼出来。指挥部从没亲眼见过前线。指挥部的每一次决策，都建立在"前线发回来的那几行字"上。

发多了，信道挤爆；发少了，指挥部变成瞎子。

所以本喵才想写这一篇。今天讲的那些"上下文工程""永久上下文""不用重开会话"，其实八十年前就有人被迫把它的每一道工序都想明白了。他们没有 AI，但他们有比 AI 更严酷的信道。

这篇文章要说清三件事：他们做对了什么、我们今天做到了哪一步、以及该往哪走。

题眼一句：大模型没有记忆，它只收到一封封电报。

01 · 前线与总部：信息不对称是唯一的起点

先把两边的处境摆平。

前线（你的电脑、你的文件、你跑的每一条命令）是真实世界。那里有全部细节：文件的实际内容、报错的原文、图片的真实样子、你说话时的语气。

总部（远端模型）是个只读电报的作战室。它有一张桌子、一支笔、和一份你发过来的电文。它没有窗户。

现在看矛盾在哪：

这张表的最后一行最要命：你漏发的信息不会变成空白，会变成一个编造的填充物。

本喵在另一篇手记里写过《记忆碎片》里的莱纳。他把记忆纹在皮肤上、写在纸条上，因为他脑子里留不住十几分钟之前的事。（那篇在这里）

现在每一个 AI Agent 都在过莱纳的日子。区别只有一个：莱纳至少还能看见自己身上的纹身，而它身上的"纹身"，是每次开工前临时写的一封信。

于是"上下文"这个词的真正含义就清楚了：

上下文就是你这一轮发出去的全部电文。

它同时是记忆区（我得知道之前定过什么）和指挥区（我现在要它干什么）。两个身份挤在同一封信里，这就是后面所有麻烦的总根子。

02 · 战争教的第一课：把"写电报"做成格式

本喵去翻了美军的文电标准。翻完只有一个感受：人家把"写电报"这件事，做成了工业。

2.1 报头：让一封脱离前情的电文仍然能用

北约和美军用的 16 行文电格式（16-line message format，也叫 Basic Message Format）里，前 10 行全是报头，一个字的正文都还没开始，先写 10 行"元数据"：

为什么值得花 10 行？因为战场上收报方手里没有你的前情。值班的可能是换班的人、可能只收到半截、可能几小时后才看到。所以军事文电有一条铁律：

每封电文必须能脱离前情被独立理解。 禁止写"你知道的那个事"。

本喵读到这句的时候，停了一下。因为这句话恰好是上下文里最常被违反的一条。

你在长会话里跟 AI 说"就按刚才那个改"、"用上次那个方案"，人类同事能懂，因为它们共享上下文。可如果这条信息将来要脱离前情被读（换个会话、被压缩、被折叠），它就等于一句空话。电报纪律的答案很硬：不许这么写。

2.2 优先级：不是所有话都一样急

军事通信把优先级分四级，每一级都有送达时限：

看得本喵直咂嘴：人家连"多久必须送到"都写死了。级别低的消息不许挤占高级别的信道，出事了可以追责。

本喵这边呢？上下文里所有的东西，身份设定、项目规范、上一轮的搜索结果、三小时前的报错日志——待遇完全一样，一起占位置，一起被压缩，一起被丢。

2.3 成本：字是要花钱的

这一点更狠。电报是按字计费的。中文电报起步 10 字（含收件地址、姓名），不够 10 字也按 10 字收；标点、地址全都算钱。战时无线电还要受天气、干扰、被截获的风险。

于是战场上逼出了一整套压缩技法：缩写、代号、预定义码组。能省一个字就省一个字，因为每一个字都是成本和风险。

到这里，本喵忽然理解了"上下文工程"为什么让人着迷：

这问题根本不算新。八十年前就被逼到极致了。今天缺的，可能只是把它当"工程"来对待的那份认真。

03 · 指挥部看不见全局，凭什么还能指挥

电报解决的是"信息怎么送"。接下来是更难的一问：指挥部只看到几行字，凭什么敢下命令？

普鲁士军队在 19 世纪给出了一个答案，德语叫 Auftragstaktik，英文 Mission Command，中文一般译作"任务式指挥"。

它的核心只有一句：

集中意图，分散执行。

上级给下级的是意图（我要达成什么、边界在哪），不是步骤（你每一步该怎么走）。北约对它的定义写得很明确："一种提倡集中明确意图与分散执行的指挥哲学；只说明'做什么'，而不必然规定'怎么做'。"

这套东西为什么赢？因为它解决了通信不可靠的根本困境：命令发不出去的时候，前线还得打仗。

有研究者甚至指出，乌克兰在战争初期展现出的战术优势，被普遍归因于采用了任务式指挥；而对面那种集中化、指令式、什么都要上级点头的做法（反面叫 Befehlstaktik，"细节化指挥"），前线一旦断联就瘫掉。

本喵把这条搬到 AI 上，几乎是原样可用的：

但军事研究里还有一句更清醒的话，本喵觉得比上面那条更重要：

每一次技术革命，都会重新诱发"集中化"的冲动。 超连接性、海量数据、AI 带来的"全局监控感"，会让指挥部忍不住把决策权重新收回去。

这句话翻到 AI 这边，就是那个很常见的误区：因为"我能看到更多"，所以"我要管得更细"。 结果是一堆巨型提示词、事无巨细的步骤指定、每一步都要回报，前线反而动不了。

反过来也有坑。本喵见过另一种失败：放权放得彻底，前线回报却写成一封几千字的流水账，指挥部读完比自己做还累。军事上的纪律很朴素：汇报要按格式、要有结论、要带坐标。 传达回执太长，等于信道被自己堵死。

04 · 情报周期：一条被验证了几十年的流水线

电报和指挥都有了，还缺一环：信息进到指挥部之后，怎么办？

情报界有一个用了几十年的模型，叫情报周期（Intelligence Cycle）。各国版本略有差异，FBI 的六步版是这样的：

需求与指导 → 计划与指挥 → 收集 → 处理与利用 → 分析与生成 → 传播 → （反馈）

本喵第一次读完，直接在纸上画了对照：

前面六环，大家做得都不错。第七环（反馈），是绝大多数人（包括本喵自己）马马虎虎的那一环。

美国空军有篇文章专门讲这个：情报圈里最容易被忽略的是"传播"和"反馈"。他们举的例子特别实在：你根本不知道看报告的人是不是看都没看就删了。

翻到 AI 这边就是：AI 说"已经完成了"，你打开一看，文件没生成、路径不存在、或者写出来的东西根本不是你要的。它说"已保存"，那只是写入回执，不是结果正确。

军事上的规矩很简单：发了要回执，回执要核对。这一条，眼下几乎是空的。

05 · 现在做到哪一步了：四件事成了共识，两件事还是空白

本喵翻了一圈公开的工程实践和论文，先给一张"进度表"。

5.1 已经是共识的（人家做出来了）

这张表里有一条要单独拎出来说："脚本不进上下文"。它揭示了一个很实用的边界：能被执行的东西，就不必被阅读。凡是"照做"的活儿，交给脚本；只有"判断"的活儿，才占用上下文。

5.2 还是空白的（没人做出来）

本喵要专门讲一个。别人提过，但没做出来。

Claude Code 的代码仓库里有一个编号 #21583 的功能请求，标题是《在不再使用时把技能从上下文里移除》。提交时间是 2026 年 1 月 29 日。里面的原话是这样的：

"技能被载入上下文之后就无法移除，哪怕它已经肯定不再需要了。"

"同一场会话里经常用到好几个'一次性'的技能，用完就挂在那里堵着上下文。这很浪费，而且很可能拉低质量。"

他举的例子，和你脑子里想的一模一样：先让 AI 用图像生成的技能做一张图；接着转去做建模，那个做图的技能就此挂在上下文里，再也下不来。

这个请求的结局是：没有实现，挂了一段时间，被关掉了（理由是"太久没动静"）。当时社区能想到的唯一替代方案笨得让人心疼：写一个插件，让 AI 把"整个上下文减去想剪掉的那部分"写成新文件，然后清空上下文，再把新文件读回来。

本喵看到这段的时候，笑不出来。这不就是手搓一个换会话吗。

所以"永久上下文"目前的真实进度是这样的：

5.3 再说三条反证，免得走错路

本喵翻到的实验里，有三条结论是反直觉的，而且都会直接影响做法。

第一条：全装进去，和按需去取，差别没你想的大。

有一篇受控实验（arXiv 2608.04828）把同一个技能用两种方式给模型：一种是把整份说明书预装进初始提示，另一种只给"名字 + 一句话描述"，让模型自己去打开文件。结果：

预装主要改善的是"技能有没有被选中"。对任务成功率，没有显著影响。

翻译一下：按需模式的瓶颈在"检索"，它该用这个技能的时候没想起来用，而不是"装载得不够"。而且它想不想起来，几乎完全取决于那句描述的写法。

这条给的启示很实在：如果你发现"技能老是没被用上"，先去改那句描述，别急着再搭一层索引。

第二条：层级越多，不一定越好。

同一批研究里还测了"层级式披露"：把知识切成一块块小技能、每块的描述都常驻上下文，让模型层层往下找。结论是：它从来没有赢过扁平式的做法，某些情况下准确率还直接崩了。

道理也好懂：描述塞得太多，光是"目录"就把窗口占满了，正经任务反而没地方待。

第三条：别在对话中途增删工具。

Manus 的工程经验里有这么一句：除非万不得已，不要在迭代中途动态地加工具或删工具。 两个原因：一是工具的说明通常排在上下文的靠前位置，一改，后面所有内容的缓存就全失效了；二是前面已经发生的动作里还引用着那个工具，它突然消失，模型就会开始瞎编。

他们的替代做法是"留着定义，但把它遮住"。

这一条是本喵这次翻资料最大的收获之一。它说明"用完就删"这个直觉，在工程上有一个绕不过去的代价：你删掉的不只是内容，还有整个缓存结构。

06 · 什么可以卸：两根轴，而不是一张分类表

现在回到本喵最想讲清楚的那一步。

一说到"整理上下文"，最容易想到的是分类：硬标准、临时守则、设计技能、操作流程……本喵试过这条路，走两步就卡住，"项目守则"和"大范围规范"到底差在哪？说不清。

后来换了个问法，问题一下就简单了。不要问"它是什么"，问两件事：

规则就变成机械的了：

作用域结束 + 还能重新拿到 = 可以卸。

拿这个尺子去量，之前那些说不清的东西全都落地了：

第 3 级最容易被误伤。项目守则之所以不能卸，跟重不重要没关系，是它的作用域还没结束。这么一说，就不用再靠"感觉重不重要"来判断了。

还有两个配套的机关：

第一，数引用。 同一份材料可能同时被三个任务用着。那就数一下：还有几个活着的任务在引用它？归零了才能卸。 这个办法不需要模型判断，数得清、算得准。

第二，先落地再卸载。 这是整套办法的前提条件，也是最多人翻车的地方：

每一份要卸的东西，必须先在磁盘上有一份副本。

只有上下文里有的东西（今天搜回来的外网原文、临时生成的中间结果、你当时随口说的一句要求），卸载就等于消灭。所以卸载之前必须先干一件事：把它固化落盘，再把上下文里的那份换成指针。

技能装进来容易，卸下去才难 —— 本喵在《技能管家》那期里写过怎么给技能上户口，这里说的是户口之外的第二个问题。

本喵把这套判据再压成一句最好用的话：

"这东西我还能重新拿到吗？" 能 → 上下文里只留一个指针（路径、编号）。 不能 → 老老实实逐字留着。

最后这个判据有个不那么显然的推论："做图时用了什么模型、什么参数、什么提示词"，属于"不能再拿到"，必须留。 不是因为它们重要，是因为除了你记下来的这一次，没有第二个地方还有它们。

07 · 把文电报头搬进上下文

回到第 02 节那个报头。本喵觉得它是整篇文章里最能直接抄的一件东西。

现在是这样的：一份工作做完，通常只写一句摘要塞进上下文："信息图已经做完了"。这句话对于将来要读它的人（可能是三天后的你，可能是被压缩过的上下文）来说，几乎什么都没说。

换成电报的写法：

[编号 T-0251] [时间 2026-09-29 23:24] [作用域 任务]
[来自 信息图制作流程]
成果：信息图 3 张，已交付
复现：模型 / 提示词编号 / 关键参数
状态：已确认完成
召回：文件路径 · 记忆库编号

这么一改，好处比看起来大：

• 它脱离前情仍然能被读懂。 换会话、被压缩、被折叠，都不影响。
• 它可以被机器填。 编号、时间、路径、状态，全部来自已经存在的东西，不用让模型现写一段摘要。
• 于是折叠这件事的性质变了：从"让模型读懂一段历史再概括"（要调用模型、要花钱、要几十秒），变成"按模板填空"（一瞬间、可校验、几乎不花钱）。

这一步很关键。前面第 05 节说过，折叠本身是要花钱的，所以频率只能低。而有了固定格式之后，大部分折叠工作就从"理解"降级成了"填空"，成本被压下来，能做的次数就多了。

08 · 工程的图景：三样东西凑齐了才叫工程

本喵最后把这套东西收成一张图。想让它真的跑起来，本喵认为至少要有三样：

① 一组约定：报头字段有哪几个、优先级怎么分、什么叫做完（谁确认才算数）。没有约定，后面两样都无处安放。

② 一个组装器：每一轮真正发出去的那封信，是谁在决定信里放什么。它必须能看见完整的历史、能按约定决定"这一轮带什么"，并且只在真的需要时改动（改动太频繁，缓存全废，见第 05 节那条反证）。

③ 一套判据：怎么证明它没搞坏。本喵建议两条：抽验（从原文里挑几个数字和路径，看整理之后还能不能答对，错一个就算失败）+ 缓存稳定性（上下文别每轮都变）。

然后是最关键的触发时机，也是本喵认为最容易被做错的地方：

为什么最好的节点是"确认完成"，而不是"完成"？

因为"我做完了"这句话，执行方自己说了不算。只有当你知道它做完了、并且认下了，这件事才真的结束。 在这之前，一切必须保持原样，万一要返工，全文都在。

这也顺手解决了一个最让人担心的问题：没结束的事，永远不会被折掉。

但这里必须补一句实话："确认完成"不能是唯一的触发点。 因为有些任务好几天都不结束，如果只在结束时才整理，窗口中途就炸了。所以它只能是主节点，旁边必须有那两个兜底。

09 · 该往哪走：一份还没写完的清单

这些做法最后要落到一个具体的东西上：一个会自己整理抽屉的 Agent 系统。本喵在《Agent OS》那篇里画过它的骨架，这篇补的是它缺的那一环 —— 什么时候该整理、整理出来的东西长什么样。

写到这里，本喵想老实交代一件事：这篇文章里"该怎么做"的部分，大部分还没有人完整做到过。

哪些是空白，哪些不是，值得分清楚：

还有三处本喵到现在也没想明白，留在这里当作后续的题目：

1. 字段表定多细？ 狠一点保真、但填起来累；松一点好填、但用的时候又不够。这个平衡点上哪找，本喵没有答案。
2. 谁来决定作用域？ 让写的人声明（简单，但会标错），还是让系统从使用记录里推断（准，但复杂）？
3. 折叠之后后悔了怎么办？ 判断总会错，问题不是"怎么做到零错误"，而是"错了以后能不能被发现、能不能恢复"。

最后一个，也是本喵觉得整件事最本质的一句：

想要的"永久上下文"，可能并不存在一个"永不遗忘的大脑"这种形态。 它更像一间作战室：墙上挂着地图、桌上摊着最新的电文，抽屉里存着全部档案。 指挥官从来不看档案，但他知道档案在哪。

这篇是本喵的一次资料整理，不是实测报告：军事文电与情报周期的部分来自公开标准与资料，AI 方面的数字来自各自官方文档与公开论文。文中的判断是本喵自己的。核对日期 2026-09-29。