背景与目标：从提示词工程到挽具工程

1.1 代码智能体的崛起与挑战

1.1.1 智能体架构的演进脉络

代码智能体（Coding Agent）的崛起标志着软件工程自动化进入新纪元。从2023年初GitHub Copilot的代码补全功能，到2024年Claude、GPT-4等模型展现出的多步骤任务执行能力，再到2025年各类终端智能体（Terminal Agent）和仓库级智能体（Repository Agent）的涌现，AI辅助编程已经从简单的”代码补全”演进为复杂的”任务执行”。

flowchart LR
    A[2023: 代码补全] -->|单行/多行建议| B[2024: 对话式编程]
    B -->|上下文理解| C[2025: 多步骤任务执行]
    C -->|工具调用| D[2026: 自主挽具演化]
    
    style A fill:#e1f5e1
    style B fill:#fff4e1
    style C fill:#e1f0ff
    style D fill:#ffe1e1

这种演进的背后是智能体架构的根本性转变。早期模型仅依赖输入提示词生成输出文本，而现代代码智能体采用挽具（Harness）架构——一个由多个组件构成的协调系统，包括：

• 系统提示词（System Prompt）：定义智能体的角色、行为准则和高层策略
• 工具定义（Tool Definitions）：描述可用工具的功能、参数和调用方式
• 工具实现（Tool Implementation）：实际执行工具调用的代码逻辑
• 中间件（Middleware）：在模型调用前后处理输入输出的逻辑层
• 技能（Skills）：针对特定任务类型的预定义工作流
• 子智能体配置（Sub-agent Configuration）：多智能体协作的编排定义
• 长期记忆（Long-term Memory）：跨会话持久化的知识和状态

1.1.2 挽具工程的手工困境

尽管挽具的重要性日益凸显，但挽具工程（Harness Engineering）在2026年之前仍然是一个手工技艺（Manual Craft）。生产团队通常遵循以下低效循环：

1. 轨迹检查：人工审查智能体的执行轨迹（Trajectory），识别失败模式
2. 直觉编辑：基于经验直觉编辑提示词、工具定义或中间件逻辑
3. 批量测试：在新任务批次上测试修改效果
4. 隐性知识积累：成功经验以非结构化形式散落在团队成员的个人笔记中

这一流程存在三个根本性缺陷：

缺陷一：异构操作空间（Heterogeneous Action Space）

挽具组件的类型极其多样——从纯文本的提示词到代码实现的工具逻辑，从配置文件的中间件参数到向量数据库的记忆结构。这种异构性使得自动化搜索难以定义统一的”编辑操作”，导致现有自动化方法（如ACE、GEPA、DSPy）只能优化单一组件（通常是提示词），而工具、中间件和记忆始终保持封闭。

缺陷二：信号淹没（Signal Burial）

单次任务执行可能产生数百万Token的原始轨迹数据。这些日志包含大量噪声——成功的步骤、无关的中间输出、格式化的元数据——将真正可指导改进的信号深埋其中。人工检查一条轨迹可能需要30-60分钟，而生产系统每天可能产生数千条轨迹，人工分析成为不可持续的瓶颈。

缺陷三：效果归因困难（Attribution Difficulty）

即使观察到性能变化，将变化归因于特定编辑也极其困难。智能体的性能受任务难度分布、模型随机性、环境状态等多重因素影响。在一个组件被多次编辑后，甚至难以确定哪些编辑是有效的，哪些是无效或有害的。

1.1.3 现有自动化方法的局限

在AHE之前，学术界和工业界已经探索了多种自动化优化路径，但都存在根本性局限：

这些方法的共同盲点在于：它们都将挽具的大部分组件视为不可变的基础设施，而将优化努力集中在单一的”适配层”（通常是提示词）上。AHE的核心洞见是：提示词只是七个关键组件中的一个，而且可能不是最重要的一个。

1.2 AHE的研究动机与问题定义

1.2.1 核心研究问题

AHE试图回答一个根本性问题：是否可能在不修改基础模型、不依赖人工调优的情况下，通过自动化演化实现挽具组件的全局优化？

这个问题的分解揭示了三个子挑战：

挑战一：如何表示和操作异构的挽具组件？

如果组件包括文本提示词、代码实现、配置文件和数据库状态，自动化系统如何对这些组件进行统一的”编辑”操作？编辑后如何回滚？

挑战二：如何从海量轨迹中提取可操作的洞察？

面对数百万Token的原始轨迹，如何自动识别失败模式、归因根本原因，并生成针对性的改进建议？

挑战三：如何验证编辑效果并处理倒退？

如何区分”好的编辑”和”坏的编辑”？当编辑导致性能倒退时，如何自动检测并回滚？

1.2.2 AHE的核心设计哲学

AHE通过**可观测性驱动（Observability-Driven）**的设计哲学应对上述挑战。其核心信念是：只有将系统内部状态暴露为结构化、可追溯的工件，自动化演化才能从试错升华为工程实践。

这一哲学体现为三个可观测性支柱：

1. 组件可观测性（Component Observability）：每个可编辑组件必须有显式的文件级表示，使操作空间显式化、版本化和可回滚
2. 经验可观测性（Experience Observability）：原始轨迹必须被蒸馏为分层的、可钻取的证据语料库，使演化智能体能够消费和理解
3. 决策可观测性（Decision Observability）：每次编辑必须附带自声明的预测（预期修复的任务、预期导致的倒退），使编辑转化为可证伪的契约

flowchart TD
    subgraph "可观测性三大支柱"
        A[组件可观测性<br/>Component Observability] -->|提供| D[显式操作空间]
        B[经验可观测性<br/>Experience Observability] -->|提供| E[分层证据语料]
        C[决策可观测性<br/>Decision Observability] -->|提供| F[可证伪契约]
    end
    
    D --> G[自动演化引擎]
    E --> G
    F --> G
    
    G -->|生成| H[挽具优化]
    
    style A fill:#e1f5fe
    style B fill:#e8f5e9
    style C fill:#fff3e0

1.2.3 研究目标与成功标准

AHE项目的具体目标包括：

目标一：建立闭环演化能力

设计并实现一个完全自动化的演化循环，能够从任务执行中学习、生成挽具编辑、验证编辑效果，并在必要时自动回滚，无需人工介入。

目标二：超越人工调优水平

在标准基准测试上，证明自动演化能够超越现有的人工设计挽具（如Codex-CLI、opencode、terminus-2）。

目标三：验证跨场景迁移能力

证明演化出的挽具不仅适用于训练时的基准，还能迁移到不同的任务类型（SWE-bench-verified）和不同的基础模型（跨模型迁移）。

目标四：定位性能增益来源

通过系统的消融实验，明确挽具各组件对最终性能的贡献，特别是验证”非提示词组件”的价值。

成功标准：

• Terminal-Bench 2 pass@1 ≥ 75%（超越Codex-CLI的71.9%）
• 演化时间 ≤ 48小时
• 跨基准迁移保持正向增益
• 至少一个非提示词组件贡献正向增益

1.3 研究范围与边界

1.3.1 研究范围

本研究聚焦于以下方面：

• AHE框架的技术原理：三大可观测性支柱的具体实现机制
• 实证结果分析：Terminal-Bench 2、SWE-bench-verified和跨模型迁移的详细结果
• 典型演化案例：从失败到修复的四个典型轨迹
• 实践启示：对开发者和非开发者的流程优化建议

1.3.2 研究边界

以下内容不在本研究重点范围内：

• 基础模型训练：AHE不改变模型权重，仅演化挽具
• 通用智能体研究：聚焦于代码/终端任务场景
• 安全与对齐问题：虽然重要，但不是AHE的核心关注点
• 商业部署细节：如成本控制、并发处理等工程实现

1.3.3 关键假设

AHE的有效性依赖于以下假设：

1. 可验证性假设：存在可靠的验证器（Verifier）提供二元的任务通过/失败信号
2. 可重复性假设：任务执行在相似条件下的结果具有统计可重复性
3. 组件独立性假设：挽具组件之间存在足够的松耦合，允许独立编辑和回滚

这些假设在代码任务场景中通常成立，但在开放域对话或创意生成任务中可能失效。

1.4 小结

AHE的诞生源于对现有智能体优化范式的深刻反思。提示词工程虽然重要，但它只是挽具优化的一个维度。当行业将80%的优化精力投入在提示词上时，AHE的消融实验揭示了一个令人不安的事实：单独优化系统提示词不仅收益有限，甚至可能导致性能倒退。

AHE的野心是将智能体优化从”手工技艺”提升为”工程学科”。通过建立三大可观测性支柱，AHE为自动化演化提供了必要的基础设施。接下来的章节将深入剖析这些支柱的具体实现，以及它们如何协同工作以实现挽具的全局优化。