大模型上下文工程：从“填充Prompt“到构建虚拟运行时环境的革命！

文章探讨上下文工程核心思想，即将LLM视为CPU而非全能神，通过构建良好外部环境提升AI Agent性能。介绍了Cursor的"万物皆文件"策略、Manus的"上下文生命周期管理"机制、内核态与用户态分层架构，以及多Agent协作的结构化契约通信模式，旨在优化上下文处理，让AI Agent更聪明稳定。

小涂Ss

447人浏览 · 2026-01-14 09:00:00

小涂Ss · 2026-01-14 09:00:00 发布

简介

核心论点：上下文工程（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 就会越聪明、越稳定。

说真的，这两年看着身边一个个搞Java、C++、前端、数据、架构的开始卷大模型，挺唏嘘的。大家最开始都是写接口、搞Spring Boot、连数据库、配Redis，稳稳当当过日子。

结果GPT、DeepSeek火了之后，整条线上的人都开始有点慌了，大家都在想：“我是不是要学大模型，不然这饭碗还能保多久？”

我先给出最直接的答案：一定要把现有的技术和大模型结合起来，而不是抛弃你们现有技术！掌握AI能力的Java工程师比纯Java岗要吃香的多。

即使现在裁员、降薪、团队解散的比比皆是……但后续的趋势一定是AI应用落地！大模型方向才是实现职业升级、提升薪资待遇的绝佳机遇！

这绝非空谈。数据说话

2025年的最后一个月，脉脉高聘发布了《2025年度人才迁徙报告》，披露了2025年前10个月的招聘市场现状。

AI领域的人才需求呈现出极为迫切的“井喷”态势