AHE技术原理核心：三大可观测性支柱与七组件架构

2.1 七组件挽具架构

2.1.1 架构概览

AHE将代码智能体的”挽具”定义为七个可编辑组件的集合，这些组件共同构成了模型与外部环境交互的接口层。理解这七个组件的功能和相互关系是理解AHE工作原理的基础。

flowchart TB
    subgraph "挽具组件层 (Harness Layer)"
        direction TB
        
        subgraph "配置组件"
            SP[系统提示词<br/>System Prompt]
            TD[工具定义<br/>Tool Definitions]
            SAC[子智能体配置<br/>Sub-agent Config]
        end
        
        subgraph "实现组件"
            TI[工具实现<br/>Tool Implementation]
            MW[中间件<br/>Middleware]
            SK[技能<br/>Skills]
        end
        
        subgraph "状态组件"
            LM[长期记忆<br/>Long-term Memory]
        end
    end
    
    subgraph "基础模型"
        BM[Base Model]
    end
    
    subgraph "执行环境"
        EE[终端/文件系统<br/>Terminal/Filesystem]
    end
    
    BM <-->|调用| SP
    SP -->|指导| BM
    BM -->|生成| TD
    TD -->|触发| TI
    TI -->|操作| EE
    MW -->|拦截| TI
    SK -->|编排| TD
    SAC -->|协调| BM
    LM -->|提供上下文| BM
    
    style SP fill:#ffebee
    style LM fill:#e8f5e9
    style TI fill:#e3f2fd
    style MW fill:#fff3e0

2.1.2 各组件详解

1. 系统提示词（System Prompt）

系统提示词是模型接收的高层指令，定义了智能体的角色、行为准则和任务处理策略。传统的提示词工程几乎全部集中在这个组件上。

在AHE框架中，系统提示词的表现令人惊讶：单独优化系统提示词导致性能下降2.3个百分点。这表明过度复杂的提示词可能引入噪声或相互矛盾的指令，反而干扰模型的推理过程。

2. 工具定义（Tool Definitions）

工具定义以结构化格式（通常是JSON Schema）描述智能体可调用的工具集合，包括工具名称、功能描述、参数定义和返回值格式。

工具定义的质量直接影响模型调用工具的准确性。模糊或不完整的定义会导致模型选择错误工具或传递错误参数。AHE通过分析失败轨迹自动识别定义缺陷并生成改进建议。

3. 工具实现（Tool Implementation）

工具实现是实际执行工具调用的代码逻辑。与工具定义不同，工具实现包含具体的执行逻辑、错误处理和状态管理。

AHE的一个关键发现是：工具实现层面的修改能够带来实质性性能提升。例如，在path-tracing案例中，通过在shell工具中安装”发布状态保护”（publish-state guard）机制，成功阻止了智能体在完成验证后意外删除结果文件的行为。

4. 中间件（Middleware）

中间件是在模型调用前后执行的处理逻辑，包括输入预处理、输出后处理、日志记录和权限控制等。中间件可以拦截和修改模型与工具之间的数据流。

AHE的演化循环在mcmc-sampling-stan案例中生成了一种名为”执行风险提示中间件”（ExecutionRiskHintsMiddleware）的新组件，该中间件监控命令历史中的风险模式（如代理验证器、浅层验证、重复重试等），并向模型发出警告。

5. 技能（Skills）

技能是针对特定任务类型的预定义工作流或模板。例如，“Git仓库操作”技能可能包含标准化的分支创建、提交、推送流程。

技能组件使智能体能够将复杂任务分解为已知模式，减少推理负担。AHE通过分析重复出现的成功模式自动生成新技能。

6. 子智能体配置（Sub-agent Configuration）

子智能体配置定义了多智能体协作的编排方式，包括子智能体的角色分工、通信协议和任务分配策略。

在复杂任务中，单一智能体可能难以同时处理多个关注点。子智能体配置允许将任务分解给专门的子智能体，如”代码阅读智能体”、“测试智能体”和”重构智能体”。

7. 长期记忆（Long-term Memory）

长期记忆是跨会话持久化的知识和状态存储，通常基于向量数据库或结构化存储实现。与对话历史（短期记忆）不同，长期记忆能够在任务间保持上下文连续性。

AHE的消融实验显示：长期记忆组件单独贡献了5.6个百分点的性能提升，是所有单组件增益中最高的。这表明在复杂多步骤任务中，跨步骤的状态跟踪和知识累积至关重要。

2.1.3 组件间的相互作用

七个组件并非孤立工作，而是形成一个复杂的交互网络：

flowchart LR
    SP[系统提示词] -->|指导策略| M[模型]
    M -->|生成调用| TD[工具定义]
    TD -->|触发| TI[工具实现]
    
    MW[中间件] -.->|拦截/增强| TI
    SK[技能] -.->|提供模板| M
    SAC[子智能体配置] -.->|协调| M
    LM[长期记忆] -.->|提供上下文| M
    
    TI -->|反馈| M
    
    style MW stroke:#f57c00,stroke-width:2px
    style LM stroke:#388e3c,stroke-width:2px

这种相互作用产生了非叠加性效应（Non-additive Effects）：三个正向增益组件（记忆+5.6pp、工具+3.3pp、中间件+2.2pp）的简单相加为+11.1pp，但完整AHE仅实现+7.3pp。这意味着组件间存在干扰，最优配置并非各组件最优的简单组合。

2.2 三大可观测性支柱

2.2.1 组件可观测性（Component Observability）

核心原则：文件级表示

组件可观测性的核心设计决策是将每个可编辑挽具组件映射为文件级表示（File-level Representation）。这一设计带来三个关键优势：

1. 显式操作空间：组件不再是代码中的内嵌逻辑，而是可被读取、编辑和版本控制的独立文件
2. 细粒度回滚：每次编辑对应一个Git提交，天然支持文件级回滚
3. 失败模式映射：每个失败模式可以清晰映射到需要修改的组件类别

在NexAU框架（AHE运行的底层框架）中，七个组件类型被映射到固定的挂载点：

workspace/
├── system_prompt.md          # 系统提示词
├── tools/
│   ├── bash.json            # 工具定义（Bash工具）
│   ├── bash_impl.py         # 工具实现（Bash工具）
│   └── git.json             # 工具定义（Git工具）
├── middleware/
│   ├── pre_process.py       # 输入预处理中间件
│   └── risk_hints.py        # 风险提示中间件
├── skills/
│   ├── git_workflow.yaml    # Git工作流技能
│   └── debug_skill.yaml     # 调试技能
├── subagents/
│   ├── code_reader.yaml     # 代码阅读子智能体配置
│   └── test_agent.yaml      # 测试子智能体配置
└── memory/
    ├── vector_store/        # 向量记忆存储
    └── state.json           # 状态记忆

种子挽具的极简设计

AHE采用**极简种子挽具（Minimal Seed Harness）**策略：初始挽具仅包含一个基本的bash工具，没有任何中间件、技能或记忆。这种设计确保演化过程中添加的每个组件都必须在实测 rollout 中证明其价值。

种子挽具的基线性能为69.7%（Terminal-Bench 2 pass@1），这为后续的增益评估提供了清晰基准。

失败模式到组件的映射

组件可观测性使得失败模式可以与特定组件类别关联：

2.2.2 经验可观测性（Experience Observability）

问题：原始轨迹的信号淹没

单次任务执行可能产生数百万Token的原始轨迹数据，包含：

• 模型生成的思考过程（Chain-of-Thought）
• 工具调用的输入输出
• 环境状态变化
• 格式化元数据和日志

人工分析一条轨迹需要30-60分钟，这种瓶颈使得经验积累不可规模化。

解决方案：分层证据语料库

AHE通过Agent Debugger框架将原始轨迹蒸馏为分层的、可钻取的证据语料库（Layered Evidence Corpus）：

flowchart TB
    subgraph "原始轨迹"
        RT[数百万Token<br/>原始日志]
    end
    
    subgraph "第一层：消息级"
        M1[消息1文件]
        M2[消息2文件]
        M3[消息3文件]
        MN[...]
    end
    
    subgraph "第二层：任务级"
        TR[根本原因报告<br/>Root Cause Report]
    end
    
    subgraph "第三层：基准级"
        BO[基准概览<br/>Benchmark Overview]
    end
    
    RT -->|分割| M1
    RT -->|分割| M2
    RT -->|分割| M3
    RT -->|分割| MN
    
    M1 & M2 & M3 & MN -->|聚合分析| TR
    TR -->|汇总| BO
    
    style RT fill:#ffebee
    style BO fill:#e8f5e9

层级结构详解：

• 消息层（Message Level）：每条轨迹消息存储在独立文件中，支持精确引用和验证，但不对演化智能体直接暴露
• 任务层（Task Level）：每个失败任务生成一份根本原因报告（Root Cause Report），识别失败模式和归因
• 基准层（Benchmark Level）：聚合所有任务报告，形成演化智能体的入口点数据

这种分层结构的关键设计是：原始轨迹保持可访问以支持验证，但演化智能体首先从高层概览消费信息，仅在需要时钻取到具体消息。

归因先于蒸馏（Attribution Before Distillation）

经验可观测性的关键原则是归因先于蒸馏。在生成新的证据层之前，系统首先对上一轮的编辑进行归因验证——编辑是否如预期修复了目标问题？是否引入了未预见的倒退？

这种设计将编辑效果反馈绑定到证据语料库中，使演化智能体能够基于经过验证的历史决策进行学习，而非基于未经检验的自我合理化。

2.2.3 决策可观测性（Decision Observability）

核心机制：变更清单（Change Manifest）

决策可观测性要求每次编辑必须附带一个变更清单（Change Manifest），这是一个结构化的JSON文件，明确声明：

{
  "edit_id": "edit_2026_05_18_001",
  "timestamp": "2026-05-18T10:30:00Z",
  "component": "middleware/shell_guard.py",
  "change_type": "new_file",
  "failure_pattern_addressed": "premature_cleanup",
  "predicted_task_fixes": [
    "path-tracing",
    "configure-git-webserver"
  ],
  "predicted_regressions": [
    "fast-cleanup-tasks"
  ],
  "constraint_level": "tool_implementation",
  "rationale": "安装发布状态保护机制，在检测到验证器风格的成功检查后保护相关路径不被后续删除"
}

从合理化到契约的转变

传统优化流程中，编辑的理由（rationale）通常在编辑后撰写，作为对编辑的事后合理化。决策可观测性将这一关系颠倒：清单在编辑前生成，编辑成为对清单承诺的兑现。

在下一轮迭代中，系统会验证：

• predicted_task_fixes中的任务是否确实被修复？
• predicted_regressions中的任务是否确实出现倒退？

如果预测与实际结果不符，编辑会被自动回滚。这种机制将”自我合理化”（Self-justification）转变为”基于度量的验证”（Measurement-based Verification）。

自动回滚机制

决策可观测性支持细粒度的自动回滚：

sequenceDiagram
    participant E as 演化智能体
    participant M as Change Manifest
    participant R as 本轮Rollout
    participant V as 验证器
    participant G as Git
    
    E->>M: 写入变更清单
    E->>G: 提交编辑
    E->>R: 执行新一轮Rollout
    R->>V: 验证任务结果
    V->>M: 比对预测vs实际
    
    alt 预测不符
        M->>G: 触发回滚
        G->>G: git revert <commit>
        M->>M: 记录失败归因
    else 预测相符
        M->>M: 标记验证成功
    end

约束层级（Constraint Level）

变更清单中的constraint_level字段标识编辑所属的约束层级：

• prompt：提示词层面的软性建议
• tool_description：工具定义层面的接口契约
• tool_implementation：工具实现层面的执行保证
• middleware：中间件层面的拦截/增强
• skill：技能层面的工作流模板

约束层级影响回滚策略：较高层级的约束（如tool_implementation）提供的保证更强，回滚成本也更高。

2.3 演化循环的工作机制

2.3.1 六阶段外循环

AHE的外循环包含六个严格定义的阶段：

Algorithm 1: AHE Outer Loop
─────────────────────────────
H_best ← H₀                    # 初始化：bash-only种子挽具
for t = 1 to N do              # N=10轮迭代
    
    # Phase 1: 生成Rollout
    T_t ← Rollout(M, H_{t-1}, D, k)   # k≥2次rollout/任务
    
    # Phase 2: 清洗轨迹
    T̃_t ← Clean(T_t)                  # 移除base64、去重
    
    # Phase 3: 归因与回滚
    if t ≥ 2 then
        V_t ← Attribute(C_{t-1}, T_{t-1}, T_t)  # 验证上一轮清单
        H_{t-1} ← Rollback(H_{t-1}, V_t)        # 自动回滚失败编辑
    
    # Phase 4: 蒸馏证据
    R_t ← AgentDebugger(T̃_t)          # 生成分层证据语料
    
    # Phase 5: 演化编辑
    (H_t, C_t) ← Evolve(H_{t-1}, R_t, V_t)  # 生成新编辑和清单
    
    # Phase 6: 提交与标记
    Commit(H_t, C_t, t)               # Git提交并标记迭代
    
    # 更新最佳挽具
    if Pass@1(T_t) > Pass@1(H_best) then
        H_best ← H_t

return H_best

2.3.2 安全约束与防短路机制

演化智能体的操作受到严格约束，以防止”捷径”行为：

1. 只写工作区：演化智能体只能在workspace/目录内写入，不能修改runs/、tracer、verifier或LLM配置
2. 种子提示词不可删除：系统提示词的基础版本受到保护，防止演化智能体完全替换核心指令
3. 验证器只读：验证器（Verifier）提供的通过/失败信号是演化智能体无法修改的外部事实来源

这些约束阻止了无约束自修改器可能采取的捷径，如禁用验证器或提高推理预算。

2.3.3 迭代优化动态

在10轮迭代中，AHE展现出非线性的优化动态：

xychart-beta
    title "AHE迭代性能曲线 (Terminal-Bench 2)"
    x-axis ["种子", "迭代1", "迭代2", "迭代3", "迭代4", "迭代5", "迭代6", "迭代7", "迭代8", "迭代9", "迭代10"]
    y-axis "Pass@1 (%)" 65 --> 78
    line "性能" [69.7, 70.1, 71.2, 71.5, 72.3, 73.8, 74.2, 75.1, 76.97, 76.5, 77.0]
    
    annotation "db-wal-recovery修复" 2
    annotation "path-tracing修复" 5
    annotation "mcmc-sampling修复" 6
    annotation "configure-git修复" 8

关键观察：

• 早期快速增益（迭代1-2）：主要来自系统提示词的基本规则补充
• 中期波动（迭代3-7）：工具实现和中间件的调整带来不稳定但总体向上的趋势
• 后期收敛（迭代8-10）：性能在76-77%区间波动，边际收益递减

2.4 小结

AHE的技术架构建立在一个核心洞见之上：可观测性是自动演化的先决条件。通过将挽具组件映射为文件级表示、将原始轨迹蒸馏为分层证据语料、将编辑决策转化为可证伪契约，AHE为智能体优化建立了一个严谨的工程框架。

七组件架构的消融实验揭示了一个反直觉但意义深远的结论：工具、中间件和记忆等非提示词组件才是性能增益的主要来源。这一发现对整个行业实践具有颠覆性启示——提示词工程虽然重要，但它只是智能体工程的冰山一角。

演化循环的六阶段设计和安全约束机制确保了优化过程的可靠性和可追溯性。自动回滚机制将”试错”提升为”基于证据的验证”，使AHE区别于传统的黑盒优化方法。