先选这次修改需要的材料，不要先选最大的窗口。 收集相关代码、当前指令和测试。检查这些材料能否放进当前工具的可用窗口。再运行任务，验证结果。更大的窗口是一个待测选项，不是正确修复的保证。
这篇指南帮助你准备第一次输入，并判断失败后该做什么。内容结合了我们在 ContextAdapt 中的实践。已发表的研究文章比较了不同方法能保留哪些代码证据。它没有证明所有编程 Agent 都适用同一个上下文长度。
AI 编程需要多长的上下文
我们不能给所有编程任务推荐同一个 token 数。你可以用下面的清单准备第一次尝试。这是一套起步方法，不是已经验证的最小值。
按任务选择材料
每个任务都先写清四件事：预期行为、当前约束、允许修改的范围、验收方法。然后补充相关代码和测试：
| 任务 | 先收集哪些材料 |
|---|---|
| 修复一个范围明确的错误 | 失败输入或报错、相关实现、直接调用方，以及能复现错误的测试。 |
| 修改多个模块之间的行为 | 上述材料，再加上受影响的接口、配置、依赖关系，以及关联模块的测试。 |
| 迁移整个仓库 | 迁移范围、受影响的模块、当前版本和目标版本、兼容要求，以及迁移验收项。处理到哪一部分，再补充对应源码。 |
例如，假设解析器遇到空输入就出错。先提供解析函数、传入空输入的调用方和失败测试。这是教学示例，不是 ContextAdapt 的实验结果。不要预先认定只给一个函数就够，也不要认定必须把整个仓库放进去。
接着，统计组装后输入的 token 数。工具提供计数功能时，优先使用它。把指令、对话历史和工具返回内容一起计算。按服务商的规则预留输出空间。窗口容量是可用上限。实际输入是你送入的内容。任务证据是完成任务所需的信息。这三者不同。检查当前服务商和工具的限制，不要只看模型名称。窗口概念可参考 Google 的上下文指南。
失败后，先检查原因
- 缺了必需文件： 先检索并补充，再重试。补充相关材料不一定需要更大的窗口。
- 必需材料放不下： 测试更大的可用预算。依赖关系允许时，也可以拆分任务。两种做法都要验证结果。
- 环境或权限阻止了执行： 有授权时修复测试环境；没有所需权限时停止并请求授权。增加 token 不能解决这些问题。
我们的实验能补充什么
在 30 个留出任务中，同样给定 40% 的源代码预算，头尾截断有 10 个任务通过严格证据保留指标，关键词检索有 18 个，ContextAdapt v3 也有 18 个。相关源文件已预先选定。这里的通过是保留了证据，不是修好了问题。这个结果支持我们比较材料选择方法，但不能证明 ContextAdapt 在这个预算下优于关键词检索。完整实验和限制见研究文章。这不是 200K 与 1M 的对比实验。
大模型上下文长度应该怎么选
先规定怎么验收，再选择上下文策略。 策略包括检索什么、保留什么、何时补充材料。窗口上限本身不能回答这些问题。
先填写一张任务卡。下面是一个假设示例：
| 项目 | 修改 API 适配器的示例 |
|---|---|
| 预期结果 | 支持新的响应格式，同时保留旧格式支持。 |
| 第一次输入 | 两种格式的说明、适配器代码、直接调用方和相关测试。 |
| 验收方法 | 新格式测试、旧格式回归测试，以及修改范围检查。 |
| 限制 | 不得修改已保存的客户数据或无关模块。 |
统计完整请求，不要只统计源码。指令、历史消息和工具结果也会占用上下文。可参考 VS Code 的官方说明。按服务商规则预留输出空间。
准备两个候选。第一个只包含上表中的相关材料。第二个再加入可能解释失败的关联依赖。使用同一初始状态的独立副本运行。固定模型、工具和测试。记录是否完成、是否越界、全部成本和总耗时。
如果精简输入通过验收，再用另一个有代表性的任务检查这套策略。如果失败原因是缺少依赖，先检索补齐，不要直接认定窗口太小。如果必须更换模型才能扩大窗口，就把结果称为两套配置的比较。不能把差异全部归因于上下文长度。
200K 上下文写代码够用吗
必需输入放得下，并且 Agent 能通过验收时，它就可能够用。 这是两个条件。没有超限，不代表材料选对了，也不代表 Agent 会正确使用这些材料。
下面是假设的 token 预算，不是 ContextAdapt 的实测结果。假设当前配置允许输入和输出共用 200K token，并允许分配 16K 输出空间：
| 内容 | token 数 |
|---|---|
| 指令、工具定义和已有历史 | 12K |
| 选定的源码 | 68K |
| 测试结果和报错细节 | 4K |
| 预留的输出额度 | 16K |
| 合计分配 | 100K |
当前输入为 84K token。按这个假设，共享窗口还剩 100K 空间。但这不保证后续每次工具返回都能放下。会话增长后要重新计数，也要检查单独的输入和输出限制。优先使用当前模型的计数工具。可参考 Google 的请求计数和返回用量说明。
在这个例子中，先用已整理的材料运行测试。不要为了填满窗口而加入无关文件。缺少调用方，就检索该调用方。必需材料仍然放不下，再比较更大的可用预算。缺少环境依赖导致测试无法启动，就先在授权范围内修复环境。缺少权限，就停止并请求授权。单凭其中一种失败，不能认定 200K 不够用。
200K 和 1M 上下文编程怎么选
比较任务结果，不要只比较窗口标签。 这里的 200K、400K 和 1M 是容量示例。只有当前配置支持时才能测试。可用上限是 1M，不代表每次必须输入 1M token。
以跨模块迁移为例。先定位受影响的接口、调用方和测试。如果相关材料能放进较小预算，先测试这个候选。如果必需的关联信息无法一起保留，再测试更大的候选。也可以沿着能独立验收的边界拆分任务。
让下面三种策略处理同一组有代表性的任务：
| 策略 | 待测试的规则 |
|---|---|
| 固定较小上限 | 在较小上限内检索并保留相关材料。 |
| 固定较大上限 | 允许保留更多相关材料，但不刻意填满空间。 |
| 按条件扩大 | 先用较小预算；记录到缺失证据或材料放不下时，再判断是否扩大。 |
运行前规定重试次数。第一次尝试、检索、准备和每次重试都要计入成本。尽量固定模型和工具。只有确实需要比较中间档时，才增加 400K 候选。
也要检查工具怎样压缩历史。VS Code 官方文档说明，历史摘要可能压缩或遗漏早期细节。扩大上限与改进摘要策略，是两种不同的修改。
最后选择能满足预定验收和安全标准，且总成本可接受的策略。动态调整只是待测方案，不是预定赢家。我们已发表的证据保留实验没有证明哪个窗口档位更好。
上下文窗口越大代码生成效果越好吗
有时会，但更大的窗口不保证补丁正确。 如果它能补回任务需要的信息，就可能有帮助。信息进入了上下文，不代表 Agent 一定会正确使用。
Google 与 Sourcegraph 在 2024 年公布的案例中，长上下文的 Cody 配置改善了技术问答。这个结果适用于当时的配置和任务，不能直接当作所有错误修复的结论。Google 的上下文指南也指出，检索多条信息可能比只找一条更不稳定。编程助手案例 · 检索限制
增加上下文前，可以在同一任务上比较三份输入：
- 当前输入。
- 当前输入，加上具体缺失的证据，例如调用方或失败测试。
- 包含这些证据及更多周边代码的较大输入。
固定模型、起始代码、工具和验收测试。重复测试每种输入。比较修复是否通过、是否引入回归、是否越权，以及总成本和耗时。如果只有精准补充有效，这支持的是材料选择方法，不是把窗口填满。如果较大输入多次改善结果，再判断改善是否值得额外成本。
下面的已发表实验回答一个更窄的问题：选择上下文后，哪些代码证据被保留下来。它不衡量任务是否修复。
我们的留出实验实际发现了什么
在 2026 年 9 月 2 日冻结的实验中，我们使用来自 12 个仓库的 30 个 SWE-bench Lite 留出任务，比较上下文选择方法。同样给定 40% 的源代码预算，严格证据保留指标的结果如下：
| 上下文选择方法 | 满足证据保留条件的任务数 |
|---|---|
| 头尾截断 | 10 / 30 |
| 根据问题关键词检索 | 18 / 30 |
| ContextAdapt v3 | 18 / 30 |
通过这个指标，需要同时满足：不超预算、保留源代码中与问题描述精确匹配的所有行，以及为参考补丁的每个修改块至少保留一行标记为删除的原代码。它不等于 Agent 修好了问题。相关文件已根据参考补丁预先选定；选择器只看到问题和原始源码，补丁内容仅用于评分。这一步没有测试全仓库定位，也没有执行生成补丁。
这个对照给了我们一个实际理由：除了问“上下文有多长”，还要测“留下了什么”。它也对我们自己的设计提出了挑战：在这个预算下，更复杂的方法没有胜过关键词检索。对全部七个压缩预算取平均，ContextAdapt 相对关键词检索的优势为 7.1 个百分点，95% 置信区间为 −2.3 到 +17.9，仍不能确认存在提升。
对正在选方案的开发者，我的建议是先加入一个简单的相关性检索基线，再判断复杂方案是否值得用。仅仅胜过截断，还不足以作出这个判断。这里的百分比是按字符数估算 token 后分配的源代码预算，不是对 200K 和 1M 窗口的直接比较。完整结果见结果账本与冻结协议。
大模型上下文长度的成本延迟和准确率怎么权衡
先定可接受的完成率和安全要求，再比较总成本与耗时。 单次请求便宜，不代表完成一个任务更便宜。
每次任务尝试都保留一条记录：
| 记录项 | 包含什么 |
|---|---|
| 结果 | 独立验收结果、新增回归、约束违反情况，以及失败原因。 |
| 用量和费用 | 全部输入与输出 token、缓存用量、准备调用、检索、重试和升级。实际费用与估算费用分开。 |
| 耗时 | 从开始到最终结果，包括工具执行和重试。首 token 延迟单独记录。 |
| 条件 | 模型、上下文策略、任务版本，以及缓存状态。 |
Google 指出，Gemini 的较长请求通常会增加首 token 延迟；缓存可以降低重复输入的成本。这两点都不能直接给出你的编程流程总耗时或总费用。仍要检查当前服务商的规则，并测量完整流程。延迟说明 · 缓存文档
一个实用指标是：包含失败尝试的全部实测成本 ÷ 通过验收的任务数。
举一个虚构算例。方案 A 在十个任务上花费 2 美元，完成八个，每个完成任务的成本是 0.25 美元。方案 B 在同样十个任务上花费 1.50 美元，完成五个，每个完成任务的成本是 0.30 美元。A 的总支出更高，但每个完成任务的成本更低。这只是计算示例，不是 ContextAdapt 的实验结果，也不是服务商报价。
在这个比值旁边，同时展示完成率、安全失败，以及常见和较慢运行的耗时。如果没有任务完成，比值就没有定义。违反必需安全条件的方案，即使平均成本低，也不应被选中。
如何评估编程任务需要的最小上下文
测量目标是：在固定验收条件下，找出能通过的最小已测上下文。它不是通用最小值。先选一个边界清楚的小修复，再选一个较难的跨文件修改。
- 固定两个任务、初始代码版本、必过测试、受保护文件和成功标准。不要用预期补丁来挑选输入。
- 选择几个环境支持的输入预算。每次模型请求都使用对应预算，不只限制第一条提示。固定模型、工具、输出预留空间、检索和摘要规则。同时改变材料选择方法和长度，会混入两个因素。
- 每次从干净的初始状态运行。提前规定重复次数、重试上限和升级条件。保留每次失败。
- 保存实际上下文和全部尝试。记录检索、准备、审查、重试、输入输出用量、费用和总耗时。
- 比较完成情况、约束违规和成本。先在未参与调试的任务上重复验证，再给出更广的建议。
每个任务、候选和重复轮次各记一行：
| 记录项 | 保存什么 |
|---|---|
| 设置 | 任务、代码版本、模型、材料选择方法、输入预算 |
| 结果 | 必过测试、受保护文件检查、失败原因 |
| 完整尝试 | 实际输入、输出用量、重试、费用、总耗时 |
不要假设上下文越长，成功率就持续上升。仅靠二分搜索不能证明最小值。一次成功也不能证明稳定可靠。
保留证据和完成修复是两种测量。ContextBench也单独测量过程中的上下文检索，不只看最终成功。
在我们的冻结实验中，ContextAdapt v3 对 30 个留出任务中的 8 个，在已测预算中需要保留预先选定的完整源码，才能覆盖参考补丁每个修改块的原代码行。这不等于 8 个真实 Agent 必须读取整个仓库。它说明需要上面的真实 Agent 实验，不能作为自动停止增加上下文的规则。冻结结果
有哪些开源工具可以测试 AI Agent 上下文长度
先决定要测什么，再选工具。这三个项目都不能自动替你的应用找出最优上下文窗口。
| 工具 | 测量对象 | 不能据此证明 | 从哪里开始 |
|---|---|---|---|
| RULER | 长度和复杂度可控的合成长上下文任务 | Agent 能否安全修复你的仓库 | 从 README 指向的当前评测分支开始 |
| SWE-bench | 将生成补丁应用到真实仓库，再执行测试 | 结果由哪种上下文策略造成，或完整成本是多少 | 阅读 Lite 评测和补丁提交格式 |
| ContextAdapt | 已发表实验测量固定源代码预算下保留的修改证据 | 真实修复提升、账单节省或通用最小窗口 | 查看证据包和冻结对照 |
RULER 帮助测试模型的长上下文表现。SWE-bench 检查提交的补丁能否解决其任务。ContextAdapt 的已发表实验比较不同材料选择方法保留源码证据的情况。三者可以配合使用，分数不能互相替代。
我们的实验本身使用了 SWE-bench Lite 任务。它不是 SWE-bench 的替代品，也不存在“胜过其评测框架”的结论。
第一次编程实验，可以使用上一节的两个任务和记录表。让每个候选生成补丁，再运行相同的独立测试。Agent 失败后，分别检查它检索的上下文和它生成的补丁。如果还需要研究长上下文检索，再加入合成基准。
运行上游基准前，先检查硬件、存储、凭证和模型调用费用。阅读结果与亲自复现，是两个不同步骤。