Agent 的上下文不是记忆，技能库才是
你有没有遇到过这种崩溃瞬间？
你让 Agent 总结一份 20 万 token 的董事会材料，三分钟后它交了一份漂亮的摘要。你刚想夸它，却发现它把 Q2 的数据当成了 Q3，还把一份无关邮件的附件当成了核心依据。
你第一反应是换更大的模型，开更长的上下文窗口。结果过几天同样的问题又来一次，只是这次它把张总的反馈归到了李总头上。
Tomer Tunguz 在他那篇《The AI Preflight Check》里写了一句挺刺耳的话，上下文窗口大小不是瓶颈，记忆架构才是。我读完之后愣了一下，然后觉得他说到了点上。
坦率的讲，过去一年多我们被上下文长度绑架了。32K、128K、200K、1M，数字越涨越夸张，但我们的 Agent 并没有因此变得更靠谱。它们只是能在同一次对话里装下更多垃圾，然后再从垃圾里翻出更多错误。
今天顺着 Tunguz 的预检架构，我想聊聊 Agent 的工作记忆到底该怎么设计。
一、Preflight 是什么？一句话就能说清
它的结构其实特别简单，甚至简单到让人怀疑是不是在炒冷饭。
一个查询进来，Agent 先从长期技能库里检索相关技能，只把需要的技能加载到上下文窗口。然后本地模型基于加载后的上下文执行，困难任务再路由给 frontier 模型。执行过程中，Watchdog 记录每一次预检决策和技能调用。到了夜里，异步推理把这些轨迹翻出来，决定哪些该变成新技能，哪些该改成确定性代码。
Tunguz 打了个比方，飞行员起飞前要做预检规划航线，Agent 也一样。
但别小看这个流程。它解决的不是「模型不够聪明」，而是「模型根本找不到该用哪部分聪明」。
二、为什么上下文窗口不是答案
现在很多人的做法是这样的，把邮件、PDF、聊天记录、历史会话全部塞进 prompt，然后对模型说「请总结」。
模型不是不聪明，它是被淹没在信息里。20 万 token 里真正相关的可能只有 3000 token，但模型得先把所有内容都读一遍，再靠推理把 relevant 的东西挑出来。
这一步对长上下文模型来说确实能完成，但成本、延迟和出错概率都跟着上来了。更重要的是，它把「检索」这个软件工程问题外包给了「推理」。
换个角度看，你绝对不会让一个人类助理干这种事。人类助理会先看一眼任务，然后问你要文件，再翻笔记本找上次类似项目的总结，而不是闭上眼睛把所有历史资料都读一遍。
Agent 也该如此。它的记忆不该等于上下文窗口的长度，而该等于它能不能在正确的时间找到正确的工具、模板和上下文。
三、技能库，才是真正的长期记忆
Tunguz 的技能库大约有 90 个 workflow 文件，存在磁盘上，按意图做索引匹配。每个技能被写成一次，版本化管理，然后以 tool schema 的形式交给模型。
这和我们平时做 RAG 有点像，但又不完全一样。
RAG 通常检索的是文档片段，然后让模型自己拼答案。技能库检索的是「动作模板」，比如「总结董事会材料」「处理日历冲突」「提取发票信息」。这些技能本身就是压缩后的记忆，包含了该做什么、不该做什么、成功标准是什么。
我自己在 LangGraph 里做编排的时候，也有类似的体感。State 里塞太多东西，图就会变得很难维护。把能力拆成独立节点、工具、checkpointer，反而能让每一步都清晰可控。
Tunguz 更进一步，把技能库变成 Agent 的索引层。上下文窗口只存当下要用的技能，而不是全部历史。这是一种对记忆的取舍，取的是「相关性」，舍的是「完整性」。
完整性当然好，但靠完整性堆出来的智能，成本太高，也靠不住。
四、本地模型扛 80%，frontier 模型兜底 20%
这套架构里另一个让我印象深刻的点，是他用本地模型 Ornith 35B 处理大约 80% 的常规任务。
分类、草拟、工具选择、结构化提取，这些任务不需要 GPT-5.5 级别的推理能力。一个 35B 的开源模型在 Apple Silicon 上就能跑得不错，成本低、延迟小、还能离线跑。
困难任务再路由到 frontier。这样既省钱，又保留了解决复杂问题的能力。
这个设计思路其实很像微服务里的降级策略。核心链路用本地资源保证可用性，异步或复杂路径再走外部强依赖。做工程的人都知道，把最贵的能力用在最贵的地方，不是吝啬，是理性。
对 Agent 开发者来说，这里有个很实用的启发，不要一刀切。你的 Agent 不需要每个节点都调最强的模型。先把任务分类，再决定路由策略，比无脑堆模型效果好得多。
而且，本地模型还有个被忽略的好处，隐私。很多企业不能把敏感数据发到第三方 API，本地部署是必须。能在本地解决的事尽量在本地解决，是一种很现实的设计倾向。
五、Watchdog 的夜间作业，是自我改进的关键
我觉得这套架构里最性感的地方不是 Preflight，而是 Watchdog。
它记录每一次预检决策、每一个技能调用、每一次成功和失败。夜里等大家睡觉了，异步推理跑一遍当天的轨迹，判断两件事。
第一，有没有重复出现的新场景，需要新增技能。第二，现有技能的哪些部分已经稳定到可以变成确定性代码，比如日历排期直接用 Rust 实现，而不是继续让 LLM 去比空闲时段。
这一步太重要了。它把 Agent 从一个静态的 prompt + 工具组合，变成了一个会自我迭代的系统。新技能是增量记忆，固化代码是记忆压缩。两者交替进行，系统才能越用越稳。
Tunguz 说，昨天是 Watchdog 第一次没有提出任何改进建议。他怀疑这只是暂时的，但它暗示了一个平台期，只有真正新的异常才需要人类介入。
我当时读到这儿，脑子里冒出一句话，Agent 的终极目标不是替代人类，而是把人类从重复判断里解放出来。
六、对 LangGraph 开发者的三个启发
如果你也在用 LangGraph 或者其他 Agent 框架，我觉着这套架构至少有三点可以直接偷师。
第一，State 不是记忆容器，而是工作记忆的临时缓存。真正长期的东西应该放在工具、技能库、checkpointer、外部存储里。State 只装当前任务需要的最小上下文。
第二，工具不是越多越好。Tunguz 的技能库大约 90 个，看起来不少，但每个都有明确意图和版本。比工具数量更重要的是检索质量。如果模型找不到对的工具，工具再多也没用。
第三，把反馈循环当作一等公民。LangGraph 的 checkpoint 已经能记录执行轨迹，但记录不是目的。目的是用这些轨迹去更新技能、优化路由、固化确定性逻辑。没有夜间 Watchdog，Agent 永远只是一个被调用的函数，而不是一个能进化的系统。
可以在 LangGraph 里试着做一个简单的 Preflight 节点，在接到用户输入时先做一次意图匹配，加载少量相关工具，然后再进入主图。这个节点不用太复杂，但能立刻让图的边界感清晰起来。
七、它不是万能药，不能直接抄
说真的，我也不确定这套架构搬到所有场景都好使。
意图匹配的准确性是个大问题。如果 Agent 在预检阶段就选错了技能，后面再努力也白搭。Tunguz 没说他的意图匹配是怎么做的，是 embedding 检索、还是关键词、还是一个小模型分类，这直接影响落地难度。
另外，本地模型 35B 能不能稳定处理 80% 的任务，取决于任务类型。如果你的 Agent 要处理大量开放式创意写作，35B 可能不够。如果是结构化、重复性工作，那它很合适。
还有技能固化这件事。把 LLM 的决策变成 Rust 代码听着很酷，但维护和测试成本不能忽视。一旦业务规则变了，你改的是代码，而不是 prompt。这个切换本身就需要一套新的工程流程。
所以我的感受是，Preflight 提供了一种结构思路，不是一份可以直接抄的模板。你得根据自己的任务特征、团队能力、成本预算去调整。
八、动手之前，先问自己三个问题
这套思路很迷人，但我也不建议立刻把现有 Agent 重构一遍。动手前可以先问自己三个问题。
第一，你的任务是否足够结构化，能拆出常规动作和异常动作。如果每一次输入都是全新的、没法预测的，那技能库的作用就很小。相反，如果每天有 80% 的需求都是几类固定场景，技能库才值得投入。
第二，你是否能接受「部分业务逻辑固化」的成本。把 LLM 的决策转成代码，等于说你得写测试、做版本管理、处理回退。这些工作不是柔性的，但它们能让系统在关键路径上更稳。
第三，你的团队是否能维护技能库。技能库不是写一次就完事的东西，它需要不断地收集场景、修复失败案例、删除过时技能。如果没有人负责，它很快会变成一堆用不上的废码。
我自己的判断标准是这样的，如果你的 Agent 负责处理重复性任务，并且对成本和隐私敏感，那这种记忆架构很值得试试。如果你追求的是高灵活度和开放式交互，那还是先把基础模型能力做好更要紧。
九、最后想说的
Agent 领域现在有点过热，大家都在比谁接的模型更强、谁的上下文更长、谁的工具更多。但 Tunguz 这篇文章提醒我们，Agent 说到底还是软件工程。
软件工程的核心问题从来都不是「能不能装下更多数据」，而是「能不能在正确的时候找到正确的逻辑并执行正确」。
上下文窗口是带宽，技能库是记忆，Watchdog 是反馈循环。三者合在一起，Agent 才像一个真的能帮你干活的系统，而不是一个会聊天的搜索框。
如果你最近也在折腾 Agent 的稳定性，不妨试试把焦点从「加窗口」挪到「建技能库」上。可能效果比你想象得更直接。
