当你第100次看着你的Agent在几十万Token的上下文里“大海捞针”，最后还是把那个关键的API参数搞错时，有没有想过：我们可能从根儿上就错了？
现在市面上都在吹“无限上下文”、“1M Context Window”。好像只要窗口够大，把整个代码库、所有的文档、甚至你祖宗三代的族谱都塞进去，AI就能立地成佛。
别扯了。
那不仅是在烧钱，更是在制造噪声。你花大价钱塞进去的10k Token里，99%是网页里的CSS垃圾、无关的广告和废话。真正的关键信息，早就在这堆数据垃圾里窒息了。
今天咱们不聊虚的，聊点反共识的硬核干货。最近我扒了LangChain最新的Deep Agent架构，发现了一个极具嘲讽意味的真相：
拯救AI记忆危机的，不是什么炸裂的新型向量数据库，而是计算机界最古老、最不起眼的东西——文件系统。
上下文工程的“红绿圆圈”悖论
不论是RAG还是长窗口，本质上都在赌概率。我们现在的搞法，就像是给了AI一个只有几百KB的CPU寄存器（Context Window），然后拼命往里塞东西。
真正的架构师怎么看这个问题？他们把Context Window看作昂贵且易失的CPU寄存器，而把文件系统看作便宜、无限且持久的外挂显存（External VRAM）。
这就引出了那个让无数开发者深夜痛哭的“红绿圆圈”悖论：
图注：上下文工程的核心挑战——Retrieved（抓取到的）与Needed（真正需要的）往往并不重叠。
看这张图，扎不扎心？
• 红色区域（Retrieved Context）：你一股脑塞给AI的那些一大坨未经清洗的HTML、文档和日志。 • 绿色区域（Needed Context）：解决当前bug真正需要的那一行报错代码。
这两者之间的巨大鸿沟，就是你的Agent总是“一本正经胡说八道”的原因。Context Engineering 的本质，就是想尽办法让红圈和绿圈完美重合，而不是无脑扩大红圈。
真正的解药：Write -> Filter -> Read 闭环
为什么传统的 RAG（检索增强生成）在 Coding Agent 场景下经常翻车？
因为代码是逻辑结构，不是语义结构。你问 RAG：“用户认证在哪里？”，它可能会给你返回一段由“用户”和“认证”这两个词组成的注释，而不是真正的 AuthService 类。
基于文件系统的 Context Engineering 则构建了一个全新的“确定性”工作流：
Manus Architecture" class="rich_pages wxw-img" data-ratio="0.562962962962963" data-type="png" data-w="1080" style='box-sizing: border-box;border: 0px solid rgb(229, 229, 229);margin: 0.1em auto 0.5em;padding: 0px;outline-color: oklab(0.144521 0.00000657141 0.00000288337 / 0.5);vertical-align: middle;display: block;max-width: 100%;height: auto;text-align: left;line-height: 1.75;font-family: -apple-system-font, BlinkMacSystemFont, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;border-radius: 4px;' title="null" data-imgfileid="100011205">图注：Manus 的 Context Engineering 架构——利用文件系统作为中间层，实现“读写分离”与“精准降噪”。
这套逻辑的核心在于将 Context 的管理权交还给 Agent，形成了 Write (卸载) -> Filter (定位) -> Read (加载) 的闭环。在这套逻辑里，ls、grep、glob 这些老古董，比 Embedding 模型管用一万倍。
代码实战：Deep Agents 如何用代码实现“上下文清洗”
我仔细研读了 deepagents 的 filesystem.py 源码。这不仅仅是文件操作库，这是一套标准的 Context Engineering 实施规范。
让我们深入代码底层，看看 Deep Agents 是如何一步步实现这个闭环的：
Step 1. Write：将“红圈”卸载到窗口之外 (Offloading)
当 Agent 抓取到大量信息（如 20k Token 的 Web Search 结果）时，最愚蠢的做法是直接塞进 Chat History。
Deep Agents 的做法是将其“卸载”到文件系统：
def write(self, file_path: str, content: str) -> WriteResult:
# ...
# 关键逻辑：数据落地，但不返回给Context Window
flags = os.O_WRONLY | os.O_CREAT | os.O_TRUNC
if hasattr(os, "O_NOFOLLOW"):
flags |= os.O_NOFOLLOW # 顺手还防了个Symlink攻击，讲究
fd = os.open(resolved_path, flags, 0o644)
with os.fdopen(fd, "w", encoding="utf-8") as f:
f.write(content)
# 返回的是 WriteResult(path=...), 而不是 file_content
return WriteResult(path=file_path, files_update=None)Context Engineering 原理：
注意看，这个函数执行完，Context Window 里增加的仅仅是“文件已保存”这几个字，而不是那 20k 的垃圾数据。这相当于把内存数据Swap到了硬盘上，极大地释放了 Agent 的“注意力带宽”。
Step 2. Filter：用结构化搜索寻找“绿圈” (Indexing)
数据在硬盘里了，Agent 怎么找？
传统的 RAG 返回的是模糊的 Chunk，而 Deep Agents 的 grep 返回的是精确坐标。
源码中 _ripgrep_search 的实现极其硬核：
def _ripgrep_search(self, pattern: str, base_full: Path, include_glob: str | None) -> dict:
cmd = ["rg", "--json"] # 灵魂所在：输出机器可读的元数据
if include_glob:
cmd.extend(["--glob", include_glob])
# ...
# 结果被解析为：{ "filepath": [ (line_num, text), ... ] }Context Engineering 原理：
为什么要用 --json？因为 Agent 需要一张高信噪比的地图。
通过 grep，Agent 获得了一个包含 {file_path, line_number} 的精简列表。这步操作，是在成吨的“红圈”数据中，通过逻辑规则（而非概率语义）筛选出了可能的“绿圈”候选集。
Step 3. Read：外科手术式的精准加载 (Surgical Extraction)
找到了坐标（比如第 42 行），最后一步才是真正的“加载上下文”。
如果直接 Read 整个文件，前功尽弃。看看 FilesystemBackend.read 是怎么做 Token 预算管理的：
def read(self, file_path: str, offset: int = 0, limit: int = 2000) -> str:
# ...
lines = content.splitlines()
# 核心逻辑：滑动窗口 (Sliding Window)
selected_lines = lines[start_idx:end_idx]
# 贴心细节：自动打上行号，方便后续 Edit 操作
return format_content_with_line_numbers(selected_lines, start_line=start_idx + 1)Context Engineering 原理：offset 和 limit 参数，本质上是 Context Window 的预算控制器。
Agent 像一位外科医生，只将病灶周围的那 10 行代码切片加载到内存（Window）中。这让 Agent 具备了处理 GB 级日志文件的能力，却只消耗几百 Token。
从“无状态”到“数字生命”
当我们把文件系统的读写权限赋予Agent的那一刻，性质就变了。
以前的Agent，是“无状态”的，聊完即忘。
现在的Agent，有了文件系统，就有了长期记忆。
• 它可以在 skills.md里写下：“上次用户骂我写的SQL没有加分号，下次要注意。”（In-Context Learning 的持久化）• 它可以在 plan.txt里记录：“任务完成了30%，下一步该去调优Redis配置。”（长程规划的外部化）
当Agent开始在文件系统里写下自己的“配置文件”时，它就不再是一个简单的问答机器，而是一个真正拥有记忆、能够自我进化的“数字生命体”。
基于文件系统的 Context Engineering，或许正在为下一代 Deep Agent 提供一种比单纯扩大窗口更务实、更高效的解题思路。
