自测题：Agent Harness Engineering
基础题 (5 题)
Q1: ETCLOVG 分别代表什么？
答案
E = Execution Environment & Sandbox (执行环境与沙箱) T = Tool Interface & Protocol (工具接口与协议) C = Context & Memory Management (上下文与记忆管理) L = Lifecycle & Orchestration (生命周期与编排) O = Observability & Operations (可观测性与运维) V = Verification & Evaluation (验证与评估) G = Governance & Security (治理与安全)
Q2: 论文的三个核心主张是什么？
答案
- 概念性主张：agent 执行框架是独立系统层，其工程质量驱动了大部分实际可靠性
- 分类学主张：ETCLOVG 七层分类法，将可观测性和治理作为独立层级
- 实证主张：对 170+ 开源项目的映射显示了生态系统的覆盖模式与空白
Q3: 沙箱在 agent 时代的三种使命是什么？
答案
- 安全：隔离恶意代码
- 可复现性：重置到已知基线
- 活性/自由度：在受限区域内自由操作（Claude Code 沙箱化后权限提示减少 84%）
第三种是 agent 时代独有的。
Q4: 什么是”绑定约束论题”（Binding-Constraint Thesis）？
答案
对于长程任务，在同类前沿模型之间，基准方差可能由执行框架与模型本身共同驱动，甚至更多由框架驱动。这意味着改善框架往往比换用更强模型获得更大的可靠性提升。
Q5: 列举三个框架级改动优于模型级改动的案例。
答案
- Bölük (2026a)：仅修改编辑工具格式，15 个模型编码基准提升高达 10×
- Trivedy (2026)：GPT-5.2-Codex 固定，框架改动从 52.8% → 66.5%（+13.7 pp）
- Meta-Harness (Lee et al., 2026)：自动化框架优化在 Terminal-Bench-2 达 76.4%，超越所有手工方案
中级题 (5 题)
Q6: 论文提出的工程三阶段演化是什么？每个阶段的关键问题是什么？
答案
- Prompt Engineering (2022-2023)：焦点在”提示怎么写”——单轮推理、无状态
- Context Engineering (2023-2024)：焦点在”上下文如何组织”——多轮对话、工具使用
- Harness Engineering (2025-)：焦点在”基础设施如何设计”——长程任务、可靠性、安全
这个演化的本质是问题从”模型的输出质量”转移到”系统的设计质量”。
Q7: 论文为什么将可观测性 (O) 和治理 (G) 提升为独立层级？
答案
- 可观测性有自己独立的工具栈（OpenTelemetry, Langfuse, AgentOps）和专用团队
- 治理有自己独立的基础设施（权限引擎、API 网关、审计管线、生命周期钩子）
- 在生产部署中，这些层通常由不同的团队负责，而非生命周期编排的副产品
- 论文主张分类法应反映工程现实而非学术便利
Q8: 什么是”成本-质量-速度三角”？框架如何影响这个三角？
答案
这是一个三向权衡：
- 高精度（CoT + 多次采样）→ 高成本 + 慢速
- 低成本（单次 prompt）→ 低质量
- 快速（流式输出）→ 质量不足
框架的设计决定了这个三角的操作点。例如：
- 使用 Verifier/Evaluator 可以在低成本下提升质量
- 并行执行可以以成本换速度
- 缓存和复用可以减少成本
框架不应只在一个维度上优化，而应提供在不同场景下切换操作点的机制。
Q9: 什么是”能力-控制权衡”？沙箱如何帮助管理这个权衡？
答案
给 agent 越多权限和能力，就越难确保它按要求行事。沙箱同时解决两个方向：
- 作为牢笼：定义 agent 可以在哪些目录/网络/操作范围内行动
- 作为许可证：在沙箱范围内 agent 不需要每步征求许可
这种设计使 agent 在有限区域内获得完全的自由，平衡了能力（可以做复杂的事）和控制（不会超出范围）。Claude Code 的沙箱化把权限提示减少了 84%。
Q10: 什么是”框架耦合问题”？论文提出哪些解耦策略？
答案
agent 逻辑和框架越耦合，更换任何一方都越困难。解耦策略：
- 协议标准化：如 MCP 标准化工具接口、A2A 标准化 agent 间通信
- 沙箱抽象层：如 SWE-ReX 统一 Docker/Modal/E2B/Daytona 等多种后端
- 声明式配置：如声明式宪法 (Declarative Constitution) 把治理规则与代码分离
- 生命周期钩子：把策略注入点与业务逻辑分离
高级题 (5 题)
Q11: 论文的语料收集方法有什么局限性？这些局限性如何影响其结论的泛化性？
答案
- 英语与 GitHub 偏见：偏向 English-language 来源和 GitHub 可见项目，非英语和非开源生态被低估
- 编码 agent 过采样：coding agent 有最丰富的公开轨迹（repo、benchmarks、sandboxes、issue-to-PR），其他类型的 agent 可能代表性不足
- 基于文档的层分配：某项目可能实现了某些功能但没有公开文档，导致被标记为”未覆盖”
- 单编码员协议：没有多编码员一致性研究来确保分类的可复现性
- 商业系统欠采样：除非通过工程博客暴露机制，否则内部框架不可见
这些局限性意味着论文对”开源 agent 框架生态”的描述是可靠的，但对”整体 agent 系统生态”的描述可能有系统性偏差。
Q12: 论文说”沙箱在 agent 时代的第三个使命是活性/自由度”，这个论点与直觉相反（沙箱通常是限制自由的）。请分析其逻辑链条。
答案
逻辑链条：
- 没有沙箱时，agent 每执行一个潜在危险操作（写文件、装包、网络调用）都需要人工确认
- 人工确认有两个失败模式：用户放弃 agent（失去生产力），或用户无脑批准所有请求（失去安全性）
- 沙箱定义了一个有界区域，在该区域内 agent 可以自由操作
- 结果：用户不必每步确认，agent 获得更大的实际自由度
- 实证：Claude Code 的沙箱化使权限提示减少 84%
核心洞察：约束不是自由的反面，设计良好的约束是自由的前提。类似交通规则——限速不限制出行，反而让所有车都能安全快速地行驶。
Q13: 论文提出将状态管理放在 Lifecycle (L) 层而非 Context (C) 层，为什么？
答案
论文的论点：
- 状态管理属于执行流（谁在读/写状态），而不是信息结构（数据长什么样）
- 状态是在生命周期中被创建、读取、修改和销毁的
- 与执行流的紧邻关系决定了状态的可见性、一致性、持久性策略
这反映了一个更深层的设计原则：分类应按责任域而非数据类型。按数据类型分类会把写状态的 L、读状态的 C、控制状态的 G 混在一起；按责任域分类每个层的内聚度更高。
Q14: 从论文的跨层综合角度，设计一个 agent 系统时应该按什么顺序关注各层？
答案
论文虽然没有明确给出顺序建议，但从其框架可以推导：
阶段 1 (MVP)：E + T + L
- 先让 agent 能跑起来：执行环境、工具调用、基本生命周期循环
阶段 2 (可靠性)：C + V
- 确保 agent 记住该记的、忘掉该忘的；验证它在正确做事
阶段 3 (生产化)：O + G
- 出了事能排查；agent 不会越权
迭代式跨层优化：
- 随着系统成熟，不断回到各层调整操作点（成本-质量-速度三角）
- 引入抽象层解耦（MCP、沙箱抽象层）
一个常见陷阱：很多团队在阶段 1 直接跳到阶段 3（先加权限控制），反而降低了 agent 的活力。
Q15: 论文在结论中提出了 5 个开放研究问题。如果你要补充第 6 个，会是什么？
答案
这是一个开放性题目，以下是一个合理回答：
第 6 个开放问题：跨 agent 记忆和经验的共享与迁移
目前大部分 agent 的记忆系统是针对单个 agent 实例的。即使有共享知识库（RAG），agent 在任务执行中积累的经验（哪些策略有效、哪些工具参数常见错、什么 prompt 模板好用）也通常无法在 agent 之间迁移。这个问题的挑战在于：
- 隐私与隔离（agent A 的经验可能包含敏感信息）
- 经验的有效性评估（agent B 是否应该信任 agent A 的经验？）
- 冲突解决（agent A 和 agent B 的经验相互矛盾时）
另一个方向：标准化 agent 运行记录 的格式，以便跨框架的可迁移性和可复现性研究。