Claude递归协作架构：实现AI智能体自我引导与复杂任务自动化

1. 项目概述与核心价值

最近在开发者社区里，一个名为“Gsunny45/Claude_on_Claude”的项目引起了我的注意。乍一看这个标题，可能会觉得有些“套娃”的意味——一个Claude在另一个Claude上运行？这听起来既像是一个技术实验，又像是一个充满哲学意味的玩笑。但当我深入探究其代码仓库和设计理念后，我发现这远不止是一个简单的概念验证，它实际上触及了当前AI应用开发中一个非常核心且前沿的议题：如何让大型语言模型（LLM）实现自我引导、自我优化，甚至自我迭代。

简单来说，这个项目的核心目标是构建一个系统，让一个Claude模型（作为“执行者”或“代理”）能够接收来自另一个Claude模型（作为“规划者”或“监督者”）的指令、反馈和评估，从而完成更复杂、更可靠的任务。这打破了传统上“人类用户直接与单一AI模型对话”的线性模式，引入了一个分层、递归的思考与执行框架。其背后的价值在于，单个LLM在处理多步骤、需要长期记忆、或涉及复杂决策链的任务时，容易“迷失方向”或产生“幻觉”。通过引入一个“元认知”层（即另一个Claude），系统可以更好地进行任务分解、步骤规划、过程监控和结果校验，显著提升复杂任务完成的成功率与质量。

这个项目非常适合以下几类朋友关注：一是对AI Agent（智能体）架构设计感兴趣的开发者，你能从中看到一个清晰的多智能体协作范本；二是希望利用Claude API构建更强大、更自动化工作流的产品经理或创业者，这里提供了超越简单问答的交互模式；三是任何对AI自我进化和递归能力抱有好奇心的技术爱好者，这个项目像一扇窗，让我们窥见未来AI系统可能的工作方式。

2. 核心架构与设计哲学拆解

2.1 从“单轮对话”到“递归协作”的范式转变

传统的AI应用，无论是聊天机器人还是文本生成工具，大多遵循“用户输入 -> 模型响应”的单轮或有限多轮交互模式。这种模式的瓶颈很明显：模型缺乏对长期目标的坚持，容易在复杂任务中偏离主题；它没有内置的“反思”机制来评估自己输出的质量；对于需要多步骤、多工具调用的任务，其规划能力也相对薄弱。

“Claude_on_Claude”项目的设计哲学，正是为了突破这些瓶颈。它借鉴了人类解决问题时的“思考-执行-评估”循环。在这个架构中：

• 上层Claude（规划者/监督者）：扮演“大脑”或“项目经理”的角色。它的核心职责是理解终极任务目标、进行顶层规划、将大任务分解为可执行的子任务序列、并为每个子任务生成清晰明确的指令。更重要的是，它需要评估下层Claude的执行结果，判断任务是否完成、质量是否达标，并决定下一步是继续、修正还是重新规划。
• 下层Claude（执行者/代理）：扮演“双手”或“工程师”的角色。它接收来自上层Claude的具体指令，专注于高质量地完成当前步骤。这可能包括生成代码、撰写文档、调用外部API、进行数据分析等。它不需要关心全局目标，只需对当前分配的任务负责。

这种“递归协作”的范式，使得系统能够处理远超单个模型上下文窗口限制的复杂任务。规划者可以维护一个高层次的“任务清单”和“状态跟踪”，而执行者则专注于当下。当执行者遇到困难或产出不符合预期时，规划者可以介入，提供更详细的指导或调整后续步骤。

2.2 关键组件与数据流设计

要实现上述架构，项目需要精心设计几个核心组件和数据流转机制。根据对开源代码的分析，其核心模块通常包括：

1. Orchestrator（协调器）：这是整个系统的大脑和调度中心。它通常是一个独立的服务或脚本，负责初始化任务、维护与两个Claude实例的会话、控制交互流程。协调器需要决定何时向规划者提问，何时将规划者的指令转发给执行者，以及如何处理执行者的返回结果。

2. Planner Module（规划模块）：封装了与“上层Claude”的交互逻辑。它向规划者Claude发送包含任务描述、当前进度、历史上下文等信息的提示（Prompt），并解析其返回的规划指令。提示工程在这里至关重要，需要引导Claude输出结构化的规划，例如使用JSON格式来明确列出步骤、成功标准和后续动作。

3. Executor Module（执行模块）：封装了与“下层Claude”的交互逻辑。它接收来自规划模块的具体指令，构建针对性的提示，发送给执行者Claude，并获取其产出（代码、文本、决策等）。这个模块可能还需要集成工具调用（Function Calling）能力，让Claude能够执行搜索、计算等操作。

4. State Management（状态管理）：由于任务可能是长周期的，系统必须有能力维护任务状态。这包括：当前任务目标、已完成的步骤列表、每个步骤的输入输出、规划者最新的评估结论等。这些状态信息会作为上下文，在每一轮交互中反馈给规划者，确保其决策是基于完整历史的。

5. Evaluation & Feedback Loop（评估与反馈循环）：这是实现“自我优化”的关键。规划者不仅给出指令，还要评估执行结果。评估标准可能包括：与指令的符合度、代码的正确性、文本的逻辑性等。评估结果（“通过”、“需修改”、“失败”）将直接影响协调器的下一步决策，形成一个闭环。

整个系统的数据流可以概括为：用户输入 -> 协调器 -> 规划者（生成计划） -> 协调器 -> 执行者（执行步骤） -> 协调器 -> 规划者（评估结果）-> … -> 最终输出。这个循环会持续进行，直到规划者判定任务成功完成或无法继续。

3. 核心实现细节与实操要点

3.1 环境搭建与依赖配置

要复现或基于此项目进行开发，首先需要搭建合适的环境。项目通常基于Python，并强烈依赖Anthropic官方的Claude API。

基础环境准备：

# 1. 创建并激活虚拟环境（推荐） python -m venv claude_on_claude_env source claude_on_claude_env/bin/activate # Linux/macOS # 或 claude_on_claude_env\Scripts\activate # Windows # 2. 安装核心依赖 pip install anthropic # Claude官方SDK pip install openai # 如果项目设计中也用到了OpenAI的模型作为对比或备选 pip install python-dotenv # 用于管理环境变量和API密钥 pip install loguru # 结构化日志，对于调试复杂流程至关重要

API密钥与配置管理：这是安全操作的重中之重。绝对不要将API密钥硬编码在代码中。

1. 在项目根目录创建.env文件。
2. 在.env文件中添加你的Anthropic API密钥：

   ANTHROPIC_API_KEY=your_actual_api_key_here

3. 在代码中，使用python-dotenv加载配置：

   from dotenv import load_dotenv import os load_dotenv() anthropic_api_key = os.getenv("ANTHROPIC_API_KEY")

4. 确保.env文件已被添加到.gitignore中，防止意外提交。

注意：由于项目需要同时调用两个Claude实例，你需要确保你的API密钥有足够的权限和额度。在开发测试阶段，密切关注Anthropic API控制台的使用量和费用情况。可以考虑为规划和执行角色使用不同的API密钥进行配额隔离和成本追踪，但这并非必需。

3.2 双Claude实例的初始化与会话管理

项目核心在于同时管理两个独立的Claude“会话”。虽然它们底层是同一个模型，但在系统中被赋予不同的角色和对话历史。

import anthropic class ClaudeSystem: def __init__(self, api_key): self.client = anthropic.Anthropic(api_key=api_key) # 初始化规划者会话：使用独立的对话历史 self.planner_messages = [] # 初始化执行者会话：使用另一个独立的对话历史 self.executor_messages = [] def _call_claude(self, messages, model="claude-3-opus-20240229", max_tokens=1000, system_prompt=""): """通用的Claude调用函数""" try: response = self.client.messages.create( model=model, max_tokens=max_tokens, system=system_prompt, messages=messages ) return response.content[0].text except Exception as e: # 详细的错误处理逻辑，包括速率限制、上下文超限等 print(f"调用Claude API失败: {e}") # 这里可以加入重试逻辑或降级策略 return None

关键设计点：

• 角色系统提示词（System Prompt）：这是区分规划者和执行者的关键。在每次调用_call_claude时，通过system_prompt参数注入不同的角色定义。
  • 规划者的System Prompt：应强调其战略思考、分解任务、评估质量的能力。例如：“你是一个高级任务规划专家。你的职责是将一个复杂目标分解为一系列清晰、可执行的步骤，并评估每一步执行结果的质量。请用结构化的方式思考。”
  • 执行者的System Prompt：应强调其专注执行、遵循指令、产出具体成果的能力。例如：“你是一个高效的任务执行者。严格遵循给定的指令，专注于完成当前步骤，产出准确、高质量的成果（代码、文本、分析等）。”
• 独立的对话历史：self.planner_messages和self.executor_messages必须严格隔离。规划者的历史中记录的是任务目标、分解逻辑和评估记录；执行者的历史中记录的是具体的操作指令和产出。混合两者会导致角色混乱。

3.3 规划者提示工程与结构化输出解析

规划者的输出必须是机器可解析的，这样才能驱动自动化流程。常见的做法是要求Claude以特定的结构化格式（如JSON、YAML或带标记的文本）返回其计划。

示例：规划者提示词设计

def build_planner_prompt(ultimate_goal, history=None): """ 构建给规划者Claude的提示词 :param ultimate_goal: 最终任务目标，如“创建一个简单的Python Flask web应用，提供天气查询接口” :param history: 之前的步骤和结果列表 :return: 完整的提示词字符串 """ base_instruction = """你是一个AI项目规划师。请将以下复杂任务分解为具体的、可顺序执行的步骤。 每个步骤必须包含： 1. `step_id`: 步骤序号。 2. `instruction`: 给执行AI的清晰、无歧义的指令。 3. `deliverable`: 该步骤期望产出的具体成果描述。 4. `criteria`: 用于评估该步骤成果是否合格的标准。 请以如下JSON格式输出你的计划： { "plan": [ {"step_id": 1, "instruction": "...", "deliverable": "...", "criteria": "..."}, ... ], "current_focus": "第一步的ID" // 指明应从哪个步骤开始执行 } """ history_context = "" if history and len(history) > 0: history_context = "\n\n## 已完成的步骤历史：\n" + "\n".join([f"- {h}" for h in history]) full_prompt = f"{base_instruction}\n\n## 终极任务目标：\n{ultimate_goal}{history_context}\n\n请开始规划：" return full_prompt

解析与错误处理：收到规划者的回复后，不能假设它一定是完美的JSON。需要健壮的解析逻辑。

import json import re def parse_planner_response(response_text): """ 解析规划者的响应，提取结构化计划。 :param response_text: Claude返回的文本 :return: 解析后的计划字典，或None（如果解析失败） """ # 方法1：尝试直接解析整个响应为JSON try: plan_data = json.loads(response_text) return plan_data except json.JSONDecodeError: pass # 方法2：使用正则表达式提取JSON部分（Claude可能在JSON前后添加了解释性文字） json_pattern = r'```json\n(.*?)\n```' # 匹配被```json ```包裹的代码块 match = re.search(json_pattern, response_text, re.DOTALL) if match: try: plan_data = json.loads(match.group(1)) return plan_data except json.JSONDecodeError: pass # 方法3：更宽松的提取，寻找类似JSON的结构 # 这里可以编写更复杂的启发式解析逻辑... # 如果所有解析都失败，记录错误并可能触发重新规划 print(f"无法解析规划者响应: {response_text[:200]}...") return None

实操心得：在提示词中明确要求JSON格式并给出示例，能极大提高Claude输出结构化的成功率。但永远要做好解析失败的准备，并设计降级方案，比如让协调器请求规划者重新以纯文本列出步骤，再由协调器进行简单的文本解析。

3.4 执行者指令传递与工具集成

执行者接收到的指令必须极其清晰。除了规划者提供的instruction字段，协调器还可以附加一些上下文信息。

构建执行者提示词：

def build_executor_prompt(step_instruction, context_from_planner=None, previous_outputs=None): """ 构建给执行者Claude的提示词 :param step_instruction: 规划者提供的具体指令 :param context_from_planner: 规划者提供的额外背景（如为什么这一步重要） :param previous_outputs: 之前步骤的相关产出，供本步骤参考 :return: 完整的提示词字符串 """ system_prompt = "你是一个专注的AI执行者。请严格、准确地完成以下指令。只产出指令要求的内容，不要添加额外的解释或步骤，除非指令明确要求。" user_prompt = f"## 当前步骤指令：\n{step_instruction}\n\n" if context_from_planner: user_prompt += f"## 规划背景：\n{context_from_planner}\n\n" if previous_outputs: user_prompt += f"## 相关前置步骤产出（供参考）：\n{previous_outputs}\n\n" user_prompt += "请开始执行：" return system_prompt, user_prompt

工具调用集成：对于需要实际操作（如运行代码、查询数据库、调用Web API）的任务，执行者Claude可能需要使用“工具调用（Function Calling）”能力。这需要在初始化客户端和调用时进行特殊配置。

# 示例：定义工具（这里是一个执行Python代码的工具） tools = [ { "name": "execute_python_code", "description": "在一个安全的沙箱环境中执行一段Python代码，并返回结果或错误信息。", "input_schema": { "type": "object", "properties": { "code": {"type": "string", "description": "要执行的Python代码字符串"} }, "required": ["code"] } } ] # 在调用执行者时，传入tools参数 executor_response = self.client.messages.create( model="claude-3-sonnet-20240229", # 执行者可以用更轻量的模型 max_tokens=2000, system=system_prompt, messages=[{"role": "user", "content": user_prompt}], tools=tools # 关键：声明可用的工具 )

当Claude的回复中包含tool_use时，你的代码需要识别它，执行相应的工具函数，并将结果以tool_result的形式追加到对话历史中，再请求Claude生成最终给用户的回复。这个过程实现了AI与真实环境的交互。

3.5 状态维护与循环控制逻辑

协调器是整个系统的“总控”，它维护着一个状态机。一个简化的核心循环逻辑如下：

class Orchestrator: def __init__(self, claude_system, ultimate_goal): self.cs = claude_system self.ultimate_goal = ultimate_goal self.plan = None # 存储当前计划 self.history = [] # 存储步骤历史：[{step_id, instruction, output, evaluation}] self.current_step_index = 0 def run(self): """主运行循环""" # 阶段1：初始规划 planner_response = self.cs.query_planner(self.ultimate_goal, history=self.history) self.plan = self.cs.parse_plan(planner_response) if not self.plan: print("初始规划失败，退出。") return # 阶段2：循环执行与评估 max_iterations = 20 # 防止无限循环 for i in range(max_iterations): if self.current_step_index >= len(self.plan['plan']): print("所有计划步骤已完成！") break current_step = self.plan['plan'][self.current_step_index] print(f"执行步骤 {current_step['step_id']}: {current_step['instruction'][:50]}...") # a. 执行步骤 executor_output = self.cs.query_executor( instruction=current_step['instruction'], context=current_step.get('deliverable', ''), previous_outputs=self._get_relevant_history() ) # 记录执行结果 step_record = { 'step_id': current_step['step_id'], 'instruction': current_step['instruction'], 'output': executor_output, 'evaluation': None } # b. 请求规划者评估 evaluation_prompt = f"请评估以下步骤的执行结果是否满足成功标准。\n步骤指令：{current_step['instruction']}\n成功标准：{current_step['criteria']}\n执行产出：{executor_output}\n请回答‘PASS’、‘FAIL’或‘NEEDS_REVISION’，并可附上简短说明。" evaluation_response = self.cs.query_planner(evaluation_prompt, history=self.history, role="evaluator") # 解析评估结果 evaluation_result = self._parse_evaluation(evaluation_response) step_record['evaluation'] = evaluation_result self.history.append(step_record) # c. 根据评估结果决定下一步 if "PASS" in evaluation_result.upper(): print(f"步骤 {current_step['step_id']} 评估通过。") self.current_step_index += 1 # 继续下一个步骤 elif "NEEDS_REVISION" in evaluation_result.upper(): print(f"步骤 {current_step['step_id']} 需要修订。") # 可以尝试重新执行，或请求规划者生成修正指令 # 这里简化处理，直接重试一次（需防止死循环） continue else: # FAIL 或无法解析 print(f"步骤 {current_step['step_id']} 评估失败。可能需要重新规划。") # 触发重新规划：将当前历史和失败信息反馈给规划者，请求新计划 replan_response = self.cs.query_planner( f"任务在执行步骤 {current_step['step_id']} 时失败。失败步骤指令：{current_step['instruction']}。失败产出：{executor_output}。请分析原因并提供新的计划或修正方案。", history=self.history ) new_plan = self.cs.parse_plan(replan_response) if new_plan: self.plan = new_plan self.current_step_index = new_plan.get('current_focus', 0) # 从新计划指定的步骤开始 else: print("重新规划失败，任务中止。") break # 阶段3：任务总结 final_output = self._compile_final_output() return final_output

这个循环体现了“规划 -> 执行 -> 评估 -> 决策”的核心逻辑，是项目动态适应性的来源。

4. 典型应用场景与实战案例

4.1 场景一：自动化代码生成与迭代开发

这是“Claude_on_Claude”最直观的应用。假设我们要开发一个“个人博客内容管理系统”。

1. 用户输入终极目标：“创建一个使用Flask框架的个人博客CMS后端，包含用户认证、文章CRUD、标签分类功能，并编写基本的API文档。”
2. 规划者行动：规划者Claude将这个目标分解为：
   • 步骤1：初始化Flask项目结构，安装依赖（Flask, Flask-SQLAlchemy, Flask-Login等）。
   • 步骤2：设计数据库模型（User, Post, Tag）。
   • 步骤3：实现用户认证相关的视图和路由（注册、登录、登出）。
   • 步骤4：实现文章和标签的CRUD API。
   • 步骤5：使用Flask-RESTX或类似工具生成交互式API文档。
   • 步骤6：编写基本的单元测试。
   • 步骤7：创建Dockerfile和docker-compose.yml用于容器化部署。
3. 执行与评估循环：
   • 执行者完成步骤1，生成requirements.txt和app/__init__.py。规划者评估：文件结构清晰，依赖正确 ->PASS。
   • 执行者完成步骤2，生成models.py。规划者评估：模型关系定义正确（一对多、多对多），字段齐全 ->PASS。
   • 执行者完成步骤3，生成auth.py。规划者评估：登录逻辑完整，使用了密码哈希，但缺少“记住我”功能。 ->NEEDS_REVISION。协调器要求执行者补充该功能。
   • ... 如此循环，直到所有步骤通过评估。
4. 最终产出：一个结构完整、功能可用的Flask项目代码库，以及部署配置。

这个场景的优势：将复杂的软件开发任务自动化，尤其适合生成样板代码、搭建项目框架。规划者确保了功能的完整性和架构的合理性，执行者保证了代码的细节正确。

4.2 场景二：复杂研究与分析报告撰写

假设我们需要撰写一份关于“量子计算对现有加密算法冲击”的技术调研报告。

1. 用户输入终极目标：“撰写一份约5000字的深度技术报告，分析Shor算法等量子算法对RSA、ECC等非对称加密体系的威胁时间线、当前抗量子密码学（PQC）的发展现状，以及企业的迁移建议。”
2. 规划者行动：规划者Claude制定报告大纲：
   • 第一部分：引言（量子计算基本原理、威胁概述）。
   • 第二部分：详解Shor算法等量子攻击原理。
   • 第三部分：分析RSA、ECC等算法的脆弱性及理论破解时间线。
   • 第四部分：综述NIST PQC标准化进程及主要候选算法（如CRYSTALS-Kyber, SPHINCS+）。
   • 第五部分：企业应对策略（风险评估、迁移路径规划、混合方案）。
   • 第六部分：总结与展望。
   • 附录：关键术语表、参考文献。
3. 执行与评估循环：
   • 执行者撰写第一部分。规划者评估：概念解释清晰，但缺乏一个吸引人的开篇引语 ->NEEDS_REVISION。执行者补充一个生动的开篇案例。
   • 执行者撰写第二部分。规划者评估：技术细节准确，但图表描述过于文字化 ->NEEDS_REVISION。执行者将关键步骤用伪代码或流程图文字描述重新组织。
   • 执行者撰写第三部分。规划者评估：时间线分析引用了最新研究（如2023年论文），数据详实 ->PASS。
   • ... 规划者会检查每一部分的逻辑连贯性、数据准确性、与前后文的衔接。
4. 最终产出：一份结构严谨、内容详实、逻辑通顺的长篇技术报告。规划者充当了“主编”和“审稿人”的角色，确保了报告的整体质量。

4.3 场景三：多步骤业务流程自动化

例如，自动化处理客户支持请求并生成知识库条目。

1. 用户输入终极目标：“分析最近的客户邮件，提取常见问题，并为其生成标准化的解答文档和知识库文章草稿。”
2. 规划者行动：
   • 步骤1：读取指定邮箱文件夹的客户邮件（模拟或通过API）。
   • 步骤2：对邮件内容进行聚类分析，识别出3-5个最频繁出现的问题主题。
   • 步骤3：为每个主题总结核心问题点、客户痛点和现有回复模式。
   • 步骤4：为每个主题撰写一份结构化的FAQ解答（问题描述、原因分析、解决方案、相关链接）。
   • 步骤5：将FAQ格式化为适合导入公司知识库的Markdown文档。
   • 步骤6：生成一份执行摘要，汇报发现的主要问题类别和建议的解决方案。
3. 执行与评估循环：
   • 执行者调用邮件API（工具调用）获取数据。规划者评估：数据获取成功，样本量足够 ->PASS。
   • 执行者进行文本聚类分析。规划者评估：聚类结果（如“登录问题”、“账单疑问”、“功能请求”）合理，但“功能请求”类别过于宽泛 ->NEEDS_REVISION。执行者根据规划者建议，使用更细的关键词进行二次聚类。
   • 执行者撰写FAQ。规划者评估：解答准确，但语气过于技术化，不符合客户支持文档的友好风格 ->NEEDS_REVISION。执行者调整语气，加入更多示例和同理心表达。
4. 最终产出：一套分类清晰、解答准确、风格统一的客户支持知识库草稿，以及一份给管理层的分析报告。

5. 常见问题、挑战与优化策略

在实际构建和运行此类递归AI系统时，会遇到一系列特有的挑战。以下是我在实验过程中遇到的一些典型问题及应对策略。

5.1 规划者的“幻觉”与计划不切实际

问题描述：规划者Claude有时会生成过于理想化或忽略实际约束的计划。例如，在软件开发任务中，它可能要求执行者“集成一个不存在的第三方库”，或者规划了一个在技术上不可行或顺序错误的步骤流。

排查与解决：

1. 增强系统提示词的约束：在给规划者的提示词中，明确加入现实约束。例如：“请确保你规划的每一步都是当前技术环境下可实现的。避免使用假设的、未发布或不存在的工具、库或API。考虑步骤之间的依赖关系，基础设置（如环境配置）应排在前面。”
2. 引入“可行性检查”步骤：在规划者生成初步计划后，可以插入一个由执行者（或另一个专门的“验证者”角色）进行的快速可行性检查。例如，让执行者模拟执行计划的第一步，如果立即遇到无法解决的错误（如“pip install unknown-package”失败），则将该信息反馈给规划者要求重新规划。
3. 人工种子计划或模板：对于非常复杂的任务，可以先由人类提供一个高层次的任务分解框架（大纲），然后让规划者在这个框架内填充具体指令。这能有效引导规划方向，减少“天马行空”的情况。

5.2 执行者对指令的理解偏差

问题描述：执行者可能错误理解了规划者的指令，导致产出偏离预期。例如，指令是“创建一个函数计算平均值”，执行者可能只创建了函数但未编写调用示例，或者使用了错误的数据结构。

排查与解决：

1. 指令的原子化与明确化：要求规划者生成的指令必须尽可能原子化、无歧义。使用“SMART”原则（具体、可衡量、可达成、相关、有时限）来审视指令。好的指令示例：“编写一个Python函数calculate_mean(numbers: List[float]) -> float，它接收一个浮点数列表，返回其算术平均值。请包含函数定义、docstring和一个使用示例print(calculate_mean([1.0, 2.0, 3.0]))。”
2. 增加“指令-产出”对齐度评估：在规划者的评估标准（criteria）中，必须包含对“是否严格遵循指令”的检查。评估提示词可以设计为：“请严格对照步骤指令，逐条检查产出是否满足了指令中的每一项要求。列出所有符合和不符合的点。”
3. 迭代澄清机制：当评估结果为“NEEDS_REVISION”且原因是理解偏差时，协调器不应简单地让执行者重做，而应首先将偏差反馈给规划者，请求它生成一份更清晰、更详细的修正指令，再交给执行者。这比让执行者盲目重试更有效。

5.3 上下文长度限制与历史管理

问题描述：Claude模型有上下文窗口限制（例如200K tokens）。在长任务循环中，完整的对话历史（规划、执行、评估多次迭代）很容易超出限制，导致模型“遗忘”早期信息。

排查与解决：

1. 选择性上下文窗口：不是将所有历史消息都塞进每一次API调用。协调器需要智能地维护一个“摘要”或“关键信息”缓冲区。
   • 对规划者：主要提供任务终极目标、当前计划、最近几步的详细历史和高度总结的早期步骤。
   • 对执行者：主要提供当前步骤的详细指令、直接相关的上一步产出，以及整个任务的极简摘要（一两句话）。
2. 自动摘要生成：在历史记录达到一定长度后，可以调用Claude（可以是一个轻量模型）对之前的对话历史生成一个简洁、信息丰富的摘要。在后续的交互中，用这个摘要替代冗长的原始历史。这本质上是在模仿人类的“工作记忆”。
3. 向量数据库存储与检索：对于超长任务，可以将每一步的输入输出（指令、产出、评估）作为文档存入向量数据库（如Chroma, Pinecone）。当需要为当前步骤提供上下文时，根据当前指令从向量库中检索最相关的历史片段，而不是按时间顺序提供所有历史。这实现了基于语义的“记忆”检索。

5.4 成本控制与循环失控

问题描述：递归调用两个Claude实例，尤其是使用高性能模型（如Claude 3 Opus），成本增长很快。更危险的是，如果系统陷入“规划-失败-重新规划”的死循环，会产生大量无意义的API调用，导致不必要的开销。

排查与解决：

1. 模型选型策略：并非所有角色都需要最强大的模型。
   • 规划者：需要较强的推理和分解能力，建议使用claude-3-sonnet或claude-3-opus。
   • 执行者：对于大多数具体执行任务（写代码、总结文本），claude-3-haiku或claude-3-sonnet通常已足够，成本更低，速度更快。
   • 评估者：评估工作相对简单，完全可以与规划者共用同一个实例，或在提示词中明确切换角色。甚至可以尝试用更便宜的模型（如GPT-3.5-Turbo）进行初步评估。
2. 设置循环安全阀：
   • 最大迭代次数：如上面代码示例中的max_iterations，必须设置一个硬性上限。
   • 相同步骤失败阈值：如果同一个步骤连续失败（如评估不通过）超过N次（例如3次），则终止任务并报错，提示需要人工干预。
   • 预算监控：在协调器中集成简单的成本计算器，估算每次API调用的token消耗和费用，当接近预算阈值时发出警告或暂停。
3. “人工介入”检查点：对于关键决策点（如计划首次生成后、重大步骤开始前、连续失败后），可以设计流程暂停，并将当前状态和选项输出给用户，等待用户确认或选择。这实现了人机协同，既能利用AI自动化，又能防止完全失控。

5.5 评估的主观性与不一致性

问题描述：规划者对执行结果的评估本身也可能出现“幻觉”或不一致。比如，对一份代码的评估，第一次说“逻辑正确”，第二次又说“存在边界条件错误”。

排查与解决：

1. 量化评估标准：在规划阶段，就要求规划者为每个步骤制定尽可能量化的criteria。例如，不是“代码运行正确”，而是“函数能处理空列表输入返回0，能处理正常列表返回正确平均值，并通过了附带的3个测试用例”。
2. 引入客观验证机制：对于可以客观验证的产出（如代码、数学答案），协调器应优先采用客观验证，而非完全依赖规划者的主观评估。
   • 代码：尝试在安全沙箱中实际运行。
   • 数学问题：用计算库进行验算。
   • 事实查询：可以调用搜索工具进行交叉验证。 将客观验证结果作为评估的重要输入，甚至替代主观评估。
3. 多数裁决或高级模型裁决：对于重要的评估，可以让规划者进行多次评估（每次用不同的随机种子），或者引入第三个“仲裁者”Claude实例（使用更高阶的模型）对存在争议的评估进行最终裁定。虽然增加了成本，但提高了决策的可靠性。

构建一个稳定、高效、经济的“Claude_on_Claude”系统，是一个需要不断调试和权衡的过程。它不仅仅是一个技术集成项目，更像是在设计一个具有初级“元认知”能力的AI工作流引擎。每一次失败和调试，都让我们对如何让大语言模型更好地协作、思考、自我纠正有了更深的理解。