编码智能体的基本循环并不神秘：理解目标、搜索代码、制定计划、修改文件、运行检查，再根据工具反馈迭代。大代码库真正困难的地方，常常不是生成一段代码，而是找到完成改动所需的全部关系。
模型只能推理当前看到的信息。它若只打开一个函数和附近测试，可能交出局部正确的补丁，却漏掉另一个仓库的调用者、序列化协议、权限守卫、迁移脚本或集成测试。
上下文问题有两个相反的失败方向
第一种是信息不足。关键词搜索或向量相似度找到“看起来相关”的文件，却没有覆盖符号定义、所有调用点、接口实现和跨仓库依赖。
第二种是信息过载。把整座代码库、长对话、所有工具说明一次塞进上下文，会稀释高价值信号并增加成本。Anthropic 对上下文工程的定义强调，目标是找到足以产生正确行为的最小高信号信息集合，而不是最大化 token 数量。
因此，上下文系统应同时具备“扩大搜索范围”和“缩小每次读取内容”的能力。
检索需要多条通道
大型代码库不适合只依赖一种检索方式：
- 文本搜索适合错误信息、配置键、日志和未知符号；
- 语言服务器或代码索引适合定义、引用、实现和类型关系；
- AST 或语法感知切片可以只提供相关函数、类型和邻近结构；
- 构建图、依赖图和所有者信息用于识别跨包、跨服务影响；
- 工单、设计文档和历史决策解释代码为何如此；
- 测试、编译器和运行时输出提供当前环境的事实反馈。
Sourcegraph 的 2026 指南把精确符号关系与跨仓库搜索作为“大代码”场景的重点。不过它是厂商文章，其中的“80% 问题”和企业使用数据应视为 Sourcegraph 对客户场景的概括，不是普适研究结论。
缓存不能替代正确性
Prompt Cache 可以降低重复前缀的处理成本，适合稳定的系统指令、工具定义和长期不变的仓库说明。但缓存命中只说明输入前缀复用，不说明内容仍然正确。
实践中应把上下文分层：
- 稳定层：安全规则、仓库地图、工具契约，版本变化较慢。
- 任务层：工单、验收标准、相关模块与依赖，随任务更新。
- 工作层：当前 diff、测试输出、失败轨迹，只保留近期高信号部分。
- 外部状态：计划、决策日志、未完成项和验证结果，写入可恢复文件。
当代码、分支、索引或工具版本变化时，缓存键也必须变化。否则省下的 token 可能换来陈旧上下文。
差异追踪让上下文跟着工作区变化
智能体每次修改后，都应重新建立“当前状态”，而不是继续依赖修改前的摘要。可追踪的信息包括：
- 哪些文件和符号被修改；
- 修改触及哪些引用与依赖；
- 新增或删除了哪些测试；
- 工作区与基线分支的差异；
- 哪些检查实际运行、结果是什么；
- 哪些风险仍未验证。
一个实用的完成门槛是：智能体声明完成后，再对被修改的公共符号做一次引用搜索，对最终 diff 运行构建、静态检查和相关测试。测试通过仍不等于改动完整，但能提供比模型自述更可靠的证据。
把搜索预算用于不确定性最高的地方
不是所有任务都需要跨仓库索引。单文件格式修复可以使用局部上下文；公共接口、认证、数据模型和共享库变化，则应升级为跨仓库影响分析。
团队可以在任务开始时先分类：
- 改动是局部还是横切；
- 是否涉及公共契约或持久化数据；
- 哪些仓库和运行环境可能受影响；
- 有哪些机器可验证的验收条件；
- 哪些信息只能由代码所有者判断。
上下文工程并不能保证智能体找到所有隐含依赖，也不能免除代码评审。它的价值是让“为什么读这些文件、还缺什么证据”变得可观察，从而降低在错误局部视野中自信完成的概率。
参考资料与延伸阅读
- Anthropic：Effective context engineering for AI agents
- Sourcegraph：Agentic Coding in 2026
- GitHub Docs：About code navigation
- OpenAI：Prompt caching
- Model Context Protocol：Architecture
资料核验日期：2026-08-23。