1. 项目概述当AI实验员学会“记笔记”最近在折腾AI智能体Agent做自动化实验时我被一个看似简单却极其烧钱的问题卡住了让Agent去读一篇学术论文然后基于论文内容设计后续的实验步骤。传统的“读取-思考-行动”ReAct模式每次执行新步骤时都会把之前的对话历史和论文内容重新塞进上下文Context里。这就好比让一个实验员每做一步新操作就得把实验记录本从头到尾再念一遍。论文动辄几千上万token几个回合下来API调用成本直接起飞上下文窗口也很快被塞满实验被迫中断。这不仅仅是成本问题更是效率瓶颈。真正的科研人员或工程师在连续实验时靠的是大脑里的“工作记忆”和实验记录本上的“状态摘要”而不是反复阅读原始文献。于是“Remember, Don‘t Re-read”记住别重读这个想法应运而生。它本质上是在构建一个有状态的、令牌高效的自主实验智能体。核心目标就一个让AI像人一样在长期、多步骤的任务中只记住关键的状态和结论而不是背负着所有原始数据的“全量记忆”从而实现低成本、可持续的自动化探索。这个项目结合了ReAct的推理行动框架、LangGraph的图状态管理能力以及针对“自主实验”场景的定制化设计。它不是为了取代研究者而是成为一个不知疲倦、严格遵循流程、且能极大节约计算成本的“AI实验助理”。接下来我会拆解这个架构的每一个核心环节分享从零搭建过程中踩过的坑和最终验证有效的方案。2. 核心架构与设计思路拆解2.1 为什么是“状态化”的ReAct经典的ReActReasoning Acting模式是一个循环观察 - 思考 - 行动 - 观察。在LangChain或LlamaIndex的早期实现中这个循环通常是无状态的Stateless。意味着每一轮循环智能体收到的“观察”都需要包含之前所有步骤的完整历史记录和初始知识比如那篇论文。这导致了两个致命问题令牌膨胀历史记录像滚雪球一样越滚越大每次调用大语言模型LLM的提示词Prompt都变得更长、更昂贵。上下文窗口限制即使你不在乎钱主流LLM的上下文窗口也有上限如128K。对于需要几十甚至上百个步骤的复杂实验流程很容易触及天花板。“状态化”的核心理念是将智能体的“记忆”外置。我们不再把历史对话全部放进Prompt而是维护一个独立于LLM调用的状态对象State Object。这个状态对象只保存精炼后的、对后续步骤真正有用的信息例如当前实验进行到哪一步、已得到的关键数据结果、根据之前观察推导出的假设或规则。注意这里的状态不是聊天历史而是任务本身的进展摘要。比如在化学实验场景中状态可能包括“已混合A和B试剂观察到放热现象溶液变黄pH值降至5。下一步计划测试加入C试剂后的反应”。2.2 LangGraph 如何成为状态管理的“中枢神经系统”LangGraph 是 LangChain 框架中用于构建有状态、多智能体工作流的库。它基于图Graph的概念将工作流中的每个步骤定义为一个节点Node节点之间的连线Edge由条件逻辑决定流向。其状态管理State机制是本项目的基石。在LangGraph中我们定义一个State类它本质上是一个类型化的字典TypedDict。对于自主实验场景我设计的State通常包含以下核心字段from typing import TypedDict, List, Annotated import operator class AgentState(TypedDict): # 输入与目标 input_document: str # 初始输入如论文摘要 overall_goal: str # 实验总目标 # 核心状态 current_step: int # 当前步骤序号 completed_steps: List[str] # 已完成的步骤描述列表 key_findings: List[str] # 从已完成的步骤中提炼的关键发现 hypothesis: str # 当前的工作假设 # 工作记忆与上下文 working_memory: Annotated[list, operator.add] # 用于累积临时信息的“便签” # 输出与决策 next_action: str # 由“思考”节点决定的下一步动作 observation: str # 执行动作后得到的观察结果 is_finished: bool # 任务是否完成标志关键设计解析working_memory使用了Annotated[list, operator.add]。这是LangGraph的一个高级特性它声明这个字段是一个列表且当多个节点并行修改它时修改方式为“追加”add。这非常适合用来累积实验过程中的临时数据、错误信息或中间计算结果。key_findings和hypothesis是“精炼记忆”的体现。它们不是原始观察的堆砌而是经过LLM提炼后的结构化信息是避免“重读”的关键。next_action和observation构成了ReAct的单步循环但它们被存储在状态中而不是对话历史里。2.3 自主实验工作流的图结构设计基于上述State我们在LangGraph中构建一个闭环工作流。这个图通常包含以下几个关键节点它们按顺序或条件执行路由节点Router检查AgentState决定下一步是进入“思考”、“行动”还是“总结”节点。例如如果observation为空刚开始则路由到“思考”如果next_action已定义且非空则路由到“行动”。思考节点Reasoning Node这是智能体的“大脑”。它接收当前的State包含目标、已完成步骤、关键发现等调用LLM进行推理输出两样东西一是对next_action的详细描述二是对hypothesis或key_findings的更新。关键在于这个节点的Prompt只接收State中的精炼信息而不是完整的原始文档和历史。行动/实验节点Action/Experiment Node根据next_action的描述执行具体操作。在模拟环境中这可能是一个函数调用用于计算、查询数据库或调用模拟器API在真实世界集成中这可能控制实验仪器。执行后将结果写入observation。提炼与更新节点Update Node这是实现“记住”而非“重读”的核心。在获得新的observation后此节点调用一个轻量级的LLM或同一个LLM的简化Prompt将observation与现有的key_findings、hypothesis融合生成更新后的、更精炼的摘要。这个过程就像实验员在记录本上更新“实验结论”栏而不是誊抄所有原始数据。判断节点Condition Node检查任务是否完成例如current_step达到上限或observation表明实验成功/失败更新is_finished从而决定工作流是继续循环还是结束。这个有向图结构确保了信息流动是高效、有状态的。原始的长文档只在初始化时被完整读取一次并转化为初始的overall_goal和key_findings。之后的所有推理都基于不断演进的、紧凑的State进行。3. 核心组件实现与令牌效率优化实战3.1 状态初始化与文档的“首轮消化”项目启动的第一步是如何处理那篇冗长的输入文档比如一篇30页的PDF论文。我们不能直接把它扔进State因为那会立刻占用大量令牌。我的做法是设计一个“初始化处理器”。这个处理器是一个独立的LLM调用链其任务是对长文档进行目的性摘要。Prompt会明确指示“你是一名科研助理请从以下文档中提取出与[实验领域如‘合成新型聚合物电解质’]直接相关的核心目标、可用方法、关键参数和已知结论。输出格式为JSON包含‘goal’ ‘methods’ ‘constraints’ ‘initial_hypothesis’四个字段。”from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI def initialize_state_from_document(full_document: str, domain: str) - dict: 初始化处理器将长文档消化为结构化状态摘要。 init_prompt ChatPromptTemplate.from_messages([ (system, 你是一个专业的科研摘要助手。你的任务是从技术文档中提取实验相关的核心信息忽略背景介绍、长篇论述和无关细节。), (human, 文档内容{doc}\n\n请聚焦于‘{domain}’领域提取以下JSON信息\n1. goal: 文档中描述的核心实验目标或待验证的科学问题。\n2. methods: 提到的关键实验方法或技术路径列出不超过5项。\n3. constraints: 实验条件限制或注意事项如温度范围、材料禁忌。\n4. initial_hypothesis: 基于文档可以提出的一个初始可测试假设。) ]) llm ChatOpenAI(modelgpt-4-turbo-preview, temperature0.1) chain init_prompt | llm # 这里使用支持JSON输出的LLM或让LLM输出文本后再用解析器提取JSON result chain.invoke({doc: full_document[:8000], domain: domain}) # 可截取部分以节省令牌 # 解析result.content中的JSON返回字典 extracted_info json.loads(result.content) return extracted_info通过这一步一篇上万token的文档被压缩成一个几百token的结构化摘要。这个摘要将成为AgentState中overall_goalkey_findings初始方法和hypothesis的初始值。这是令牌效率提升的第一个数量级。3.2 思考节点基于精炼状态的推理思考节点的Prompt设计是第二个关键。它必须引导LLM仅基于State做出决策。def reasoning_node(state: AgentState): 思考节点分析当前状态决定下一步行动。 # 构建仅包含精炼信息的Prompt prompt_template ChatPromptTemplate.from_messages([ (system, 你是一个自主实验AI。你正在执行一个分步骤的实验计划。你拥有以下记忆摘要和当前状态。请严谨推理决定下一步最该做什么实验动作。 重要原则你的思考必须严格基于下方提供的“当前状态摘要”不要引入外部知识或回忆原始文档全文。), (human, ## 实验总目标 {goal} ## 当前状态摘要 - 已完成步骤{completed_steps} - 关键发现{findings} - 当前工作假设{hypothesis} - 最新观察{latest_obs} ## 你的任务 请输出一个具体的、可执行的下一步实验动作描述。动作应直接服务于验证或推进“当前工作假设”。 如果根据现有发现假设已被证实或证伪请提出调整假设后的新动作。 如果实验目标已达成或已证明不可行请输出“任务完成”。 请用以下JSON格式回复 {{ reasoning: 你的简要推理过程, next_action: 具体的动作描述例如将反应体系加热至80°C维持30分钟并每分钟记录溶液颜色变化。 或 任务完成, updated_hypothesis: 根据推理更新后的假设如果无需更改则写‘保持不变’ }} ) ]) # 从State中提取信息 messages prompt_template.format_messages( goalstate[overall_goal], completed_steps; .join(state[completed_steps][-3:]), # 只取最近3步防止过长 findings; .join(state[key_findings]), hypothesisstate[hypothesis], latest_obsstate.get(observation, 无) ) llm ChatOpenAI(modelgpt-4o, temperature0.2) # 使用能力更强的模型进行关键推理 response llm.invoke(messages) # 解析响应更新State try: decision json.loads(response.content) state[next_action] decision[next_action] # 如果假设有更新则覆盖旧的 if decision[updated_hypothesis] ! 保持不变: state[hypothesis] decision[updated_hypothesis] state[working_memory].append(fReasoning: {decision[reasoning]}) except json.JSONDecodeError: # 错误处理如果LLM没有返回合规JSON设置一个默认动作 state[next_action] 暂停解析推理结果失败。 state[working_memory].append(fLLM响应解析失败: {response.content[:200]}) return state这个设计的精髓在于“信息节流”。completed_steps只展示最近几步key_findings始终是摘要列表。这确保了每次调用LLM的Prompt长度基本稳定不会随实验步骤增加而增长。3.3 状态更新节点实现“记忆进化”行动节点执行后会产生新的observation可能是一段数据文本。状态更新节点的任务是将这个新的、原始的observation“消化”进精炼的key_findings中。def update_state_node(state: AgentState): 更新节点整合新观察精炼关键发现。 if not state.get(observation): return state # 使用一个更便宜、更快的模型来做摘要提炼工作 summarizer_llm ChatOpenAI(modelgpt-3.5-turbo, temperature0) update_prompt ChatPromptTemplate.from_messages([ (system, 你是实验记录员。请将新的实验观察整合到已有的关键发现列表中提炼出最核心的信息点去除冗余和无关细节。保持列表简洁每条发现不超过15个单词。), (human, 已有关键发现 {existing_findings} 新的实验观察 {new_observation} 请执行以下操作 1. 理解新观察。 2. 判断它是否证实、否定或补充了已有发现。 3. 输出一个**更新后的**关键发现列表JSON数组格式。列表应合并新旧信息保持条目数量在5条以内按重要性排序。 示例输出[发现A, 发现B与C相关, 在条件X下现象Y出现] ) ]) chain update_prompt | summarizer_llm update_result chain.invoke({ existing_findings: \n.join(state[key_findings]), new_observation: state[observation] }) try: updated_findings json.loads(update_result.content) # 确保是列表且不过长 if isinstance(updated_findings, list): state[key_findings] updated_findings[:5] # 强制限制在5条以内 else: state[key_findings].append(f整合更新失败: {update_result.content[:100]}) except: # 如果解析失败将新观察简单摘要后追加 state[key_findings].append(f新观察: {state[observation][:100]}...) # 清空observation为下一轮做准备 state[observation] state[current_step] 1 state[completed_steps].append(state.get(next_action, )) state[next_action] # 清空等待思考节点填充 return state这个节点是令牌效率的守护神。它确保key_findings这个最重要的记忆载体始终保持精简和高质量。使用gpt-3.5-turbo这类更经济的模型来完成这个“消化”工作是成本控制上的一个实用技巧。3.4 图的工作流组装与条件路由最后我们用LangGraph将上述节点组装起来并定义它们之间的流转逻辑。from langgraph.graph import StateGraph, END # 1. 创建图 workflow StateGraph(AgentState) # 2. 添加节点 workflow.add_node(router, routing_node) # 路由节点判断下一步 workflow.add_node(reason, reasoning_node) workflow.add_node(act, experiment_action_node) # 行动节点调用工具 workflow.add_node(update, update_state_node) workflow.add_node(summarize, final_summary_node) # 最终总结节点 # 3. 设置入口点 workflow.set_entry_point(router) # 4. 定义条件边Conditional Edges def decide_next_step(state: AgentState) - str: 路由逻辑根据state决定下一个节点 if state.get(is_finished): return summarize # 如果完成进入总结 if not state.get(next_action): return reason # 如果无下一步动作需要思考 if state.get(next_action) and not state.get(observation): return act # 如果有动作但未执行需要行动 if state.get(observation): return update # 如果有新观察需要更新状态 return reason # 默认返回思考 # 5. 添加带条件的边 workflow.add_conditional_edges( router, decide_next_step, { reason: reason, act: act, update: update, summarize: summarize } ) # 6. 添加固定顺序的边在条件边之后执行 workflow.add_edge(reason, router) # 思考完后返回路由器决定是行动还是其他 workflow.add_edge(act, router) # 行动完后返回路由器此时有了observation workflow.add_edge(update, router) # 更新状态后返回路由器开始下一轮思考 workflow.add_edge(summarize, END) # 总结后结束 # 7. 编译图 app workflow.compile()这个图结构形成了一个高效的自治循环router - reason - (router -) act - router - update - router - reason - ...直到is_finished被置为True流向summarize并结束。整个过程中长上下文数据被隔离在初始化和更新节点中核心的reason节点始终处理轻量的State实现了“记住不重读”。4. 性能评估、成本分析与实战避坑指南4.1 令牌消耗对比传统ReAct vs. 状态化ReAct为了量化收益我设计了一个基准测试让智能体阅读一篇关于“催化剂筛选”的模拟论文约5000 token然后规划并执行10个模拟实验步骤。传统无状态ReAct每个步骤的Prompt都包含完整的论文内容全部对话历史。10个步骤后累计发送给LLM的Prompt token超过60,000。状态化ReAct本方案初始化摘要消耗约800token一次性。每个思考步骤Prompt仅包含精炼State平均1200token/步。每个更新步骤消耗约500token/步使用gpt-3.5-turbo。总计10步800 10 * 1200 10 * 500 20,800token。结果状态化方案节省了约65%的输入token。如果使用GPT-4等按token计费的高阶模型成本节约效果将非常显著。更重要的是它完全避免了因上下文窗口限制而导致任务中断的风险。4.2 常见问题与排查技巧实录在实际搭建和运行中我遇到了以下几个典型问题及解决方案问题1状态污染与信息丢失现象智能体在运行多步后做出与早期关键发现相矛盾的决策仿佛“忘记”了之前的重要结论。根因key_findings在更新节点被过度概括或错误覆盖。例如更新Prompt过于激进地要求“合并相似项”导致两条互补但不同的发现被合并成一条模糊的信息。解决方案强化更新节点的Prompt明确指令“不要丢失任何已证实的独特发现。合并仅适用于描述同一现象的不同表述。”引入版本控制或权重为每条key_finding添加一个“置信度”或“被引用次数”字段。在更新时优先保留高权重发现。设置“不可变核心发现”列表将最初从文档中提取的、或实验早期验证的核心约束如“反应温度不得超过100°C”放入一个单独的core_constraints列表该列表在更新节点只增不减。问题2思考节点“脱离状态”天马行空现象智能体提出的next_action完全基于其内部知识而忽略了State中已有的hypothesis和key_findings。根因思考节点的Prompt指令不够强硬或者State中提供的信息格式不易被LLM关联使用。解决方案在Prompt中使用“强制关联”句式例如“你必须基于‘当前工作假设{hypothesis}’来设计下一步动作。动作的目的必须是直接验证或否定这个假设。”结构化State输入不用自然语言段落描述State而改用更结构化的方式如[实验目标]{goal} [待验证假设]{hypothesis} [支持证据]{findings} [矛盾证据]{contradictions}在working_memory中记录偏离警告如果LLM的reasoning字段明显没有提及State中的关键信息可以在working_memory中添加一条警告并在下一轮思考时将该警告也纳入Prompt提醒智能体。问题3循环无法终止或提前终止现象实验陷入无限循环重复相似动作或在未达成目标时过早标记is_finished为True。根因终止条件Condition设计不合理。可能只依赖current_step上限而缺乏对任务实质进展的判断。解决方案设计多维度终止条件在判断节点中综合评估current_step max_steps步骤上限hypothesis是否已被明确证实或证伪可通过分析最近几次observation与hypothesis的相关性判断key_findings中是否出现了“目标达成”或“路径不可行”的结论性语句可通过关键词匹配或轻量级LLM判断引入“死循环”检测在working_memory中记录最近5个next_action。如果检测到高度重复的模式则强制注入一条新的observation“检测到动作循环请重新评估假设或尝试替代方案。”设置“人工审核点”对于关键步骤如第5步、第10步可以设计一个节点将当前State摘要输出给用户或另一个审核Agent请求继续或终止的指令。这在高风险或高成本的真实实验中非常必要。问题4更新节点成为性能瓶颈或错误源现象更新节点调用的LLM如gpt-3.5-turbo有时会产生低质量摘要甚至输出格式错误的JSON导致状态损坏。根因用于摘要的模型能力不足或Prompt对格式的要求不够鲁棒。解决方案降级使用与格式加固如果使用能力稍弱的模型Prompt中必须包含极其明确的格式示例并加入“如果无法整合请原样返回已有发现列表”的兜底指令。实现解析重试机制捕获JSON解析异常并尝试用更简单的规则如按行分割、提取引号内内容进行二次提取。关键步骤使用更强模型在实验的里程碑步骤如每5步可以切换回更可靠的模型如GPT-4进行一次高质量的“状态回顾与整理”修正可能累积的摘要误差。4.3 进阶优化与扩展思路在基础框架跑通后可以考虑以下方向进行深化分层记忆系统将State中的记忆分为“工作记忆”短期高细节、“实验记忆”中期精炼发现和“知识记忆”长期从多次实验中抽象出的规则。不同层级的记忆以不同频率和粒度被访问与更新。工具调用Tool Calling的集成将next_action直接映射到预定义的工具函数。例如动作描述“计算pH值”触发一个calculate_ph(data)函数。LangGraph与LangChain Tool的集成非常顺畅这能让智能体真正操作模拟软件或数据库。多智能体协作实验利用LangGraph原生支持多智能体的特性可以创建“规划者”、“执行者”、“分析者”等角色智能体。它们共享一个全局State但各有专精通过图进行协作适合更复杂的实验流程。人类在环Human-in-the-loop在图的特定节点如路由节点或更新节点后设置检查点将State的可视化摘要发送给人类研究者审批。人类可以修正hypothesis、否决不合理的next_action或直接注入指导实现人机混合智能。搭建“Remember, Don‘t Re-read”智能体的过程是一个在有限资源令牌、上下文下追求无限可能自主性、复杂性的典型工程挑战。它的价值不仅在于节省了API调用费用更在于为构建能够处理长周期、多步骤复杂任务的可靠AI智能体提供了一个可扩展的状态管理范式。从简单的文档分析实验到复杂的模拟计算流程这个框架都能通过保持记忆的“高营养密度”让智能体持续、高效地运转下去。