大家好，我是玄姐。

核心论点：上下文工程（Context Engineering）的本质不是“如何填充 Prompt”，而是“如何在有限的 Attention Window 和 KV Cache 约束下，构建一个图灵完备的虚拟运行时环境”。过度工程化（Over-engineering）通常源于试图在 Prompt 中模拟操作系统，而正确的路径是将能力卸载（Offload）给外部环境。

一、 熵减策略：从“短期记忆”到“文件系统” (Context Offloading & I/O)

Agent 的上下文随时间推移必然熵增（Context Rot），导致注意力机制分散（Attention Dispersion）。解决之道在于引入分级存储架构。

1、Cursor 的“万物皆文件” (Everything is a File)

第一、设计模式：

Unix 哲学。将所有的非结构化状态（Terminal Output, Tool Result, Chat History）序列化为文件系统中的静态资源。

第二、动态发现机制 (Dynamic Discovery)：

Agent 不再持有全量数据，而是持有数据的句柄（File Handle/Path）。

Lazy Loading：通过 tail、grep 或语义索引（Semantic Index）按需调取数据。这实际上是在 LLM 外部实现了一个简易的虚拟内存换页（Paging）机制。

IO 重定向：将标准输出（STDOUT/STDERR）重定向到 output.log，上下文窗口中只保留指针。

总结 Cursor 做法：针对 Agent 开发中因将海量日志（如终端输出）直接塞入 Prompt 而导致模型“脑雾”与高成本的痛点，Cursor 采用了一种“上下文卸载”策略，核心在于“不记内容，只记路径”。系统将冗长的输出拦截并固化为本地文件（如output.log），仅向模型传递文件路径；模型若需排查问题，会像工程师一样自主生成tail或grep等指令进行按需读取。这种动态上下文发现机制，将 AI 的工作模式从“死记硬背整本书”转变为“按索引去图书馆查阅”，在释放宝贵上下文窗口的同时，大幅提升了推理的精准度与经济性。

2、Manus 的“上下文生命周期管理” (Lifecycle Management)

第一、阈值触发 (Pre-rot Threshold)：

基于 Perplexity 或 Token 计数（如 128k/200k）触发 GC（垃圾回收）。

第二、两级压缩流水线：

Level 1 - 紧凑化 (Compaction / Serialization)：无损操作。将 write_file(content=...) 这种高消耗操作，替换为 write_file_success(path=...)。这是将“数据”转化为“元数据”。

Level 2 - 摘要与快照 (Snapshot & Summarization)：有损操作。在执行摘要前，先做 Core Dump（全量上下文转储到日志）。这保证了操作的可逆性，Agent 仍可通过检索日志“恢复现场”。

总结 Manus 做法：面对长对话导致上下文溢出且传统摘要易丢失关键信息（如密码）的痛点，Manus 提出了一套“紧凑化+快照”的生命周期管理机制。这套机制分两步走：首先通过“去水分”，将历史操作（如写入的大文件内容）替换为仅包含路径和状态的元数据，保留关键骨架；其次在必须进行有损摘要前，先“打快照”，将全量对话备份到本地文件。这种设计如同清理手机内存，先存缩略图，再把原图导出的双重保险，确保模型在发现摘要信息不足时，拥有随时回读备份文件的“后悔药”，从而实现了记忆的高效压缩与无损召回。

二、 行动空间分层：内核态与用户态 (Kernel vs. User Space)

如何解决工具定义（Tool Definitions）对 KV Cache 的污染？

1、KV Cache 友好的分层设计

L1 内核层 (Kernel / Atomic Functions)：仅保留文件读写、Shell 执行等原子操作。这些定义是静态的，位于 System Prompt，保证 KV Cache 的固定前缀（Fixed Prefix）不被刷新，极大降低 Time-to-First-Token (TTFT) 延迟。

L2 用户态/沙箱层 (Userland / Sandbox)：将 MCP 工具、格式转换器、Linter 等封装为二进制或脚本，置于沙箱文件系统中。

Agent 通过 L1 的 Shell 命令（如 ls /bin, tool --help）去探索 L2。

优势：工具的扩充不会导致 Prompt 膨胀，避免了“上下文混淆”，且不需要每次请求都重新计算工具描述的 Attention Matrix。

L3 代码层 (Code / Interpreter)：利用 Python/Pandas 处理数据密集型任务，实现 CodeAct 范式。

针对 Agent 挂载海量工具导致 Prompt 臃肿、首字延迟高且易产生幻觉的痛点，Manus 借鉴操作系统原理设计了“内核态 vs 用户态”的分层架构。该架构在 Prompt 常驻的 L1 内核层仅保留“读写/Bash”等极简原子指令，利用其静态特性最大化 KV Cache（预计算缓存） 的命中率，从而极致优化响应速度与成本；而复杂的业务工具则被下沉至 L2 用户态沙箱中封装为 CLI 程序。模型无需在上下文中检索繁杂的 API 文档，而是通过 Bash 指令像程序员一样在终端按需调用，这种“首屏只留终端，应用按需调用”的设计，在保持上下文轻量化的同时，赋予了 Agent 无限且有序的能力扩展空间。

三、 进程间通信：Agent 协作模式 (IPC for Agents)

多 Agent 协作本质上是分布式系统的状态同步问题。

1、RPC 模式 (委托/Delegation)

架构：Share-Nothing。主 Agent 调用子 Agent 如同调用一个远程函数。

适用：正交任务（如“在代码库中搜索 X”）。

优点：上下文隔离，无噪音干扰。

2、Fork 模式 (共享上下文/Shared Context)

架构：Copy-On-Write (概念上)。子 Agent 继承父 Agent 的完整内存（History）。

代价：无法复用父 Agent 的 KV Cache（因为 System Prompt 变了），导致 Prefill 成本高昂。

适用：强依赖历史信息的深度推理任务。

3、结构化契约 (Structured Contract)

MapReduce：主 Agent 定义 Output Schema（JSON Schema），子 Agent 执行并返回。

约束解码 (Constrained Decoding)：强制 LLM 的 Logits 采样必须符合 Schema 语法树，确保 IPC 通信的类型安全（Type Safety）。

针对多 Agent 协作中因自然语言回复过于发散（如废话多、格式乱）导致主 Agent 解析困难且易错的痛点，该方案确立了“填表而非写作文”的结构化通信原则。主 Agent 通过下发 JSON Schema 建立严格的数据契约，并配合约束解码（Constrained Decoding）技术，在底层强制锁定模型的输出空间，确保子 Agent 只能生成符合预定义类型和格式的内容。这种机制将不确定的自然语言交互转化为精确的“强类型契约”，彻底杜绝了格式错误，实现了 Agent 间零误差的高效协作。

总结一句话：这一波技术进化的核心，就是不再把 LLM 当作一个无所不能的神，而是把它当作一个会操作电脑的 CPU。

Cursor 教会了它用硬盘（文件化）。

Manus 教会了它用操作系统（分层与生命周期）。

谁能把这个“外部环境”搭建得越好，谁的 AI Agent 就会越聪明、越稳定。

好了，这就是我今天想分享的内容。如果你对构建企业级 AI 原生应用新架构设计和落地实践感兴趣，别忘了点赞、关注噢~

—1—

加我微信

扫码加我👇有很多不方便公开发公众号的我会直接分享在朋友圈，欢迎你扫码加我个人微信来看👇

加星标★，不错过每一次更新！

⬇戳”阅读原文“，立即预约！