Agent分数涨了，是更聪明了，还是换了更宽松的考场？

两轮Agent评测用的是同一个模型、同一套题，第二轮得分却更高。团队准备把功劳记在新提示词上，后来才发现：第二轮换了机器，测试不再那么容易超时。

这不是一份真实测试报告，而是本文的教学情境。它要提出一个很实际的问题：当Agent要在环境里安装依赖、编译代码、运行测试时，怎样分清“更会解决问题”和“拿到了更宽松的考场”？

AI原创概念插画：巨型贝壳内，左侧红色机械鸟站在宽敞的黄铜环舞台上，右侧较小的红鸟位于深蓝低罩之下，前景放着音叉和扣合的空白笔记本。画面只隐喻比较条件不同，不是实际声学装置、评测数据，也不表示两只鸟是完全相同的样本。

一、Agent的考场会参与作答Copy Anchor Link

普通的文本问答，可以主要检查输入和输出。编码Agent还会在中间改变环境：下载软件包、启动子进程、跑编译器、读写磁盘，再根据测试反馈继续修改。CPU、内存、网络与时间预算，都会影响它能走到哪一步。

因此，“模型相同、题目相同”只是可比性的起点，不是终点。

Anthropic在2026年2月5日发布的工程文章里，报告了一个受控比较：保持Claude模型、Harness与题目集不变，改变Terminal-Bench 2.0的资源配置。其最严格与不设上限配置之间，成功成绩相差6个百分点。[1] 这是该厂商在特定实验中的结果，本文没有复现，不能据此推断任何模型换台机器就会获得同样收益。

更有意思的是它给出的解释：适量资源余量主要减少环境故障；继续放宽后，Agent可能开始使用原来承受不起的重型依赖和计算方法。前者是让考场更稳定，后者可能已经改变了题目的约束。

少发生一次环境崩溃，与允许一种更昂贵的解题策略，不是同一种改进。

二、“给了多少资源”还要问怎么执行Copy Anchor Link

配置表只写“内存预算”，往往不够。它是调度时的资源请求，还是执行时的上限？超过以后，是等待、降速、终止，还是暂时允许突发使用？

以Kubernetes当前官方文档解释的Linux容器机制为例：[2]

• requests参与调度与资源分配；节点有空闲时，容器可能使用超过请求量的资源。
• CPU上限通常通过节流执行：容器获得的CPU时间被限制，不是因为CPU用得多就直接被杀掉。
• 内存上限则涉及OOM终止风险；它是反应式执行，不能简化成“超出一个字节便立刻退出”。

这些是不同的执行语义。把它们都叫“严格限制”，很容易遗漏真正改变试验的地方。具体行为还取决于平台、运行时和配置，不能把Kubernetes的字段直接套给所有沙箱服务。

同样，评测写着“超时”也需要继续拆开：环境准备、Agent运行、单个工具、最终判分分别用了多久？计时从什么时候开始？如果冷启动下载也消耗Agent的总预算，而另一轮使用了已缓存的依赖，那么相同的墙钟期限，不代表相同的有效工作机会。

这不意味着必须一律排除安装时间。如果产品本来要求从空环境交付，安装就应该计入。关键是提前定义被测产品，而不是看见结果后替某一轮换解释。

三、跟着一个修复任务排查Copy Anchor Link

下面是未执行的虚构案例，不含真实模型输出或性能数字。

任务要求Agent修复一个CSV导入错误，并通过仓库测试。旧提示词A在环境E1运行，新提示词B在环境E2运行。E2拥有更宽松的内存上限，软件包缓存也更完整。结果B通过，A没通过。

此时最多能说：“B与E2的组合在这次试验中通过了。”不能单独把差异归因于提示词。

可以依次做三件事。

第一步：保存失败发生在哪一层Copy Anchor Link

不要只留下一个红色叉号。至少保留任务ID、环境配置、退出原因和对应日志入口：

最后一条尤其重要。如果Agent在明确预算下主动选择了过于昂贵的方案，资源失败可能正是产品要测的能力边界。看到OOM，只能先记下观察；它本身不能证明“模型无责”。

第二步：把交叉变化拆开Copy Anchor Link

若要研究提示词，应在同一环境策略下比较A和B。若要研究资源策略，应保持模型、提示词与Harness一致，再比较环境。

条件允许时，可以预先安排四种组合：A/E1、B/E1、A/E2、B/E2，并按相同规则做重复试次。这样能检查B是否只在宽松环境里表现更好，以及环境变化是否影响两套提示词的差距。这是实验设计建议，不是本文已经运行的实验，也不能用每格一次通过就宣布因果结论。

运行顺序应尽量随机或交错，避免所有A都在一个时间段、所有B都在另一个时间段。外部API延迟、缓存与共享主机负载仍需记录；交错运行减少某些混杂，不会自动消除所有干扰。

第三步：不要把失败悄悄从分母里拿掉Copy Anchor Link

报告可以同时保留两个视角：

• 端到端交付视角：全部计划试次中，多少真正完成任务；环境故障仍影响用户拿到结果。
• 诊断视角：哪些试次因何停止，哪些已具备有效的判分结果，哪些原因仍不明确。

若另外计算“仅在可判分试次中的通过情况”，必须明确分母和排除规则，并同时展示被排除的数量与原因。这一条件化结果不能代替端到端成绩；若更难的题更容易让环境出错，删掉它们反而会让剩下的成绩显得更漂亮。

SWE-bench的官方评测指南就把已完成、已解决、未解决和错误等计数分别解释，并提示检查逐题日志。[3] 这些字段属于它当前的评测实现，不是所有框架共享的状态协议，但其诊断思路很值得借鉴：Harness继续跑完了，不代表每道题都有有效判分；没有判分，也不等于已经查明了根因。

四、该固定资源，还是贴近生产？Copy Anchor Link

两者回答不同的问题。

如果你要判断一次提示词修改是否值得保留，就应该尽量固定资源与执行方式，把环境作为受控条件。如果你要判断一个Agent产品能否在廉价机器上稳定工作，那么有限资源、冷启动与真实期限就是题目的一部分。

还可以单独做资源敏感性检查：保持Agent版本不变，改变事先声明的资源策略，观察故障分类、成功结果、时间与成本是否出现明显变化。但不要看见某个资源档位更好，就把它当成普适标准。

Anthropic文章中讨论的资源余量和经验倍数，来自特定基准与任务分布。[1] 它能支持“需要校准与公开资源执行方法”，不能支持“所有评测都应该照搬同一个倍数”。多给资源也不是免费的质量提升：它可能增加费用，掩盖低效策略，并降低结果对实际部署环境的解释力。

五、一份可以直接复用的比较清单Copy Anchor Link

在接受“新Agent更强”之前，至少核对：

• 这次比较测的是模型、提示词、Harness，还是包含部署环境的完整产品？
• 模型与行为版本、任务集、判分器、依赖及镜像是否留有可追溯标识？
• CPU和内存分别记录了请求、上限与实际执行方式，而非只写机器型号？
• 是否记录并发、主机竞争、磁盘与网络条件，以及缓存冷热状态？
• 环境准备、Agent、工具和判分的期限是否明确，起算点是否一致？
• 每次失败都有原始观察与日志定位；推断的根因和未知项是否分开？
• 重跑与排除规则是否在看成绩前确定，是否保留首次失败？
• 总试次数、可判分数、成功数、排除数及原因能否对账？
• 是否用重复、交错或资源敏感性检查验证差异，而不是只挑一次较高成绩？

资源配置不是论文附录里无关紧要的小字。对需要动手的Agent来说，考场本身就是系统的一部分。先说清楚它在哪里、带着什么预算完成了什么，再谈那个更高的分数意味着什么。

资料与阅读范围Copy Anchor Link

本文由AI创作。案例、排查表与比较方案均为教学设计，未运行模型、容器、Kubernetes集群、SWE-bench或性能基准；没有把来源中的实验当作本人实测。

1. Anthropic：Quantifying infrastructure noise in agentic coding evals，2026-02-05。实际阅读公开HTML正文各节；引用的是厂商内部实验与方法建议，不视作独立复现或通用资源标准。
2. Kubernetes：Resource Management for Pods and Containers，动态官方文档，页面显示最后修改2026-07-27；未锁定发布版本。实际阅读Requests and limits、How Kubernetes applies resource requests and limits相关正文，仅用其解释Linux容器请求与限制机制，不涉及新特性的部署建议。
3. SWE-bench：Evaluation Guide，动态官方指南，未核实独立发布日期或锁定代码版本。实际阅读Overview、结果计数、日志与Troubleshooting；用于解释该项目当前报告的诊断边界，未执行文中命令。

实际检索截止：2026-10-23 21:51 UTC。网页提取不完整的章节已通过公开HTML补读；本文解释工程机制，不报道模型新品、当前榜单或产品性能排名。