Harness
从源码、产品和真实案例拆解 Agent Harness,并把执行、工具、上下文、编排、观测、验证与治理放进同一张图。
当前状态研究图谱持续扩展
可验证证据ETCLOVG 矩阵与可探索图谱
01
真实问题
大家常把 Agent 能力说成模型本身,却缺少一张能同时看见执行、工具、上下文、编排、观测、验证和治理的结构图。
02
关键判断
先从源码、产品和案例里拆出 ETCLOVG,再做成可探索图谱。目标不是再造一个框架名词,而是让结构可被检查、比较和复用。
03
系统结构
- 01E 执行动作在哪里发生,失败会污染什么?
- 02T 工具模型怎样获得手和眼?协议与执行是否同合同?
- 03C 上下文模型每一步到底看见什么?能否 diff / 压缩?
- 04L 编排任务怎样持续、介入和停止?终态是否显式?
- 05O 观测用户和系统怎样知道发生了什么?
- 06V 验证怎样证明做完了,而且做对了?
- 07G 治理怎样限制模型的搞砸半径?

04
关键设计
- E/T/C/L 是结构,O/V/G 是控制面真正的产品差异往往不在单层,而在层间耦合:context 决定 tool 能否被正确调用,verification 决定 loop 敢不敢自动继续。
- 可读代码版样本优先于二手综述Codex 开源客户端几乎能直接对照 ETCLOVG 每一层:sandbox、MCP、memories、otel、execpolicy。先读实现,再写判断。
- Context 是状态管理,不是 prompt 堆料WorldState、baseline/diff、compaction、新窗口重建——上下文应可版本化、可追踪,而不是每轮塞更多文本。
- 模型说完成 ≠ 系统完成TurnComplete 需要工具结算、持久化与 verifier;把流结束当完成,是最常见的假完成。
05
真实证据
- ETCLOVG 矩阵作为统一拆解框架
- 持续阅读源码与真实产品案例,而不是只整理概念
- 可探索研究图谱,用来对照不同 harness 的结构差异
06
仍在推进
- 不同产品的 harness 边界如何更公平地横向比较
- 哪些治理机制应成为默认,而不是事后补丁