A04 信息流决策框架·四去向
一个 agent 任务跑起来后，每一步都会产生新的信息——工具返回的 50 行 ls、一份 30 页的 PDF、一次子任务的探索轨迹、一个会被反复用到的用户偏好。问题不是”信息够不够”，而是”这条信息该去哪”。本节点要解决的，是 Context Engineering 里最被低估、却决定质量与成本生死的一个判断：面对一条新信息，它应该（1）放进当前 context window、（2）外化进 memory layer、（3）走 RAG 按需检索，还是（4）丢给 subagent 先消化再回传压缩结果？ 我把这四个去向称为「信息流四去向决策框架」。判断主轴只有一句：没有信息流决策框架，context 贪婪会让质量与成本同时崩盘——而绝大多数人默认的策略恰恰是”全塞进 context”。
§0 为什么是”四去向路由”而不是”上下文越大越好”
读者脑中的默认框架往往是两个极端之一：要么”窗口够大就全塞进去”（长上下文派），要么”什么都走 RAG”（检索派）。这两个框架都错，错在它们把”信息放哪”当成一个全局开关，而不是逐条信息的路由决策。
正确的框架是把 LLM 的 context window 当成操作系统里的 RAM——一种稀缺、需要主动调度的资源。这个类比不是我发明的：MemGPT 论文（Packer et al., “MemGPT: Towards LLMs as Operating Systems”, arXiv:2310.08560, 2023-10）正是把 OS 的内存分层（RAM / 磁盘）映射到 LLM 上下文管理，提出 main context（≈RAM）+ external context（≈disk）的虚拟上下文管理。LangChain 的官方框架（“Context Engineering for Agents”, 2025-07-02）把它系统化为四个操作动词 Write / Select / Compress / Isolate，并明确类比”操作系统管理 CPU 内存”。
我的四去向框架是在这个 OS 隐喻上做的 PM 化重述：不谈底层操作动词，而谈一条信息进来时，决策者（PM 或 agent 设计者）该把它路由到哪个层。四个去向对应四种资源代价与四种失效模式：
| 去向 | OS 类比 | 何时选 | 主要代价 | 失效模式 |
|---|---|---|---|---|
| 放 context | 装进 RAM | 当前这步立即要用、且高信号 | 占 token、稀释注意力 | context rot、成本线性涨 |
| 外化 memory | 写入磁盘文件 | 跨会话/跨步骤要复用的状态 | 写入开销、检索延迟 | 记忆冲突、时效幻觉 |
| 走 RAG | 按需 page-in | 大语料、动态、稀疏命中 | 索引维护、检索失败 | 召回错块、引入干扰项 |
| subagent 消化 | 子进程独立内存 | 探索量大、只需结论 | 跨 agent 沟通损耗 | 上下文割裂、决策冲突 |
这张表的价值在于：它把”上下文管理”从一个模糊的工程口号，变成一个每条信息都要过一遍的判断闸门。
§1 去向一：放 context —— 默认选项，也是最危险的选项
放进 context 是成本最低的动作（不用写文件、不用建索引），所以它是所有人的默认——这恰恰是问题所在。Anthropic 的官方定义把 Context Engineering 描述为”curating and maintaining the optimal set of tokens at inference time”（来源：Anthropic Engineering, “Effective Context Engineering for AI Agents”, 2025-09-29），关键词是 curating（策展）——意味着”放什么进去”是个需要主动做减法的决策，不是默认全收。
为什么默认全塞会崩？因为 token 不是免费躺在窗口里不影响质量的。Anthropic 同篇提出 context rot（上下文腐化）：随 token 累积，注意力稀释导致模型表现退化。Chroma 的系统测评（Kelly Hong, Anton Troynikov, Jeff Huber, “Context Rot”, trychroma.com/research/context-rot, 2025-07-14）测试了 18 个前沿模型（Claude Opus 4 / Sonnet 4 / 3.7、GPT-4.1 / GPT-4o、Gemini 2.5 Pro/Flash、Qwen3-235B 等），结论是所有 18 个模型在所有输入长度增量上均出现性能下降，无一例外。更狠的是 NoLiMa 基准（Modarressi et al., ICML 2025）：GPT-4o 声称 128K 窗口，但实际有效上下文约 8K token；Claude 3.5 Sonnet 从 1K 时的 87.6% 准确率跌到 64K 时的 29.8%。
所以”放 context”的正确判据不是”窗口装得下吗”，而是 Anthropic 的那句话：“Find the smallest set of high-signal tokens that maximize desired outcomes.”（找到最小的高信号 token 集合）。只有”这一步立即要用 + 高信号”的信息才配进 context，其余三个去向都是在为这个窗口减负。
§2 去向二：外化 memory —— 把”要记住的”从窗口里搬出去
如果一条信息现在用不上、但以后（下一步、下一个会话）要复用——比如一份项目约定、一个已确认的事实、一份 TODO 计划——它应该被外化到 memory layer，而不是一直占着 context。这是 memory layer 成为”一等公民”的核心理由：它让 agent 从”无状态文本生成器”变成”有状态的适应性 agent”（A-Memory 综述用语，来源：Memory for Autonomous LLM Agents 综述, arXiv:2603.07670, 2026-03，原文 “Memory is what turns a stateless text generator into a genuinely adaptive agent”）。
memory 的具体形态有两类工程实现，各有量化收益：
- 文件式外化：Anthropic 的 Memory Tool（
memory_20250818，2025-08 进入公测）让 agent 在/memories目录写持久化文件，系统 prompt 自动注入”做任何事之前先查 memory 目录”的指令。Anthropic 公布的数据：Context Editing + Memory Tool 组合使 agent 搜索性能提升 39%（vs 基线），单独 Context Editing 提升 29%（来源：Anthropic, “Context Management”, claude.com/blog/context-management）。 - 结构化记忆系统：Mem0（Chhikara et al., arXiv:2504.19413, 2025-04）做动态提取-整合-检索，在 LOCOMO benchmark 上相比 OpenAI full-context，LLM-as-a-Judge 提升 26%、P95 延迟降低 91%、token 成本降低 90%。
判断主轴在这里有个致命细节：哪些信息绝不能只靠 context 的压缩保留？Anthropic Cookbook 的明确规则是——必须放进 CLAUDE.md（或外部 memory）的内容，不要依赖压缩保留，假设它不会被保留。我作为 Claude Code/CLAUDE.md 的深度用户，对此有一手体感：把”项目约定 / 已确认的架构决策”写进 CLAUDE.md 而不是指望它在长对话里活下来，是唯一可靠的做法。一旦触发自动压缩（Claude Code 约在 80% 窗口、~160K token 时触发，来源：okhlopkov.com/claude-code-compaction-explained），没外化的状态就是赌运气。
§3 去向三：走 RAG —— 当语料太大、太动态、命中太稀疏
第三个去向针对的是”信息量远超窗口、且大部分时候用不上”的情形：企业知识库、文档库、代码库。这里的判断不是”RAG vs 长上下文谁强”（那是 c09 - RAG 架构 和本专题对照节点的事），而是”这条/这批信息该走按需检索而非常驻 context”。
EMNLP 2024 的系统比较（Li et al., “Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach”, arXiv:2407.16833）给了关键判据：资源充分时长上下文平均性能持续高于 RAG，但 RAG 的成本优势显著；他们提出的 Self-Route 混合路由让模型自我判断按查询路由，把 Gemini-1.5-Pro 计算成本降低 65%、GPT-4o 降低 39%，同时维持接近长上下文的性能。这正是”四去向”在 RAG 这一支的精髓：不是全走 RAG 也不是全进 context，而是逐查询路由。
走 RAG 的判据可以落成一张决策表：
| 维度 | 倾向走 RAG | 倾向直接放 context |
|---|---|---|
| 语料规模 | 大、装不下 | 小、可完整装入 |
| 更新频率 | 实时/频繁 | 静态 |
| 查询频率 | 高频（成本主导） | 低频（成本可承受） |
| 延迟 SLO | 严格（<2s） | 宽松（>10s 可接受） |
| 查询类型 | 精确事实、稀疏证据 | 跨文档推理、全局摘要 |
注意 RAG 自身也有失效模式：检索回错块、引入干扰项会放大幻觉——Chroma 的实验显示1 个干扰项即已降低基线性能，4 个累积更显著。所以”走 RAG”不是甩锅，检索质量本身要按 m205 - RAG 生产环境：索引运维与评估体系 的方法验证。
§4 去向四：subagent 先消化回传 —— 用隔离换窗口寿命
第四个去向最反直觉也最强：当某个子任务需要大量探索（读 20 个文件找一个配置项、跑 50 次搜索），不要让这些探索轨迹污染主 agent 的 context，而是丢给一个 subagent，让它在自己独立的窗口里消化完，只回传压缩后的结论。子 agent 各自拥有独立 context window、系统提示、工具权限，主 agent 只接收最终摘要，从而延迟主上下文耗尽的时间。
Anthropic 的 Focus Agent 实验（arXiv:2601.07190, 2025-01 区间）量化了”自主压缩”的收益：token 减少 22.7%（14.9M→11.5M），准确率不变。但有个关键发现——必须显式提示”每 10-15 次工具调用压缩一次”，被动提示仅节省 6%；当前 LLM 在无脚手架情况下不会自然优化上下文效率。这条对 PM 的启示是：subagent 隔离不是配好就生效的银弹，路由策略要被显式设计进 harness，不能指望模型自觉。
判断主轴：没有路由框架，context 贪婪致质量与成本双崩
这是区分”会用 agent”与”会设计 agent 信息流”的命门。90% 的人在这四个去向上会犯的典型错误，每个都带症状→为什么错→正确做法→真实反例：
错误一：把所有工具输出都留在 context（默认全塞）。
- 症状：长任务跑到后期质量肉眼下降，成本随轮次线性飙升。
- 为什么错：误以为 token 在窗口里”躺着不影响质量”。
- 正确做法：旧 tool_result 用占位符遮蔽（Observation Masking）或清除。JetBrains Research（“Efficient Context Management”, blog.jetbrains.com/research, 2025-12）在 SWE-bench 上实测：Qwen3-Coder 480B 用 Masking 后解决率提升 2.6%、成本降低 52%；反观 LLM Summarization 意外使 agent 运行时间增加约 15%（摘要遮盖了停止信号）。
- 真实反例：Claude Code 不留全部输出，约 80% 窗口触发压缩，保留架构决策/未解 bug，丢弃冗余工具输出（来源：okhlopkov.com/claude-code-compaction-explained）。
错误二：该外化的状态只靠 context 压缩”祈祷它活下来”。
- 症状：长对话后 agent 忘了早先确认的关键约定，或自相矛盾。
- 为什么错：把易失的 working memory 当成持久存储用。
- 正确做法：跨步骤要复用的写进 memory/
CLAUDE.md，假设压缩不保留它。 - 真实反例：LongMemEval（ICLR 2025, arXiv:2410.10813）显示，商业 chat assistant 和长上下文 LLM 在跨会话记忆上准确率下降 30%——光靠窗口记不住。
错误三：什么都走 RAG，连小而静态的语料也建索引。
- 症状：为一份 50 页固定手册维护一整套向量库+检索管道，还时不时召回错块。
- 为什么错：把”大语料”的解法套到”小语料”上，徒增工程复杂度和检索失败面。
- 正确做法：小到能装进窗口、又静态的，直接放 context（甚至配 Prompt Caching 复用）。
- 真实反例：EMNLP 2024 Self-Route 证明，对简单/可全装的查询直接走长上下文，性能更高且省去检索失败风险。
错误四：滥用 subagent，把需要全局一致性的任务也拆出去。
- 症状：两个并行 subagent 各自”合理”的决策组合起来失败（一个建 Super Mario 背景，另一个建视觉不兼容的角色）。
- 为什么错：误以为隔离永远是好的，忽视隔离本身的沟通成本。
- 正确做法：需要共享决策历史的任务别拆；要拆就传完整 trace 而非单条消息。
- 真实反例：见下节 Cognition 的反驳。
产品 PM 视角补盲
工程视角只看到”省 token”，PM 还得看到三个走样点：
- 成本结构错配：四去向的成本曲线完全不同。放 context 是按 token 线性付费、可被 Prompt Caching 摊薄（缓存命中读取仅 0.1x 基础价）；走 RAG 是固定索引成本+低边际查询成本；subagent 是多份并行推理。一个高频、低复杂度的客服 agent 全塞 context，单位经济模型必崩——这是”四去向”直接关联到 m209 - 推理成本控制手册 的地方。
- 合规与数据驻留：外化 memory 意味着用户数据落盘持久化，触发 GDPR/数据驻留/被遗忘权。对 Rick 所在的国际化场景，“哪些信息能外化、存哪个区域”是先于技术的合规决策，不能由 agent 自动决定。
- 用户的”记忆心智模型”：用户对”AI 记得我什么”有强烈预期与焦虑。memory 写多了像监控，写少了像失忆。memory layer 作为一等公民，意味着 PM 要把”记什么/忘什么/给不给用户可见可删”做成产品决策，而非纯后端配置。
对手框架回应：Cognition 的”别建多 Agent”
最有力的业界反方来自 Cognition（“Don’t Build Multi-Agents”, cognition.ai/blog/dont-build-multi-agents, 2025）。他们直接打第四去向：subagent 隔离会造成上下文割裂（只收到子任务描述的 subagent 因缺乏整体决策历史而误解任务）和隐式决策冲突（并行 subagent 各自合理却组合失败）。他们的结论是”Share full agent traces, not just individual messages”，主张更可靠的单线程+完整上下文常优于多 agent。
接受 + 边界：我接受 Cognition 对的部分——subagent 不是免费午餐，当任务需要全局一致性、决策相互依赖时，隔离的沟通损耗会盖过省 token 的收益，强行拆分反而引入新失效模式。这正是我把”上下文割裂/决策冲突”列为去向四失效模式的原因。但我坚持的边界是：Cognition 反对的是把隔离当默认，而四去向框架本就主张逐情形路由——对”探索量大、只需结论、彼此独立”的子任务（如并行检索互不相干的文档），隔离仍是延长主窗口寿命的最优解。我赌的是：模型跨 agent 沟通的可靠性会随版本提升，使隔离的适用边界扩大；但今天，PM 的安全默认应是”能不拆就不拆，要拆就传完整 trace”。这是个活跃争论，无定论——Vellum、Collabnix 等实践者认为隔离可用 scoped prompts 弥补，Cognition 认为根因是模型可靠性而非工程补丁。
跨域呼应：Herbert Simon 的”注意力稀缺”与信息经济学
四去向框架的底层逻辑，其实是 Herbert Simon 1971 年那句被反复引用的话：“a wealth of information creates a poverty of attention”（信息的丰裕造成注意力的贫困）。Simon 的洞察是：当信息变得廉价丰裕，稀缺的不再是信息，而是消费信息的注意力——必须在过剩的信息源之间高效配置注意力。
这个框架精确地改变了我对”context window 越大越好”的判断。长上下文派的隐含假设是”信息越多越好”——但 Simon（以及 context rot 的实证）告诉我们，LLM 的注意力是有限资源，多塞信息等于稀释注意力，是负收益。于是”放什么进 context”不是一个存储问题（窗口够不够大），而是一个注意力经济的配置问题（哪条信息值得占用这步的注意力预算）。四去向框架就是这个注意力预算的分配机制：memory/RAG/subagent 三个去向，本质都是”把不该占用此刻注意力的信息挪走”，好让有限的注意力对准高信号 token。这不是装饰性引用——它把一个看似工程的 token 管理问题，重构成了一个有 50 年理论积累的资源配置问题，并直接证伪了”窗口越大越好”这一默认框架。详见 0114认识论 对注意力与信息的辨析。
PM 决策启示
- 面试怎么用：被问”agent 上下文怎么管”，别答”用大窗口”。答”我会先做信息流路由：逐条信息判断放 context / 外化 memory / 走 RAG / 丢 subagent，因为 context 是 RAM 不是仓库，全塞会触发 context rot——Chroma 测的 18 个模型无一幸免”。30 秒立判高下。
- 选型怎么用：评估一个 agent 平台，别只看”支持多大上下文窗口”。问四个问题：有没有 memory layer（外化）、有没有原生检索（RAG）、有没有 subagent 隔离、有没有自动压缩/遮蔽。缺哪个都意味着信息只能全塞 context。
- 复现怎么用：在
CLAUDE.md里显式写下”什么该外化、什么该走检索、什么子任务该拆 subagent”，并把”每 N 次工具调用压缩一次”写进 harness——Focus Agent 证明被动提示只省 6%，显式脚手架才省 22.7%。
与已有节点的关系
- 对照 c09 - RAG 架构：c09 解决”RAG 内部怎么做”（chunking、检索范式、reranker、评估）。本节点升高一个抽象层做”对话”——把 RAG 仅当成四去向之一，回答”一条信息到底该不该走 RAG”这个更前置的路由问题。不复述 c09 的检索机制。
- 对照 m206 - Agent 产品化：记忆机制与技术进展：m206 讲”记忆怎么实现”（短期四策略、长期三库、衰减/冲突/隐私四决策）。本节点做纠偏+提升：把 memory 从”agent 的一个功能模块”提升为”信息流的四个一等去向之一”，并明确”何时该外化 vs 何时该留 context”的路由判据——这是 m206 未显式回答的上游决策。
- 对照 m209 - 推理成本控制手册：本节点为 m209 提供了”成本从哪来”的信息流视角——四去向各有不同成本曲线，路由决策直接决定单位经济模型。是补缺关系。
- 与 m201 - Prompt Engineering 实战体系 的关系：m201 是”怎么写这句话”，本节点是”哪些信息该在窗口里”——正是 prompt engineering → context engineering 升格的具体落点。
- 与本专题 A01 Context Engineering 概念史与升格、A05 Memory Layer 作为一等公民、S01 Context 管理分层剖面 互链：A01 给术语史背景，A05 深挖去向二，S01 给整体架构剖面，本节点是把它们串起来的决策闸门。
关联节点
核心（必读）
- c09 - RAG 架构 —— 去向三的内部机制
- m206 - Agent 产品化：记忆机制与技术进展 —— 去向二的实现细节
- m209 - 推理成本控制手册 —— 四去向的成本曲线
- Agent —— 信息流路由的承载主体
- KV Cache / Prompt Caching —— “放 context”的成本可被缓存摊薄
延伸（可选）
- m201 - Prompt Engineering 实战体系 —— 上游的指令设计
- m205 - RAG 生产环境：索引运维与评估体系 —— 验证去向三的检索质量
- m203 - RAG 生产环境：Embedding 与文档解析 / m204 - RAG 生产环境：Chunking 与范式演进 —— RAG 去向的工程基础
- RAG / Embedding —— 原子概念
- 幻觉 —— 干扰项与记忆冲突如何放大幻觉
- Claude Code —— 四去向的一手实践场
- 0114认识论 —— 注意力稀缺的跨域框架
- AI PM 知识图谱·总索引
修订日志
- R0（2026-06-07）：首稿。建立四去向路由框架（放 context / 外化 memory / 走 RAG / subagent 消化），判断主轴四件套，Cognition 反方”接受+边界”回应，Simon 注意力稀缺跨域呼应，与 c09/m206/m209/m201 升级对照。所有 benchmark/论文/产品行为均接地标年份。