你的上下文已被污染
Source: Dev.to
请提供您希望翻译的完整文本内容，我将按照要求保留源链接并仅翻译正文部分。谢谢！
上下文工程框架
LangChain 的 Lance Martin 发布了一个上下文工程框架，包含四种操作——Write（写入）、Select（选择）、Compress（压缩）和 Isolate（隔离），每种操作都有其对应的失效模式。将这些映射到我们六代理自主系统的生产数据中，发现 4,768 起违规行为，全部可追溯到这四种被污染的上下文模式之一。
Failure Mode 1: Stale Context (Write)
您的代理指令是在三次冲刺前编写的。API 已更改，模式已迁移，而代理仍在针对已不再存在的现实版本生成代码。
Symptoms
CLAUDE.md文件引用了已移动的文件路径。- 约束引用了已被取代的规范。
- 代码库几周前强制的模式仍在使用。
Fix – Structural enforcement via L5 hooks that validate context freshness before the agent acts
- 当指令引用文件路径时，钩子会验证该路径是否存在。
- 当约束引用规范时，钩子会确认该规范仍然有效。
检测工具只能在破损代码发布 之后 告诉您上下文已过时。通过构建时的钩子可以阻止过时的上下文进入代理，从根本上防止问题的产生。
失效模式 2：缺失上下文（选择）
代理拥有 200 K‑token 的窗口，但只选择了一小部分——例如，40 K 的对话历史、20 K 的文件内容，以及 零 字节的关键配置。
标签
“context gap” 违规。
示例
代理做出了一个决定，如果它先阅读了仓库中的 CLAUDE.md 本来是正确的，但没有任何机制强制它这么做。
修复 – 通过 L5 钩子强制加载必需上下文
- 在编码代理接触任何仓库之前，钩子会验证它已读取仓库的
CLAUDE.md。 - 在响应操作员消息之前，代理必须检查其收件箱。
这些都是自动化闸门，会阻止执行，直至加载所需的上下文。
Failure Mode 3: Bloated Context (Compress)
大型上下文窗口（200 K 令牌）在代理读取大量文件、执行命令并累积对话历史后，可能变得难以管理。此时进行 压缩，会丢弃较旧的消息。
首先被丢弃的是什么？
系统提示、行为约束以及顶层指令。
影响
在压缩事件后，代理平均 每天违规 12 次，大约每 45 分钟就会无声地忘记自己的规则。
解决方案 – 预压缩内存刷新钩子
- 在进行 150 次工具调用时，钩子会在压缩前将关键上下文写入持久存储。
- 当压缩发生时，已保存的知识仍然保留在磁盘上。
Failure Mode 4: Leaking Context (Isolate)
在多代理系统中，Agent A 的约束可能泄漏到 Agent B 的上下文中，导致角色之间出现意外的影响。
Observed issue
编码器代理开始执行本应由 CEO 代理下达的战略指令，未经授权就做出产品决策。
Fix – Structural isolation at the data‑access layer
- 每个代理的上下文都是有界的。
- 跨代理信号遵循定义好的路由协议（例如，编码器不能读取 CEO 的邮箱；预言机不能修改编码器的优先级）。
数字
- 4,768 检测到的违规总数，涉及六个代理
- 18 违规被提升为结构性强制（L3‑L5）
- 477:1 违规‑提升比例——衡量自我改进速度
- < 5 % 对已接受 L5 强制的违规的回归率
检测发现违规；强制使其不可能发生。这一区别将单纯监控与真正的上下文工程分开。
这对您的系统意味着什么
如果您在生产环境中运行 AI 代理——如编码助手、研究代理、自治工作流——您的上下文很可能在以下四种方式中的至少一种上受到污染。故障模式可能是静默的，代理会自信地基于已降级的上下文生成输出。
关键问题不是您的上下文是否干净；而是您的系统能否在结构上检测并防止上下文污染，在代理行动之前。
- 对您的代码库进行扫描，以评估上下文工程的健康状况。
最初发布于 walseth.ai