AIAgent怎样少花冤枉钱:规划、工具和上下文怎么配
AI Agent怎样少花冤枉钱：规划、工具和上下文怎么配
规划、工具和上下文压缩，该给AI Agent配到什么程度？一项176组配置实验，拆出成功率与成本之间的具体取舍。
同一个编程模型，接上不同的执行框架，可能一个还没改文件就停了，另一个改完以后反复检查，迟迟不肯结束。这两类失败需要不同的处理：前者要帮助模型推进任务，后者要明确完成条件。只盯着最终分数，很难判断该增加工具、强化计划，还是先清理上下文。
Run-Ze Fan、Zihao Zhang等研究者的《An Empirical Study of Harness Design for Coding Agents》把这些选择拆开研究。论文于2026年9月17日17:58 UTC首次提交arXiv，对应北京时间9月18日01:58；这里讨论的是v1。作者主页将其列为技术报告，尚无已核实的会议录用结论。[1][2]
这项工作的可用之处，在于把“框架好不好”转换成了有条件的问题：在什么模型、什么任务和什么窗口预算下，一个组件改善了哪种行为，又付出了多少代价。它没有给出适合所有AI Agent的配置单。
先分清模型与Harness各自做什么
Harness可以理解为围绕模型的执行框架。模型负责决定下一步；框架负责组装输入、提供工具接口、执行动作、收集返回内容，并判断还能不能继续。文件操作约束、上下文压缩和计划状态，也由这一层组织。
作者采用固定的ReAct循环：模型推理，发出动作，工具执行，观察结果回到下一轮。框架基于LangGraph实现，Harbor管理每道题的容器与验证器，宿主侧的Agent对容器采取动作。Harbor官方文档也将任务、Agent和运行环境分为不同对象；框架名称相同，不代表任务、权限和验证方式自动相同。[1][5]
研究主要拨动三个开关：是否维护持续更新的计划；工作区操作使用结构化工具还是主要通过shell表达；历史记录采用什么压缩策略。其他支持机制尽量保持不变，用来减少整套系统对比时的混杂因素。
这仍然有一个重要边界：工具接口切换会连带改变提示词、文件状态跟踪和编辑后的自动诊断。因此，实验能比较两套动作接口的整体效果，不能把全部变化归因于“工具数量变少了”。
图1：实验设计的阅读顺序。两项组件消融都与T4/128k基准分别比较，并非先关计划、再在无计划条件下切换工具。
176组配置，究竟比较了什么
模型包括Nemotron-3的30B、120B、550B，以及Mistral-Medium-3.5-128B。前三个模型提供同一系列内的比较，Mistral则帮助观察结论换一个模型家族是否仍成立。参数规模只是能力的粗略线索，训练数据、工具使用习惯和shell熟练程度都会影响结果。
评测覆盖两类工作。SWE-Bench Verified包含500个人工确认可解的真实GitHub问题，要求Agent在已有Python仓库里修复缺陷。Terminal-Bench 2.1包含89个终端任务，既有代码问题，也有环境与其他命令行工作。它们都需要连续行动，但“修好已有仓库”与“完成终端任务”的动作分布并不一样。[1][3][4]
这里的Terminal-Bench必须保留2.1版本号。官方说明，2.1是在2.0基础上对26个任务修复问题、调整资源或增强对奖励投机的抵抗能力。当前官网已经展示更新代际的榜单，不能拿那些成绩与论文的2.1结果直接并列。
上下文实验比较五种策略，分别搭配32k、64k、96k、128k四档窗口；每个模型在每个基准上得到20组配置。另加两组：在T4/128k条件下关闭计划，或改用bash-only接口。合计176组配置。计划与工具接口没有在所有窗口和压缩策略下穷举，因此这不是完整的全因素实验。
每个任务最多300步，每次模型输出最多16,384个Token，工具返回会截到24k字符；每步最多并行执行八个只读工具。实验采用本地SGLang、BF16精度，温度为0。每种配置对每道题运行一次，这一点限制了对稳定性的判断。[1，第3.1节]
“成本”也有专门口径。模型实际在本地运行，论文按2026年8月OpenRouter的输入、输出Token价格折算每任务美元成本，并不等于作者实际支付的GPU账单。它没有给出包括容器、存储、网络和人工维护在内的完整运营成本，省Token成本也不能直接翻译成更低延迟。
上下文压缩，先解决被窗口强行截断的问题
假设AI Agent已经读过多个文件，拿到大段搜索结果和测试日志。如果这些内容每轮原样带回，历史记录会越来越长。窗口一满，模型即使快要完成任务，也可能再没有机会继续。
论文中的T0不做额外的跨轮压缩，超过窗口就报错终止。它仍然受单次工具返回截断等共同限制，所以“无管理”不能理解为系统完全不处理输入。
其余四种策略分别处理这个问题：
| 策略 | 怎样处理旧记录 |
|---|---|
| T1 | 把较旧的大段工具输出换成短占位说明 |
| T2 | 在T1基础上保存原文，允许按事件编号调回 |
| T3 | 用同一个模型另开无工具调用，把旧记录总结成摘要 |
| T4 | 较早做删减并保存原文，仍然偏长时再总结 |
T4把历史分成需要保留的开头、需要保留的近期记录，以及可以压缩的中间部分。系统提示和最初任务保持原文，近期窗口按预算保留且至少覆盖最后两轮。这样，压缩优先作用于旧的中间内容，减少刚获得的重要结果立刻被改写的机会。
软阈值是可用窗口的0.6，硬阈值是0.85。超过软阈值，T4先把中间区域的大段工具观察存到外部，再留下占位说明；处理后仍超过硬阈值，才对更旧事件生成滚动摘要。近期原文窗口预算为可用窗口的0.3。这里的比例以“可用窗口”为分母，不宜未经核算就直接套在模型宣传的最大上下文长度上。
图2：T4的分阶段压缩逻辑。图中未超阈值时跳过相应压缩动作；外部回读按需发生，系统不会每轮自动把全部原文装回来。
作者报告，在32k窗口下，四种管理策略相对T0的平均成功率优势，在SWE-Bench上是35.7个百分点；到128k时，优势缩小为2.7个百分点。Terminal-Bench对应的是9.5和2.8个百分点。这是T1到T4的平均表现与T0比较，不能写成“T4提升35.7个百分点”。[1，第3.2节、图3]
与此同时，T0在SWE-Bench上的模型平均溢出失败率，从32k时的78.7%降到128k时的8.7%；有管理的策略在这些实验中没有窗口溢出失败。两组现象支持一个具体解释：小窗口下，压缩让原本被迫终止的任务获得了继续执行的机会。
因此，看到压缩后的成绩大幅提升，先检查旧系统有多少任务死于窗口溢出。若原系统已经很少溢出，再增加摘要层的收益可能小得多；摘要还会引入调用成本、信息损失和错误传播风险。
T4平均更省，回读接口却很少被用
T4的优势主要体现在成本结构。规则删减不需要另请模型概括长日志，能够处理的内容先用这一步解决，再把剩余压力交给摘要。在论文按模型和基准等权汇总的比较中，T4在四档窗口下都有最低的平均每任务成本；把四档窗口合起来看，它在八个模型—基准组合中的七个组合成本最低。[1，图4、图5]
这是汇总结论，不是每个单元格都获胜。例如Nemotron-3 30B在SWE-Bench、32k条件下，T1的每任务成本为0.09美元，T4为0.11美元。某一策略平均更合算，仍可能不适合你的模型与任务。
外部回读则暴露了另一个工程落差。T2保存原文，并提供recall_event，模型理论上能够找回被删内容。作者把T2与只有删减的T1配对比较：32组对照中，T2赢15组、输14组、平3组，平均成功率差为负0.36个百分点，未呈现一致收益。
在启用回读的64组T2、T4配置中，有36组完全没有调用这个接口。附录表13统计的是“每任务平均调用次数”，不是“多少任务调用过回读”的比例，更不能理解成信息保留率。
这个结果适合指导一次产品诊断：保存了历史，不代表模型会主动使用；提供了工具，也不代表它在合适时机知道该找哪段内容。可以分别观察回读触发率、编号选择是否正确、取回信息是否改变了下一步，以及最终是否完成任务。
但不能据此宣判长期记忆无用。这里研究的是单次编程轨迹里的旧工具输出回读，不是跨会话的用户偏好、长期项目知识或检索增强记忆。T4本身也包含外部存储，实验没有单独给出“完全相同的T4只移除回读”这一对照，所以不能把它的低成本归因于回读组件。
计划的作用，取决于模型在哪一步停下来
这项研究中的“有计划”，是一套明确的持续状态机制：最初要求创建计划，模型通过update_plan更新当前状态，后续每次调用都注入最新计划，而不把一份份旧计划反复追加到历史。关闭计划时，提示、提醒、注入和工具一起移除。
它测量的是这套计划支撑机制的效果，不是模型能不能在内部进行规划，更不是所有“先想后做”提示词的总效果。
Nemotron-3 30B在SWE-Bench上的变化比较直观：关闭计划时成功率13.6%，开启后25.2%，提高11.6个百分点；每任务Token折算成本则从0.02美元增加到0.09美元。作者的轨迹分析显示，没有计划时，68.6%的任务在未出现编辑行为时结束；有计划后，这一比例降到27.8%。计划帮助它继续推进，因此成功更多，也花得更多。[1，表3、表6]
对于Nemotron-3 550B，计划让每任务成本从3.31美元降到2.33美元，但成功率也从67.8%降到65.8%。Mistral在相同SWE-Bench设置下，成本从4.65美元降到3.14美元，成功率从69.0%变成68.6%。这类结果可以称为较低成本下的取舍，不能写成“加计划无损省钱”。
轨迹标签提示，较强模型减少的轮次主要来自修改后的验证阶段。作者据此认为，计划帮助模型减少重复验证。工程上仍要保留测试与交付门槛：少验证几轮，只有在关键验证依然完整时才有意义。若只是提前结束，账单会下降，漏掉的缺陷却可能转移到用户手里。
一个可操作的区分方式，是同时记录“未编辑就结束”“修改后重复验证”和“通过要求的验证后结束”。对第一类任务，计划应帮助定位下一步；对第二类任务，计划应带上明确完成条件。这些是由论文结果引出的工程建议，仍需用自己的任务验证。
只留bash，可能更自由，也可能更容易跑偏
完整工具接口提供读文件、写文件、精确编辑、列目录、搜索、网页获取以及bash。bash-only移除预定义的文件、搜索和网页工具，让模型主要用shell表达工作区动作。不过，与其他组件相关的update_plan和recall_event仍保留。因此，这里的“only”并非整个Agent只有一个函数。
Nemotron-3 550B在SWE-Bench上切到bash-only后，成功率从65.8%升到69.4%，成本从2.33美元降到1.11美元。作者观察到，它会把更多操作组合进一次命令，减少零碎交互。对熟悉shell的模型，这种动作表达确实可能更高效。[1，表3、表7]
Mistral则给出了很有价值的反例。在SWE-Bench上，同样切换后，成功率从68.6%降到45.4%；在Terminal-Bench上，却从37.08%升到43.82%。后者的成本也从2.22美元增加到2.75美元。一个模型面对不同工作负载，可以同时表现出相反的接口偏好。
所以，不能用一次终端任务表现就决定删掉文件工具。修复已有仓库时，精确搜索、带行号的阅读和局部修改可能很重要；命令行中心的任务则更容易受益于组合命令。工具选择需要结合任务类型，以及模型是否能可靠地把意图表达成有效命令。
还要单独检查保护机制。论文附录明确说明，shell发起的修改不进入结构化文件工具的状态跟踪和自动诊断路径。结构化工具中“先读后写”“检查外部修改”等机制，不能仅因为仍在同一个Harness里，就被认为对shell操作同样生效。
这项实验没有证明bash-only更安全。生产系统评估它时，还需要检查容器隔离、命令审批、文件访问范围、网络权限和修改后的验证。成功率与成本两个指标不足以批准更宽的执行权限。
把结果迁移到自己的AI Agent之前
论文的统计与覆盖范围决定了结论能走多远。作者使用任务配对的双侧精确McNemar检验，并以Benjamini–Hochberg方法控制多重比较的假发现率。Terminal-Bench只有89道题，不少差异没有达到统计显著；小幅分数变化应当视为后续验证线索。
此外，每个配置对每题只运行一次。即使温度为0，这也不等于检验过多次运行的可靠性。计划与动作接口只在T4/128k下比较，不能直接推出32k或其他压缩策略下会发生同样的变化。模型覆盖也仅限两个家族，SWE-Bench的Python仓库任务不能代表所有语言和全部软件工程工作。
轨迹解释依赖模型标注，再用人工样本检查。附录报告，200条轨迹的人工核验覆盖15,610个标注单元，汇总一致率约94.2%。三名标注者分别处理互不重叠的样本，不是三人逐条共同复核所有轨迹。这样的证据有助于理解行为分布，但仍不等于已经证明某一内部认知机制。
作者原文与主页提供了方法、提示词及工具说明，但目前未找到可确认属于该论文的官方实现链接与代码许可证。因此，现阶段适合借鉴其配置比较方法，不能把它当作已验证可直接安装的开源框架。上述数值均为作者报告的实验结果，尚不能当作独立复现结论。
如果正在维护一个编程AI Agent，可以从失败分类开始，而不必一次性重写整个框架：
- 经常窗口溢出时，先比较不压缩、规则删减和分阶段摘要，记录失败是否真的从“被截断”变成了“完成任务”。
- 模型迟迟不修改，或修改后反复检查时，在相同任务上单独开关持续计划，保留每阶段轮次与完成条件。
- 准备减少结构化工具时，将仓库修复和终端任务分开比较，并核对shell路径有没有失去原有保护。
- 所有比较同时报告成功率、每任务成本和停止原因；上线决策再加入多次运行稳定性、耗时及权限风险。
这些步骤不要求预先相信T4、计划或bash中的任何一项。先固定模型与任务，把一个变化对应到一种可观察行为，再决定是否保留。若成功率下降超出业务容忍度，即便平均Token成本更低，也应继续寻找其他配置。
资料来源
[1] 论文v1：方法、实验、表3—4及附录7—9。
https://arxiv.org/html/2609.20804v1
[2] Run-Ze Fan作者主页：技术报告条目与作者信息。
https://rzfan525.github.io/
[3] SWE-bench官方文档：问题修复任务及Verified数据集。
https://www.swebench.com/SWE-bench/
[4] Terminal-Bench 2.1官方仓库：该版本的说明与任务目录。
https://github.com/harbor-framework/terminal-bench-2-1/tree/7131e4375048a0e408a8fb404b5f499d726b695b
[5] Harbor官方文档：任务、Agent与运行环境的边界。
https://www.harborframework.com/docs