反思与扩展：Agent Harness Engineering
如果我要扩展这篇工作
1. 增加定量测量的实证支持
论文的核心主张（框架 > 模型）依赖于少数几个案例（Bölük 2026a, Trivedy 2026, Meta-Harness）。虽然这些案例很有说服力，但可以做的更系统：
- 对照实验设计：在多个基准上，控制模型不变、变化框架，统计框架效应量
- 因果分析：识别框架的哪些具体改动产生了最大影响（是工具格式？上下文结构？还是验证机制？）
- 跨模型泛化：在不同参数量级模型上验证框架效应是否一致
2. 半自动化层评估方法论
目前的层分配是人工编码的，论文也承认缺乏多编码员一致性研究。可以开发一个半自动化评估协议：
- 基于 README/论文/API 文档的结构化特征提取
- 用 LLM-as-judge 辅助层分类（但需验证可靠性）
- 建立标准化的层覆盖评分量表
3. 框架耦合度的定量度量
论文提出了”框架耦合问题”（harness coupling problem）但未给出度量。可以定义：
框架耦合度 = 替换某层时需修改的其余层代码量 / 总代码量
通过分析开源项目的提交历史来追踪耦合度的变化趋势。
哪些假设是脆弱的
- 开源代表性假设：论文假设开源生态可以代表整体 agent 系统生态。实际上，商业系统的工程成熟度可能远高于开源项目（尤其在 O 和 G 层）
- 语言和时区偏好：非英语开源项目（如中文 agent 框架）被系统性排除
- agent 类型均匀性：编码 agent 过采样，其他领域（如机器人、科学计算、创意工作流）的 agent 可能完全不同的框架需求
- 静态快照假设：框架认证照在 2026-05 冻结，这个领域发展极快，可能数月后结论就过时
- 线性演化假设：三阶段演化模型（Prompt→Context→Harness）可能过于线性——实际上不同组织可能跳过某些阶段或并行发展
它在实践中可能失败的地方
- 框架层过重：遵循 ETCLOVG 全部七层可能导致”框架肥胖”，小型 agent 系统不堪重负
- 一刀切的分类法：并非每类 agent 都需要所有层。一个简单的 RAG agent 可能只需要 C+V，一个 coding agent 需要 E+T+L+V+G
- 组织成本：要让 O 和 G 达到生产标准，需要专门的运维和安全团队——对个人开发者或小团队不现实
- 框架 vs 灵活性的矛盾：标准化（如 MCP）带来可替换性但也失去特定场景的优化空间
- 过度工程风险：在框架工程投入远大于实际需要时，可能不如直接上更好的模型