2026 年 9 月初,围绕"AI 智能体在工程任务里到底能把测试与验证做得多好"这一问题,技术社区集中产出了两份高关注度的对照工作。一份来自独立工程师 Dan Luu 在其个人博客发表的《How well do agents use test/verification techniques?》,他在 Zstd 压缩算法的实现任务上,设计了 26 种提示词条件,系统对比了在这些条件指引下,编程智能
2026 年 9 月初,围绕"AI 智能体在工程任务里到底能把测试与验证做得多好"这一问题,技术社区集中产出了两份高关注度的对照工作。一份来自独立工程师 Dan Luu 在其个人博客发表的《How well do agents use test/verification techniques?》,他在 Zstd 压缩算法的实现任务上,设计了 26 种提示词条件,系统对比了在这些条件指引下,编程智能体产出的实现质量。另一份来自 Terminal-Bench-Science 团队发布的同名评测基准的扩展版,专门针对科学研究的端到端工作流,把"智能体能否完整跑完一项科学任务"作为评估维度。这两份工作虽然切入角度不同——一个聚焦语言级工程实现,一个聚焦科研级端到端流程——但它们共同指向一个判断:在 2026 年下半年,"AI 智能体能不能把任务做对"已经从演示级问题转变为可量化、可对照、可对抗性测试的工程问题,任何把 AI 智能体放进生产链路的企业,都必须基于这一新基线重新校准自己的验收标准。本文以这两份工作为底本,把"AI 智能体工程评估的新基线"讲清楚,并讨论它对企业落地 AI Agent 的实际意义。
一、Dan Luu 的实验:26 种提示词条件下的智能体测试能力评估
Dan Luu 在 2026 年 9 月 8 日发布的文章中,延续了他早前关于"AI 辅助编程时代软件质量反而在变差"的观察。他注意到一个反直觉的现象:虽然让编程智能体用上更好的测试技术比以往任何时候都更容易,但软件质量并未因此同步提升,意味着开发者目前使用的默认工作流可能并不有效。他做了一个简单但严格的对照实验:复用了自己早前关于"智能体编程语言效率比较"的评估任务,这次把变量从"用什么编程语言实现 Zstd"换成"用什么测试技术或测试库来实现 Zstd"。
具体来说,所有实验都使用同一个实现任务——让智能体实现 Zstd,一个工业级的压缩算法,所有实现都用 Rust 编写。Dan Luu 设计了 26 种提示词条件(26 prompt conditions),这些条件之间唯一的差别,就是追加在提示词末尾的"用 X 技术 / X 库"的指令。这 26 种条件覆盖了严肃软件工程工具箱里的几乎所有主流验证手段:形式化验证(ACL2、Alloy、Lean 4、TLA+、Verus)、符号执行与求解(Kani、Creusot、SMT solvers,提供 Z3、cvc5、Yices 三种求解器、Spin)、程序测试(Rust 内置、rstest、Insta)、基于属性的测试(Property-based testing、Proptest、QuickCheck、Metamorphic testing)、变异测试(Mutation testing)、差分测试(Differential testing)、审计与模糊(Audit first、Audit and fuzz risky areas、Fuzzing),以及对照条件(Default 不追加任何指令、Make no mistakes、Judgement 让智能体自己选最好的技术)。
除了提示词条件之外,Dan Luu 还在 Hegel 与 Rust 测试两个场景下引入了"技能"(skill)——即把官方 Hegel skill 与一个社区的 Rust 测试 skill 通过 SKILL.md 注入到智能体的工作流里,测试当智能体被显式提供了专家整理过的工程手册时,表现会不会更好。他在文章中简略提及了另一项评估任务,即让智能体实现 IMAP RFC,作为对 Zstd 评估的补充对照。
这次评估最重要的不是哪一个条件胜出,而是 26 个条件同时摆在桌面上之后,产生的几个对照:一是 Default 条件与所有追加指令条件之间的对照,这是"有没有更明确指令"对智能体表现的边际影响;二是 Hegel skill / Rust testing skill 与裸提示词之间的对照,这是"专家整理的工程手册被注入"对智能体表现的边际影响;三是 26 种技术之间的横向对照,这是"在不同验证手段的指导下,智能体完成同一任务的质量分布"。这种横截面设计,把"AI 智能体的工程能力"这件事从过去的"印象式描述"推到了"对照式量化"。
二、Terminal-Bench-Science:把智能体评估推到科学研究的端到端流程
如果说 Dan Luu 的评估聚焦在语言级工程实现这一相对受限的场景,那么 Terminal-Bench-Science 的扩展版则把智能体评估推到了科学研究的端到端流程。在原版 Terminal-Bench 已经覆盖的命令行与软件工程任务基础上,扩展版专门针对"科学研究工作流"做了一整套评测任务的设计。这类任务的典型形态包括:从公开数据源获取实验数据、对数据进行清洗与预处理、跑统计分析、生成可视化、撰写结果报告、对照已有文献做结论核对。
Terminal-Bench-Science 的核心方法学是把"科学研究工作流"分解为多个相互衔接的子任务,然后针对每一个子任务设计可重复执行的验证条件。这种分解方式在工程上与单元测试、集成测试、端到端测试的经典分层相对应,只不过被评估的对象从"软件系统"换成了"AI 智能体"。在每一个子任务上,Terminal-Bench-Science 都设置了明确的成功条件与失败条件,这种设计让智能体的实际表现可以被精确量化。
这个扩展版的关键贡献在于,它揭示了智能体在"工程实现级任务"和"科研流程级任务"上的能力不对称:即便在工程实现任务上表现良好的智能体,在科研流程级任务上的表现也可能显著退化,因为后者涉及更多的开放性决策、更长的上下文依赖、更复杂的判断逻辑。这种能力不对称,正是企业落地 AI Agent 时最容易低估的——企业内的很多业务流程,本身在结构上接近科研流程(多步骤、跨工具、需要判断),而不是单一工程任务(明确输入、明确输出、可验证)。
三、两条基线的共同工程信号
把 Dan Luu 的评估与 Terminal-Bench-Science 的评估并列起来,可以看到几条对所有 AI Agent 工程评估工作具有普适意义的信号。
第一,智能体的能力必须用对照实验来衡量,而不能用厂商的宣称或一次性的演示来替代。Dan Luu 的 26 个条件横截面,本身就是这个原则的具体实现:他把所有候选条件放在同一组任务上,让结果自然显现出差异。Terminal-Bench-Science 把同样的方法学推到了更复杂的科研场景。这种"对照实验"思路,在过去几年的 AI Agent 评估里一直是少数派——更多的工作停留在"展示 Agent 完成了某个任务",而不是"展示 Agent 在多种条件下完成同一个任务时的能力分布"。2026 年下半年开始,这种对照式评估会成为主流。
第二,智能体的能力不是单一指标,而是分布在多个评估维度上的曲线。Dan Luu 的横截面显示,智能体在不同测试技术下的表现不是单调的——某些技术指引下产出质量更高,某些反而更低,这与"专家直觉"未必一致。Terminal-Bench-Science 的多场景评估进一步说明,即便在工程实现任务上表现良好的智能体,在科研流程任务上可能完全不可用。这意味着,任何对 AI Agent 的能力声称,都应该被分解为多个具体的评估维度,并在每个维度上提供量化证据,而不是给出一个笼统的"它能做 X"的论断。
第三,智能体对外部指导的响应程度,显著影响其能力上限。Dan Luu 的实验里,Default 条件(不给任何额外指引)与其他条件之间的差异,证明了"指引质量"对智能体表现的强烈影响;Hegel skill 与 Rust testing skill 的引入,进一步证明了"专家整理的工程手册被注入"对智能体表现的边际提升。Terminal-Bench-Science 的科研任务里,这种"外部指导"的形态会更复杂——可能是文献综述的指引、可能是数据预处理的规范、可能是统计方法的选用标准。这些指引的显式化与结构化,是企业落地 AI Agent 时必须投入的工程工作。
第四,智能体的能力评估不能脱离"具体任务类型"。两个工作都隐含了这一结论:任何"AI Agent 通用能力强"的论断,都需要被具体任务类型的评估结果所支撑。Dan Luu 的 Zstd + IMAP RFC 任务,Terminal-Bench-Science 的科研工作流任务,都是具体的、有边界的、可重复的。这种"任务边界明确化"的评估思路,在企业落地 AI Agent 时应该被严格遵循——业务方不应该问"这个 Agent 强不强",而应该问"这个 Agent 在我的这个具体业务场景下,表现如何"。
四、对企业落地 AI Agent 的实际启示
把这两种评估工作的具体设计抽象出来,可以归纳出几个对企业落地 AI Agent 具有直接意义的启示。
第一个启示是关于验收清单的设计。Dan Luu 的 26 种验证手段横截面,可以直接转译成企业内部对智能体产出的验收清单:如果团队在用编程智能体,不要满足于"它能跑",而要明确要求它产出对应的可重复验证手段——TDD 与 Property-based testing 的产出对应"测试覆盖率与重复执行性";形式化方法的产出对应"关键不变式的机器可验证证明";Mutation testing 与 Differential testing 的产出对应"测试本身的有效性审计"。让智能体做它声称的验证手段,并把验证结果本身作为产出物的一部分,而不仅仅是代码本身。
第二个启示是关于业务任务的边界化。Terminal-Bench-Science 的多场景评估提醒企业 IT,智能体的能力评估必须落到具体的业务任务上。任何"Agent 在我们公司能做什么"的笼统问题,都应该被拆解为多个"Agent 在这个具体业务任务上表现如何"的明确问题,并在每个任务上做小规模的对照评估。这种评估方式会让企业 IT 在短期内投入更多工作量,但从中长期看,会显著降低"智能体上线后才发现它做不了某个任务"的概率。
第三个启示是关于团队工程的显式化。Dan Luu 的工作里,专家 skill 的注入显著提升了智能体的表现。这意味着,企业内部要把 AI Agent 真正用好,必须把过去散落在资深工程师脑子里的隐性工程知识,显式整理成智能体可消费的 skill、提示词模板、约束规则、参考实现。这种整理工作本身是一项工程投入,而且是一项持续维护的工程投入,但它是把"智能体的潜在能力"转化为"智能体在企业里的实际能力"的必经之路。
第四个启示是关于智能体治理的边界化。基于评估结果,企业 IT 需要为每一个具体的业务场景,明确划定智能体的能力边界——这个智能体在这个任务上被允许做哪类动作、产生哪类产出、采用哪类验证手段;超出边界的部分,要么明确不允许,要么强制人工介入。这种"边界化治理"在过去几年里被低估了,原因是大家倾向于把智能体视为"通用助手",而忽略了它的能力在不同任务上的显著不对称。
五、对未来的判断
把这两种评估工作放在一起,结合 2026 年下半年 LLM Agent 工程评估的整体方向,可以对未来做出几个相对确定的判断。
第一,围绕 LLM Agent 的对照式工程评估将在 2026 年底到 2027 年成为独立研究方向。Dan Luu 的横截面与 Terminal-Bench-Science 的科研工作流扩展,共同为这一方向奠定了早期范式。后续工作会沿着两个方向走:一是把同样的横截面应用到更大的代码规模、更多的语言、更多的任务类型;二是把"技能注入"作为更标准的实验维度,系统化研究不同 skill 对智能体表现的影响。
第二,围绕企业 Agent 落地的评估产品化会同步推进。Dan Luu 与 Terminal-Bench-Science 的工作目前还停留在研究阶段,但它们的方法学非常容易产品化——把对照实验封装成可重复运行的评测服务,把评估结果作为企业选型 AI Agent 时的决策依据。围绕这一方向,接下来 12-18 个月里会出现一批专门的"Agent 评估 SaaS"产品,服务于企业的 AI 选型与治理需求。
第三,"任务边界明确化"会成为企业 Agent 治理的核心原则。任何严肃的企业 AI 落地,都需要把"Agent 在这个任务上具体被允许做什么"写明到操作规范里,而不是停留在"它能帮我"这种模糊表述。这种边界化的工作,会推动企业 IT 内部的 AI 治理能力从"准入审批"升级为"任务级契约管理"。
第四,智能体能力评估的多维度曲线,会让企业的 AI 选型从"选模型"转向"选任务组合"。一个模型可能在某些任务上很强、在另一些任务上很弱;一个 harness(Agent 框架)可能在某些场景下让能力放大、在另一些场景下让能力收缩。未来企业选型 AI Agent 时,会更倾向于按"具体业务任务"为单位做选型决策,而不是按"模型版本"或"框架品牌"做笼统选择。
回到企业 IT 与业务方的视角,Dan Luu 的横截面与 Terminal-Bench-Science 的扩展版,共同传递了一个非常关键的信号:今天再讨论"AI 智能体能不能用",已经是一个过期的问题;真正要回答的问题是"在我的这个具体业务任务上,这个智能体的能力曲线落在哪里,边界在哪里,我准备为它显式投入多少工程纪律"。这两个评估基线,把这件事从"未来可能要面对"推进到了"今天就要开始面对",这也是过去一年来围绕智能体所有严肃工程评估工作给出的共同结论。
