Harness Engineering 高级话题（七）：可观测性、熵管理与三类约束体系
约 8 分钟2320 字31 次阅读系列第 6/8 篇
Harness Engineering 指南第 6 篇，共 8 篇
Harness Engineering 高级话题（七）：可观测性、熵管理与三类约束体系
引言
这一篇面向已经有一定 Harness 实践经验的同学，讲解高级话题：
- 可观测性怎么为 Agent 所用
- 熵管理为什么必须自动化
- 三类约束体系（Maintainability / Architecture / Behaviour）
- Model-Harness 耦合问题
一、可观测性：不止给人看，也要给 Agent 看
1.1 传统可观测性 vs Agent-Aware 可观测性
传统可观测性是给人看的——人类工程师通过日志、指标、链路追踪来理解系统状态。
Agent-Aware 可观测性则把这些数据也暴露给 Agent，让 Agent 能够：
- 自我诊断：Agent 能读取自己的性能指标
- 目标验证：Agent 能验证自己的输出是否达到目标
- 自适应：Agent 能根据反馈调整行为
1.2 OpenAI 的实践
OpenAI 把 Chrome DevTools Protocol 接入了 Agent 运行时：
- Agent 能自己抓 DOM 快照
- Agent 能自己截图
- 日志、指标、链路追踪都通过本地可观测性栈暴露
效果："把启动时间降到 800ms 以下"从模糊愿望变成了 Agent 可以自己测量、自己验证的目标。
1.3 实现路径
可观测性栈
→ 日志（结构化，grep友好）
→ 指标（Prometheus格式）
→ 链路追踪（OpenTelemetry）
→ 暴露给 Agent（通过工具）
关键设计：
- 结构化日志：用
ERROR: [reason]格式，Agent 能 grep 定位问题 - 指标可查询：让 Agent 通过工具查询自己的性能数据
- 链路可追溯：让 Agent 理解一次请求的完整调用链
二、熵管理：AI 生成物的质量衰减问题
2.1 什么是熵积累？
LLM 生成的代码有一个特性：它经常重新实现已有功能，而不是复用现有代码。随着时间推移，代码库会：
- 功能重复实现越来越多
- 文档和代码不一致增加
- 架构违规累积
- 技术债务加速增长
这就是"熵积累"——无序度在增加。
2.2 为什么必须自动化
OpenAI 的教训：
一开始每周五花 20% 的时间手动清理 AI 生成物中的低质量代码。这在团队规模小、PR 少时可行；一旦规模扩大，人工清理成为瓶颈。
后来自动化了：后台 Agent 定期扫描文档不一致、架构违规和冗余代码，自动提交清理 PR。
2.3 熵管理的架构
定期触发（cron/hook）
↓
清理Agent（独立session）
↓
扫描：文档不一致 | 架构违规 | 冗余代码 | 死代码
↓
生成修复PR
↓
人工审查合并
2.4 清理速度 >= 生成速度
这是可持续运行的关键。
如果清理速度 < 生成速度，熵积累速度会越来越快，最终系统质量崩溃。
三、三类约束体系
Martin Fowler 提出的框架，把 Harness 分为三类：
3.1 Maintainability Harness（可维护性约束）
关注点：内部代码质量和可维护性
| 控制类型 | 能捕获 | 不能可靠捕获 |
|---|---|---|
| Computational | 结构性问题：重复代码、圈复杂度、缺少测试覆盖、架构漂移、风格违规 | 语义问题 |
| Inferential（LLM） | 语义重复代码、冗余测试、暴力修复、过度工程 | 高影响问题：误诊、过度工程、指令误解 |
Computational sensors 的例子：
- ArchUnit（Java架构测试）
- ESLint + 自定义规则
- 测试覆盖率工具
- 依赖分析工具
3.2 Architecture Fitness Harness（架构Fitness约束）
关注点：应用的架构特性是否达到要求
本质上是 Fitness Functions——一组定义了"架构想要什么"的自动化验证。
例子：
Feedforward：
- Skill：性能要求
- Skill：可观测性规范（logging标准）
Feedback：
- 性能测试：告诉Agent性能是提升还是退化
- 日志质量审计
3.3 Behaviour Harness（行为约束）
关注点：应用功能行为是否符合需求
这是最难解决的一类。
当前大多数人的做法：
| 控制类型 | 做法 |
|---|---|
| Feedforward | 功能规格（从简短提示到多文件描述） |
| Feedback | AI生成的测试套件是否绿色通过 |
Böckeler 的批评：
"用 AI 生成的测试来验证 AI 生成的代码，本质上是用同一双眼睛检查自己的作业。That's not good enough yet."
部分解决方案：Approved Fixtures
Thoughtworks 的同事发现 Approved Fixtures 模式在某些场景下有效——但它更适合局部而非全量。
四、Model-Harness 耦合问题
4.1 什么是 Model-Harness 耦合
LangChain 发现：当前的 Agent 产品（Claude Code、Codex）是模型和 Harness 一起训练的。这导致一种过拟合：
换了工具逻辑后，模型表现会变差。
在 Terminal Bench 2.0 排行榜上，Opus 在 Claude Code 的 Harness 下的得分，远低于它在其他 Harness 中的得分。
4.2 关键结论
"The best harness for your task is not necessarily the one a model was post-trained with."
为你的任务选择 Harness 时，不要被模型的默认 Harness 束缚。
4.3 应对策略
- 独立评估：不要假设默认 Harness 就是最优的
- Benchmark：在不同 Harness 上测模型，选表现最好的
- 定期重评：模型更新后，重新测试 Harness 组合
五、Harness 的版本化管理
5.1 为什么是软件工程问题
Böckeler 指出：
"Skills, prompts, and MCP configurations are code. Version them, review them in PRs, and refactor them when they drift. A stale prompt rots just like a stale test."
Harness 是需要维护的软件，不是配置完就扔的东西。
5.2 实践建议
版本控制：
harnesses/
├── v1/
│ ├── AGENTS.md
│ └── lints/
├── v2/
│ ├── AGENTS.md
│ └── lints/
└── current -> v2/
PR 审查：
- 改 AGENTS.md 需要代码审查
- 新 Skill 要有测试
- 约束变更要论证
定期重构：
随着模型变强，之前必要的保护机制可能已经冗余。要定期简化 Harness。
六、Harness 的评测体系
6.1 当前缺失
Böckeler 提出的开放问题：
"How do we evaluate harness coverage and quality similar to what code coverage and mutation testing do for tests?"
目前没有类似"测试覆盖率"的指标来衡量 Harness 的有效性。
6.2 可能的评测维度
| 维度 | 含义 |
|---|---|
| 覆盖率 | 多少比例的任务类型有对应约束/验证 |
| 准确性 | 约束/验证的结果与真实质量的相关性 |
| 时效性 | 从问题出现到被捕获的平均时间 |
| 效率 | 每次变更运行 Harness 的成本（时间+金钱） |
总结
高级 Harness Engineering 关注三个核心问题：
1. 可观测性不止给人，也要给 Agent
- 结构化日志 + 指标可查询 + 链路追踪
- Agent 能自我诊断、自验证、自适应
2. 熵管理必须自动化
- AI 生成 ≠ 完美生成，熵会积累
- 清理速度 >= 生成速度才能可持续
3. 三类约束各司其职
- Maintainability：用 Computational sensors 捕获结构问题
- Architecture Fitness：Fitness Functions 定义架构目标
- Behaviour：最难，目前无完美方案
Model-Harness 解耦是长期方向——不要被默认 Harness 束缚，定期重新评估组合。
标签：#AI #Agent #HarnessEngineering #可观测性 #熵管理 #Observability