Agent Harness
Agent的外围执行系统不仅负责调用模型，还要处理工具、状态、上下文和约束。这条路线先澄清Harness的定义，再比较工程组织、自动优化和安全审计，不把最终任务成功当作唯一验收标准。
从你的问题开始
分不清框架、SDK和Harness
先读定义论文，再用工程综述整理组件和职责。
比较时看：看具体系统是否真正控制执行循环和环境交互，不只看产品名称。
失败很多，却不知道应该改哪里
从Code as Agent Harness读到AHE和Harness-R1。
比较时看：区分改接口、改运行时和改模型；检查可观测轨迹、回归集与补丁验收。
任务完成了，但担心越权和执行偏离
单独阅读HarnessAudit的轨迹审计视角。
比较时看：同时检查结果、权限边界和实际执行过程，避免用完成率替代安全性。
建议阅读顺序
按理解问题的顺序精选，非时间排名。下方日期为原文发表日期；不同论文的分数不作直接横比。
-
01 · 定义边界
What Makes a Harness a Harness：先厘清定义
用执行循环、环境接口、上下文管理等判定条件理解Harness，先建立共同语言。
阅读边界：这是该论文提出的判定框架，不能当作行业已经统一的标准。
-
02 · 梳理组件
Agent Harness Engineering：工程综述
借助ETCLOVG分层框架整理沙盒、工具接口、运行时控制等职责，识别系统的薄弱层。
阅读边界：组件多不代表系统好；对照自己的任务需求选取必要层，而非照单堆叠。
-
03 · 连接接口和反馈
Code as Agent Harness：用代码组织执行
关注代码作为环境接口、执行控制和验证反馈的作用，不把它仅看作模型生成的最终产物。
阅读边界：可执行不等于安全，工具权限、隔离环境和结果验证仍需独立设计。
-
04 · 找到修改依据
AHE：可观测性驱动的Harness优化
观察组件、经验和决策的可观测性如何支持迭代，把失败轨迹转为可验证的修改假设。
阅读边界：优化需要独立验证集和回归检查，不能把同一组任务上的反复调试当作泛化。
-
05 · 比较优化对象
Harness-R1：从失败轨迹到运行时补丁
阅读专职工程师根据失败信息编辑运行时的流程，区分优化Harness和直接训练任务Agent。
阅读边界：补丁必须通过运行验证；不能假设在一个Agent上有效就能无条件迁移。
-
06 · 审计安全
HarnessAudit：检查成功背后的执行过程
从边界合规、执行保真度和系统稳定性三个层次检查轨迹，补足只看结果的盲区。
阅读边界：基准测试覆盖的攻击和环境有限，不能据此宣称系统已具备全面安全保证。