2.1 KiB
2.1 KiB
title, created, updated, type, tags, sources
| title | created | updated | type | tags | sources | ||||
|---|---|---|---|---|---|---|---|---|---|
| 脚手架跨层交互 (Cross-Layer Interactions) | 2026-07-13 | 2026-07-13 | concept |
|
|
脚手架跨层交互
定义
脚手架六组件（harness-six-components）虽然在分析上可分离，但在实践中并非独立运行。一个组件的设计选择经常重塑其他组件的负担。脚手架设计因此是耦合系统问题而非六个模块的独立优化。
关键耦合关系
I_obs ↔ C（观测-上下文耦合）
更丰富的观测改善接地性，但也增加了上下文选择、压缩和格式化的成本。SWE-agent 的 ACI 重新设计同时改变了观测和上下文——无法孤立地优化其一。
I_act ↔ V（行动-验证耦合）
更富表达力的行动扩展了能力，但要求更强的权限控制、沙盒化、rollback 和审计。当 tool 调用可能产生不可逆副作用时，V 的压力急剧上升。
S → C, V（状态-上下文-验证反馈环）
持久化的计划、日志、checkpoint 和产物同时决定什么可以被重新浮现给模型（C）和什么证据可用于判断进度（V）。
设计后果
优化某一层可能将风险转移到其他地方：
- 更强的压缩降低成本，但可能削弱下游验证（信息丢失）
- 更丰富的行动改善任务覆盖，但增加治理压力
- 更多持久化状态改善连续性，但也引入过时或冲突的证据
任务作为压力剖面
由于这种耦合性，任务结构本身成为脚手架设计的一部分。不同领域、视界、oracle 强度和自主性要求对 I_obs、C、L、I_act、S、V 施加不同的压力剖面。相同的解剖结构因此成为阅读任务格局的方式：任务因它们挤压哪些运行时责任和哪些配置选择变得决定性而不同。