给 AI Agent 装上"裁判眼"5：从评判到进化——多范式协同构建自我改进闭环

admin · 2026-05-16 · closed-loop · multi-paradigm · evaluation · evolution · Generator-Evaluator · 闭环进化

01 一个任务的完整生命旅程

前四章我们分别拆解了评估系统、多智能体工作流、上下文管理和对抗式讨论。现在把镜头拉远——看看一个任务从用户输入到最终交付，经历了什么：

用户一句话 → 系统做了什么 → 用户看到什么用户: "为5月12日南京博物馆做导览网页，含穿衣建议" │ ▼ [Stage 1] 记忆预取 + 需求预审核 MainAgent: prefetch("南京博物馆") → 注入历史偏好 Generator: 生成需求文档 → 含"闭馆提醒"交付物 Evaluator: 审核完整性 → 评分 0.88 → 通过 → 用户看到: 需求清单 + 任务计划 │ ▼ [Stage 2-3] 任务分解 + ReAct 执行分解为 6 个子任务: 搜索×2 + 构建×3 + 验证×1 子任务 1: baidu_search("南京博物馆") → 获取展馆信息子任务 2: baidu_search("南京天气 0512") → 穿衣建议数据子任务 3: write_file("nanjing_guide_0512.html") → 组装 HTML 子任务 4-6: 验证 + 补充 + 最终确认 → 检查点检测: 2 个检查点，均判定无需重规划 │ ▼ [Stage 4] 真实执行验证检测入口点 → nanjing_guide_0512.html HTML 结构验证: DOCTYPE ✓ head ✓ body ✓ → 采集: exit_code=0, 结构完整 │ ▼ [Stage 5] 对抗式评估讨论 Evaluator: 6 维度评估 → 初始总分 0.84 Defender: "评估合理" → 1 轮共识 → 最终报告: Grade B+ │ ▼ 用户看到: 导览网页 + 评估摘要

五个阶段，四种交互范式，三个独立 LLM 客户端——这就是 buddyMe 的多范式融合管线。本文将从全局视角拆解这条管线的架构设计、范式协同机制，以及跨框架对标分析。

02 四范式融合架构：一个管线，四种语言

buddyMe 在一条五阶段管线中融合了四种不同的 Agent 交互范式，每种范式解决一个特定的问题：

范式 I · Generator-Evaluator 编排

阶段：Stage 1 预审核
语言：结构化需求文档（冲刺合同）
解决的问题：需求遗漏和隐含约束未识别

范式 II · ReAct 工具调用循环

阶段：Stage 2-3 任务执行
语言：Thought-Action-Observation 循环
解决的问题：复杂任务的分步执行和工具调用

范式 III · Evaluator-Defender 对抗讨论

阶段：Stage 5 评估讨论
语言：辩护-重评循环（≤20 轮）
解决的问题：消除评估中的信息不对称

范式 IV · 分层记忆增强

阶段：跨阶段（横切关注点）
语言：三层记忆注入（短期/情景/长期）
解决的问题：上下文传递和跨会话知识积累

架构分层图

用户界面层

User Input → CLI / Command Registry → AgentMain（编排器）

│

▼

预执行层

Memory Prefetch → Command Dispatch → TaskRunner

│

▼

需求预审核 · Generator-Evaluator

Generator（_sub_client） ↔ Evaluator（_review_client）
最多 3 轮，阈值 0.8 → 冲刺合同

│

▼

任务分解 + 执行 · ReAct Loop

TaskPipeline → 8 个工具 + Skill Library（embedding 匹配）
检查点 → 动态重规划

│

▼

真实执行验证

Python / HTML / Shell → asyncio 子进程 → exit_code / stdout / stderr

│

▼

对抗式评估 · Evaluator-Defender

TaskEvalAgent（6 维度）→ EvaluationDiscussion（≤20 轮）
Defender（_sub_client）↔ Evaluator（_eval_client）
→ 最终报告（加权评分 + 等级）

│

横切 ▼

记忆系统（横切关注点）

Layer 1: Working Memory（MessageHistory）— 单次 session
Layer 2: Episodic Memory（SubtasksManager）— 单次任务
Layer 3: Long-term Memory（MemoryStore → USER.md）— 永久
生命周期: Score → Decay → Consolidate

03 五阶段管线的形式化定义

每个阶段的交互范式可以用精确的数学语言描述。这不是学术炫技——形式化定义让设计意图没有歧义，也方便后续的工程验证。

Stage 1：Generator-Evaluator 预审核

形式化定义

# R_i = 第 i 轮的需求文档
# G = Generator, E = Evaluator
# S(E, R_i) = Evaluator 的评分 ∈ [0, 1]
# θ = 0.8 (APPROVAL_THRESHOLD, plan_reviewer.py:34)
# F(E, R_i) = Evaluator 的结构化反馈

R(i+1) = R(i)  if S(E, R(i)) ≥ θ
       else G(R(i), F(E, R(i)))  # Generator 根据反馈修正

# 终止条件: S(E, R_i) ≥ 0.8 或 i = 3（强制执行）

Stage 2-3：ReAct 工具调用循环

形式化定义

# 每一步的输出
o(t) = LLM(p_system ⊕ p_user ⊕ h(# p_system = 动态构建的 system prompt
# p_user = 用户 prompt（需求 + 子任务 + 对话历史）
# h(

if o(t) 包含工具调用 a(t):
    r(t) = ToolExec(a(t))
    h(t) = h(# 继续循环
else:
    return o(t)  # 纯文本 → 终止

# 最大步数: max_steps = 11 (agent.py:57)

Stage 5：Evaluator-Defender 对抗讨论

形式化定义

# v_i = 第 i 轮的 6 维评分向量
# D(v_i, C) = Defender 的回应（基于当前评分和执行上下文 C）

v(i+1) = E(v(i), D(v(i), C), C)

# 共识检测:
# 1. Defender 明确接受（字符串匹配）
# 2. |加权均分(i+1) - 加权均分(i)| ≤ 0.05
#    (CONSENSUS_THRESHOLD, verify.py:1078)

04 闭环的断点：评估结果去哪了？

完整的闭环应该是：执行 → 评估 → 反馈 → 改进 → 再执行。但 buddyMe 当前的闭环在"反馈"环节断裂了。

理想闭环 vs 当前现实理想闭环: 执行 → 评估 → 反馈回 MainAgent → 记忆系统学习 → 下次执行改进 ↑ │ └──────────────────────────────────────────┘ 当前现实: 执行 → 评估 → 报告打印到控制台 → 结束（fire-and-forget） │ └─ 不回传 MainAgent └─ 不持久化到记忆系统 └─ 不影响后续任务行为

这意味着：如果同一个错误在 Task A 中被 EvalAgent 发现，在 Task B 中可能再次出现——EvalAgent 每次都独立发现，但系统整体没有"记忆"。

为什么当前设计是合理的：在 v0.2.2 阶段，系统的主要目标是"可靠执行"而非"持续进化"。评估报告的 fire-and-forget 策略保证了主流程的稳定性——评估失败不会拖垮执行流程。但这个断点确实是未来进化的关键方向。

05 记忆系统：闭环的"神经中枢"

如果评估反馈要回流到系统中，记忆系统是唯一的载体。buddyMe 的三层记忆架构已经为闭环奠定了基础：

记忆生命周期 Creation（创建） MemoryExtractor 通过 LLM 从对话中提取关键信息 │ ▼ Scoring（评分）每次命中时增加活跃度分数 │ ▼ Active（活跃使用） prefetch(query) → 注入 system prompt → 强化（reinforced） │ ↑ │ └── 重新访问时重新激活 ▼ Decay（衰减）会话结束时降低未使用记忆的分数 │ ▼ Consolidation（整合）合并相似记忆，淘汰低分记忆 │ ├── Merged → Active（合并后回到活跃状态） └── Evicted → [*]（彻底淘汰） Layer 1: Working Memory (MessageHistory) — 单次 session Layer 2: Episodic Memory (SubtasksManager) — 单次任务 Layer 3: Long-term Memory (MemoryStore → USER.md) — 永久

闭环的接入点

短期闭环（Layer 1）

当前已实现。对话历史（MessageHistory）在多轮对话中自然累积，用户说"上次的按钮改成蓝色"，MainAgent 能理解指代关系。
局限：只在一个 session 内有效

中期闭环（Layer 2）

当前已实现。子任务结果通过 SubtasksManager 在同一任务内传递，后续子任务能看到前序结果。
局限：任务结束即销毁

长期闭环（Layer 3）— 当前断点所在

评估报告中的关键发现（常见错误模式、代码风格不一致、工具调用冗余）应该持久化到 MemoryStore，供后续任务参考。
当前状态：Layer 3 存储的是用户偏好和项目知识，不包括评估经验教训

06 跨框架对标：buddyMe 不是唯一的解法

buddyMe 的多范式融合不是唯一的架构选择。不同框架对"评估反馈"和"闭环"的处理方式截然不同：

多智能体编排对比

维度	buddyMe	CrewAI	AutoGen	LangGraph
编排模式	集中式（AgentMain）	角色化流水线	对等对话	有向图 + 条件边
评估集成	内置 6 维度	外部	外部	外部
对抗讨论	内置 Evaluator-Defender	无	可模拟	条件分支
反馈闭环	部分（缺 Layer 3）	无内置	对话式	Checkpointer
记忆持久化	三层 + 生命周期	短期	无	状态图

工具调用循环对比

维度	buddyMe	LangChain Agent	OpenAI Assistants
工具定义	BaseTool 抽象	@tool 装饰器	Function Schema
Skill 自动发现	Embedding 匹配	无	无
工具限制策略	最后一步禁止创建	无	无
上下文压缩	ContextCompressor	可选	自动

记忆系统对比

维度	buddyMe	MemGPT	A-Mem
层数	3 层（完整）	分层存储	自主管理
检索方式	prefetch(query)	语义检索	Agent 决策
衰减机制	评分→衰减→整合	FIFO	Agent 自主遗忘
跨任务传递	SubtasksManager（文件桥接）	消息流	经验库

buddyMe 的独特定位：将评估系统作为一等公民集成在编排中，而非依赖外部工具。每次任务执行后都有标准化的六维度评估 + 对抗式讨论。这是 CrewAI、AutoGen、LangGraph 都不具备的——它们将评估视为外部关注点。

07 实证：四案例交叉验证

四种交互范式在真实任务中的表现如何？四个案例提供了交叉验证：

维度	案例一（北京博物馆）	案例二（南京博物馆）	案例三（定时任务）	案例四（综合导览）
主导范式	ReAct 循环	多智能体编排	ReAct + 记忆	全范式融合
交互体验	★★★★	★★★★★	★★★★	★★★
效率提升	6-12x	不可量化（避免白跑）	持续自动化	效率评分 0.5
认知负荷	极低	极低	低	中等
记忆参与	低（预取）	中（上下文注入）	高（外部记忆）	高（三层全启）

案例二亮点：隐含约束自动发现

Agent 主动识别"5月12日为周一→博物馆闭馆"这一隐含约束，自动添加闭馆提醒。Generator-Evaluator 协作确保约束被纳入冲刺合同的交付物。
这是单 Agent 难以可靠实现的能力——需要"审核者"角色来检查"执行者"是否遗漏了非显而易见的约束。

案例四瓶颈：工具调用冗余

26 次工具调用中约 30% 是重复操作（同一文件被读 8-9 次、相似搜索查询重复发起）。效率评分仅 0.5，成为整体评分的拖累项。
根因：缺少文件读取缓存和搜索去重机制

三条综合发现

发现 1 · 体验与复杂度负相关

越复杂的任务等待时间越长。案例二通过"主动预判"弥补了这一不足——不是让用户更快，而是让结果更出乎意料地贴心。

发现 2 · 瓶颈在工具不在推理

效率瓶颈不在 Agent 的"脑子"，而在它的"手脚"——工具调用冗余。引入缓存和去重可显著改善。

发现 3 · 认知负荷降低是核心价值

四个案例中用户均无需了解技术细节（HTML 结构、天气 API、定时器实现、评估 Schema），通过自然语言完成复杂任务。这是 Agent 系统最核心的用户价值。

发现 4 · 评估收敛快但闭环断

对抗讨论 70% 在 2-3 轮收敛，初始评估已较准。但评估结果 fire-and-forget，同一错误可能在后续任务中重复出现——闭环的断点。

08 闭环进化路线图：从"评判"到"进化"

基于实证发现和跨框架对标，buddyMe 的闭环进化路线清晰可见：

短期：接上断点

评估经验持久化

将 EvalAgent 的关键发现（常见错误模式、工具调用冗余、风格不一致）写入 MemoryStore，注入 Layer 3 长期记忆。
效果：Task A 发现的"重复搜索"问题，在 Task B 的 system prompt 中出现提醒

│

工具调用缓存

引入文件读取缓存 + 搜索去重，解决案例四中 30% 的冗余调用。
效果：同一文件在同一次任务中只读取一次，相同搜索查询复用结果

│

自适应编排

根据任务复杂度动态调整 Agent 数量和交互轮次，而非固定 3 轮预审核 + 20 轮讨论。
效果：简单任务跳过预审核，复杂任务增加到 5 轮

中期：增量检索

当前：全文注入

_build_conversation_context() 将整个 memory_summary.md（≤6000 字符）注入 prompt
问题：信息过载，关键信息可能被淹没

目标：语义检索

用 embedding 相似度按需检索最相关的记忆片段，替代全文注入
效果：Token 消耗降低，相关性提升

长期：学习型闭环

学习型闭环 · Learning-from-Evaluation 执行 Agent → 生成代码 │ ▼ EvalAgent → 六维度评估 + 对抗讨论 │ ▼ 关键发现提取 → 持久化到 MemoryStore │ ▼ 记忆系统 → 下次任务的 system prompt 注入经验教训 │ ▼ 执行 Agent → 改进后的执行（避免已知的错误模式） │ └── 循环往复，质量持续提升

本质转变：从"每次从零开始"到"每次站在上一次的肩膀上"。评估不再是任务终点，而是下一次进化的起点。这就是从评判到进化的核心转变。

09 全系列回顾与核心原则

五篇文章，从"为什么需要评估"到"如何构建自我改进闭环"，形成了一条完整的思维链路：

第一章 · 评估系统从零到落地

建立六维度评估 Schema + 真实执行验证 + 独立客户端隔离

│

▼

第二章 · 多智能体协作全链路

MainAgent 拆解 → Sub-Agent 执行 → EvalAgent 评审的完整工作流

│

▼

第三章 · 上下文管理的利弊博弈

持续 vs 独立 vs 无状态——三种上下文策略的取舍

│

▼

第四章 · 讨论大于判断

两层对抗式协作：冲刺合同 + Evaluator-Defender 讨论

│

▼

第五章 · 从评判到进化（本文）

四范式融合管线 + 闭环断点 + 跨框架对标 + 进化路线图

六条核心原则

原则 1 · 评估是一等公民

评估不是可选的外部工具，而是内置在管线中的核心组件。每次执行都有标准化评估。

原则 2 · 讨论优于单次判断

70% 的讨论以"接受"结束，说明初始评估已较准。但 30% 的修正证明了讨论的不可替代性。

原则 3 · 隔离保证客观性

三客户端隔离 + 对话隔离 + temperature=0。客观性是评估的生命线。

原则 4 · 真实执行不可替代

"能跑"比"看起来对"重要。入口点检测 + 子进程执行是最硬的证据。

原则 5 · 兜底优于完美

3 轮上限、20 轮上限、强制执行、规则兜底。宁可接受不完美，也不要无限循环。

原则 6 · 闭环是进化的前提

当前闭环在"反馈"环节断裂。接上这个断点，系统就能从"每次从零开始"进化为"每次站在上次肩膀上"。

写在最后：给 AI Agent 装上"裁判眼"系列到此完成。从评估系统的零到一，到多智能体协作的全链路设计，到上下文管理的利弊权衡，到对抗式讨论的工程实践，再到闭环进化的路线图——我们用五个章节完整拆解了 buddyMe 的评估与进化体系。

核心信息只有一句：评估不是终点，而是下一次进化的起点。