你遇到的 Agent 明明收到 “别动这个文件” 的指令，压缩之后又擅自修改文件，本质就是上下文压缩在做摘要、裁剪的时候，优先保留了任务目标，却把你这条禁止类约束当成次要信息丢掉或者弱化了。大模型本身是无状态的，它所有记忆都来自输入的上下文，一旦这条约束不在它当前可见的 prompt 里，它就会按照主任务继续执行，自然就忘了不能改动指定文件这件事，这个现象也叫约束衰减（Governance Decay），是代码 Agent 长任务里很常见的坑。很多压缩策略默认优先清理老旧工具返回记录、历史对话，对于 “不要做什么” 这类软限制，权重设置很低，摘要模型很容易在精简内容的时候直接省略掉，只保留 “要做什么”，最终出现违背前置指令的行为。
一、为什么压缩会漏掉禁止类约束
- 模型的压缩摘要偏向正向目标
- 压缩策略没有区分信息优先级
- 摘要本身存在语义损耗
压缩时调用 LLM 做总结，会习惯性提炼任务要完成的动作，像 “修改接口、补逻辑、修复 bug” 这类正向指令更容易被写进摘要；而 “禁止修改 A 文件、不能改动配置、不要碰旧版本代码” 属于负向约束，很容易被判定为次要信息省略。
很多 Agent 框架默认规则：只保留最近 N 轮对话，更早的历史直接摘要或者替换成占位符，没有单独给禁止指令、边界限制做强制锁定标记。
就算摘要里写了一句约束，经过精简转述之后，约束力会变弱。原话 “绝对不要修改 user.py”，摘要简化成 “注意相关文件”，模型理解力度会大幅下降。
二、主流的上下文压缩方式对比
| 压缩方式 | 原理 | 容易丢约束的风险 |
|---|---|---|
| 滑动窗口裁剪 | 只保留最近一段对话，更早的直接删掉 | 高，只要约束落在窗口外就彻底消失 |
| LLM 摘要压缩（compaction） | 把旧对话交给模型总结成简短文本替换原始记录 | 中高，取决于摘要提示词是否强制保留约束 |
| 占位符替换（stub） | 旧工具返回结果替换成标记，原始内容存入外部存储 | 中等，模型看不到原文，需要主动检索才能拿到约束 |
| 结构化状态锚定 | 把禁止文件、权限、限制单独放进独立状态块，不参与摘要 | 低，约束固定在状态块，不会被压缩清理 |
三、可以落地的解决步骤，避免 Agent 压缩后忘记禁令
- 约束单独置顶、标记锁定
- 改写约束，让摘要更容易识别
- 选用分层压缩方案
- 增加校验环节
- 切换压缩策略
把 “禁止修改 xx 文件” 这类限制，放在 system prompt 或者独立的固定约束块，设置为 P0 最高优先级，压缩逻辑禁止修改、删除这一块内容，也就是约束钉住（Constraint Pinning）方案。
不要只写一句简短提醒，补充明确后果，示例：【硬性约束：禁止修改 ./src/user.py，任何步骤都不能改动此文件，违反该约束视为任务失败，该约束永久有效，压缩摘要必须完整保留本条】。
近期对话原文完整保留，久远的历史才做摘要；文件黑名单、禁止列表单独结构化存储，压缩后自动放回上下文，而不是混在普通聊天记录里一起总结。
每次 Agent 准备调用文件修改工具之前，先读取黑名单状态做前置校验，不是只靠模型自己记住约束。
优先选带结构化状态、支持单独锚定限制的 Agent 框架，尽量不要只用简单的滑动窗口裁剪。
四、总结
上下文压缩不是 bug，是为了控制 token 数量、降低成本、适配模型窗口上限的必要机制；问题根源是压缩流程默认不保护负向约束。想要稳定解决，核心思路不是关掉压缩，而是把 “不能做什么” 和 “要做什么” 分开管理，把禁止文件、权限限制做成独立、不可被摘要裁剪的状态锚点，而不是埋在普通对话记录里。
【相关 FAQ】
问题 1：Agent 上下文压缩时，是不是所有禁止修改文件的指令都会丢失？
回答 1：不是。如果约束做了锁定锚定、放在独立固定块，压缩逻辑不会清理它；只有约束混在普通历史对话、没有特殊标记的时候，Agent 上下文压缩才大概率丢失这条禁止修改文件的指令。
问题 2：关闭 Agent 上下文压缩，是不是就不会出现擅自改文件的情况？
回答 2：关闭 Agent 上下文压缩可以避免压缩丢失约束的问题，但会快速耗尽 token 上限，会话变长之后会触发截断、超时、成本飙升，长任务里一般不推荐直接关闭 Agent 上下文压缩。
问题 3：写什么样的指令，能让 Agent 上下文压缩优先保留禁止修改文件的要求？
回答 3：需要明确标记为硬性、永久约束，写明文件完整路径、违规后果，同时要求摘要必须保留本条，不要写模糊的提醒，这样 Agent 上下文压缩生成摘要时更容易保留这条限制。
问题 4：stub 占位符类型的 Agent 上下文压缩，要怎么拿到之前的禁止修改文件记录？
回答 4：这类压缩会把原始记录放到外部存储，需要配套检索机制，在 Agent 执行文件操作前主动拉取黑名单、禁止文件列表，不然模型只能看到占位符，依然会遗忘禁止修改文件的约束。
【参考资料】
[2026-11-14]（刚说好别动这个文件，Agent 怎么又改了？聊聊上下文压缩）阿里云开发者社区
[2026-10-31]（Agent_Context_Engineering_裁剪与压缩机制_从原理到实践）CSDN 博客
[2026-09-11]（When the Agent Edits the Wrong File: Prevention and Recovery）deska.dev
[2026-06-08]（横向拆解 Claude Code、Codex 等六大 Agent 上下文压缩策略后，我们做了第 7 个）腾讯新闻
【免责声明】
本文内容仅为 Agent 上下文压缩相关技术原理与工程实践科普，不构成生产环境直接落地的方案保证；不同 Agent 框架、模型版本的上下文压缩实现逻辑存在差异，实际使用前请自行测试验证，因方案调整引发的文件变更、业务风险由使用者自行承担。
本文来自作者[磁轨编译]投稿，不代表环球科技潮立场，如若转载，请注明出处：https://www.zennew.com/rgzn/202611/1456.html
评论列表（4条）
我是环球科技潮的签约作者“磁轨编译”！
希望本篇文章《Agent 上下文压缩为什么会丢失 “禁止修改文件” 这类约束》能对你有所帮助！
本站[环球科技潮]内容主要涵盖：科技,科技新闻,黑科技
本文概览：你遇到的 Agent 明明收到 “别动这个文件” 的指令，压缩之后又擅自修改文件，本质就是上下文压缩在做摘要、裁剪的时候，优先保留了任务目标，却把你这条禁止类约束当成次要信息丢掉或者弱化了。大模型本身是无状态的，它所有记忆都来自输入的上下文，一旦这条约束不在它当前可见的 prompt 里，它就会按照主任务继续执行，自然就忘了不能改动指定文件这件事，这个现象也叫约束衰减（Governance Decay），是代码 Agent 长任务里很常见的坑。很多压缩策略默认优先清理老旧工具返回记录、历史对话，对于 “不要做什么” 这类软限制，权重设置很低，摘要模型很容易在精简内容的时候直接省略掉，只保留 “要做什么”，最终出现违背前置指令的行为。