1. 项目概述为什么现在需要自己动手搭Agent框架最近和几个做AI应用开发的朋友聊天发现一个挺有意思的现象大家一提到“智能体”或者“Agent”第一反应往往是去GitHub上找现成的框架比如LangChain、AutoGen这些明星项目。这当然没问题成熟的轮子能极大提升开发效率。但聊深了就会发现很多朋友在用这些框架时一旦遇到稍微复杂点的定制需求或者想优化一下Agent的决策逻辑就有点无从下手了感觉像是在一个黑盒外面敲敲打打。这让我想起早年做Web开发一开始都用各种现成的CMS后来为了追求极致的性能和灵活性不得不从零开始理解HTTP协议、路由、模板引擎。现在搞AI应用开发尤其是Agent似乎也到了这个阶段。从零搭建一个Agent框架听起来像是个“造轮子”的苦差事但它的价值远不止于此。这更像是一次深度解剖让你彻底搞明白一个能自主感知、规划、调用工具、并从错误中学习的智能体它的“大脑”究竟是如何运转的各个模块之间如何通信协作记忆如何形成和检索决策的“灵魂”又在哪里通过亲手搭建你获得的将不仅仅是使用一个框架的能力而是设计和调试智能体的能力。当现成框架的某个设计不符合你的业务场景时你能快速定位问题所在甚至有能力去修改底层逻辑或者为自己的特定领域比如游戏NPC、客服机器人、自动化数据分析流水线设计一个更贴合的架构。这就是本篇文章想带你做的事情我们不追求功能的大而全而是追求理解的深而透。我们会从一个最简单的“思考-行动”循环开始逐步加入记忆、工具使用、反思等核心模块最终形成一个可运行、可扩展的迷你Agent框架。过程中我会分享很多在纯使用框架时不会遇到的“坑”和设计抉择。2. 核心架构设计拆解Agent的“五脏六腑”在动手写代码之前我们必须先想清楚架构。一个典型的Agent框架无论简单还是复杂都离不开几个核心组件。我们可以把它们类比成一个探险家的心智模型。2.1 大脑核心Agent Loop代理循环这是Agent的“心跳”一个永不停止的循环过程。最经典的模型是ReAct (Reasoning Acting)范式其核心流程可以概括为观察 (Observe)接收来自外部的输入用户问题、环境状态、上一次行动的结果。思考 (Think)基于当前观察和内部记忆决定下一步要做什么。这是Agent的“推理”环节通常由大语言模型驱动。行动 (Act)执行思考环节决定的操作。可能是调用一个工具如搜索、计算、写文件也可能是直接生成回答。评估 (Evaluate)观察行动产生的结果判断目标是否达成或是否需要继续循环。这个循环的终止条件通常是Agent认为任务已完成生成了最终答案或达到了最大循环次数以防无限循环。在我们的实现中这个循环是框架的调度中心。注意很多初学者会混淆“一次LLM调用”和“一次Agent循环”。一次循环可能包含多次LLM调用例如思考一次调用工具后根据结果再思考一次我们的框架需要妥善管理这些交互的上下文。2.2 记忆系统短期、长期与工具记忆记忆是Agent拥有“连续性”和“学习能力”的关键。我们不能让Agent像金鱼一样每次循环都忘记之前发生的事情。通常我们将记忆分为三类短期记忆 (Short-term Memory)即当前对话的上下文。它通常是一个长度有限的列表保存着最近的用户消息、AI回复、工具调用及结果。这部分直接作为提示词的一部分喂给LLM。长期记忆 (Long-term Memory)当对话或任务历史超出上下文窗口时我们需要将重要的信息存储下来并在未来需要时检索。这可以通过向量数据库实现将历史信息嵌入成向量在需要时进行相似性搜索召回。工具记忆 (Tool Memory)这是一个常被忽略但至关重要的部分。它记录的是Agent对工具的使用经验。例如调用“天气查询”工具时需要什么格式的参数上次调用“代码执行”工具时因为语法错误失败了这次应该注意什么我们可以为每个工具维护一个简明的使用记录或注意事项在Agent决定使用该工具前将这些经验作为提示词的一部分注入。在我们的迷你框架中我们会先实现一个简单的对话历史管理短期记忆并预留出长期记忆和工具记忆的接口说明其扩展思路。2.3 工具引擎Agent的“手脚”工具是Agent与外部世界交互的唯一途径。一个框架的工具引擎需要解决几个问题注册与管理如何方便地让开发者将自定义函数如下载网页、运行SQL、调用API注册为Agent可用的工具描述与发现Agent如何知道有哪些工具可用每个工具是做什么的需要什么参数这需要通过自然语言描述每个工具的功能和参数格式。调用与解析Agent在思考步骤中可能会说“我需要调用天气查询工具参数是city北京”。工具引擎需要能解析这种自然语言或结构化指令找到对应的工具函数并以正确的参数格式调用它。安全与沙箱对于执行代码、文件操作等高风险工具框架是否需要提供沙箱环境这是一个进阶话题但设计之初就需要考虑。我们将实现一个基于Python函数和装饰器的简易工具注册系统让Agent能自动获取工具列表和描述并完成调用。2.4 思考中枢LLM的集成与提示工程这是Agent的“灵魂”所在。框架需要提供一个抽象层让开发者可以灵活接入不同的大模型如OpenAI GPT、 Anthropic Claude、国内大模型或本地部署的模型而无需重写核心逻辑。这个抽象层的核心是统一的消息格式将对话历史、工具描述、系统指令、用户问题等按照不同模型的要求组装成正确的提示格式。支持结构化输出为了可靠地解析Agent的决策例如“下一步是调用工具X参数是Y”我们强烈建议使用LLM的“函数调用”或“JSON模式”输出功能。这能极大提高框架的稳定性和可解析性。系统指令设计这是控制Agent行为的关键。指令需要明确告诉Agent你是谁、你的目标是什么、你有哪些工具、你应该如何思考例如遵循ReAct格式、以及如何输出例如必须以“Thought:”, “Action:”, “Action Input:”的格式回应。3. 从零开始实现一个最小可行Agent框架理论说得再多不如一行代码。我们现在就从一个最简单的命令行交互式Agent开始实现。我们将使用OpenAI的API因其函数调用功能稳定但架构上会保持对其它模型的开放性。3.1 环境准备与基础类定义首先安装核心依赖并定义几个基础的数据类。这些类就像乐高积木的零件定义了整个系统交互的数据结构。pip install openai# agent_core.py from dataclasses import dataclass from typing import Any, Callable, Dict, List, Optional, Tuple import json dataclass class Message: 代表对话中的一条消息 role: str # system, user, assistant, tool content: str name: Optional[str] None # 可选用于工具调用时指定工具名 dataclass class Tool: 工具定义 name: str description: str function: Callable # 实际执行的Python函数 parameters_schema: Dict[str, Any] # 描述函数参数的JSON Schema dataclass class AgentStep: 记录Agent单次循环的完整输出用于解析和后续处理 thought: Optional[str] None # 思考内容 action: Optional[str] None # 决定执行的动作通常是工具名 action_input: Optional[Dict[str, Any]] None # 动作的输入参数 observation: Optional[str] None # 执行动作后的观察结果 final_answer: Optional[str] None # 如果是最终答案则存放于此这里的关键是AgentStep类它强制了Agent输出的一种结构。我们将要求LLM严格按照这个结构进行思考这比让它自由发挥然后我们用正则表达式去解析要可靠得多。3.2 构建工具管理系统工具管理系统是框架的“服务注册中心”。我们设计一个ToolRegistry单例类来管理所有工具。# tool_registry.py class ToolRegistry: _instance None _tools: Dict[str, Tool] {} def __new__(cls): if cls._instance is None: cls._instance super(ToolRegistry, cls).__new__(cls) return cls._instance def register(self, tool: Tool): 注册一个工具 if tool.name in self._tools: raise ValueError(fTool {tool.name} is already registered.) self._tools[tool.name] tool print(f[Tool Registered] {tool.name}: {tool.description}) def get_tool(self, name: str) - Optional[Tool]: 根据名称获取工具 return self._tools.get(name) def get_tools_description(self) - List[Dict]: 获取所有工具的JSON Schema描述用于构造LLM提示词 return [ { name: tool.name, description: tool.description, parameters: tool.parameters_schema } for tool in self._tools.values() ] def execute(self, tool_name: str, **kwargs) - str: 执行指定工具 tool self.get_tool(tool_name) if not tool: return fError: Tool {tool_name} not found. try: # 这里可以加入权限检查、参数验证、沙箱执行等逻辑 result tool.function(**kwargs) # 确保返回结果是字符串方便后续拼接 return str(result) except Exception as e: return fError while executing tool {tool_name}: {str(e)} # 创建一个装饰器方便开发者注册工具 def register_tool(name: str, description: str, parameters_schema: Dict): 工具注册装饰器 def decorator(func: Callable): tool Tool(namename, descriptiondescription, functionfunc, parameters_schemaparameters_schema) ToolRegistry().register(tool) return func return decorator现在开发者只需要用register_tool装饰自己的函数这个函数就自动变成了Agent可用的工具。例如我们注册两个简单的工具# my_tools.py from tool_registry import register_tool register_tool( nameget_current_time, description获取当前的日期和时间。当用户询问时间、日期、现在几点时使用。, parameters_schema{ type: object, properties: {}, # 这个工具不需要参数 required: [] } ) def get_current_time(): from datetime import datetime return datetime.now().strftime(%Y-%m-%d %H:%M:%S) register_tool( namecalculate, description执行数学计算。支持加()、减(-)、乘(*)、除(/)、乘方(**)等基本运算。, parameters_schema{ type: object, properties: { expression: { type: string, description: 数学表达式例如 3 5 * 2 } }, required: [expression] } ) def calculate(expression: str) - str: try: # 警告在生产环境中直接eval是危险的这里仅为演示。 # 应使用更安全的表达式求值库如 ast.literal_eval 或自定义解析器。 result eval(expression, {__builtins__: {}}, {}) return str(result) except Exception as e: return f计算错误: {str(e)}3.3 实现思考中枢LLM驱动模块这个模块负责与LLM对话并将复杂的提示工程封装起来。我们实现一个LLMDriver基类和一个OpenAI的具体实现。# llm_driver.py from abc import ABC, abstractmethod from typing import List import openai import os class LLMDriver(ABC): LLM驱动器的抽象基类便于未来扩展其他模型 abstractmethod def chat_completion(self, messages: List[Message], tools: List[Dict] None) - Tuple[str, Dict]: 发送聊天补全请求。 返回: (LLM的回复内容, 可能包含的元数据如函数调用信息) pass class OpenAIDriver(LLMDriver): def __init__(self, model: str gpt-3.5-turbo, api_key: str None): self.model model self.client openai.OpenAI(api_keyapi_key or os.getenv(OPENAI_API_KEY)) def chat_completion(self, messages: List[Message], tools: List[Dict] None) - Tuple[str, Dict]: # 将我们内部的Message格式转换为OpenAI API格式 openai_messages [] for msg in messages: openai_msg {role: msg.role, content: msg.content} if msg.name: openai_msg[name] msg.name openai_messages.append(openai_msg) kwargs { model: self.model, messages: openai_messages, temperature: 0.1, # 低温度使输出更确定更适合Agent决策 } if tools: # 如果提供了工具描述则启用函数调用功能 kwargs[tools] tools # 我们可以要求模型在需要时自动调用工具也可以设置为“auto”让模型决定 kwargs[tool_choice] auto response self.client.chat.completions.create(**kwargs) message response.choices[0].message # 提取回复内容和可能的工具调用信息 content message.content or tool_calls message.tool_calls metadata {} if tool_calls: metadata[tool_calls] [] for tc in tool_calls: metadata[tool_calls].append({ id: tc.id, name: tc.function.name, arguments: json.loads(tc.function.arguments) }) return content, metadata3.4 组装核心Agent循环现在我们把记忆、工具、LLM驱动器和循环逻辑组装起来形成Agent类。# agent.py from llm_driver import OpenAIDriver from tool_registry import ToolRegistry from agent_core import Message, AgentStep import re class Agent: def __init__(self, llm_driver: LLMDriver, system_prompt: str None): self.llm llm_driver self.tool_registry ToolRegistry() self.memory: List[Message] [] # 短期记忆对话历史 self.max_steps 10 # 防止无限循环 # 系统提示词定义了Agent的角色和行为规范 self.system_prompt system_prompt or 你是一个有帮助的AI助手可以调用工具来解决问题。 请严格按照以下格式回应 1. 如果你需要调用工具来获取信息请输出 Thought: 你需要解释你为什么需要调用工具以及你的思考过程。 Action: 工具的名称 Action Input: 一个包含工具输入参数的JSON对象例如 {{key: value}} 2. 如果你已经有了最终答案请输出 Thought: 解释你的推理过程并得出结论。 Final Answer: 你的最终答案 请确保Action和Final Answer不会同时出现。 # 初始化时加入系统指令 self.memory.append(Message(rolesystem, contentself.system_prompt)) def _parse_llm_output(self, text: str) - AgentStep: 解析LLM的输出提取Thought, Action, Action Input, Final Answer。 这是一个基于正则的简单解析器。在实际生产中更推荐使用LLM的JSON模式或函数调用来获得结构化输出。 step AgentStep() # 提取 Thought thought_match re.search(rThought:\s*(.*?)(?\nAction:|\nFinal Answer:|\n?$), text, re.DOTALL) if thought_match: step.thought thought_match.group(1).strip() # 提取 Action 和 Action Input action_match re.search(rAction:\s*(\w), text) action_input_match re.search(rAction Input:\s*(\{.*?\}), text, re.DOTALL) if action_match and action_input_match: step.action action_match.group(1) try: step.action_input json.loads(action_input_match.group(1)) except json.JSONDecodeError: step.action_input {raw_input: action_input_match.group(1)} # 提取 Final Answer final_answer_match re.search(rFinal Answer:\s*(.*?)$, text, re.DOTALL) if final_answer_match: step.final_answer final_answer_match.group(1).strip() return step def run(self, user_input: str) - str: 运行Agent处理一次用户输入 print(f\n[User]: {user_input}) self.memory.append(Message(roleuser, contentuser_input)) for step_count in range(self.max_steps): print(f\n--- Step {step_count 1} ---) # 1. 准备当前上下文系统指令 对话历史 工具描述 tools_description self.tool_registry.get_tools_description() # 将工具描述也作为系统消息的一部分或单独的消息发送给LLM tools_prompt 你可以使用的工具如下\n \n.join( [f- {t[name]}: {t[description]} (参数: {t[parameters]}) for t in tools_description] ) # 构造本次请求的消息列表 current_messages self.memory.copy() # 在最后一次用户消息后插入工具提示也可以放在系统消息里 # 这里采用一个简单方法将工具提示作为一条独立的系统消息插入 current_messages.insert(-1, Message(rolesystem, contenttools_prompt)) # 2. 调用LLM进行“思考” llm_response, metadata self.llm.chat_completion(current_messages) print(f[LLM Raw Response]:\n{llm_response}) # 3. 解析LLM的输出 step self._parse_llm_output(llm_response) if metadata.get(tool_calls): # 如果使用了OpenAI的函数调用我们可以从metadata直接获取更精确的结构化信息 # 这里我们优先使用结构化信息它比正则解析更可靠 tc metadata[tool_calls][0] step.action tc[name] step.action_input tc[arguments] # 我们需要从原始回复中提取thought或者让LLM在函数调用前输出thought # 简化处理如果原始回复有内容且不是函数调用就当作thought if llm_response and not llm_response.startswith({): # 简单判断 step.thought llm_response # 将Agent的“思考”和“行动”记录到记忆 assistant_response_content fThought: {step.thought}\n if step.action: assistant_response_content fAction: {step.action}\nAction Input: {step.action_input} elif step.final_answer: assistant_response_content fFinal Answer: {step.final_answer} self.memory.append(Message(roleassistant, contentassistant_response_content)) # 4. 判断并执行行动 if step.action: print(f[Agent] 决定执行动作: {step.action} with input {step.action_input}) # 执行工具 observation self.tool_registry.execute(step.action, **step.action_input) print(f[Tool Observation]: {observation}) # 将工具执行结果作为观察记录到记忆 self.memory.append(Message(roletool, contentobservation, namestep.action)) # 循环继续... elif step.final_answer: print(f[Agent] 给出最终答案: {step.final_answer}) # 将最终答案也记录到记忆方便后续查看 self.memory.append(Message(roleassistant, contentfFinal Answer: {step.final_answer})) return step.final_answer else: # 既没有行动也没有最终答案可能LLM输出格式不符合预期 print([Warning] LLM输出无法解析将原样返回。) return llm_response # 循环达到最大次数 return f达到最大循环次数({self.max_steps})仍未完成任务。3.5 运行你的第一个Agent最后我们写一个简单的脚本把一切跑起来。# main.py from agent import Agent from llm_driver import OpenAIDriver import my_tools # 这行很重要它会执行装饰器自动注册工具 def main(): # 1. 初始化LLM驱动请确保已设置OPENAI_API_KEY环境变量 llm_driver OpenAIDriver(modelgpt-3.5-turbo) # 2. 创建Agent实例 my_agent Agent(llm_driverllm_driver) # 3. 运行一个示例对话 print( 迷你Agent框架启动 ) print(已注册工具:, [t.name for t in my_agent.tool_registry._tools.values()]) queries [ 现在几点了, 3的平方加上4的平方等于多少, 先计算(105)*2再用结果除以3。 ] for query in queries: answer my_agent.run(query) print(f\n[Agent Final Output]: {answer}) print(- * 50) if __name__ __main__: main()运行这个脚本你会看到Agent一步步的思考过程、工具调用和最终结果。恭喜你你已经拥有了一个从零搭建的、可运行的Agent核心框架4. 深入优化与功能扩展上面的代码实现了一个最基础的骨架。要让它在实际项目中可用我们还需要在稳定性、功能和易用性上做大量工作。以下是几个关键的优化和扩展方向。4.1 强化输出解析从正则到结构化使用正则表达式解析LLM的输出是脆弱且容易出错的。更健壮的方法是强制LLM输出结构化数据如JSON。OpenAI的GPT系列支持response_format: { type: json_object }我们可以定义一个严格的JSON Schema要求LLM必须按照这个格式输出。我们可以修改LLMDriver和Agent的提示词要求LLM返回如下格式的JSON{ thought: 用户问时间我需要调用获取时间的工具。, has_action: true, action: { name: get_current_time, arguments: {} }, final_answer: null }或者当是最终答案时{ thought: 我已经通过工具获得了当前时间可以直接回答用户。, has_action: false, action: null, final_answer: 当前时间是2023-10-27 14:30:00。 }这种方式几乎完全消除了解析错误是生产级系统的必备选择。你需要更新系统提示词并可能在chat_completion调用中传入response_format参数。4.2 构建记忆系统从对话历史到向量检索我们当前的self.memory只是一个简单的对话列表当对话轮次变多很快就会超出LLM的上下文窗口。此时我们需要引入长期记忆。总结式记忆在对话历史达到一定长度后调用LLM对之前的对话进行总结将总结文本作为新的系统消息或早期消息从而压缩历史。这是一种低成本方案。向量检索记忆这是更强大的方案。将每一轮有信息量的对话特别是工具调用结果、关键结论通过嵌入模型如OpenAI的text-embedding-3-small转换为向量存入向量数据库如Chroma、Qdrant、Pinecone。当Agent需要决策时将当前问题或上下文也转换为向量从数据库中检索出最相关的几条历史记忆作为额外上下文插入提示词。这实现了类似“联想记忆”的功能。实现向量记忆是一个相对独立模块它包含嵌入、存储、检索三个步骤。你可以设计一个VectorMemory类在Agent.run方法的准备上下文阶段调用它的retrieve方法获取相关记忆片段。4.3 设计更复杂的Agent工作流我们目前实现的是单一Agent的ReAct循环。现实中的任务可能更复杂需要多个Agent协作或者需要更复杂的工作流。规划与子任务分解在“思考”阶段让Agent先制定一个计划将复杂任务分解为多个子任务然后逐个执行。这可以通过在系统提示词中强调“先做规划”来实现或者引入一个专门的“规划器”Agent。多Agent协作你可以创建多个Agent实例每个拥有不同的系统指令和工具集。然后设计一个“协调员”或“主Agent”来分配任务。例如一个Agent负责搜索信息另一个负责分析数据主Agent负责整合结果并回答用户。Human-in-the-loop人工介入为Agent增加“请求人类帮助”的能力。当Agent不确定、遇到权限问题或工具执行失败时可以暂停循环通过某种方式如发送消息到聊天界面、生成一个待办项请求人类输入然后将人类反馈作为新的观察继续循环。4.4 提升可靠性与可观测性一个健壮的框架必须考虑错误处理和监控。工具调用异常处理在ToolRegistry.execute中我们已经用try-catch包裹了工具执行。但还需要更细粒度的处理比如参数验证失败、网络超时、权限不足等并返回结构化的错误信息供Agent“反思”。循环超时与中断除了最大步数限制还应设置总时间限制。对于长时间运行的任务需要提供中断机制。完整的日志记录记录每一次LLM请求和响应、每一次工具调用及结果、每一步的AgentStep对象。这不仅是调试的需要也是后续优化提示词、分析Agent行为的数据基础。可以考虑将日志结构化成JSONL格式便于分析。可观测性在关键节点如循环开始、工具调用前后、最终输出暴露钩子函数或事件方便开发者集成监控、审计或自定义逻辑。5. 避坑指南与实战心得在开发和测试这个迷你框架以及在实际项目中应用类似思想时我积累了一些宝贵的经验教训。5.1 提示词设计是灵魂需要反复迭代系统提示词的质量直接决定了Agent的“性格”和能力上限。不要指望一次写好。你需要明确角色与边界清晰地告诉Agent“你是谁”、“你该做什么”、“你不该做什么”。例如“你是一个数据分析助手只回答与数据相关的问题对于其他问题礼貌拒绝。”提供丰富的示例在提示词中加入少量2-3个高质量的思维链示例能极大提升模型输出的格式正确性和推理质量。这就是所谓的“少样本提示”。格式化输出要求必须强硬且明确使用“必须”、“严格遵循”、“只能输出以下格式”等词语。并像我们之前做的那样最好通过JSON Schema或函数调用来约束而不是依赖模型自觉。分阶段测试先设计一个极简的提示词让Agent跑通流程然后逐步增加复杂度如加入规划要求、反思要求观察其行为变化。5.2 工具设计的“粒度”与“安全性”平衡工具粒度要适中工具既不能太“粗”如“完成一份市场报告”这会让LLM难以理解和使用也不能太“细”如“字符串拼接”这会导致需要频繁调用效率低下且容易出错。好的工具应该是完成一个原子性操作如“搜索网页”、“查询数据库表A”、“发送邮件”。工具描述至关重要description字段要用自然语言清晰、无歧义地描述工具的功能、适用场景、输入输出格式。好的描述能让LLM准确判断何时该调用它。安全是第一要务对于任何执行代码、访问文件系统、调用外部API的工具必须实施严格的参数验证、权限控制和资源隔离。我们的calculate工具使用了危险的eval这仅用于演示。在生产中必须替换为安全的表达式解析库或限制可用的操作符和函数。5.3 处理LLM的“幻觉”与“死循环”即使有严格的格式要求LLM偶尔也会“胡言乱语”或陷入无效循环。幻觉调用不存在的工具Agent可能会生成一个你未注册的工具名。在ToolRegistry.execute中我们已经做了检查并返回错误。关键是Agent需要能从这个错误观察中学习在下一步思考中纠正自己。你的系统提示词可以加入“如果你调用的工具不存在或者调用失败请分析错误信息尝试其他方法或直接给出你能给出的最佳答案。”死循环Agent可能反复调用同一个工具或者在不同的工具间来回切换却无法推进任务。除了设置max_steps硬性限制外可以在提示词中要求Agent“如果连续三步没有取得实质性进展请总结当前困境并向用户请求更多信息或直接给出部分答案”。你也可以在框架层面实现一个简单的循环检测逻辑。5.4 性能与成本考量每次Agent循环都意味着至少一次LLM API调用成本不可忽视。上下文管理精炼你的提示词定期清理或总结对话历史避免不必要的令牌消耗。向量检索长期记忆也是一种用计算换令牌的策略。缓存对于频繁出现的、结果固定的用户查询如“你是谁”或工具调用如查询某个静态配置可以引入缓存机制避免重复计算和LLM调用。模型选型对于简单的工具调用和格式解析gpt-3.5-turbo通常足够且更便宜。对于需要复杂规划、推理和反思的任务再考虑使用gpt-4。可以根据任务复杂度动态选择模型。从零搭建Agent框架的过程是一个从“使用者”到“创造者”的思维转变。你不再满足于调用agent.run(prompt)而是开始思考这个run方法内部每一行代码的意义。当你在未来使用LangChain等成熟框架时你会一眼看穿其AgentExecutor、Tool、Memory类背后的设计意图能够更高效地调试和定制。更重要的是你获得了为特定垂直领域量身定制智能体工作流的能力这才是构建差异化AI应用的核心竞争力。这个简单的框架只是一个起点它的每一个模块都为你打开了一扇深入探索的门等待你用更精妙的设计去填充。 从零搭建AI Agent框架：深入理解智能体核心架构与实现
1. 项目概述为什么现在需要自己动手搭Agent框架最近和几个做AI应用开发的朋友聊天发现一个挺有意思的现象大家一提到“智能体”或者“Agent”第一反应往往是去GitHub上找现成的框架比如LangChain、AutoGen这些明星项目。这当然没问题成熟的轮子能极大提升开发效率。但聊深了就会发现很多朋友在用这些框架时一旦遇到稍微复杂点的定制需求或者想优化一下Agent的决策逻辑就有点无从下手了感觉像是在一个黑盒外面敲敲打打。这让我想起早年做Web开发一开始都用各种现成的CMS后来为了追求极致的性能和灵活性不得不从零开始理解HTTP协议、路由、模板引擎。现在搞AI应用开发尤其是Agent似乎也到了这个阶段。从零搭建一个Agent框架听起来像是个“造轮子”的苦差事但它的价值远不止于此。这更像是一次深度解剖让你彻底搞明白一个能自主感知、规划、调用工具、并从错误中学习的智能体它的“大脑”究竟是如何运转的各个模块之间如何通信协作记忆如何形成和检索决策的“灵魂”又在哪里通过亲手搭建你获得的将不仅仅是使用一个框架的能力而是设计和调试智能体的能力。当现成框架的某个设计不符合你的业务场景时你能快速定位问题所在甚至有能力去修改底层逻辑或者为自己的特定领域比如游戏NPC、客服机器人、自动化数据分析流水线设计一个更贴合的架构。这就是本篇文章想带你做的事情我们不追求功能的大而全而是追求理解的深而透。我们会从一个最简单的“思考-行动”循环开始逐步加入记忆、工具使用、反思等核心模块最终形成一个可运行、可扩展的迷你Agent框架。过程中我会分享很多在纯使用框架时不会遇到的“坑”和设计抉择。2. 核心架构设计拆解Agent的“五脏六腑”在动手写代码之前我们必须先想清楚架构。一个典型的Agent框架无论简单还是复杂都离不开几个核心组件。我们可以把它们类比成一个探险家的心智模型。2.1 大脑核心Agent Loop代理循环这是Agent的“心跳”一个永不停止的循环过程。最经典的模型是ReAct (Reasoning Acting)范式其核心流程可以概括为观察 (Observe)接收来自外部的输入用户问题、环境状态、上一次行动的结果。思考 (Think)基于当前观察和内部记忆决定下一步要做什么。这是Agent的“推理”环节通常由大语言模型驱动。行动 (Act)执行思考环节决定的操作。可能是调用一个工具如搜索、计算、写文件也可能是直接生成回答。评估 (Evaluate)观察行动产生的结果判断目标是否达成或是否需要继续循环。这个循环的终止条件通常是Agent认为任务已完成生成了最终答案或达到了最大循环次数以防无限循环。在我们的实现中这个循环是框架的调度中心。注意很多初学者会混淆“一次LLM调用”和“一次Agent循环”。一次循环可能包含多次LLM调用例如思考一次调用工具后根据结果再思考一次我们的框架需要妥善管理这些交互的上下文。2.2 记忆系统短期、长期与工具记忆记忆是Agent拥有“连续性”和“学习能力”的关键。我们不能让Agent像金鱼一样每次循环都忘记之前发生的事情。通常我们将记忆分为三类短期记忆 (Short-term Memory)即当前对话的上下文。它通常是一个长度有限的列表保存着最近的用户消息、AI回复、工具调用及结果。这部分直接作为提示词的一部分喂给LLM。长期记忆 (Long-term Memory)当对话或任务历史超出上下文窗口时我们需要将重要的信息存储下来并在未来需要时检索。这可以通过向量数据库实现将历史信息嵌入成向量在需要时进行相似性搜索召回。工具记忆 (Tool Memory)这是一个常被忽略但至关重要的部分。它记录的是Agent对工具的使用经验。例如调用“天气查询”工具时需要什么格式的参数上次调用“代码执行”工具时因为语法错误失败了这次应该注意什么我们可以为每个工具维护一个简明的使用记录或注意事项在Agent决定使用该工具前将这些经验作为提示词的一部分注入。在我们的迷你框架中我们会先实现一个简单的对话历史管理短期记忆并预留出长期记忆和工具记忆的接口说明其扩展思路。2.3 工具引擎Agent的“手脚”工具是Agent与外部世界交互的唯一途径。一个框架的工具引擎需要解决几个问题注册与管理如何方便地让开发者将自定义函数如下载网页、运行SQL、调用API注册为Agent可用的工具描述与发现Agent如何知道有哪些工具可用每个工具是做什么的需要什么参数这需要通过自然语言描述每个工具的功能和参数格式。调用与解析Agent在思考步骤中可能会说“我需要调用天气查询工具参数是city北京”。工具引擎需要能解析这种自然语言或结构化指令找到对应的工具函数并以正确的参数格式调用它。安全与沙箱对于执行代码、文件操作等高风险工具框架是否需要提供沙箱环境这是一个进阶话题但设计之初就需要考虑。我们将实现一个基于Python函数和装饰器的简易工具注册系统让Agent能自动获取工具列表和描述并完成调用。2.4 思考中枢LLM的集成与提示工程这是Agent的“灵魂”所在。框架需要提供一个抽象层让开发者可以灵活接入不同的大模型如OpenAI GPT、 Anthropic Claude、国内大模型或本地部署的模型而无需重写核心逻辑。这个抽象层的核心是统一的消息格式将对话历史、工具描述、系统指令、用户问题等按照不同模型的要求组装成正确的提示格式。支持结构化输出为了可靠地解析Agent的决策例如“下一步是调用工具X参数是Y”我们强烈建议使用LLM的“函数调用”或“JSON模式”输出功能。这能极大提高框架的稳定性和可解析性。系统指令设计这是控制Agent行为的关键。指令需要明确告诉Agent你是谁、你的目标是什么、你有哪些工具、你应该如何思考例如遵循ReAct格式、以及如何输出例如必须以“Thought:”, “Action:”, “Action Input:”的格式回应。3. 从零开始实现一个最小可行Agent框架理论说得再多不如一行代码。我们现在就从一个最简单的命令行交互式Agent开始实现。我们将使用OpenAI的API因其函数调用功能稳定但架构上会保持对其它模型的开放性。3.1 环境准备与基础类定义首先安装核心依赖并定义几个基础的数据类。这些类就像乐高积木的零件定义了整个系统交互的数据结构。pip install openai# agent_core.py from dataclasses import dataclass from typing import Any, Callable, Dict, List, Optional, Tuple import json dataclass class Message: 代表对话中的一条消息 role: str # system, user, assistant, tool content: str name: Optional[str] None # 可选用于工具调用时指定工具名 dataclass class Tool: 工具定义 name: str description: str function: Callable # 实际执行的Python函数 parameters_schema: Dict[str, Any] # 描述函数参数的JSON Schema dataclass class AgentStep: 记录Agent单次循环的完整输出用于解析和后续处理 thought: Optional[str] None # 思考内容 action: Optional[str] None # 决定执行的动作通常是工具名 action_input: Optional[Dict[str, Any]] None # 动作的输入参数 observation: Optional[str] None # 执行动作后的观察结果 final_answer: Optional[str] None # 如果是最终答案则存放于此这里的关键是AgentStep类它强制了Agent输出的一种结构。我们将要求LLM严格按照这个结构进行思考这比让它自由发挥然后我们用正则表达式去解析要可靠得多。3.2 构建工具管理系统工具管理系统是框架的“服务注册中心”。我们设计一个ToolRegistry单例类来管理所有工具。# tool_registry.py class ToolRegistry: _instance None _tools: Dict[str, Tool] {} def __new__(cls): if cls._instance is None: cls._instance super(ToolRegistry, cls).__new__(cls) return cls._instance def register(self, tool: Tool): 注册一个工具 if tool.name in self._tools: raise ValueError(fTool {tool.name} is already registered.) self._tools[tool.name] tool print(f[Tool Registered] {tool.name}: {tool.description}) def get_tool(self, name: str) - Optional[Tool]: 根据名称获取工具 return self._tools.get(name) def get_tools_description(self) - List[Dict]: 获取所有工具的JSON Schema描述用于构造LLM提示词 return [ { name: tool.name, description: tool.description, parameters: tool.parameters_schema } for tool in self._tools.values() ] def execute(self, tool_name: str, **kwargs) - str: 执行指定工具 tool self.get_tool(tool_name) if not tool: return fError: Tool {tool_name} not found. try: # 这里可以加入权限检查、参数验证、沙箱执行等逻辑 result tool.function(**kwargs) # 确保返回结果是字符串方便后续拼接 return str(result) except Exception as e: return fError while executing tool {tool_name}: {str(e)} # 创建一个装饰器方便开发者注册工具 def register_tool(name: str, description: str, parameters_schema: Dict): 工具注册装饰器 def decorator(func: Callable): tool Tool(namename, descriptiondescription, functionfunc, parameters_schemaparameters_schema) ToolRegistry().register(tool) return func return decorator现在开发者只需要用register_tool装饰自己的函数这个函数就自动变成了Agent可用的工具。例如我们注册两个简单的工具# my_tools.py from tool_registry import register_tool register_tool( nameget_current_time, description获取当前的日期和时间。当用户询问时间、日期、现在几点时使用。, parameters_schema{ type: object, properties: {}, # 这个工具不需要参数 required: [] } ) def get_current_time(): from datetime import datetime return datetime.now().strftime(%Y-%m-%d %H:%M:%S) register_tool( namecalculate, description执行数学计算。支持加()、减(-)、乘(*)、除(/)、乘方(**)等基本运算。, parameters_schema{ type: object, properties: { expression: { type: string, description: 数学表达式例如 3 5 * 2 } }, required: [expression] } ) def calculate(expression: str) - str: try: # 警告在生产环境中直接eval是危险的这里仅为演示。 # 应使用更安全的表达式求值库如 ast.literal_eval 或自定义解析器。 result eval(expression, {__builtins__: {}}, {}) return str(result) except Exception as e: return f计算错误: {str(e)}3.3 实现思考中枢LLM驱动模块这个模块负责与LLM对话并将复杂的提示工程封装起来。我们实现一个LLMDriver基类和一个OpenAI的具体实现。# llm_driver.py from abc import ABC, abstractmethod from typing import List import openai import os class LLMDriver(ABC): LLM驱动器的抽象基类便于未来扩展其他模型 abstractmethod def chat_completion(self, messages: List[Message], tools: List[Dict] None) - Tuple[str, Dict]: 发送聊天补全请求。 返回: (LLM的回复内容, 可能包含的元数据如函数调用信息) pass class OpenAIDriver(LLMDriver): def __init__(self, model: str gpt-3.5-turbo, api_key: str None): self.model model self.client openai.OpenAI(api_keyapi_key or os.getenv(OPENAI_API_KEY)) def chat_completion(self, messages: List[Message], tools: List[Dict] None) - Tuple[str, Dict]: # 将我们内部的Message格式转换为OpenAI API格式 openai_messages [] for msg in messages: openai_msg {role: msg.role, content: msg.content} if msg.name: openai_msg[name] msg.name openai_messages.append(openai_msg) kwargs { model: self.model, messages: openai_messages, temperature: 0.1, # 低温度使输出更确定更适合Agent决策 } if tools: # 如果提供了工具描述则启用函数调用功能 kwargs[tools] tools # 我们可以要求模型在需要时自动调用工具也可以设置为“auto”让模型决定 kwargs[tool_choice] auto response self.client.chat.completions.create(**kwargs) message response.choices[0].message # 提取回复内容和可能的工具调用信息 content message.content or tool_calls message.tool_calls metadata {} if tool_calls: metadata[tool_calls] [] for tc in tool_calls: metadata[tool_calls].append({ id: tc.id, name: tc.function.name, arguments: json.loads(tc.function.arguments) }) return content, metadata3.4 组装核心Agent循环现在我们把记忆、工具、LLM驱动器和循环逻辑组装起来形成Agent类。# agent.py from llm_driver import OpenAIDriver from tool_registry import ToolRegistry from agent_core import Message, AgentStep import re class Agent: def __init__(self, llm_driver: LLMDriver, system_prompt: str None): self.llm llm_driver self.tool_registry ToolRegistry() self.memory: List[Message] [] # 短期记忆对话历史 self.max_steps 10 # 防止无限循环 # 系统提示词定义了Agent的角色和行为规范 self.system_prompt system_prompt or 你是一个有帮助的AI助手可以调用工具来解决问题。 请严格按照以下格式回应 1. 如果你需要调用工具来获取信息请输出 Thought: 你需要解释你为什么需要调用工具以及你的思考过程。 Action: 工具的名称 Action Input: 一个包含工具输入参数的JSON对象例如 {{key: value}} 2. 如果你已经有了最终答案请输出 Thought: 解释你的推理过程并得出结论。 Final Answer: 你的最终答案 请确保Action和Final Answer不会同时出现。 # 初始化时加入系统指令 self.memory.append(Message(rolesystem, contentself.system_prompt)) def _parse_llm_output(self, text: str) - AgentStep: 解析LLM的输出提取Thought, Action, Action Input, Final Answer。 这是一个基于正则的简单解析器。在实际生产中更推荐使用LLM的JSON模式或函数调用来获得结构化输出。 step AgentStep() # 提取 Thought thought_match re.search(rThought:\s*(.*?)(?\nAction:|\nFinal Answer:|\n?$), text, re.DOTALL) if thought_match: step.thought thought_match.group(1).strip() # 提取 Action 和 Action Input action_match re.search(rAction:\s*(\w), text) action_input_match re.search(rAction Input:\s*(\{.*?\}), text, re.DOTALL) if action_match and action_input_match: step.action action_match.group(1) try: step.action_input json.loads(action_input_match.group(1)) except json.JSONDecodeError: step.action_input {raw_input: action_input_match.group(1)} # 提取 Final Answer final_answer_match re.search(rFinal Answer:\s*(.*?)$, text, re.DOTALL) if final_answer_match: step.final_answer final_answer_match.group(1).strip() return step def run(self, user_input: str) - str: 运行Agent处理一次用户输入 print(f\n[User]: {user_input}) self.memory.append(Message(roleuser, contentuser_input)) for step_count in range(self.max_steps): print(f\n--- Step {step_count 1} ---) # 1. 准备当前上下文系统指令 对话历史 工具描述 tools_description self.tool_registry.get_tools_description() # 将工具描述也作为系统消息的一部分或单独的消息发送给LLM tools_prompt 你可以使用的工具如下\n \n.join( [f- {t[name]}: {t[description]} (参数: {t[parameters]}) for t in tools_description] ) # 构造本次请求的消息列表 current_messages self.memory.copy() # 在最后一次用户消息后插入工具提示也可以放在系统消息里 # 这里采用一个简单方法将工具提示作为一条独立的系统消息插入 current_messages.insert(-1, Message(rolesystem, contenttools_prompt)) # 2. 调用LLM进行“思考” llm_response, metadata self.llm.chat_completion(current_messages) print(f[LLM Raw Response]:\n{llm_response}) # 3. 解析LLM的输出 step self._parse_llm_output(llm_response) if metadata.get(tool_calls): # 如果使用了OpenAI的函数调用我们可以从metadata直接获取更精确的结构化信息 # 这里我们优先使用结构化信息它比正则解析更可靠 tc metadata[tool_calls][0] step.action tc[name] step.action_input tc[arguments] # 我们需要从原始回复中提取thought或者让LLM在函数调用前输出thought # 简化处理如果原始回复有内容且不是函数调用就当作thought if llm_response and not llm_response.startswith({): # 简单判断 step.thought llm_response # 将Agent的“思考”和“行动”记录到记忆 assistant_response_content fThought: {step.thought}\n if step.action: assistant_response_content fAction: {step.action}\nAction Input: {step.action_input} elif step.final_answer: assistant_response_content fFinal Answer: {step.final_answer} self.memory.append(Message(roleassistant, contentassistant_response_content)) # 4. 判断并执行行动 if step.action: print(f[Agent] 决定执行动作: {step.action} with input {step.action_input}) # 执行工具 observation self.tool_registry.execute(step.action, **step.action_input) print(f[Tool Observation]: {observation}) # 将工具执行结果作为观察记录到记忆 self.memory.append(Message(roletool, contentobservation, namestep.action)) # 循环继续... elif step.final_answer: print(f[Agent] 给出最终答案: {step.final_answer}) # 将最终答案也记录到记忆方便后续查看 self.memory.append(Message(roleassistant, contentfFinal Answer: {step.final_answer})) return step.final_answer else: # 既没有行动也没有最终答案可能LLM输出格式不符合预期 print([Warning] LLM输出无法解析将原样返回。) return llm_response # 循环达到最大次数 return f达到最大循环次数({self.max_steps})仍未完成任务。3.5 运行你的第一个Agent最后我们写一个简单的脚本把一切跑起来。# main.py from agent import Agent from llm_driver import OpenAIDriver import my_tools # 这行很重要它会执行装饰器自动注册工具 def main(): # 1. 初始化LLM驱动请确保已设置OPENAI_API_KEY环境变量 llm_driver OpenAIDriver(modelgpt-3.5-turbo) # 2. 创建Agent实例 my_agent Agent(llm_driverllm_driver) # 3. 运行一个示例对话 print( 迷你Agent框架启动 ) print(已注册工具:, [t.name for t in my_agent.tool_registry._tools.values()]) queries [ 现在几点了, 3的平方加上4的平方等于多少, 先计算(105)*2再用结果除以3。 ] for query in queries: answer my_agent.run(query) print(f\n[Agent Final Output]: {answer}) print(- * 50) if __name__ __main__: main()运行这个脚本你会看到Agent一步步的思考过程、工具调用和最终结果。恭喜你你已经拥有了一个从零搭建的、可运行的Agent核心框架4. 深入优化与功能扩展上面的代码实现了一个最基础的骨架。要让它在实际项目中可用我们还需要在稳定性、功能和易用性上做大量工作。以下是几个关键的优化和扩展方向。4.1 强化输出解析从正则到结构化使用正则表达式解析LLM的输出是脆弱且容易出错的。更健壮的方法是强制LLM输出结构化数据如JSON。OpenAI的GPT系列支持response_format: { type: json_object }我们可以定义一个严格的JSON Schema要求LLM必须按照这个格式输出。我们可以修改LLMDriver和Agent的提示词要求LLM返回如下格式的JSON{ thought: 用户问时间我需要调用获取时间的工具。, has_action: true, action: { name: get_current_time, arguments: {} }, final_answer: null }或者当是最终答案时{ thought: 我已经通过工具获得了当前时间可以直接回答用户。, has_action: false, action: null, final_answer: 当前时间是2023-10-27 14:30:00。 }这种方式几乎完全消除了解析错误是生产级系统的必备选择。你需要更新系统提示词并可能在chat_completion调用中传入response_format参数。4.2 构建记忆系统从对话历史到向量检索我们当前的self.memory只是一个简单的对话列表当对话轮次变多很快就会超出LLM的上下文窗口。此时我们需要引入长期记忆。总结式记忆在对话历史达到一定长度后调用LLM对之前的对话进行总结将总结文本作为新的系统消息或早期消息从而压缩历史。这是一种低成本方案。向量检索记忆这是更强大的方案。将每一轮有信息量的对话特别是工具调用结果、关键结论通过嵌入模型如OpenAI的text-embedding-3-small转换为向量存入向量数据库如Chroma、Qdrant、Pinecone。当Agent需要决策时将当前问题或上下文也转换为向量从数据库中检索出最相关的几条历史记忆作为额外上下文插入提示词。这实现了类似“联想记忆”的功能。实现向量记忆是一个相对独立模块它包含嵌入、存储、检索三个步骤。你可以设计一个VectorMemory类在Agent.run方法的准备上下文阶段调用它的retrieve方法获取相关记忆片段。4.3 设计更复杂的Agent工作流我们目前实现的是单一Agent的ReAct循环。现实中的任务可能更复杂需要多个Agent协作或者需要更复杂的工作流。规划与子任务分解在“思考”阶段让Agent先制定一个计划将复杂任务分解为多个子任务然后逐个执行。这可以通过在系统提示词中强调“先做规划”来实现或者引入一个专门的“规划器”Agent。多Agent协作你可以创建多个Agent实例每个拥有不同的系统指令和工具集。然后设计一个“协调员”或“主Agent”来分配任务。例如一个Agent负责搜索信息另一个负责分析数据主Agent负责整合结果并回答用户。Human-in-the-loop人工介入为Agent增加“请求人类帮助”的能力。当Agent不确定、遇到权限问题或工具执行失败时可以暂停循环通过某种方式如发送消息到聊天界面、生成一个待办项请求人类输入然后将人类反馈作为新的观察继续循环。4.4 提升可靠性与可观测性一个健壮的框架必须考虑错误处理和监控。工具调用异常处理在ToolRegistry.execute中我们已经用try-catch包裹了工具执行。但还需要更细粒度的处理比如参数验证失败、网络超时、权限不足等并返回结构化的错误信息供Agent“反思”。循环超时与中断除了最大步数限制还应设置总时间限制。对于长时间运行的任务需要提供中断机制。完整的日志记录记录每一次LLM请求和响应、每一次工具调用及结果、每一步的AgentStep对象。这不仅是调试的需要也是后续优化提示词、分析Agent行为的数据基础。可以考虑将日志结构化成JSONL格式便于分析。可观测性在关键节点如循环开始、工具调用前后、最终输出暴露钩子函数或事件方便开发者集成监控、审计或自定义逻辑。5. 避坑指南与实战心得在开发和测试这个迷你框架以及在实际项目中应用类似思想时我积累了一些宝贵的经验教训。5.1 提示词设计是灵魂需要反复迭代系统提示词的质量直接决定了Agent的“性格”和能力上限。不要指望一次写好。你需要明确角色与边界清晰地告诉Agent“你是谁”、“你该做什么”、“你不该做什么”。例如“你是一个数据分析助手只回答与数据相关的问题对于其他问题礼貌拒绝。”提供丰富的示例在提示词中加入少量2-3个高质量的思维链示例能极大提升模型输出的格式正确性和推理质量。这就是所谓的“少样本提示”。格式化输出要求必须强硬且明确使用“必须”、“严格遵循”、“只能输出以下格式”等词语。并像我们之前做的那样最好通过JSON Schema或函数调用来约束而不是依赖模型自觉。分阶段测试先设计一个极简的提示词让Agent跑通流程然后逐步增加复杂度如加入规划要求、反思要求观察其行为变化。5.2 工具设计的“粒度”与“安全性”平衡工具粒度要适中工具既不能太“粗”如“完成一份市场报告”这会让LLM难以理解和使用也不能太“细”如“字符串拼接”这会导致需要频繁调用效率低下且容易出错。好的工具应该是完成一个原子性操作如“搜索网页”、“查询数据库表A”、“发送邮件”。工具描述至关重要description字段要用自然语言清晰、无歧义地描述工具的功能、适用场景、输入输出格式。好的描述能让LLM准确判断何时该调用它。安全是第一要务对于任何执行代码、访问文件系统、调用外部API的工具必须实施严格的参数验证、权限控制和资源隔离。我们的calculate工具使用了危险的eval这仅用于演示。在生产中必须替换为安全的表达式解析库或限制可用的操作符和函数。5.3 处理LLM的“幻觉”与“死循环”即使有严格的格式要求LLM偶尔也会“胡言乱语”或陷入无效循环。幻觉调用不存在的工具Agent可能会生成一个你未注册的工具名。在ToolRegistry.execute中我们已经做了检查并返回错误。关键是Agent需要能从这个错误观察中学习在下一步思考中纠正自己。你的系统提示词可以加入“如果你调用的工具不存在或者调用失败请分析错误信息尝试其他方法或直接给出你能给出的最佳答案。”死循环Agent可能反复调用同一个工具或者在不同的工具间来回切换却无法推进任务。除了设置max_steps硬性限制外可以在提示词中要求Agent“如果连续三步没有取得实质性进展请总结当前困境并向用户请求更多信息或直接给出部分答案”。你也可以在框架层面实现一个简单的循环检测逻辑。5.4 性能与成本考量每次Agent循环都意味着至少一次LLM API调用成本不可忽视。上下文管理精炼你的提示词定期清理或总结对话历史避免不必要的令牌消耗。向量检索长期记忆也是一种用计算换令牌的策略。缓存对于频繁出现的、结果固定的用户查询如“你是谁”或工具调用如查询某个静态配置可以引入缓存机制避免重复计算和LLM调用。模型选型对于简单的工具调用和格式解析gpt-3.5-turbo通常足够且更便宜。对于需要复杂规划、推理和反思的任务再考虑使用gpt-4。可以根据任务复杂度动态选择模型。从零搭建Agent框架的过程是一个从“使用者”到“创造者”的思维转变。你不再满足于调用agent.run(prompt)而是开始思考这个run方法内部每一行代码的意义。当你在未来使用LangChain等成熟框架时你会一眼看穿其AgentExecutor、Tool、Memory类背后的设计意图能够更高效地调试和定制。更重要的是你获得了为特定垂直领域量身定制智能体工作流的能力这才是构建差异化AI应用的核心竞争力。这个简单的框架只是一个起点它的每一个模块都为你打开了一扇深入探索的门等待你用更精妙的设计去填充。