Context Engineering

100:1。这是一个很残酷的数字，指的是在实际的生产级Agent中，为了输出1个token，模型可能需要输入100个token。这意味着Agent的“智商”其实高度依赖于这100个token里塞了什么、剔除了什么以及怎么排列的。如果把LLM比作CPU，那么上下文窗口就是内存，而我们写Prompt的人其实在扮演操作系统的角色，决定哪些数据能加载进内存。

很多人还停留在Prompt Engineering（研究怎么措辞），但到了公司实际落地阶段，真正的战场是Context Engineering（研究模型此刻看到了什么）。

为什么上下文越长，模型越“傻”？

很多人觉得窗口越大越好，但实际部署时会发现一个现象：上下文腐烂（Context Rot）。即便窗口没满，随着token增加，模型对关键信息的注意力会被稀释。

• 注意力稀释： Transformer的注意力机制是平方级的，token越多，每个token分到的“关注度”就越薄。
• 性能下滑： 即使是顶级模型，在长上下文中处理同一任务的准确率也会大幅掉线。
• 工具过载： 这是一个典型的踩坑点。给Agent接入10个工具可能跑得飞快，但一旦增加到40个，模型就开始在调用工具时产生混乱，这跟窗口大小无关，而是模型的辨析能力到极限了。

上下文的四层构成及其风险

在公司推行AI Agent时，我们需要把上下文看作一个预算表，在以下四层之间分配额度：

• 指令层（Instructions）： 系统提示词、规则。太臃肿会稀释后续所有指令。
• 知识层（Knowledge）： 检索到的文档、用户偏好。太多会导致模型迷失，太少则会产生幻觉。
• 工具层（Tools）： 函数定义、调用结果。工具数量过多会导致调用崩溃。
• 历史层（History）： 之前的对话记录。过时的结论会误导当前的决策。

几个实操的提效策略

为了避免上述问题，我们在构建工作流时尝试了以下方案：

1. 卸载机制（Offloading）
不要把所有东西都塞进上下文。比如抓取网页，只保留一个500 token的摘要和URL，把5万 token 的正文扔掉。如果Agent后续真的需要细节，再让它去重新抓取。这种“可逆压缩”能极大节省资源。

2. 实时检索（Just-in-time Retrieval）
传统的RAG是预先检索，而Agentic RAG是给模型提供“指针”（如文件路径、查询模板）。模型决定需要什么，再去读取该片段。

3. 外部锚点
让Agent维护一个 todo.md 文件，每一步执行前重新读取。把当前目标写在上下文的最末端，能有效防止长任务在执行过程中“跑偏”。

在 Claude Code 的实战中，这种管理方式非常明显，它不会一次性加载整个数据库，而是通过 head 命令分片读取。这种对上下文的精细化管理，才是Agent从 Demo 走向生产环境的唯一路径。