--- layout: post.njk source: https://yage.ai/share/agent-harness-tricks-benchmark-20261109.html web_feed: articleId: cmw9wg7rm0003yhedm6kjn6wl feedSourceId: webfeed_yage_ai guid: https://yage.ai/share/agent-harness-tricks-benchmark-20261109.html sourceUrl: https://yage.ai/share/agent-harness-tricks-benchmark-20261109.html speaker: yage.ai title: |- 现在的 Agent Harness 越来越复杂，哪些技巧在跑分里真正管用 date: '2026-11-09' summary: 文章讨论了当前 Agent Harness 的复杂性，以及在工程评测中哪些技巧真正有效。研究通过对比不同方案，发现派多代理开会（如 Compound Engineering 插件）的成本极高，而调高单个模型的思考档位或在主循环中设置“先写失败测试”和“回合末目标核对”这两个小关卡，能以更低的成本获得显著的性能提升。此外，通过对底层框架进行改造（如慢命令转后台、长输出写文件留预览、追加式摘要保缓存）和编写单元测试，可以有效解决长程任务中的卡死和上下文压缩问题，从而提升最终得分。 area: tech-engineering category: testing tags: - agent-harness - ai-tooling - testing - workflow-automation - model-evaluation people: [] companies_orgs: - Surge AI - University of California, Los Angeles products_models: - Claude Opus 5.5 - GLM-5.3-Flash - Compound Engineering - Claude Code media_books: [] draft: true status: evergreen --- 以前我们做一个编程智能体，用一个大模型加百来行主循环就可以跑起来了。但是现在再去看看大厂开源的工程框架或者社区流行的几万星项目，包裹在模型外层负责调用工具和管理上下文的那层代码，业内称为 Harness，也就是外围框架，如今正变得越来越庞大，内置了数十种技能、十几个子代理开会机制，以及各种各样的上下文压缩钩子。确实，如果只用最简陋的主循环让智能体连续跑几个小时的大任务，它很容易在中途卡死或跑偏；但个人开发者想自己搭一套顺手的框架时，面对这堆复杂的工程设计，很难分清哪些真能提分省钱，哪些只是徒增账单的花架子。 2026 年 11 月初，数据评测公司 Surge AI 和加州大学洛杉矶分校联合团队的 FireFlash 项目在同一周发布了各自的实测报告。两家团队把流行的工作流插件和底层框架技巧逐个拆开，在真实工程题和长程终端任务上做了对照实验，帮我们筛出了真正有用的工程技巧。 ## 为什么派 17 个子代理轮流开会，还不如让单个模型多想一会儿？ 让现在的旗舰大模型写一段局部代码并不难，难的是改动大型代码库时不漏掉上下游的隐患。Surge AI 找资深工程师从真实公司的生产代码库里提炼出 60 道高阶工程题，建了一套叫作 sudo L7 的工程评测基准。这套测试每道题满分 100 分、75 分及格，评分标准像资深工程师审代码一样严苛：如果只看眼前的报错有没有修好、局部功能能不能跑通，几家主流大模型都能拿到八成左右的高分；但评分表里还会检查模型有没有把下游调用方改坏、有没有放着库里现成的工具函数不用而重复造轮子，以及有没有发现需求本身隐藏的业务漏洞。把这些工程扣分项全算进去之后，能够跨过 75 分及格线的题目比例一下子掉到了三四成。 为了解决这个问题，最流行的方法是在智能体上添加一个模拟软件公司开会的多代理插件。比如开源社区中流行的 Compound Engineering 插件，它提供了 37 项技能，让多个代理按照计划、执行、审查的流程依次进行。在 Surge AI 的外围框架实验中，有一个问题是修复活动报名系统中的一个漏洞，用户在填写报名信息后，在付款前，系统会发送一封包含线上会议密码的确认邮件。 把这道题交给 Compound Engineering 处理时，它直接派出了 17 个子代理来审查计划、精简代码、检查代码质量。遗憾的是，这批子代理全都通过了审查，没有一个发现确认邮件在付款之前就已经发送。这是因为最初写计划的主代理没有考虑到付款的时序，所有子代理都根据同一个错误的计划来审查代码格式。 整场实验跑下来，这个复杂的插件把每道题的调用成本推高到了原来的 8 倍，但分数只是从默认的基线 31.1 分微涨到 32.9 分，差别落在随机波动的范围内。甚至插件作者的代码库最近也专门合并了一条限制子代理派发条件的更新，改为只在确实划算的场合派发子代理。 与其花大价钱雇十几个浅层思考的分身开会，不如把钱直接砸在单个模型的思考深度上。最直接的一招往往不用装任何外部插件，只要把同一个 Claude Opus 5.5 模型的思考档位从默认的中档调到高档 xhigh。在另一个视频剪辑软件缺失首帧导致崩溃的题目里，中档思考的模型只把眼前的报错堵上就停手交卷了，只拿到 14 分。调到高档思考后，模型修完第一处报错，又顺着回退路径往下游多查了一步，发现另一处代码也默认第一帧必然存在，顺手把两处隐患一起修好并拿到了 100 分满分，单题只多花了 0.29 美元。 如果把整个测试汇总起来，不装任何花哨插件、单纯调高单模型的思考档位，总分直接跃升到 42.4 分。这 11.3 分的跨越只花了基线 3.5 倍的成本，在验证彻底性和性价比上都把多代理开会的方案甩在了身后。 ## 如果不搞多代理开会，控制循环里留哪两个小关卡就够了？ 在把单模型的思考档位调高之后，模型在单步推理上已经相当深入，但在多轮循环中仍然会出现两个典型错误。一个是拿到模糊需求时不写测试直接改代码，另一个是修改完第一个报错就自我感觉良好提前交卷。 解决这两个问题也不需要搞一个多代理委员会，只需要在单主干循环里面做两个小改动。开源插件 Superpowers 把多人评审的复杂场面去掉了，只要求一件事：在写功能代码之前必须核对清楚需求规格，跑通先写失败测试再写代码让它变绿的测试驱动开发循环。这个改动只让调用成本增加了 10%，就把总分提高了 2.4 分（达到 33.5 分），拿到了具有统计显著性的提升。 另一个有效的关卡是防止过早提交。Claude Code 自带的 /goal 目标核对命令结合代码审查插件，可以在每一轮模型想要停止并提交的节点，额外执行一次完成条件检查。如果检测到初始目标并未真正实现，就会把任务抛回下一轮，让模型继续干活。这个简单的回合末闭环只用了 1.8 倍的成本，就把总分推高了 3.3 分（达到 34.4 分），在所有外挂工作流里拿到了最高分。 控制层越轻越好，这一点在加州大学伯克利分校团队的 HarnessTax 评测报告里也得到了印证。研究团队把重型商业框架和只有 100 行代码的极简框架放在 492 道标准编程题上做了横向对比，发现重型框架在第一轮的系统提示词和工具定义中多消耗了近 20 倍的词元，让单题账单贵了 3 到 5 倍，但最终的解题准确率差距还不到 2 个百分点。 在 60 道真实工程题上，派 17 个子代理开会将成本推高至 8 倍却仅带来 1.8 分的无显著性微涨，而直接调高单模型思考档位以 3.5 倍成本换取了 11.3 分的跃升。 ## 单步思考和循环关卡都配齐后，长任务里的 4.4 分是从哪抠出来的？ 既然控制流如此简单，为什么工业级外围框架的底层代码仍然很厚呢？这是因为在长程终端任务中，即使模型一开始就调到了最高的思考档位，受制于终端环境的物理限制，它仍可能中途卡死。在 FireFlash 项目的长程智能体技术报告中，研究团队使用开源的 GLM-5.3-Flash 模型，将其锁死在最高思考档位，并只给它保留了在终端执行命令、读写和编辑文件这 4 个基础工具。但如果直接使用官方默认的 Claude Code 框架去跑终端评测基准 Terminal-Bench 4.0，它只能得到 35.8 分；而换成研究团队改造的底层框架，不做任何模型训练，就可以得到 40.2 分。 这额外的 4.4 分，全来自底层框架帮模型扛住了长程任务里三种具体的死法。第一种死法是终端日志糊眼和超时误杀：跑一次大型编译或测试，终端会掉出几万行输出，直接丢进对话就会把上下文淹没；若是编译慢一点撞上超时阈值，普通框架直接杀进程，前面做的努力全费了。FireFlash 的做法是让每个命令的标准输出默认都落到一个临时文件里，模型只看到一小段截断预览和文件名，想看细节就再去按需读文件；碰到慢命令超时也不杀进程，而是自动转到后台异步继续跑。 第二种死法是上下文压缩：任务做久了，对话快满 85% 容量就要压缩历史。如果直接把老的对话删掉换摘要，就改写对话的开头，打碎大模型用来省算力的前缀缓存，后面每一轮都全价重算。FireFlash 换了个巧办法：保留最新的一截原文，把老记录压成摘要，再用追加式的分段提示词接在已有历史后面，这样既腾出空间，又保住了前缀缓存。就这三项改造（慢命令转后台、长输出写文件留预览、追加式摘要）已经把单次尝试的成本砍掉大约三分之一。 疏通了管道以后，团队又针对第三种死法，在提示词里立了三条反废操作的规矩。智能体在终端里常干三件烧钱的傻事：用 sleep 命令死循环轮询后台任务、为改几行代码把整个大文件从头重写一遍、以及分多次零碎写入同一个文件。提示词明确禁止 sleep 空转、强制使用就地修改工具、要求文件单遍写完后，单次运行成本又在砍掉三分之一的基础上额外省下了 16%。 FireFlash 的底层框架通过慢命令转后台、长输出落盘预览、追加式摘要保缓存与反废操作规矩提升 4.4 分并大幅压降成本，配合保持框架一致的强化学习后总计提升 10.4 分。 ## 为什么顶尖团队最后还要给外围框架写单元测试？ 在修好底层管道后，FireFlash 团队又用强化学习补了后半程的 6.0 分，把终端基准推到了 46.2 分。而他们的开源方案单次成本只要 0.72 美元，一举反超了闭源方案 Fable 5（44.5 分，单次成本 22.02 美元）。 后半程的提升则源于一个容易忽视的细节：模型在出厂预训练时从未见过这种自定义的追加式摘要和截断文件预览格式。为了让模型真正吃透这套自定义管道，团队专门写了一套自动化单元测试，强行锁死强化学习训练采样时用的外围框架和最后考试评测时用的外围框架，保证两边的代码逻辑与提示词一字不差。接着他们用 64 张显卡跑了不到 5 天的全参数强化学习，同时对用更少词元解出题目的尝试给予长度加分，把成功解题的词元消耗压到了原来的 84%，让模型在训练中摸透了这套底层管道的脾气。 这也解释了为什么今天大厂开源的外围框架往往看起来神秘莫测，因为顶尖团队已经把底层管道和模型的后训练拧在了一起。但对不用自己从头训模型的个人开发者而言，剥掉那层复杂的外壳后，真正经受住跑分检验的做法其实就握在自己手里。与其去搭十几个子代理轮流开会的形式主义班子，不如先把单模型的思考档位调高，在主循环里守住先写失败测试和回合末目标核对这两个小关卡，再把长输出写文件留预览、慢命令转后台、追加式摘要保缓存以及禁止轮询空转写进自己的底座里，用几百行干净的代码就能拿走工业级框架最核心的红利。