20260601
This commit is contained in:
36
concepts/harness-coupling-problem.md
Normal file
36
concepts/harness-coupling-problem.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "Harness Coupling Problem(Harness 耦合问题)"
|
||||
created: 2026-05-23
|
||||
updated: 2026-05-23
|
||||
type: concept
|
||||
tags: [agent, coupling, system-design, optimization]
|
||||
sources: [raw/papers/agent-harness-engineering-survey-2026.md]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# Harness Coupling Problem
|
||||
|
||||
> Harness 各层高度耦合,局部优化可能变得脆弱。一个在隔离环境中看起来有益的更改,与其他控制回路组合后可能降低整体表现。
|
||||
|
||||
## 耦合的四种表现
|
||||
|
||||
1. **执行环境 → 评估**:包可用性、重置语义、延迟和故障模式改变评估结果
|
||||
2. **工具描述 → 模型行为**:工具 Schema 消耗 context budget 并塑造模型推理
|
||||
3. **可观测性 → 治理**:追踪只有在相同粒度捕获身份和权限状态时才成为治理证据
|
||||
4. **评估 → 编排**:评估设计通过奖励/惩罚某些恢复回路来反馈编排
|
||||
|
||||
## 闭环框架
|
||||
|
||||
在闭环控制框架下,对上下文策略、工具 Schema、验证器或恢复回路的每一次更改都在改变控制器 `C_H`,从而改变同一模型的测量行为(Bölük, 2026b)。
|
||||
|
||||
这意味着 Agent 分数无法纯粹归因于模型,而不指定周围的控制器。
|
||||
|
||||
## 工程含义
|
||||
|
||||
Harness 变更应作为**系统变更**来测试——不是 prompt、tool、memory、sandbox、verifier 或 monitor 的独立调优,而是作为一个整体 rollout 的组合效果。
|
||||
|
||||
## 相关概念
|
||||
|
||||
- [[binding-constraint-thesis]]
|
||||
- [[trace-native-evaluation]] — 需要跨层归因失败
|
||||
- [[agent-harness-engineering-survey]]
|
||||
Reference in New Issue
Block a user