| 标题（简） | 方向细分 | 来源 | 综合分 |
|---|---|---|---|
| AgentFlow: Synthesizing Multi-Agent Harnesses for Vulnerability Discovery今日选定 | Multi-Agent Harness DSL | arXiv 2026-04-22 | 94 |
| The Last Harness You'll Ever Build | Meta-Evolution Harness | arXiv 2026-04-22 (v2 04-28) | 90 |
| HARBOR: Automated Harness Optimization | BO-based Harness Tuning | arXiv 2026-04-22 | 85 |
| Harness as an Asset: CAAF | Enterprise Harness | arXiv 2026-04-25 (v2) | 83 |
| Architectural Design Decisions in AI Agent Harnesses | Empirical Survey | arXiv 2026-04-20 | 82 |
LLM Agent 已经展现出能挖掘出人类审计员和自动 Fuzzer 多年未发现的真实漏洞。但实际部署时，需要通过一个叫做 harness 的程序来协调多个 Agent，这个 harness 定义了每个 Agent 的角色、信息流、可用工具、以及失败重试协议。
一个已被多次观察到的痛点是：仅仅改动 harness，就能让 Agent 在公开 benchmark 上的成功率相差数倍。然而今天绝大多数 harness 都是手写的。现有的"harness 优化器"只能在非常窄的设计空间里搜索，并且只能用粗粒度的 pass/fail 反馈——这几乎无法诊断"究竟是 harness 哪部分出问题了"。
本文提出 AgentFlow：一个用 类型化图 DSL 联合描述 Agent 角色、Prompt、工具、通信拓扑、协调协议的 harness 表达语言；并配一个 反馈驱动的外循环，能读取目标程序的运行时信号来诊断失败、并据此改写 harness。AgentFlow 在 TerminalBench-2 上取得公开榜 84.3%（评估快照时的最高分），并在 Google Chrome 中挖出 10 个此前未知的 0-day 漏洞，其中 2 个为 Critical 级别沙箱逃逸（CVE-2026-5280 / CVE-2026-6297）。
解决了什么问题：Harness 是 Agent 系统的"总装图"，但工业界和学术界的 harness 都是人工搭的。这样做有两个硬伤——（1）设计空间巨大（角色、Prompt、工具、topology、协议……彼此耦合），人无法穷举；（2）运行失败时只能看 pass/fail 这一个 bit，完全不知道是哪条边、哪个 Agent、哪个 Prompt 段出错了。AgentFlow 把"手工 harness + 盲目搜索"这一代做法直接升级到"形式化 DSL + 反馈驱动合成"。
核心方法——两件事抬升了 harness 合成的上限：
| 组件 | 做法 | 相对前人的关键区别 |
|---|---|---|
| 类型化图 DSL | 用类型化节点描述 Agent/Tool，用类型化边描述消息通道、重试协议；整个 harness 是可序列化的图 | 替代了"一堆 Python class + 硬编码 if-else"的 ad-hoc 做法，使搜索空间有了代数结构 |
| 反馈驱动外循环 | 从目标程序（被攻击的 Chrome / 被执行的 Terminal 任务）收集运行时信号（crash 位置、tool 调用失败栈、Prompt 截断等），定位到图上最可能出错的节点/边，再做局部改写 | 不再是黑盒 pass/fail；诊断信号和编辑点之间是可解释映射 |
| 可迁移优化器 | 目标类无关：只要任务能写成"一个 bounded 的 harness 搜索空间 + 可复现任务套件" | 同一个优化器既跑 coding agent（TerminalBench-2）也跑安全 Agent（Chrome 漏洞挖掘） |
与现有工作的关键区别：同期的 HARBOR（贝叶斯优化）把 harness 调优形式化为"混变量 + 多保真度"，Last Harness You'll Ever Build 则把它抽象为两层 meta-learning；AgentFlow 的差异点在于——它把 harness 本身放进了一个可类型检查、可局部改写的图结构里，因此诊断信号可以准确定位到某个节点/边、而不是只回归到一个超参上。
为什么这篇值得读：Agent 安全社区长期有一个不舒服的事实——"同一个模型、同一个任务，换 harness 就能刷榜"；AgentFlow 直接把这件事做成了方法：让 harness 的合成进入被形式化、可优化、可归档的阶段。而它的"副产物"是两个真实的 Chrome Critical CVE——这对 Harness Engineering 研究而言是非常硬的外部信号。
https://arxiv.org/abs/2405.15793
https://arxiv.org/abs/2310.06770
https://www.tbench.ai/
https://arxiv.org/abs/2303.11366
https://googleprojectzero.blogspot.com/
https://github.com/google/oss-fuzz-gen
https://arxiv.org/abs/2604.18071
- TerminalBench-2：在评估快照时取得 84.3%，为公开榜最高分，使用 Claude Opus 4.6 作为底模。
- 真实安全影响：在 Google Chrome（使用 Kimi K2.5 作为底模）挖出 10 个未公开 0-day，其中 2 个 Critical 级沙箱逃逸（CVE-2026-5280、CVE-2026-6297）。这是 harness 合成系统首次产生成规模的生产软件 CVE。
- 结构收益 vs. 超参收益：论文论证"harness 改动带来的成功率抬升可达数倍"——这说明 harness 层的可优化性，已经超过了 Prompt / Sampling 这类表层超参。
这篇是 2026-04 月 Harness 方向最硬的一篇——它给出了一个完整闭环：类型化图 DSL → 运行时诊断信号 → 局部改写。你做 Harness 研究时，可以直接继承它的 DSL 视角：把 harness 当"可类型检查、可局部改写的图"，而不是"一个大 Python 脚本"。AHE（2604.25850）处理的是编辑候选怎么生成，HARBOR（2604.20938）处理的是超参空间怎么搜，AgentFlow 处理的是图结构自身的可合成性——三者互补且可叠加。
论文展示的另一面，是 harness 合成系统的攻击性：同样的能力可被用于"合成一个能挖出 Chrome 0-day 的攻击 Agent"。这意味着 Agent Skills Safety 必须考虑"Agent 生态本身被用于漏洞发现"的对偶风险——谁能写出最好的攻击 harness，谁就能在每一轮 patch 前领先一步。未来的 agent safety policy 应包含对"harness 合成能力"的分级监管。
论文把"harness 决定成功率"从口头认知变成了可量化的观察。对 Safety Benchmark 研究而言，这直接反驳了"同一 benchmark 的分数是模型能力直读"的常见假设——榜单 entry 背后其实是（模型 × harness）联合样本。安全 benchmark 必须要求 harness 的完整可复现声明（DSL 序列化 + runtime 配置），否则分数不可比。这件事和你上周读过的 Judge Sensitivity（2604.24074）是同一哲学：benchmark 必须公开其"暗参数"。
- Last Harness You'll Ever Build — Seong et al. (2026) — 两层 meta-learning，Harness Evolution Loop + Meta-Evolution Loop，定位更偏 workflow 自动化
https://arxiv.org/abs/2604.21003 - HARBOR: Automated Harness Optimization — Sengupta & Wang (2026) — 把 harness 调优视为混变量贝叶斯优化问题
https://arxiv.org/abs/2604.20938 - Agentic Harness Engineering (AHE) — Lin, Liu et al. (2026) — 可观测性三支柱 + 编辑视为 falsifiable contract（昨日已读）
https://arxiv.org/abs/2604.25850