-
整体架构与流程 -
实现Playbook — “策略手册” -
实现Generator — “行动者” -
实现Reflector — “复盘者” -
实现Curator — “策略管家” -
工作流组装与测试 -
问题与改进方向
整体架构与流程
参考 ACE 论文提出的结构，我们将其应用于一个基于 ReAct 范式 的智能体中。这个智能体具备自我“反思—学习—成长”的能力：
-
用一个ReAct Agent来承担Generator校色，接受输入任务，输出答案与推理过程。当然，实际应用中可以是任何形态的Agent。
-
离线模式（Offline Adapter） 即"训练模式"，用来在固定的训练数据集上多轮迭代运行ACE流程，每轮处理相同的样本，生成初始的策略库（Playbook）。这类似于学生反复做题，总结规律，积累经验。
-
在线模式（Online Adapter） 即"生产模式"：部署到真实业务场景中。此时输入数据不再固定，也不会多次迭代，但智能体会根据新任务实时更新 Playbook。它更像是一个在实战中不断成长的从业者，边工作边学习。
实际上，对于单次任务输入（迭代次数=1） 的情况，两者在基本流程上并无本质区别。因此我们可以构建一个统一的工作流结构：
-
若需“预训练”，只需在固定数据集上重复运行多轮 -
若直接“生产”，则让工作流持续接收新输入并在线更新策略
接下来，我们将逐步拆解各个模块的实现逻辑，从 Playbook 开始（为了更好地聚焦于 ACE 框架的核心逻辑，原型实现做了很多简化）。
实现Playbook — “策略手册”
Playbook 提供两种检索方式：
-
基于评分：基于评分优先返回表现好的策略
-
基于语义：借助向量实现语义级检索
每条策略都会在任务执行后根据反馈被打上标签（helpful / harmful / neutral）。系统根据这些反馈自动计算得分（Score）：
高分策略在检索时权重更高，而低分策略会逐步被淘汰。这使得智能体的经验体系具备自我优化能力。
3. 策略去重与整合
为避免知识冗余，Playbook 会在新增策略时进行去重检测（基于向量相似度）。当系统检测到已有相似策略时，不会简单新增，而是更新已有策略的统计信息。
4. 持久化与可重建
class Strategy:
id: str # 唯一标识
content: str # 策略内容
category: str # 分类（如 "react", "calculation"）
helpful_count: int # 有效次数
harmful_count: int # 有害次数
neutral_count: int # 中性次数
created_at: str # 创建时间
updated_at: str # 更新时间
@property
def score(self):
# 净得分 = 有效次数 - 有害次数
returnself.helpful_count - self.harmful_count
..."dat-00007": {
"id": "dat-00007",
"content": "信息来源评估原则：在确认信息时，必须对每个信息来源进行权威性评估。步骤：1) 获取多个来源的信息；2) 评估来源的权威性，例如是否为政府机构或知名组织；3) 选择最权威的来源并说明选择理由；4) 若存在差异，需给出合理解释。",
"category": "data_verification",
"helpful_count": 1,
"harmful_count": 0,
"neutral_count": 0,
"created_at": "2025-10-31T04:24:00.338080+00:00",
"updated_at": "2025-10-31T04:24:00.338084+00:00"
}通过这样的结构，Playbook 在执行阶段能动态调用最优策略，在反思阶段生成并吸收新策略，最终形成一个能够持续自我进化的“知识系统”— 让Agent不仅记得“做过什么”，还知道“怎样可以做得更好”。
实现Generator — “行动者”
Generator 是 ACE 框架中的执行者。它可以是一次简单的 LLM 调用。我们采用 ReAct范式的 Agent：根据输入问题生成可验证的答案，并产生可追溯的“推理轨迹”，供后续 Reflector 与 Curator 使用：
-
每次任务开始前，从 Playbook 检索问题相关的Top-K策略（基于分数或语义，注意不是所有策略都适合语义检索）。 -
将这些策略以“片段/指南”的形式动态注入系统提示，作为经验性先验，引导 ReAct 的思考与工具选择。
def_get_or_create_agent(self, question: str = "", context: str = ""):
"""
根据当前问题动态创建 agent，以便使用最相关的策略。
参数：
question: 当前问题
context: 额外的上下文信息
"""
return create_agent(
model=f"openai:{self.model_name}",
tools=self.tools,
system_prompt=self._get_system_prompt(question, context)
)-
Top-K 相关策略（含策略 ID，便于追溯）
-
工作原则与关键指令（如：必须逐步输出、遇到不确定先验证等）
-
工具使用说明（可选，FunctionCalling不需要）
-
任务上下文与边界（输入背景、约束、期望输出格式）
-
输出简明的“思考”过程（Reasoning） -
明确所引用的Playbook策略ID -
清晰标准工具调用相关信息
执行结束整理为统一的数据结构，至少包括：
-
最终答案（Final Answer）
-
推理轨迹（每轮Reasoning/Action序列）
-
使用的策略ID列表（用于之后的策略评估与计分）
实现Reflector — “复盘者”
它对 Generator（行动者）的推理链与执行轨迹进行系统化复盘，围绕三个关键问题给出结构化结论：
-
有ground_truth：先用评估器对最终答案与标准答案进行比对，生成客观评估信号（正确/错误、评估反馈、置信度）。Reflector 将该评估作为附加证据纳入分析，给出更精确的复盘结论。 -
无ground_truth：采用自我审查策略，基于推理链一致性检查、工具调用合理性、来源可靠性等信号，评估结果可信度并提出改进建议。
-
成功模式：哪些策略、方法和推理链起到了正面作用？能否泛化？ -
策略问题模式：哪些策略选择不当、理解偏差或逻辑跳跃？ -
工具使用错误：是否调用了错误工具、参数是否合理？ -
数据源问题：检索来源是否权威？信息是否一致？ -
计算错误：检测到LLM不擅长的数值推理等。
-
helpful：明确帮助了任务推进或提高了答案质量；
-
harmful：误导了推理或导致错误；
-
neutral：影响不大或无关。
并给出简短理由，作为 Curator 更新 Playbook 计数与内容的依据。
【输出结构（建议）】
from dataclasses import dataclass
from typing import List
@dataclass
class StrategyTag:
id: str # 策略ID
tag: str # "helpful" | "harmful" | "neutral"
justification: str # 标记理由（引用具体证据点）
@dataclass
classReflectionResult:
reasoning: str # 系统化分析（精炼、可读）
error_identification: str # 错误识别（发生了什么问题）
error_location: str # 错误位置（哪一步/哪条消息/哪次工具调用）
root_cause_analysis: str # 根因分析（为什么会错）
correct_approach: str # 正确方法（可操作的改进建议）
key_insight: str # 关键见解（可沉淀为策略的抽象经验）
confidence_in_analysis: float # 置信度（0~1）
strategy_tags: List[StrategyTag] # 对已用策略的评估标签实现Curator — “策略管家”
输出结构（建议）
from dataclasses import dataclass
from typing import List, Dict, Any
@dataclass
class CurateOperation:
operation: str # "ADD" | "UPDATE" | "REMOVE" | "MARK"
strategy_id: str = ""# 适用于 UPDATE / REMOVE / MARK
content: str = "" # 适用于 ADD / UPDATE（增量内容或补充要点）
category: str = "" # 新增/调整的分类
reason: str = "" # 操作原因（关联反思的证据/根因）
priority: int = 3 # 1~5，数值越小优先级越高
tags: Dict[str, Any] = None# 可选：delta/edge_cases/examples 等
@dataclass
class CurateResult:
operations: List[CurateOperation]
added_count: int
updated_count: int
removed_count: int
marked_count: int工作流组装与测试
各模块就位后，我们用 LangGraph 把它们串成一个最小可用的工作流。目标很简单：把已有的 ReAct Agent“包一层”，让它具备执行 → 评估（可选）→ 反思 → 策展的闭环能力（你完全可以自行用代码实现这个流程）。
def_build_graph(self) -> StateGraph:
"""
构建 LangGraph 工作流
"""
workflow = StateGraph(ACEReActState)
# 添加所有节点
workflow.add_node("react_agent", self._react_agent_node)
workflow.add_node("evaluator", self._evaluator_node)
workflow.add_node("reflector", self._reflector_node)
workflow.add_node("curator", self._curator_node)
# 设置入口
workflow.set_entry_point("react_agent")
# 使用条件边：react_agent 后根据是否有 ground_truth 决定路由
workflow.add_conditional_edges(
"react_agent",
lambda state: "evaluator"if state["react_question"].ground_truth else"reflector",
{"evaluator": "evaluator", "reflector": "reflector"}
)
# evaluator 后续路径
workflow.add_edge("evaluator", "reflector")
# reflector 和 curator 的路径
workflow.add_edge("reflector", "curator")
workflow.add_edge("curator", END)
return workflow.compile()我们用一个简洁的主程序跑通闭环：先离线“预热”出初始 Playbook，再在线测试与继续学习。为方便演示，epoch=1。
# 训练问题
questions = [
ReactQuestion(
question="计算 (25 + 17) * 3 - 8 的结果，并验证答案是否为偶数",
ground_truth="118，是偶数",
context=""
),
ReactQuestion(
question="搜索 Python 语言的创建者，并说明他创建 Python 的年份",
ground_truth="Guido van Rossum，1991年",
context=""
),
ReactQuestion(
question="搜索世界上最高的山峰名称和海拔高度，然后计算如果一个人每天爬升500米，需要多少天才能到达顶峰",
ground_truth="珠穆朗玛峰，8849米，需要约18天",
context=""
)
]-
Generator输出
-
Reflector输出
-
Curator输出
-
第一轮训练完成后的成果
-
排重
-
无监督场景测试
问题与改进方向
现在总结下我们是如何把 Agent 放进一个会“学习”的流程里：
-
LangGraph 负责编排
-
ReAct 负责生成与输出推理轨迹
-
Reflector 负责把执行过程转化成“经验”
-
Curator 负责把“经验”变成资产（Playbook）
周而复始，你会发现：同一个 Agent，做第二次同类任务，已经更“聪明”了。
尽管 ACE 的原型验证取得了一定效果，但目前仍存在若干关键问题：
1. LLM 表现波动大
-
Generator 与 Reflector 都严重依赖LLM与提示设计
-
即便相同的模型与提示，不同样本上的输出也可能不一致。特别是在基于 Function Calling 的 ReAct Agent 中，模型会在输出tool_calls后抑制本轮文本输出（content字段），导致“思考过程”或“策略引用”信息缺失
2. 策略增量更新的判定困难
Curator 在执行增量更新时，LLM 对“新增”与“更新”的边界判断并不稳定。常见问题包括：
-
倾向于新增相似策略，而非更新原策略
-
无法可靠检测重复或冲突策略
-
更新内容缺乏上下文一致性
需要引入向量检索 + 相似度阈值（如 0.7）的排重逻辑辅助。
3. 同步反思导致性能瓶颈
Reflector/Curator的同步执行会显著拖慢主流程。在生产场景中，这种“实时复盘”模式并不现实，可以采取异步或延迟执行机制。
1. 异步反思与批量学习
让 Reflector/Curator 异步运行，定期汇总反思结果并统一更新 Playbook，从而提升在线响应速度，同时保持学习闭环。
2. 领域化与定制化调优
ACE 不是一个“固定模板”，而是一种可演化的工程思想。在不同场景中，它的重心也会不同。比如，不同类型的智能体需要不同的反思与策略重点：
-
工具型智能体：更关注工具调用逻辑、参数安全、错误恢复
-
知识型智能体： 更注重专业知识积累、对话一致性与合规性
因此，实际落地时需根据业务场景、模型能力与目标指标进行调优。
3. Playbook 的生命周期管理
未来的策略库应支持：
-
更完善的质量评分与退化淘汰机制
-
版本管理与回滚（方便做 A/B 测试）
-
并发一致性控制（多任务下策略更新冲突）
-
检索优化（如何更好的选择最相关的策略）
5. 扩展性与组件化设计
-
可扩展/插拔的 Evaluator/Reflector 等模块
-
可替换的 Prompt 模板与策略过滤器
-
面向不同领域的 Playbook 预设（如财务、科研、客服等）
