1. 这篇文章到底在讲什么
论文的核心判断是：当大模型本身已经足够强时，Agent 的成败越来越取决于模型外面的那层系统工程，也就是 harness。
Agent 可靠性不只由模型决定，还由执行环境、工具协议、上下文、生命周期、监控、评测和安全治理决定。
论文把 Agent Harness 拆成七层：Execution、Tooling、Context、Lifecycle、Observability、Verification、Governance。
作者把大量开源项目映射到七层，发现运行、工具、生命周期、评测更密集；可观测性和治理相对薄弱。
2. 从 Prompt Engineering 到 Harness Engineering
文章把 2022–2026 的 Agent 工程演化分成三个阶段。它们不是互相替代，而是工程重心逐渐外移。
怎么写输入
让模型看什么
让系统怎么跑
多人多任务运维
可审计可控
| 阶段 | 核心问题 | 典型工程动作 | 局限 |
|---|---|---|---|
| 2022–2024 Prompt Engineering | 如何写好一次模型调用的输入 | 指令、few-shot、CoT、角色设定 | 单次调用有效，长任务容易崩 |
| 2025 Context Engineering | 每一步该给模型看什么 | 检索、压缩、排序、上下文窗口管理 | 能缓解遗忘，但还不能解决执行失控 |
| 2026– Harness Engineering | Agent 在真实环境里如何可靠完成任务 | 沙盒、工具协议、状态机、监控、验证、安全治理 | 系统复杂度上升，需要平台化能力 |
3. ETCLOVG 七层分类
ETCLOVG 是这篇文章最重要的框架。前四层是 Harness 的结构核心，后三层是围绕它的控制平面。
E/T/C/L 决定 Agent 在哪里跑、怎么调工具、看什么信息、按什么流程推进。
O/V/G 决定系统如何被监控、如何被验证、如何被约束和审计。
论文把 Observability 和 Governance 单独列为一等公民，而不是把它们塞进生命周期或安全小节。
4. 七层逐层解释
Execution Environment
决定 Agent 代码在哪里执行、权限边界是什么。包括容器、microVM、浏览器沙盒、桌面环境、代码运行环境、OS 权限模型。它回答的问题是：Agent 能碰什么，不能碰什么。
Tool Interface & Protocol
定义外部能力如何被描述、发现、调用和管理。MCP、A2A、工具 schema、工具选择、工具会话管理都属于这一层。
Context & Memory
决定模型在每一步能看到什么，包括短期上下文、会话状态、长期记忆、检索、压缩、上下文漂移治理。
Lifecycle & Orchestration
组织 Agent 控制流，从单 Agent loop 到多 Agent 编排，再到 issue-to-PR 的完整流水线。它决定任务如何开始、暂停、恢复、分叉、结束。
Observability & Operations
收集 traces、成本、失败、延迟、工具调用、可靠性指标。没有这一层，Agent 失败后很难知道到底错在模型、工具、上下文还是权限。
Verification & Evaluation
把任务和执行轨迹变成可评测、可归因、可回归的反馈。包括 benchmark grounding、执行前验证、trace capture、多层判断和持续回归。
Governance & Security
约束 Agent 行为，包括权限模型、身份管理、生命周期 hook、组件加固、声明式宪法、审计基础设施。
5. 他们如何映射开源项目
论文不只是提出框架，还把开源 Agent Harness 项目按七层做了标注。网页展示的当前快照里，各层 primary projects 数量如下：
| 层 | 范围 | Primary Projects | 我的理解 |
|---|---|---|---|
| E | 执行环境与沙盒 | 20 | Agent 要真实操作系统、浏览器、代码，必须先解决运行边界。 |
| T | 工具接口与协议 | 12 | MCP/A2A 这类协议正在把工具调用标准化。 |
| C | 上下文与记忆 | 9 | 独立项目较少，很多能力嵌在大框架内部。 |
| L | 生命周期与编排 | 47 | 最密集的一层，说明 workflow、multi-agent、task pipeline 是当前主战场。 |
| O | 可观测性与运维 | 15 | 开源薄一些，商业平台和内部系统更多。 |
| V | 验证与评估 | 21 | Agent benchmark、trace eval、regression 已经快速成熟。 |
| G | 治理与安全 | 14 | 越来越重要，但还没有像工具协议那样标准化。 |
6. 三个跨层系统问题
成本-质量-速度三角
更强沙盒、更深评测、更丰富上下文会提高质量和安全，但也会增加 token、延迟和基础设施成本。生产系统必须决定哪些检查同步做，哪些放到异步或回归套件里。
能力-控制权衡
工具越多、记忆越持久、沙盒越宽松，Agent 能做的事越多，但爆炸半径也越大。工具 schema、权限、身份、审计、人类审批必须一起设计。
Harness 耦合问题
局部优化可能破坏全局。一个 prompt、工具、sandbox、verifier 单独看有效，组合进完整 loop 后可能变慢、变贵或引入新失败模式。
7. 五个开放问题
| 开放问题 | 通俗解释 | 为什么难 |
|---|---|---|
| 执行环境加固与规模化 | Agent 到底该跑在容器、microVM、浏览器、桌面 VM 还是托管沙盒里？ | 安全、成本、延迟、兼容性互相冲突。 |
| 长任务可靠状态 | Agent 跑几十上百轮后，如何不忘、不乱、不被旧信息误导？ | 压缩、检索、遗忘都会丢信息，还要处理过期和矛盾。 |
| Trace-native 失败诊断 | 把 trace 当成评测和归因的核心对象，而不是事后日志。 | 要从复杂轨迹里判断模型、工具、上下文、权限哪一层出了错。 |
| Agent/工具/人类之间的标准交接 | handoff 不只是发一段摘要，还要交接意图、权限、预算、风险、证据和未决问题。 | 协议太简单不安全，太复杂又没人用。 |
| 模型变强后 Harness 如何简化 | 今天必要的脚手架，明天可能变成成本和延迟。 | 需要持续 ablation，判断哪些控制仍然 load-bearing。 |
8. 我反复读完后的重点笔记
它管理执行环境、工具、记忆、生命周期、监控、验证、安全，已经超过普通 SDK 范畴。
只解决“模型看什么”，还没解决“系统如何安全执行”。
没有 trace、成本、失败归因，Agent 无法进入生产。
权限、身份、审计、审批要从架构开始设计。
真正生产可用的 Agent 需要 durable workspace、identity、eval、governance、handoff。
同一个模型，换工具格式、上下文注入、自验证 hook，都可能带来大幅 benchmark 提升。
如果用一句话总结
9. 适合谁读
| 角色 | 应该重点看什么 |
|---|---|
| AI Infra / Agent Runtime 工程师 | ETCLOVG 七层、跨层权衡、开放问题。 |
| 产品/创业者 | 从 Agent Framework 到 Agent Platform 的趋势。 |
| 安全/合规团队 | Governance、Execution sandbox、audit、permission model。 |
| LLMOps / Eval 团队 | Observability、Verification、trace-native failure diagnosis。 |
| 研究者 | 项目语料构建、分类方法、未来研究问题。 |