在确立"先场景、后维度"之后——本摘要回答四件事：场景如何划分、6 维与 7 维(2 层)之异同与"非正交"的本质、哪些维度共识强 / 哪些发散强,以及两类真实场景该把资源压在何处。
业界对 agent 场景的划分高度收敛。综述与厂商口径合并后,对 harness 设计有显著区分度的场景共 5 个;其中编码 / 软件工程(Coding / SWE)是最核心的"母场景"——"harness"一词即源于此(OpenAI Codex、Claude Code),也是唯一对六维全部高强度依赖的场景,其余场景多是它的"维度子集 + 某一维的极端化"。
| 场景 | 角色隐喻 | 该场景的"命门"维度 |
|---|---|---|
| ① 编码 / SWE 母场景 | 工匠 | 六维全开;以 Execution Loop + Evaluation(单测)为轴 |
| ② 深度研究 Deep Research | 分析师 | Execution Loop(多跳) · Context(多源聚合) · Evaluation(引用忠实度) |
| ③ 计算机操作 / Web · GUI | 操作员 | Lifecycle Hooks(审批/护栏) · Tool Registry(动作空间) |
| ④ 对话 / 客服 | 管家 | Evaluation(多维 rubric) · Context/State(记忆/个性化) |
| ⑤ 编排 / 长任务 | 总管 | State Store(可回放) · Orchestration Loop · Context(子代理隔离) |
规律:场景越靠近"不可逆的真实世界动作"(③⑤),安全门控与状态持久越重;越靠近"产出需被问责"(②④),评估维度越重。编码场景同时具备这两类压力,故成为压力测试 harness 的母场景。
ETCLOVG 不是另起炉灶,而是六维 H=(E,T,C,S,L,V) 的精炼与升格——同一系统,动了三处"手术",并把七层归拢为运行层 / 保障治理层两大层。
出自《Agent Harness Survey》(Preprints 2026)。按职责切:Execution Loop · Tool Registry · Context Manager · State Store · Lifecycle Hooks · Evaluation Interface。强调"每一维在对抗什么失效模式"。
Execution · Tool · Context · Lifecycle · Observability · Verification · Governance。在六维基础上:并 State→Context、拆 评估为 O+V、升 Governance 独立。归为两层 ↓
E Execution(主循环) · T Tool(工具) · C Context(上下文,已吸收 State/Memory) · L Lifecycle(生命周期钩子,纯拦截机制)。这四层与六维核心高度重合,回答"功能能不能跑起来"。
O Observability(看得见:trace / log / metric) · V Verification(判得准:正确性核验 / 质量门) · G Governance(管得住:合规 / 审计 / 策略)。这三层是 ETCLOVG 相对六维的真正升级——把"质量与治理"从附属物提为独立一层。
State Store 不再独立,并入 Context。这正坐实前文"Context↔State 是强耦合对"的判断——光压缩不够、还须读状态才能恢复,二者本就难分。
原"Evaluation Interface"在截图里本就定义为"可观测 + 可分析的评估"二合一。ETCLOVG 把它拆成 O(看得见)与 V(判得准)——观测与核验是两件事。
Lifecycle Hooks 原本兼任"拦截机制"与"合规目的"。ETCLOVG 让 L 专注机制、把 G Governance(合规 / 审计 / 策略)升为独立层——机制与目的解耦。
| 关注点 | 六维 H=(E,T,C,S,L,V) | ETCLOVG 七层 | 关系 |
|---|---|---|---|
| 执行 | Execution Loop | E Execution | ✅ 原样保留 |
| 工具 | Tool Registry | T Tool | ✅ 原样保留 |
| 上下文 | Context Manager | C Context | ⊕ 吸收 State/Memory |
| 状态 | State Store(独立) | (并入 C) | ⊖ 取消独立维 |
| 生命周期 | Lifecycle Hooks(机制+合规) | L Lifecycle(纯机制) | ◐ 收窄 |
| 可观测 | (混在 Evaluation 内) | O Observability | ✚ 拆出独立 |
| 核验 / 评估 | Evaluation Interface(观测+评估) | V Verification(纯核验) | ◑ 收窄为"判得准" |
| 治理 | (混在 Lifecycle 内) | G Governance | ✚ 升为独立层 |
净变化: −1(State 并入 C)+2(拆出 O、升出 G)= 六维 → 七维。核心立意:六维把"质量 / 治理"压缩在 V、L 两维里;ETCLOVG 把它展开成 O·V·G 三层独立的"保障治理层"。一句话:六维问"功能齐不齐",ETCLOVG 追问"可信不可信、合不合规"。
这恰好回应 §03 与 §04:最发散、最不成熟的"评估",和最被低估的"治理",在 ETCLOVG 里被显化为 O / V / G 三个一等层——这正是 §04·A 企业级经营决策 agent 的命门(可观测 + 可核验 + 可治理)。越是"治理重"的场景,越该用 ETCLOVG 而非裸六维来盘点。
这是必须钉死的判断。两套框架的原始来源各自都明确否认正交性:
正确的心智模型 ——「分析正交、实现耦合」三层关系:
O/V/G(及机制层 L)不是与 E/T/C 并列的模块,而是穿过运行层的切面——Observability 观测 ETCL 的运行轨迹,Verification 的 grader 跑在记录了 tool call 的 transcript 上,Governance 经 L 在 loop 关键点落地策略。Context ↔ State(ETCLOVG 干脆把二者并成一层)、Tool ↔ Lifecycle(授权门控就长在工具注册上)。改一处必波及另一处。→ 实操结论:用 ETCLOVG 七层做盘点,用"保障层横切 + 耦合对"做改造设计。切忌假设可以单独优化某一层而不外溢。
一条可引用的判据(源码 taxonomy):维度在外部约束强处收敛,在设计仍开放处发散。
→ 这些可直接复用成熟方案,不必每场景重造。
→ 这些必须按场景定制,是 harness 工程的真正投入所在。
值得反复强调:Evaluation Interface 同时是"最发散"且"最不成熟"的维度——它既最依赖场景,又是当前最薄弱的一环。谁先把某场景的评估 harness 做扎实,谁就握住了护城河。
这类 agent 服务于"多门店 / 标准化运营 / 数据驱动决策"(选址、定价、补货、排班、销量预测),其本质是 客服式多维核验 + 长任务持久化 + 计算机操作级的审批门控 的叠加体。它不是编码型——Execution / Tool 不是它的命门;命门整层落在 ETCLOVG 的保障治理层(OVG)上:
决策动作影响实体经营、不可逆(改价、调配库存)。必须有合规策略 + 审批门控 + 越权拦截 + 审计留痕,等同计算机操作场景的安全等级。"建议"与"执行"之间必须有治理闸门(经 L 落地)。
经营决策必须判得准、可问责:多维核验(财务结果 + 合规 + 风险),而非二元对错——与客服 rubric 同源,是最难也最值钱的一层。
看得见才追得溯:"为何建议给 500 店统一调价"要能逐步回放——决策链路的 trace / 中间证据 / 数据来源全程可观测。C(Context 含 State)居中:跨周跨季持久化 + 多源异构数据聚合(POS / 库存 / 区域 / 市场)。
一句话画像:经营决策 agent ≈「保障治理层(OVG)重、运行层(ETCL)轻」——预算压在可观测、可核验、可治理上;Execution / Tool 用成熟方案即可。这正是 ETCLOVG 把 O·V·G 显化为独立层的价值场景。
设定:为上述 4·A 类服务做研发,代码组织为 polyrepo(多仓)、交付横跨多端(Web / iOS / Android / 后端),团队以 Claude Code 为研发主力。在研发迭代这一层,维度优先级与 4·A 截然不同——这里没有不可逆的经营动作,真正的 binding constraint 是跨仓上下文与每端工具链/反馈的异质性。
CLAUDE.md + 分层 AGENTS.md 注入仓约定;ToolSearch 按需加载工具 schema 而非全量预载;用 subagent 为每个 repo / 每个端隔离独立 context window,避免跨仓信息互相污染;依赖 PreCompact 钩子定制压缩保留规则。PostToolUse 钩子按语言自动跑格式化(prettier / gofmt / ktlint / swiftformat);PreToolUse 钩子在写入前做路径/越权校验;每仓 .claude/settings.json 落地"该仓专属"的 hook,使同一个 Claude Code 在不同仓表现出不同纪律。allowed_tools 按端授权——前端 Bash(npm *) / Android Bash(./gradlew *) / iOS Bash(xcodebuild *) / 后端测试命令;disallowed_tools 封禁危险操作;沙箱隔离各端构建。能力类别趋同,但注册粒度与作用域必须按端切。resume 跨日续接某仓任务;fork 在不污染主线的前提下试不同实现路线;JSONL 会话留痕供复盘。Execution Loop 用 Claude Code 默认即可,非差异化项。| 场景 | 维度重心 | 本质 |
|---|---|---|
| 4·A 经营决策 Agent | G · V · O(保障治理层) | 治理重、执行轻:可治理 + 可核验 + 可观测 |
| 4·B Polyrepo 研发迭代 | C · L · T(运行层) | 工程重、治理轻:跨仓上下文 + 每端纪律自动化 |
两类场景几乎压在 ETCLOVG 的两个不同层上:A 在保障治理层(OVG)、B 在运行层(ETCL)。唯一的"桥"是 L Lifecycle——A 经由 L 落地合规审批闸门(服务 G),B 经由 L 落地每端研发纪律(format/lint/test)。同一机制层、两种用途,正是"维度共识强(都要 hook)、诉求却发散(目的两样)"的活样本。