示例｜模型读完了项目，却改错了文件
一个大型网站包含数百个源代码文件，前端、后端和数据库分别由不同团队维护。仓库里既有当前使用的接口文档，也保留着两年前的技术方案。
用户要求AI修改“用户权限系统”。为了避免遗漏，他把整个代码仓库、历史文档、会议记录和过去的开发对话全部交给模型。
模型确实接收了这些内容，却依据一份已经过期的权限说明修改了旧接口，还忽略了藏在另一份数据库文档中的兼容要求。
从输入容量看，模型看到的信息已经足够多；从任务结果看，它并没有真正找到最重要的那部分。
这正是长上下文容易制造的误解：我们常把“模型能够接收多少信息”，直接等同于“模型能够理解多少信息”。上下文窗口扩大以后，代码确实可以放得更多，文档也不必频繁切成碎片，但容量只解决了入口问题。
信息进入窗口之后，模型能否找到、辨别、关联并正确使用，仍然是另一回事。
一百万token解决了什么
2026年2月5日，Anthropic发布Claude Opus 4.6。它是首个提供测试版100万token上下文窗口的Opus级模型，当时这项能力面向Claude Developer Platform提供。Anthropic同时表示，Opus 4.6改进了大型代码库处理、长上下文信息检索和跨大量内容进行推理的能力。(Anthropic官方介绍)
2月17日发布的Claude Sonnet 4.6也提供测试版100万token上下文窗口。Anthropic称，这一容量可以在单次请求中容纳大型代码库、长合同或大量研究资料，并强调Sonnet 4.6能够在这些内容之间进行长上下文推理。这里需要注意，这些是Anthropic根据自身评估和早期使用情况作出的产品描述，并不意味着模型可以无损理解任何放入窗口的内容。(Anthropic官方介绍)
对软件项目而言，更长的上下文窗口确实有直接价值。
一次跨文件修改往往不能只看当前函数。修改权限判断，可能同时涉及用户表、角色定义、中间件、接口路由、前端状态、缓存策略和测试用例；排查一个偶发错误，也可能需要同时阅读日志、调用链、配置文件和历史提交。
窗口过小时，模型读到后面的文件时，前面的细节可能已经被移出当前上下文。开发工具只能不断裁剪、摘要或重新检索内容，关键关系容易在切换中丢失。更大的窗口让模型有机会同时保留更广的代码范围，比较不同模块的实现，也更容易发现某个修改可能影响哪些下游组件。
这是真实进步，但不是项目理解的充分条件。
核心判断
长上下文扩大的是模型一次能够参考的信息范围。
它不能保证模型自动识别哪些内容有效、哪些已经过期，也不能保证重要信息不会被大量无关内容淹没。
四种容易混淆的“记住”
讨论百万级上下文时，当前上下文、长期记忆、外部检索和上下文压缩经常被混在一起，最终都被描述成“AI记住了更多东西”。
它们解决的其实是不同问题。
概念区分
当前上下文
模型在一次请求或当前任务中能够看到的信息，包括用户要求、代码、文档、工具结果和对话历史。上下文窗口决定这批内容最多能够有多大。
长期记忆
跨会话保存的用户偏好、项目知识或历史经验。关闭当前任务后，这些信息仍可能在未来被再次使用。它不等于当前窗口，也不代表所有历史内容都会被永久保留。
外部检索
系统根据当前问题，从代码仓库、数据库、搜索索引或知识库中寻找相关资料，再把选中的内容送入当前上下文。它解决的是“去哪里找”，而不是“窗口能装多少”。
上下文压缩
当任务历史接近窗口上限时，把较早内容整理成较短摘要，用摘要替换原始细节，使任务能够继续。它延长了可工作的时间，却可能损失早期约束和细节。
Claude Opus 4.6发布时，Anthropic在API中推出了测试版上下文压缩。官方说明是：当长对话或Agent任务接近设定阈值时，系统会自动总结并替换较早的上下文，从而避免任务直接撞上窗口限制。Sonnet 4.6随后也支持这项能力。(Claude Opus 4.6) (Claude Sonnet 4.6)
压缩并不是把所有历史原样保存到更小空间。摘要必然需要选择：哪些决定要保留，哪些过程可以省略，哪些失败尝试不再重要。
如果早期对话中有一句“不得修改旧用户数据”，压缩后的摘要只留下“更新权限系统”，后续Agent就可能失去最关键的约束。Anthropic在关于长时间运行Agent的工程实践中也指出，压缩本身并不足以保证跨多个上下文窗口稳定工作，因为传递给下一阶段的信息未必总是足够清楚。(Anthropic工程文章)
因此，长上下文不是长期记忆，压缩也不是无损记忆。它们只是不同的上下文管理手段。
三种给AI项目背景的方法
继续使用前面的权限系统示例。这个项目包含数百个文件、多套历史接口、部署说明、产品需求和几代开发者留下的编码规则。
用户可以采用三种方式提供上下文。
第一种方式，是只说一句：“修改用户权限系统。”
AI只能从当前打开的文件和项目结构中猜测需求。它可能找到一个名为permission的目录，却不知道真正的权限判断已经迁移到认证中间件；它可能完成代码修改，却没有意识到旧用户数据仍需兼容。
这种方式的问题是信息不足。模型被迫用常见做法填补空白，而项目中最重要的特殊约束没有进入它的判断过程。
第二种方式，是把整个仓库、所有历史文档和聊天记录一次性送入上下文。
这看起来最保险，却可能同时放入三份互相冲突的权限方案、已经弃用的接口示例、测试环境密钥、重复代码和大量与当前任务无关的页面组件。模型不再缺少信息，但开始缺少优先级。
第三种方式，是先提供一张项目地图：说明前端、后端、数据库和测试分别位于哪里，权限系统当前以哪个模块为准，哪些文档仍然有效，历史接口只用于兼容，不应继续扩展。
随后，Agent根据任务逐步读取：
- 当前权限模型与角色定义；
- 用户表和相关数据库迁移；
- 认证中间件与受保护路由；
- 权限系统的产品要求；
- 现有测试和明确的验收条件。
第三种方式给出的总信息未必最少，但进入当前推理过程的信息更相关，也更有顺序。
上下文不是资料堆积
成熟的上下文工程并不追求把所有内容一次性交给模型。
它更像为一名刚加入项目的开发者安排入职：先说明系统地图和可信资料的位置，再根据当前任务深入相关模块。
能够装下，不等于能够用好
模型处理长输入时，一个重要问题是信息在大量内容中的可见性。
一条关键要求如果位于输入开头或结尾，通常更容易受到注意；如果它隐藏在数十万token中间，与大量相似文本混在一起，模型可能没有在最终推理中正确调用它。长上下文性能随输入规模增加而下降的现象，常被称为“上下文退化”或“上下文腐化”。
Anthropic在Opus 4.6发布材料中也直接使用了“context rot”这一说法，并通过自己的长上下文评估说明新模型在大量文本中检索隐藏信息的表现有所改善。这可以证明长上下文检索正在进步，却不能证明问题已经消失。
代码项目尤其容易出现四类干扰。
一种是无关信息。修改权限系统时，完整的营销页面、图片处理脚本和历史构建日志几乎没有帮助，却会占据模型的注意范围。
另一种是重复信息。同一项规范可能在项目说明、团队手册和旧任务记录中出现多个版本，模型未必知道哪一份拥有最高优先级。
更危险的是冲突和陈旧信息。旧文档写着“权限存储在JWT中”，新系统已经改为服务端查询；如果两份材料同时出现，却没有日期、状态或可信来源标记，模型可能选择表达更完整、但实际已经失效的旧方案。
还有错误关联。模型看到两个名称相似的模块，可能把旧版管理员角色与当前用户权限体系联系起来，并形成一套语言上合理、项目中却不存在的关系。
容量越大，这些问题不会自动减轻。未经整理的输入越多，错误线索也越多。
项目地图比巨型说明书更重要
2026年2月11日，OpenAI发布了一篇关于Agent工程实践的文章，其中提出了一个很直接的经验：给Codex一张地图，而不是一份一千页的说明书。
OpenAI团队曾尝试使用一个巨大的AGENTS.md保存全部项目要求，但他们认为这种做法会挤占任务、代码和真正相关文档的上下文；当所有内容都被标记为重要时，Agent反而难以判断优先级。大型单一文件还容易变得陈旧，并且难以检查其覆盖范围、更新时间和责任归属。(OpenAI工程文章)
他们后来把较短的AGENTS.md作为目录入口，把架构、产品要求、执行计划、安全规范和其他资料放入结构化文档目录。Agent先读取稳定的项目地图，再按当前任务寻找更深入的信息。OpenAI将这种方式称为渐进式披露：从小而清晰的入口开始，需要时再展开细节。
这套经验的价值不只适用于Codex。
大型项目真正需要的，不是一份囊括一切的“万能说明”，而是一套能够回答以下问题的知识结构：
- 系统由哪些主要模块组成；
- 当前任务应该从哪里开始；
- 哪份文件是某项规则的可信来源；
- 哪些文档仍然有效；
- 哪些决策已经废弃；
- 如何验证修改没有破坏现有行为。
索引负责告诉Agent去哪里找；检索负责选出当前需要的文件；分层文档负责把总体架构和局部细节分开；上下文压缩负责让长任务继续；版本记录和测试则用于确认信息与代码仍然一致。
它们不是相互替代的功能，而是一套上下文供应链。
项目文档的新角色
文档过去主要帮助人类理解系统。
在Agent参与开发以后，文档还成为模型进入项目的导航层。它需要可检索、可分层、可验证，并明确标注状态与适用范围。
这也意味着，文档数量增加并不一定提升Agent效果。一份无人维护的架构说明，可能比没有说明更危险，因为它会让错误信息显得正式而可信。
长上下文也有成本和风险
更长的上下文不是免费的容器。
输入内容增加后，模型通常需要处理更多token，可能带来更长的响应时间和更高的调用成本。即使模型能够接受全部内容，系统也要为代码解析、索引、上传和上下文构建付出资源。
信息噪声是另一类成本。模型花费推理能力比较无关文件和重复规则，就意味着留给当前任务的注意力被进一步分散。
敏感信息暴露也容易被“把整个仓库都放进去”的便利掩盖。代码库中可能包含内部接口、测试账号、客户数据样例、历史日志和未清理的密钥。某个Agent只需要修改前端权限提示，却被授予读取整套生产配置的能力，这不是上下文更完整，而是权限边界过宽。
长上下文还可能扩大错误的传播范围。模型把一份过期设计当成当前事实后，可能在更多文件中持续应用同一错误规则。它读得越多，错误方案有时反而会显得越“有依据”。
因此，成熟的上下文工程至少需要同时考虑四件事：
上下文质量检查
相关性： 当前步骤真的需要这些信息吗？ 新鲜度： 文档和代码是否仍然有效？ 权限： Agent是否有必要看到其中的敏感内容？ 可验证性： 模型依据的规则能否通过代码、测试或权威文档确认？
长上下文降低了信息放不进去的限制，却提高了信息治理的重要性。
正确的信息，要在正确时间出现
AI Agent完成大型软件任务，需要的不只是一个更大的窗口。
任务开始时，它需要项目地图和修改边界；分析权限模块时，它需要当前数据库结构和角色定义；准备修改接口时，它需要兼容要求；完成代码后，它需要测试、验收标准和回滚方式。
这些信息不必全部同时停留在最前台，但必须在对应步骤中及时、准确地出现。
我更愿意把长上下文理解为更大的工作台，而不是更聪明的大脑。工作台扩大以后，可以同时摆放更多代码、文档和工具，但如果桌面上堆满过期图纸、重复说明和无关材料，工作并不会因此变得可靠。
百万级上下文解决了大型项目中的真实限制。它让跨文件分析、长文档处理和长时间Agent任务拥有更大的操作空间。上下文压缩也让任务可以跨越更多阶段，而不必每次从零开始。
但真正决定Agent质量的，仍然是它看到的信息是否相关、清晰、最新并且能够验证。
AI工程接下来要解决的问题，不会只是“还能放入多少token”，而是如何建立一套持续更新的项目地图，如何让Agent按需获得正确资料，如何在压缩后保留关键约束，以及如何避免无关和敏感信息进入不需要它们的任务。
长上下文很重要。
更重要的是，在Agent准备作出下一项决定时，它看到的恰好是当前最需要、也最可信的那部分信息。