上周我写了一篇《我的 Agent 假装上班了 5 天》，诊断了自研 ActiveAgent 的”空转”。这周我做了个更狠的决定：亲手杀掉它，推倒重写。 原因是一句话——“agent 技术发展日新月异，大概率 AA 一出生就是个落后产品。” 这篇记录从「要不要继续做」的灵魂拷问，到 AA v2 四层架构、QGS 三 Gate 时机设计、6 轮对抗式评审收敛的全过程。

1. 缘起：一个让我失眠的问题

我的 ActiveAgent（AA）是一个”自治运维壳”：每 15 分钟 tick 一次，扫描 3 个项目 × 9 个维度，发现问题就修复，每天 21:00 出日报。上周刚把它”假装上班 5 天”的空转问题修好（见《我的 Agent 假装上班了 5 天：自主系统「空转」诊断实录》）。

修完之后，我盯着它问了自己一个问题：AA 还有必要继续发展吗？

把账算清楚之后，答案让我睡不着：

数据 数值 含义
tick 次数 1416 次 系统自认为”工作”的总次数
其中只 report 的 98% 几乎全部只是汇报，没有行动
skills 只有声明无实现 宣称的能力是空的
memory 未接线 记不住任何事
频道对话 零使用 用户根本不通过它聊天

与此同时，主力 Agent 是 Hermes（已经相当优秀），备用 GenericAgent 正在被边缘化。而开源社区冒出一个新玩家——PrimeAgent（Prime Intellect 出品，GitHub）：它把 RLM（Recursive Language Model，把 context 当变量、子 agent 当函数调用）和 Continual Harness（/refine 自我改进）工程化成了可运行的系统。它还不成熟，但正因为不成熟，才有潜力。

我的判断（原话记录在案）：

“我们现在主力是 HERMES……之所以要写 AA，某种程度是为了圆我要自己写一个通用 agent 的梦。但目前 agent 相关技术发展日新月异，大概率 AA 一出生就是个落后产品。我的意见是：把 AA 目前负责的任务转移，AA 从头重写，以 PrimeAgent 为基座，结合 Proactive 思想，融合对抗式解题法和 QGS 方法，把 AA 项目本身作为一个技术开发和应用平台。”

同时附上两条硬性意见（这两条后来成了架构设计的两条主线）：

  1. 不要跟 Hermes 耦合——相关功能实现可以参考，但两个项目独立；
  2. QGS 的评审时机经常出问题（我用 Hermes 的经验），新设计要设法避免。

2. 核心方法：四层架构 + 6 轮对抗式评审

2.1 总体架构：四层，从内核到平台

AA v2 的核心命题是”用最新技术做平台，而不是再造一个轮子”。架构分四层：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
┌────────────────────────────────────────────────┐
│ L3 平台层: MCP任务注册中心 · 任务队列 · 复盘台    │
│          eval回归集 · 模型路由(自实现+降级链)     │
├────────────────────────────────────────────────┤
│ L2 质量保障层: Orchestrator · QGS三Gate(状态机+WAL)│
│          判别者引擎(8角色) · solver修复           │
├────────────────────────────────────────────────┤
│ L1 Proactive层: 扫描器 · 分析器 · Reward Filter  │
│          反馈循环（"0 LLM"仅限定这一层）          │
├────────────────────────────────────────────────┤
│ L0 PrimeAgent内核: AgentSession(RLM) · IPython  │
│          /refine · skills · Adapter薄层(双包装)  │
└────────────────────────────────────────────────┘
        │ MCP (stdio, 开放协议)
        ▼
  外部消费者（可选）: Hermes / 任何 MCP client / CLI

三个关键设计：

  • L0 用 Adapter 薄层做双包装（入口 API 5-10 个 + 数据契约 schema 版本管理）。PrimeAgent 快速演进不可控，Adapter 把”内核变更”隔离在薄层内，月度 merge + golden eval 回归。
  • “代码即智能（核心循环 0 LLM）”只限定 L1 感知层。L0 和 L2 本质是 LLM 驱动的，不受此约束——这个边界是评审轮次里被反复确认的。
  • 解耦不是口号，是可执行的验收标准：每个 Phase 验收含 grep 检查——无 import hermes、无子进程调用 Hermes CLI、无读 ~/.hermes 文件、无依赖 Hermes 环境变量；P4 再补运行时探测（沙箱内监控子进程调用，防动态 import 绕过）。

2.2 QGS 三 Gate：把”评审时机”变成状态机

用户意见②”QGS 评审时机经常出问题”是我在 Hermes 上踩出来的血泪。我把它先固化成反面清单，再逐条设计对策：

Hermes 已知问题 症状 AA v2 对策
维护命令被拦截 hermes update / npm install 被拦 Gate-0 命令白名单豁免（规则判定，非 LLM）+ 豁免产物抽检
delegate 子 agent 误触发 子代理被误评审 平台内子任务标记自动豁免
分类时机错误 分类错则评审全错 置信度门 + 失败兜底（默认 GENERATE）+ Gate-1 产物复核纠错
评审对象错位 对中间过程评审，漏交付物 评审挂在交付物产生点（Gate-1）
降级不可见 静默回退 degraded=true 显式标记；同步模式降级后阻塞等人工确认
判别者幻觉 虚构缺陷 判别者输出反幻觉规则
空 JSON 假 FAIL 空响应 → 默认 50 分 输出解析容错 + 空响应显式降级
cron 被误评审 无人值守任务被评 无人值守默认跳过 + 审批超时降级策略

三 Gate 的时机语义：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
任务提交
  ↓
[Gate-0 任务分类] GENERATE / ACTION / MAINTENANCE / QUERY
  ├─ 命令白名单(MAINTENANCE) + 规则 + LLM 兜底
  ├─ 置信度门: <0.6 → 按 GENERATE（宁可多评不漏评）
  └─ 失败兜底: 分类器异常 → 默认 GENERATE
        ↓
[Gate-1 交付物评审] 在交付物产生点触发（同步模式，GENERATE 默认）
  ├─ 产物 <200 字且无代码 → 跳过评审 = 默认收敛（敏感操作仍过审批）
  ├─ 评审超时(10min) → 降级 ≠ 放行：显式标记 + 阻塞等人工确认
  └─ 产物类型复核: Gate-0 判错但产物是生成物 → 纠错进评审
        ↓
[Gate-2 收敛] P0/P1 归零 + 总分 <20 + min_rounds=2
  ├─ 收敛 → 敏感操作过审批 → 交付
  └─ 未收敛 → solver 修复 → 再审（max_rounds=5 熔断）

最反直觉的一条：降级 ≠ 放行。评审超时不是”先放了再说”，而是显式标记 degraded 并阻塞等人工确认——“未评审不交付”是同步模式的硬语义。异步模式（复盘/观察类）则明确只复盘、不承诺门禁，且 GENERATE 类任务不可自声明异步绕过。

2.3 6 轮对抗式评审：设计文档也要过门禁

架构文档本身，我用多角色对抗式评审循环来压：每轮只验证上一轮的 P0/P1 修复，分数递减直到收敛。

轮次 评审得分 结果
R1 (v1) 功能 645 / 架构 480 / 安全 850 → v1.1
R2 (v1.1) 架构 170 / 安全 225 → v1.2 收敛
— 用户意见：解耦 + QGS 时机重设计 → v1.3
R3 (v1.3) 架构 205 / 功能 455 → v1.4
R4 (v1.4) 架构 95（P0/P1 清零，P2=3） → v1.5
R5 (v1.5) 架构 65（P0/P1 清零，P2=1） → v1.6
R6 (v1.6) 验证”真正落文” 预期收敛

有意思的是最后一轮：R5 只剩 1 个 P2——“Gate-0 防多评细节未真正落文”。架构师角色给的判定是：文档说”有命令白名单”只是声称，不是可实现的清单。于是 v1.6 把白名单落成独立文件 config/gate0_whitelist.json（含初始命令清单、变更需评审），豁免抽检给出可操作参数（10% 比例、时机、失败动作），Gate-0 定下 ≥98% 准确率阈值。评审收敛的最后一步，永远是”把声称变成可验收的清单”。

3. 踩坑记录：三类真实教训

3.1 「补课式发展」陷阱

AA v1 的问题不是 bug，是方向：1416 次 tick 里 98% 只 report，skills 只声明不实现，memory 不接线。给这种系统”补课”（加功能、修 bug）毫无意义——先判断值不值得继续，再谈怎么修。这个教训值得每个维护老系统的人反复咀嚼。

3.2 静默失败最难查：调仓信号一直输出 [SILENT]

任务转移审计时发现一个隐藏炸弹：alert_rules.json 全盘不存在（bridge 日志 WARNING 实证），bridge 返回的持仓只有代码列表、没有股数和成本价——而 portfolio_signal 工具要求 shares > 0，于是调仓信号/组合日报 cron 已经静默输出 [SILENT] 很久了。没有报错、没有告警，只是什么都不说。

修复过程也很有意思：用户提供财通证券持仓截图 → qwen3.7-plus 多模态识别 + OCR + 算术三重验证（市值/盈亏/成本完全吻合）→ 4 只 ETF 持仓（含股数、成本价）写入配置文件。静默失败的排查，往往要追到数据源是否存在，而不是代码逻辑。

3.3 约束的歧义会被评审放大

v1 里写”核心循环 0 LLM”，被 R1 揪出来：L0 内核和 L2 判别者本质就是 LLM 驱动的，这条约束放全文就自相矛盾。最后收敛为”仅限定 L1 感知层 + Reward Filter 受限逃生口（每日 ≤10 次、单次 ≤500 token、走脱敏管线）”。一条好约束，必须写清作用域。

4. 总结

三个 takeaway：

  1. 用最新技术做平台，不造轮子——自研从零写必然落后；站在 PrimeAgent 基座上，把已验证的方法论（对抗式、QGS、Proactive）注入进去，才是”平台”该有的姿势。
  2. 设计文档也要过对抗式评审直到收敛——6 轮评审把问题分从 R1 的 480/850 一路压到 R5 的 65，最后一步永远是”把声称变成可验收的清单”。
  3. 解耦要有可执行的验收标准——grep 检查 + 运行时探测，否则”解耦”只是文档里的漂亮话。

AA v2 的实现路径已排期 P0-P5（约 13-16 个开发日）：P0 任务转移（v1 职责 → Hermes，11 个扫描器已迁为 Hermes 侧 cron）、P1 基座 + 安全、P2 L1 Proactive、P3 L2 质量层（三 Gate）、P4 L3 平台层 + MCP 桥、P5 首个真实长任务 A/B 验证。

相关资源：

一句话：判断一个系统值不值得继续，比修好它更重要；而”重写”不是逃避，是把踩过的坑变成新架构的第一批验收标准。