1. 项目概述当LangChain遇上DeepAgent智能体开发的新范式最近在开源社区里一个名为langchain-ai/deepagents的项目引起了我的注意。作为一名长期关注AI应用落地的开发者我习惯性地去GitHub上“挖宝”而这个项目恰好戳中了当前AI领域的一个核心痛点如何让大语言模型LLM驱动的智能体Agent变得更“深”、更可靠、更贴近真实业务场景。简单来说deepagents不是一个孤立的工具它是LangChain生态体系下对“智能体”这一概念的一次深度探索和工程化实践。如果你正在为构建的AI助手总是“一本正经地胡说八道”、无法处理复杂多步任务、或者状态管理混乱而头疼那么这个项目背后的设计思路和实现细节或许能给你带来不少启发。传统的基于提示词Prompt的对话模型更像是一个“即时反应者”它根据当前对话历史生成回复但缺乏对长期目标、内部状态和复杂决策流程的显式管理。而智能体Agent的引入旨在赋予LLM“思考”和“行动”的能力使其能够调用工具Tools、规划步骤Plan、并在与环境Environment的交互中学习演进。deepagents项目正是在这个背景下由LangChain团队推出它试图提供一套更结构化、更可观测、也更易于调试的智能体开发框架。其核心价值在于它将智能体从简单的“工具调用器”升级为具备深度推理、状态持久化和复杂工作流处理能力的“深度执行者”。这个项目适合三类人一是正在使用LangChain构建AI应用的开发者它能极大提升你智能体的能力上限二是对AI智能体架构设计感兴趣的研究者或工程师它的源码是绝佳的学习材料三是任何希望将AI深度集成到复杂业务流程如客户支持自动化、数据分析流水线、游戏NPC等中的团队deepagents提供了一套经过深思熟虑的工程范式。接下来我将结合自己的理解和实践深入拆解这个项目的核心设计、关键技术实现以及如何将其应用到实际场景中。2. 核心架构与设计哲学解析2.1 从“链”到“深度智能体”的演进逻辑要理解deepagents必须先回顾LangChain的基础单元——“链”Chain。链是将LLM与其他组件如提示词模板、记忆、工具连接起来的一种可执行序列。它解决了单次调用的局限性但面对需要循环、分支、状态维护和长期规划的复杂任务时链的线性结构就显得力不从心。deepagents的设计哲学可以概括为“状态显式化、决策结构化、执行可观测”。首先状态显式化。一个强大的智能体必须清楚自己“身处何境”、“目标为何”以及“已经做了什么”。deepagents引入了明确的状态管理机制。这个状态State对象不再是隐藏在对话历史里的模糊上下文而是一个结构化的数据容器它可能包含当前任务目标、已收集的信息、执行历史记录、环境反馈、乃至智能体自身的“信念”Beliefs。这种设计使得智能体的内部过程变得透明且可持久化你可以随时检查、保存或加载一个智能体的状态这对于长周期任务和故障恢复至关重要。其次决策结构化。传统的Agent往往依靠一个庞大的提示词来让LLM决定“下一步做什么”这种方式不稳定且难以调试。deepagents将决策过程分解为更细粒度的阶段或“子智能体”。例如一个完整的任务处理流程可能被结构化为目标解析 - 计划生成 - 工具选择 - 参数提取 - 执行 - 结果评估 - 状态更新。每个阶段都可以由专门的、配置更精准的LLM调用或逻辑模块来处理。这大大降低了单次提示的复杂性提高了决策的可靠性和可解释性。最后执行可观测。这是工程化的关键。deepagents强调对整个智能体生命周期从状态初始化到最终输出的全面追踪Tracing。每一次LLM调用、每一个工具执行、每一次状态变更都应该被记录并可以回溯。这不仅是为了调试更是为了分析和优化智能体的行为。你可以清晰地看到智能体在哪一步消耗了最多的Token哪个工具调用失败了状态是如何一步步演变的这种可观测性是构建生产级可靠AI应用的基石。2.2 深度智能体的核心组件与协作关系在deepagents的架构中几个核心组件各司其职共同协作。理解它们的关系是灵活运用的前提。1. 状态State与状态转换器State Transformer状态是智能体的“记忆中枢”。它是一个字典-like的对象但其结构可以通过Pydantic模型进行严格定义确保类型安全。状态转换器则是驱动状态演进的核心引擎。它定义了如何根据当前的输入如用户查询、工具执行结果和当前状态计算出下一个状态。这通常是一个函数或一个可调用对象内部可以封装LLM调用、规则判断或数据处理逻辑。deepagents鼓励开发者将复杂的逻辑拆分成多个小的、可测试的状态转换器然后通过编排Orchestration将它们组合起来。2. 工具Tools与执行器Executor工具是智能体与外界交互的“手脚”。deepagents完全兼容LangChain丰富的工具生态如网络搜索、代码执行、数据库查询等。执行器负责调用工具并处理结果。deepagents的进阶之处在于它可能提供了更精细的工具调用控制例如工具调用前的参数验证、调用时的超时和重试机制、调用后的结果格式化与过滤。这确保了工具使用的稳定性和安全性。3. 规划器Planner与控制器Controller这是实现“深度”思考的关键。规划器负责审视当前状态和最终目标生成一个或多个后续步骤的计划Plan。这个计划可能是一个简单的工具调用序列也可能是一个包含条件分支的复杂流程图。控制器则负责执行这个计划协调各个状态转换器和工具执行器并处理执行过程中出现的异常如工具失败、计划偏离预期。在某些高级模式中规划器和控制器本身也可能是由LLM驱动的智能体形成一种“元认知”结构。4. 观察者Observer与追踪器Tracer这是实现“可观测性”的组件。观察者以钩子Hooks的形式嵌入到智能体执行的各个关键节点如状态变更前/后、工具调用前/后、LLM调用前/后收集运行时数据。追踪器则负责将这些数据持久化到后端如控制台、文件、或专门的APM系统形成完整的执行轨迹。这对于性能分析、成本监控和行为审计必不可少。注意deepagents并非要完全取代LangChain原有的Agent概念而是提供了一套更强大、更工程化的上层建筑。你可以将它视为构建“企业级”或“任务关键型”智能体的首选框架而对于简单的、一次性的工具调用任务使用基础的LangChain Agent可能更轻量快捷。3. 实战构建一个深度数据分析智能体理论说得再多不如动手实践。假设我们要构建一个“深度数据分析智能体”它的任务是接收用户用自然语言提出的复杂数据分析请求例如“帮我分析过去三个月销售数据找出表现最好的三个产品类别并预测下个月的趋势”然后自动完成从数据查询、清理、分析到可视化报告生成的全流程。3.1 环境搭建与项目初始化首先确保你的Python环境建议3.9以上并安装核心依赖。deepagents可能仍在快速迭代中建议从GitHub仓库安装最新开发版本同时安装常用的数据分析库。# 克隆仓库并安装假设从langchain-ai组织下 git clone https://github.com/langchain-ai/deepagents.git cd deepagents pip install -e . # 安装额外依赖 pip install pandas numpy matplotlib seaborn scikit-learn openpyxl pip install langchain-openai # 假设使用OpenAI的模型 pip install python-dotenv # 用于管理API密钥接下来初始化你的项目结构。一个清晰的结构有助于管理复杂的智能体逻辑。deep_analysis_agent/ ├── agents/ │ ├── __init__.py │ ├── analysis_agent.py # 主智能体定义 │ └── planners/ # 规划器模块 ├── tools/ │ ├── __init__.py │ ├── data_fetcher.py # 数据获取工具 │ ├── data_cleaner.py # 数据清洗工具 │ └── visualizer.py # 可视化工具 ├── state/ │ ├── __init__.py │ └── models.py # 用Pydantic定义状态结构 ├── config.py # 配置如API密钥、模型设置 ├── main.py # 应用入口 └── .env # 环境变量勿提交在.env文件中设置你的OpenAI API密钥OPENAI_API_KEYyour_key_here3.2 定义结构化状态与核心工具智能体的“大脑”需要清晰的数据结构。我们在state/models.py中定义状态。from pydantic import BaseModel, Field from typing import Optional, List, Dict, Any from datetime import datetime class AnalysisState(BaseModel): 数据分析智能体的核心状态 # 输入与目标 user_query: str Field(description用户的原始自然语言查询) parsed_objective: Optional[str] Field(defaultNone, description解析后的明确目标) # 数据层 raw_data: Optional[Any] Field(defaultNone, description获取的原始数据可能是DataFrame或路径) cleaned_data: Optional[Any] Field(defaultNone, description清洗后的数据) analysis_results: Optional[Dict[str, Any]] Field(defaultNone, description中间分析结果如统计指标) # 执行过程 current_plan: Optional[List[str]] Field(defaultNone, description当前执行计划步骤列表) completed_steps: List[str] Field(default_factorylist, description已完成的步骤) execution_log: List[Dict] Field(default_factorylist, description详细的执行日志) # 输出 final_report: Optional[str] Field(defaultNone, description最终生成的报告文本) chart_paths: Optional[List[str]] Field(defaultNone, description生成的可视化图表文件路径) # 元信息 created_at: datetime Field(default_factorydatetime.now) error: Optional[str] Field(defaultNone, description执行过程中发生的错误信息)接下来实现几个关键工具。以tools/data_fetcher.py为例from langchain.tools import BaseTool from pydantic import Field import pandas as pd import os class DataFetcherTool(BaseTool): name fetch_sales_data description 从指定数据源如CSV文件、数据库、API获取销售数据。输入应为数据源标识符例如 local:./data/sales_q2.csv 或 api:recent_3_months. def _run(self, data_source: str) - pd.DataFrame: 执行数据获取逻辑 # 这里是一个简化示例实际中可能连接数据库或调用内部API if data_source.startswith(local:): filepath data_source.split(:)[1] if not os.path.exists(filepath): raise FileNotFoundError(f数据文件未找到: {filepath}) df pd.read_csv(filepath) return df elif data_source.startswith(api:): # 模拟API调用 # ... 实际调用代码 ... print(f[工具调用] 从API获取数据: {data_source}) # 返回模拟数据 return pd.DataFrame({ date: pd.date_range(start2024-01-01, periods90, freqD), product_category: [Electronics, Clothing, Home, Electronics, Clothing] * 18, sales_amount: [100, 150, 80, 120, 90] * 18 }) else: raise ValueError(f不支持的数据源格式: {data_source}) async def _arun(self, data_source: str): # 异步版本可根据需要实现 return self._run(data_source)类似地你可以创建DataCleanerTool处理缺失值、异常值、StatisticalAnalyzerTool计算指标、TrendPredictorTool简单时间序列预测和ReportVisualizerTool生成图表。每个工具都应具有清晰单一的职责和良好的错误处理。3.3 构建状态转换器与规划逻辑这是deepagents发挥威力的地方。我们不会把所有逻辑塞进一个巨大的提示词里而是拆解。首先创建一个解析用户目标的状态转换器在agents/analysis_agent.py中from langchain_openai import ChatOpenAI from deepagents import StateTransformer from state.models import AnalysisState import json class ParseObjectiveTransformer(StateTransformer): 将模糊的用户查询解析为明确、可执行的目标列表 def __init__(self, llm): self.llm llm async def transform(self, state: AnalysisState) - AnalysisState: prompt f 你是一个数据分析任务解析专家。请将用户的自然语言请求转化为结构化的、明确的任务目标。 用户请求: {state.user_query} 请以JSON格式输出包含以下字段 - primary_objective: 主要目标的一句话描述。 - sub_tasks: 一个字符串列表列出需要完成的子任务步骤例如[获取销售数据, 清洗数据, 按产品类别聚合销售额, 识别Top3类别, 进行趋势预测]。 - data_requirements: 所需的数据维度和时间范围。 - output_format: 期望的输出形式如文本报告折线图。 只输出JSON不要有其他任何解释。 try: response await self.llm.ainvoke(prompt) parsed json.loads(response.content) # 更新状态 state.parsed_objective parsed[primary_objective] # 初始计划就是子任务列表 state.current_plan parsed[sub_tasks] state.execution_log.append({ step: parse_objective, input: state.user_query, output: parsed, status: success }) except Exception as e: state.error f目标解析失败: {str(e)} state.execution_log.append({ step: parse_objective, input: state.user_query, error: str(e), status: failed }) return state然后我们需要一个规划器来动态决定下一步该执行哪个子任务以及调用哪个工具。这是一个更高级的状态转换器它根据当前状态已完成步骤、现有数据、是否出错来决定后续动作。class DynamicPlannerTransformer(StateTransformer): 动态规划器决定下一步执行哪个子任务 def __init__(self, llm, available_tools: dict): # tools映射任务名-工具实例 self.llm llm self.tools available_tools async def transform(self, state: AnalysisState) - AnalysisState: if state.error or not state.current_plan: return state # 有错误或无计划则停止 # 找出第一个未完成的子任务 pending_tasks [t for t in state.current_plan if t not in state.completed_steps] if not pending_tasks: state.execution_log.append({step: planning, info: 所有计划任务已完成}) return state next_task pending_tasks[0] # 这里可以加入更复杂的逻辑用LLM判断该任务是否需要特定工具或只是状态转换 # 简化示例根据任务名称映射到工具 tool_to_use None for key, tool in self.tools.items(): if key in next_task.lower(): tool_to_use tool break if tool_to_use: # 更新状态指示下一步要执行的任务和工具 state.metadata {next_action: {type: tool_call, task: next_task, tool: tool_to_use.name}} else: # 如果没有匹配的工具可能是一个纯逻辑步骤标记为完成或交由其他转换器处理 state.completed_steps.append(next_task) state.execution_log.append({step: planning, info: f任务{next_task}无需工具标记为完成}) return state3.4 组装智能体与执行循环最后我们将所有组件组装成完整的智能体并实现一个执行循环控制器。from deepagents import Agent from langchain_openai import ChatOpenAI import asyncio class DeepAnalysisAgent: def __init__(self, model_namegpt-4-turbo): self.llm ChatOpenAI(modelmodel_name, temperature0) # 初始化工具 self.tools { fetch: DataFetcherTool(), clean: DataCleanerTool(), visualize: ReportVisualizerTool() } # 初始化状态转换器管道 self.transformers [ ParseObjectiveTransformer(self.llm), DynamicPlannerTransformer(self.llm, self.tools), # 可以添加更多的转换器如数据验证、结果评估等 ] async def run(self, user_query: str) - AnalysisState: 执行智能体的主循环 # 1. 初始化状态 state AnalysisState(user_queryuser_query) print(f[智能体启动] 开始处理查询: {user_query}) # 2. 执行转换管道直到状态稳定或出错 max_iterations 20 # 防止无限循环 for i in range(max_iterations): state_before state.copy() for transformer in self.transformers: state await transformer.transform(state) if state.error: print(f[错误] 在第{i}轮迭代转换器{transformer.__class__.__name__}出错: {state.error}) return state # 检查是否有下一步动作需要执行由规划器设置 if hasattr(state, metadata) and state.metadata.get(next_action): action state.metadata[next_action] if action[type] tool_call: print(f[执行] 开始执行任务: {action[task]}, 使用工具: {action[tool]}) try: # 这里需要根据具体任务决定工具输入参数可以再通过一个LLM调用或规则来生成 tool_instance self.tools.get(action[tool]) if tool_instance: # 简化假设工具不需要复杂参数。实际中需要更精细的参数生成逻辑。 result await tool_instance._arun(api:recent_3_months) # 示例参数 # 根据工具结果更新状态例如将数据存入state.raw_data if action[tool] fetch_sales_data: state.raw_data result state.completed_steps.append(action[task]) state.execution_log.append({ step: action[task], tool: action[tool], result_summary: f成功数据形状: {result.shape if hasattr(result, shape) else N/A}, status: success }) else: raise ValueError(f工具未找到: {action[tool]}) except Exception as e: state.error f工具执行失败: {str(e)} state.execution_log.append({ step: action[task], tool: action[tool], error: str(e), status: failed }) return state finally: # 清除临时动作指示 state.metadata {} # 检查终止条件所有计划完成或生成了最终报告 if (state.current_plan and set(state.completed_steps) set(state.current_plan)) or state.final_report: print(f[智能体完成] 任务执行完毕。共迭代{i1}轮。) break # 防止状态无变化导致死循环 if state state_before: print(f[警告] 第{i}轮迭代状态未发生变化可能陷入循环。) state.error 状态转换陷入停滞可能规划逻辑有误。 break else: state.error 达到最大迭代次数仍未完成。 return state # 主程序入口 async def main(): agent DeepAnalysisAgent() query 帮我分析过去三个月销售数据找出表现最好的三个产品类别并预测下个月的趋势。 final_state await agent.run(query) # 输出结果 if final_state.error: print(f执行失败: {final_state.error}) print(执行日志:, final_state.execution_log) else: print(f\n 分析完成 ) print(f目标: {final_state.parsed_objective}) print(f完成步骤: {final_state.completed_steps}) if final_state.final_report: print(f\n报告摘要:\n{final_state.final_report[:500]}...) # 截断显示 if final_state.chart_paths: print(f\n生成的图表: {final_state.chart_paths}) if __name__ __main__: asyncio.run(main())这个示例展示了deepagents思想的核心状态驱动、转换器管道、动态规划、工具执行。虽然我们这里实现了一个简化版本但langchain-ai/deepagents项目本身会提供更多开箱即用的高级抽象、标准化的追踪器、以及更鲁棒的控制器逻辑。4. 深度智能体开发中的关键挑战与应对策略在实际开发中直接套用上述模式可能会遇到不少挑战。下面分享一些我实践中总结的经验和避坑指南。4.1 状态设计的复杂性与演化管理状态是智能体的核心但设计一个既能满足当前需求又易于扩展的状态模型并不容易。一个常见的陷阱是过早优化试图在第一个版本中就设计出涵盖所有可能情况的状态结构。实操心得渐进式状态设计我的建议是采用“渐进式”设计。从最小可行状态MVP State开始只包含最核心的字段如user_query,current_step,output。随着智能体能力的增加再逐步引入新的字段和嵌套结构。例如一开始可能只需要raw_data后来发现需要区分raw_data和processed_data再后来可能需要为不同数据源分别设立sales_data和inventory_data。使用Pydantic模型的好处在于它提供了强大的数据验证和序列化支持修改起来相对安全。另一个挑战是状态版本管理。当你的智能体逻辑更新状态结构也可能需要改变。如何让旧版本保存的状态能在新版本中加载这需要一些迁移策略。一个简单的方法是在状态模型中添加一个version字段并在加载旧状态时编写迁移函数将旧字段映射或转换为新字段。4.2 规划与执行的稳定性保障让LLM来做规划Planner虽然灵活但也最不稳定。同一个任务LLM今天可能生成步骤[A, B, C]明天可能生成[A, C, B]甚至遗漏关键步骤。应对策略混合规划模式不要完全依赖LLM的零样本Zero-shot规划。可以采用以下几种混合模式提升稳定性模板化规划对于常见任务类型如“数据分析”、“报告生成”预定义任务模板。LLM的角色变为“参数填充者”即识别用户请求属于哪个模板并填充具体参数如时间范围“过去三个月”、指标“销售额”。约束性规划在给规划器LLM的提示词中严格约束输出格式。例如要求它必须从预定义的“工具清单”中选择工具并按照“(工具名: 输入参数)”的格式输出。这大大降低了输出的随机性。验证与回退规划器生成计划后增加一个“计划验证”步骤。可以用另一个LLM或一套规则来检查计划的合理性和完整性。如果验证不通过则触发回退机制例如使用一个更保守的默认计划或向用户请求澄清。工具调用的可靠性工具调用失败是常态。网络超时、API限流、输入格式不符都会导致失败。deepagents框架应或你需要自己实现提供工具调用的重试、降级和优雅处理机制。重试对于暂时性错误如网络抖动自动重试2-3次。参数校验与格式化在工具_run方法内部对输入参数进行严格校验和类型转换。例如即使LLM传来的日期是“三个月前”也应转换为具体的日期字符串。备选工具为关键工具设置备选。例如如果主要的数据API失败可以回退到查询本地缓存数据或一个更简单的模拟数据生成工具并向状态中记录降级事件保证流程不中断。4.3 可观测性与调试技巧当智能体行为不符合预期时如何快速定位问题强大的可观测性体系是关键。构建执行追踪视图除了记录日志你应该能直观地看到智能体的“思维链”。这包括状态快照在每一个转换器执行前后记录状态的差异Diff。LLM输入/输出完整记录每一次调用LLM的提示词和返回结果。这对于调试提示词效果至关重要。工具调用详情记录工具的名称、输入参数、开始时间、结束时间、返回结果或错误信息。你可以将这些信息输出到控制台使用不同颜色区分信息、警告、错误或者更专业地发送到像LangSmith这样的LLM应用监控平台。在deepagents的上下文中充分利用其提供的Observer和Tracer接口来植入这些追踪点。交互式调试模式在开发阶段为智能体增加一个“调试模式”非常有用。在此模式下智能体可以在每个关键决策点如规划器输出计划后、调用工具前暂停并将中间状态和提议的下一步动作打印出来等待开发者确认按回车继续或干预手动修改状态。这能让你像“单步调试”程序一样理解智能体的决策过程。4.4 性能优化与成本控制深度智能体可能涉及多次LLM调用和工具执行成本和延迟会成为生产环境的瓶颈。优化策略缓存LLM响应对于在相同输入下输出确定的LLM调用如目标解析、固定格式的数据提取引入缓存层。可以使用简单的内存缓存如functools.lru_cache或分布式缓存如Redis键为提示词的哈希值。并行化工具调用如果多个工具调用之间没有依赖关系应该并行执行而非串行。asyncio.gather是Python中实现并发的利器。在状态设计中可以考虑支持“并行任务步骤”。使用更经济的模型并非所有步骤都需要最强的GPT-4。可以将智能体设计为混合模型架构。例如用GPT-4做复杂的初始规划和最终报告合成而用更便宜、更快的模型如GPT-3.5 Turbo或本地小模型来处理简单的分类、信息提取等子任务。deepagents的状态转换器设计使得为不同转换器分配不同LLM客户端变得非常容易。设置预算与熔断在智能体执行循环中实时累计消耗的Token数和工具调用次数。当超过预设预算时主动终止流程并返回当前最佳结果和超支警告避免因意外循环导致巨额费用。5. 进阶应用场景与模式探索deepagents所倡导的深度智能体范式其应用远不止于数据分析。它的核心价值在于处理那些需要多步骤推理、状态保持和外部交互的复杂任务。5.1 场景一自动化客户支持与问题排查想象一个高级的客服机器人它不仅要回答常见问题还要能引导用户完成复杂的故障排查流程。状态设计包含用户问题描述、已尝试的解决步骤、收集到的系统信息如错误代码、截图、当前怀疑的根因、以及对话历史。工具集知识库检索工具、内部系统状态查询工具、创建工单工具、引导用户执行检查步骤的对话工具。规划逻辑智能体首先对用户问题进行分类是账户问题、技术故障还是计费疑问然后根据分类启动相应的诊断流程。例如对于技术故障规划可能是1. 检索相关已知问题库2. 若无匹配则引导用户提供错误日志3. 根据日志调用系统诊断API4. 根据API返回或提供解决方案或创建工单并预填诊断信息。整个过程中状态始终保持了完整的排查上下文即使对话中断后重新连接也能恢复到之前的步骤。5.2 场景二游戏中的智能NPC行为引擎在游戏中NPC非玩家角色可以不再是脚本驱动的“木头人”而是由深度智能体驱动的、拥有记忆和目标的虚拟角色。状态设计包含NPC的当前目标如“收集木材”、“守卫村庄”、对游戏世界的信念如“仓库有10单位食物”、“东边森林有狼”、情感状态如“对玩家信任度70”、物品库存、以及与其他角色交互的历史。工具集移动工具、与物体交互工具砍树、采矿、与其他NPC或玩家对话工具、交易工具。规划与执行智能体根据内部目标由游戏设计师设定或动态生成和外部感知游戏引擎传递的世界状态来制定短期计划。例如目标为“建造房屋”状态显示“缺少木材”则规划为1. 前往森林2. 砍树直到木材足够3. 返回建造点。在执行中如果感知到“狼群靠近”状态中的“威胁”字段更新规划器会动态插入“战斗”或“逃跑”的子目标。这使得NPC的行为更加连贯、智能且不可预测在合理范围内极大提升游戏沉浸感。5.3 场景三研发流程中的智能编码助手超越Copilot的单行代码补全构建一个能理解完整需求、并自主编写和测试一个模块的智能体。状态设计包含项目需求文档、已有代码库的上下文通过嵌入向量检索、当前正在编写的模块规格、已生成的代码片段、单元测试结果、编译/静态检查错误列表。工具集代码生成工具调用LLM、代码静态分析工具如pylint、ESLint、单元测试运行工具、版本控制工具git diff/add/commit、依赖管理工具。工作流智能体接收一个功能需求如“添加一个用户登录的API端点”。它首先分析现有代码结构规划出需要修改的文件路由文件、控制器、模型、测试文件。然后它依次为每个文件生成或修改代码。每完成一个文件就调用静态检查和单元测试工具。如果测试失败根据错误信息调整代码这可能涉及一个新的“调试”子状态。所有文件都通过后自动生成提交信息并创建一个Pull Request。这种深度集成将大大提升复杂代码任务的自动化水平。这些场景的共同点是任务复杂、步骤多、有状态、需与多种外部系统交互。这正是deepagents这类框架旨在解决的问题域。通过将不确定性高的LLM推理封装在结构化的状态机和明确的工具调用之中我们能够在享受LLM强大通用能力的同时获得可预测、可调试、可集成的系统行为。开发这类智能体的过程与其说是“编程”不如说是“教导”和“设计”。你需要教会智能体在什么状态下该思考什么、能使用什么工具、以及如何解读结果。这需要反复的迭代、测试和提示词优化。但一旦构建成功其带来的自动化潜力将是革命性的。langchain-ai/deepagents项目为我们提供了实现这一愿景的坚实脚手架剩下的就是结合具体业务场景去填充那些充满创造性的状态、转换器和工具了。