1. 从“造轮子”到“选轮子”一个Agent开发者的困惑与觉醒最近在社区和几个技术群里关于AI Agent开发的讨论热度一直居高不下。一个反复被提及、也最容易引发争论的话题就是“做Agent项目到底要不要用框架” 新手开发者往往一头雾水觉得不用框架就无从下手而一些有经验的工程师则可能嗤之以鼻认为框架不过是“玩具”真正的能力在于对底层模型和工程逻辑的理解。我自己在过去一年里从零开始摸索了几个不同类型的Agent项目既有为了快速验证想法而直接“裸写”代码的经历也有为了构建稳定服务而深度集成成熟框架的实践。今天我想抛开那些营销话术和框架文档里的“最佳实践”从一个一线开发者的角度聊聊我对这个问题的真实看法。这绝不是一个非黑即白的答案而是一个关于“成本、收益与约束”的权衡过程。理解这个过程比你盲目追随任何一个框架或方法论都重要得多。2. 拆解“Agent开发”我们到底在开发什么在讨论框架的必要性之前我们必须先对齐一个基本认知当我们谈论“Agent开发”时我们究竟在构建一个什么样的系统很多人可能立刻想到像AutoGPT、BabyAGI那样的“自主智能体”但实际上Agent的形态和应用场景要广泛得多。2.1 Agent的四种常见形态与复杂度光谱根据我的观察目前市面上的Agent项目大致可以按复杂度和目标分为四类单任务自动化助手这是最常见的起点。例如一个根据用户自然语言描述自动生成SQL并查询数据库最后用自然语言总结结果的工具。它的核心流程是线性的解析用户意图 - 调用工具SQL生成器、数据库- 格式化输出。这类Agent逻辑相对简单状态管理需求弱。多工具编排的工作流引擎复杂度上升一个等级。例如一个内容创作Agent需要依次调用联网搜索工具、资料分析工具、大纲生成工具、文案撰写工具最后调用发布API。这里涉及多个步骤的串行或并行执行、中间结果的传递、以及可能的条件分支如果资料不足则重新搜索。它需要工作流引擎和上下文管理。具备记忆与规划的自主智能体这就是通常意义上更“智能”的Agent。它有一个长期目标并能自主拆解为子任务根据环境反馈动态调整计划。例如一个研究某个学术课题的Agent它会自己规划“搜索相关论文 - 阅读并总结 - 提出假设 - 寻找数据验证”等步骤并在遇到困难时尝试替代方案。这需要强大的规划模块、丰富的工具库、以及长期/短期记忆机制。多智能体协作系统这是复杂度的顶峰。系统内存在多个具有不同角色和能力的Agent如分析师、撰稿人、审核员它们通过特定的通信协议进行协作共同完成一个复杂目标。这涉及到Agent间的通信、协商、任务分配与结果整合对系统的架构设计提出了极高要求。你的项目属于哪一类这是选择技术路径的首要问题。一个单任务助手你可能只需要一个脚本和OpenAI的API调用而一个多智能体系统几乎必然需要一套框架来管理其中的复杂性。2.2 核心组件拆解不用框架你需要自己实现什么无论用不用框架一个功能完整的Agent通常都包含以下几个核心组件大脑LLM集成层负责与大型语言模型交互。这不仅仅是发个HTTP请求那么简单你需要处理不同模型提供商OpenAI, Anthropic, 国内各大厂的API差异、统一的请求/响应封装、流式输出处理、Token计数与成本控制、失败重试与降级策略等。工具Tool/Function Calling让Agent能够操作外部世界。你需要定义工具的描述让LLM理解工具能做什么、调用规范输入输出格式、执行器实际运行代码并确保它们能安全、稳定地运行。记忆MemoryAgent的“经验”。包括对话历史短期记忆、向量数据库存储的长期知识、以及执行过程中的关键事实缓存。你需要设计数据的存储、检索、更新和淘汰机制。规划与控制流OrchestrationAgent的“思考”过程。对于简单任务可能是线性的链式调用LangChain的Chain对于复杂任务则需要像ReAct这样的循环推理-执行框架或者更复杂的任务分解与调度算法。评估与监控Evaluation Observability如何知道你的Agent工作得好不好你需要设计评估指标准确性、效率、成本并搭建日志、追踪Tracing系统来监控每一次交互的细节便于调试和优化。如果不用框架以上每一个组件你都需要从零开始设计和实现。这不仅仅是编码的工作量更是架构设计、抽象边界定义和长期维护的挑战。3. 主流Agent框架全景图与选型逻辑当前市面上的Agent框架可谓百花齐放各有侧重。我们可以将其大致分为三类框架类别代表项目核心特点适用场景学习与上手成本全能型/应用开发框架LangChain, LangGraph组件丰富生态庞大提供了从模型交互、提示工程、记忆、工具调用到工作流编排的全套工具箱。LangGraph特别擅长构建有状态的、循环的Agent。快速构建功能全面的Agent应用尤其是涉及复杂工作流和多步骤推理的场景。适合产品化探索。高。概念多抽象层次高初期需要花时间理解其设计哲学。轻量级/库型框架LlamaIndex, Semantic Kernel更专注于某一领域。LlamaIndex擅长数据索引与检索RAGSemantic Kernel微软强调将传统代码技能与AI技能Plugins结合。如果你的Agent核心是复杂的文档处理与问答LlamaIndex或是深度集成在.NET生态中Semantic Kernel。中。目标更明确但深入使用仍需理解其核心概念。自主智能体专用框架AutoGPT, BabyAGI提供了“自主智能体”的参考实现内置了目标分解、任务执行循环等机制。学习、研究自主智能体的运行原理或基于此进行二次开发。中高。通常结构相对固定定制化需要修改其核心循环逻辑。学术研究/新范式框架LangStream采用流式处理Streaming架构来处理AI工作流强调实时性和可观测性。对实时性要求高的复杂事件处理管道或希望用全新架构探索Agent系统的团队。很高。概念新颖社区和资料相对较少。注意框架生态日新月异Hermes Agent、CrewAI等也是近期热门选择。选型时除了看功能更要关注社区的活跃度、文档的完善程度以及版本迭代的稳定性。3.1 为什么选择框架不仅仅是“快”很多文章会说用框架是为了“提高开发效率”这没错但太片面了。根据我的经验框架带来的深层价值至少包括降低认知与设计负担框架提供了一套经过验证的抽象和设计模式。你不需要从零思考“记忆应该怎么存”、“工具怎么描述LLM才能懂”。你可以直接站在巨人的肩膀上专注于你的业务逻辑。获得即时可用的最佳实践一个成熟的框架其内置的组件往往集成了社区的经验。例如LangChain的ConversationBufferWindowMemory会自动处理长上下文截断避免你重复造轮子甚至踩坑。生态与工具链集成框架通常有丰富的集成列表比如各种向量数据库、消息队列、监控工具。使用框架你可以轻松地接入这些基础设施而不用自己写适配器。团队协作与知识沉淀使用统一的框架意味着团队有共同的语言和范式。新成员入职、代码审查、模块复用都会变得更容易。3.2 框架的“另一面”那些令人头疼的代价然而拥抱框架并非没有成本尤其是对于快速变化的AI领域。抽象泄漏与灵活性丧失所有框架都在做一件事在“通用性”和“易用性”之间做权衡。为了让你用起来简单它必须隐藏复杂性。但当你遇到一个框架设计时未考虑的边界情况时这种被隐藏的复杂性就会“泄漏”出来迫使你去钻研框架源码甚至用一些“Hack”的方式绕过限制。此时你可能发现自己花在理解框架“黑魔法”上的时间比从头实现还要多。版本迭代的阵痛AI领域迭代极快底层模型API、最佳实践都在快速变化。框架为了跟进版本迭代也非常频繁。你可能这个月刚基于某个版本的LangChain写完代码下个月就发现某个核心接口被弃用了。依赖管理成为持续的负担。性能开销与调试黑盒框架层带来的额外抽象必然引入一定的性能开销。更重要的是当Agent出现诡异的行为比如调用了错误的工具时你的调试栈会变得很深。你需要判断问题是出在你的提示词、你的工具代码、框架对工具的描述封装、还是框架与LLM的交互逻辑上。调试过程如同在迷雾中寻路。“框架思维”的禁锢初学者很容易陷入“框架能做什么我就做什么”的思维定式。比如LangChain早期强调的“Chain”概念让很多人把一切逻辑都硬塞进Chain里导致代码冗长且难以维护。框架的范式可能会限制你对问题更本质、更优雅的解决方案的探索。我亲身经历过一个项目初期为了快重度依赖LangChain。但在实现一个需要复杂自定义中断和状态回滚的业务流程时我们发现LangChain的Chain和Agent抽象变得非常笨重代码充满了为了迎合框架而写的胶水代码。最终我们剥离了框架只用其底层的LLM调用和工具定义库自己用简单的异步任务队列重写了核心调度逻辑系统反而变得清晰且高效。4. “不用框架”的实践从零搭建一个最小可行Agent那么不用框架到底怎么做我们来实操一下构建一个最简单的“单任务自动化助手”一个命令行天气查询Agent。它接收用户如“北京天气怎么样”的查询调用天气API并返回结果。我们会清晰地看到哪些部分其实很简单哪些部分会随着复杂度提升而迅速变得棘手。4.1 第一步核心大脑——直接调用LLM API我们完全不需要LangChain的LLMChain直接使用openai官方库或其他SDK即可。import openai import os from typing import Dict, Any class SimpleLLMClient: def __init__(self, api_key: str, model: str gpt-3.5-turbo): openai.api_key api_key self.model model def chat_completion(self, messages: list) - str: 最基础的聊天补全调用 try: response openai.ChatCompletion.create( modelself.model, messagesmessages, temperature0.1, # 低随机性保证工具调用稳定 max_tokens500, ) return response.choices[0].message.content.strip() except Exception as e: return fLLM调用失败: {e} # 初始化 llm_client SimpleLLMClient(api_keyos.getenv(OPENAI_API_KEY))看不到20行代码我们就有了一个可靠的大脑。我们可以完全控制请求参数、错误处理。如果明天想换Anthropic的Claude我们只需要再写一个类似的AnthropicClient并统一接口。这里的核心价值是你彻底理解了与LLM交互最基本、最直接的单元是什么。4.2 第二步定义与调用工具框架里花里胡哨的tool装饰器、Tool类其本质是什么就是让LLM能识别并触发一段Python函数。1. 定义工具函数import requests def get_current_weather(location: str) - str: 获取指定城市的当前天气情况。 Args: location: 城市名例如“北京”、“上海”。 Returns: 关于天气情况的字符串描述。 # 这里使用一个模拟的天气API。真实场景可替换为心知天气、和风天气等。 # 为简化示例我们返回模拟数据。 weather_data { 北京: 晴15°C西北风2级空气质量良。, 上海: 多云18°C东南风1级空气质量优。, 广州: 阵雨25°C南风3级空气质量良。 } return weather_data.get(location, f抱歉未找到{city}的天气信息。) # 工具库字典 TOOLS { get_current_weather: { function: get_current_weather, description: 获取某个城市的当前天气情况。, parameters: { type: object, properties: { location: {type: string, description: 城市名如‘北京’、‘上海’。} }, required: [location] } } }我们手动创建了一个工具字典包含了函数本身、描述、以及符合OpenAI Function Calling格式的参数模式。关键点在于你清晰地知道一个工具的本质就是一个函数加上一段能让LLM理解的元数据描述。2. 让LLM决定是否调用及如何调用这是核心逻辑。我们需要构造提示词让LLM以特定格式如JSON输出它的“决策”。import json def run_agent_with_tools(user_query: str) - str: # 1. 构造系统提示告诉LLM可用的工具和输出格式 system_prompt f 你是一个天气助手。请根据用户问题决定是否需要调用工具。 你可以使用的工具如下 {json.dumps([{name: k, description: v[description], parameters: v[parameters]} for k, v in TOOLS.items()], ensure_asciiFalse)} 请严格按以下JSON格式回复 {{ thought: 你的思考过程分析用户意图。, use_tool: true/false, tool_name: 如果需要调用工具填写工具名否则为null, tool_input: {{}} // 如果需要调用工具填写工具输入参数的字典 }} # 2. 调用LLM获取决策 messages [ {role: system, content: system_prompt}, {role: user, content: user_query} ] llm_decision_str llm_client.chat_completion(messages) # 3. 解析LLM的决策 try: decision json.loads(llm_decision_str) except json.JSONDecodeError: return 抱歉我无法理解你的请求。 # 4. 执行决策 if decision.get(use_tool) and decision.get(tool_name) in TOOLS: tool_name decision[tool_name] tool_input decision.get(tool_input, {}) tool_func TOOLS[tool_name][function] # 执行工具 tool_result tool_func(**tool_input) # 5. 将工具结果返回给LLM让它生成最终回复 final_messages messages [ {role: assistant, content: llm_decision_str}, {role: user, content: f工具调用结果{tool_result}。请根据这个结果回答用户最初的问题。} ] final_response llm_client.chat_completion(final_messages) return final_response else: # 不需要调用工具直接返回LLM的初始回复需从decision中提取或重新组织 return decision.get(thought, 我无法处理这个请求。)这个run_agent_with_tools函数就是一个最简化的Agent执行循环。它包含了任务理解、工具决策、工具执行、结果整合。虽然简陋但五脏俱全。4.3 第三步运行与迭代if __name__ __main__: query 请问上海今天天气如何 response run_agent_with_tools(query) print(f用户: {query}) print(f助手: {response})运行它你会看到整个流程是如何一步步执行的。这个练习的价值在于你亲手实现了ReAct模式的核心循环。你理解了工具调用中“描述”和“执行”的分离。你掌握了Agent最基础的状态流转。当你想增加“记忆”功能时你会自然地想到在messages列表里持久化历史对话。当你想支持“多个工具”时你会扩展TOOLS字典和提示词。当流程出错时你可以清晰地在你写的每一个步骤里打日志、设断点。5. 决策时刻一张帮你做选择的评估清单所以回到最初的问题你真的需要框架吗我的建议是不要问“要不要”而是问“什么时候要以及要什么”。你可以根据下面这个清单来评估考虑从零开始或仅用极简封装的情况✅项目处于极早期概念验证PoC阶段你的目标是快速验证“这个想法用AI能不能跑通”功能极其简单比如只有1-2个工具线性流程。自己写几个函数比引入一个框架更快。✅你对Agent的核心机制有强烈的学习欲望你想彻底弄懂工具调用、规划、记忆到底是怎么工作的。亲手实现一遍是最好的老师。✅你的需求非常特殊与主流框架的范式格格不入例如你需要极致的性能、非常规的通信协议、或者与现有遗留系统深度耦合。框架的抽象可能成为阻碍。✅项目规模很小且长期维护预期低一个一次性脚本或内部小工具。考虑引入一个成熟框架的情况✅你需要快速构建一个功能相对完整的演示或产品原型框架提供的现成组件聊天记忆、文档加载器、各种工具集成能帮你节省大量时间。✅项目复杂度中高涉及多步骤、有条件逻辑的工作流例如LangGraph提供的图状态机能帮你直观地设计和调试复杂流程比自己管理状态和跳转要可靠得多。✅团队协作开发需要统一的架构和代码规范框架提供了一套共同语言降低了沟通成本。✅你需要紧密跟随社区的最新实践和工具生态框架社区通常会快速集成最新的模型、工具和最佳实践。一个实用的混合策略在我的项目中我越来越倾向于一种“混合架构”核心交互层保持轻量对于LLM的调用、基础的工具定义和调用我倾向于自己封装一个薄薄的、符合项目需求的客户端。这让我对最核心的交互有完全的控制力和可调试性。在需要复杂编排时引入框架当业务逻辑涉及到复杂的、有状态的工作流时我会考虑引入像LangGraph这样的框架专门负责这一部分。把它当作一个“工作流引擎”来用而不是全盘接受它的所有抽象。把框架当作“组件库”而非“脚手架”不一定要全盘采用某个框架。可以只使用其中一两个解决特定问题的优秀组件比如LlamaIndex的RAG检索器或者LangChain里某个特别好用的文档加载器。最终衡量技术选型是否正确的唯一标准是它是否帮助你更高效、更可靠地解决了业务问题并且其长期维护成本在可接受范围内。对于Agent开发框架是强大的加速器但不是唯一的引擎。理解引擎本身如何工作能让你无论是否使用加速器都开得更稳、更远。在你下一个Agent项目启动前不妨先花半小时用最原始的方式勾勒出它的核心循环这或许会让你对是否需要框架、需要什么样的框架有一个完全不同的、更清晰的认识。 AI Agent开发框架选型指南：从零搭建与主流方案对比
1. 从“造轮子”到“选轮子”一个Agent开发者的困惑与觉醒最近在社区和几个技术群里关于AI Agent开发的讨论热度一直居高不下。一个反复被提及、也最容易引发争论的话题就是“做Agent项目到底要不要用框架” 新手开发者往往一头雾水觉得不用框架就无从下手而一些有经验的工程师则可能嗤之以鼻认为框架不过是“玩具”真正的能力在于对底层模型和工程逻辑的理解。我自己在过去一年里从零开始摸索了几个不同类型的Agent项目既有为了快速验证想法而直接“裸写”代码的经历也有为了构建稳定服务而深度集成成熟框架的实践。今天我想抛开那些营销话术和框架文档里的“最佳实践”从一个一线开发者的角度聊聊我对这个问题的真实看法。这绝不是一个非黑即白的答案而是一个关于“成本、收益与约束”的权衡过程。理解这个过程比你盲目追随任何一个框架或方法论都重要得多。2. 拆解“Agent开发”我们到底在开发什么在讨论框架的必要性之前我们必须先对齐一个基本认知当我们谈论“Agent开发”时我们究竟在构建一个什么样的系统很多人可能立刻想到像AutoGPT、BabyAGI那样的“自主智能体”但实际上Agent的形态和应用场景要广泛得多。2.1 Agent的四种常见形态与复杂度光谱根据我的观察目前市面上的Agent项目大致可以按复杂度和目标分为四类单任务自动化助手这是最常见的起点。例如一个根据用户自然语言描述自动生成SQL并查询数据库最后用自然语言总结结果的工具。它的核心流程是线性的解析用户意图 - 调用工具SQL生成器、数据库- 格式化输出。这类Agent逻辑相对简单状态管理需求弱。多工具编排的工作流引擎复杂度上升一个等级。例如一个内容创作Agent需要依次调用联网搜索工具、资料分析工具、大纲生成工具、文案撰写工具最后调用发布API。这里涉及多个步骤的串行或并行执行、中间结果的传递、以及可能的条件分支如果资料不足则重新搜索。它需要工作流引擎和上下文管理。具备记忆与规划的自主智能体这就是通常意义上更“智能”的Agent。它有一个长期目标并能自主拆解为子任务根据环境反馈动态调整计划。例如一个研究某个学术课题的Agent它会自己规划“搜索相关论文 - 阅读并总结 - 提出假设 - 寻找数据验证”等步骤并在遇到困难时尝试替代方案。这需要强大的规划模块、丰富的工具库、以及长期/短期记忆机制。多智能体协作系统这是复杂度的顶峰。系统内存在多个具有不同角色和能力的Agent如分析师、撰稿人、审核员它们通过特定的通信协议进行协作共同完成一个复杂目标。这涉及到Agent间的通信、协商、任务分配与结果整合对系统的架构设计提出了极高要求。你的项目属于哪一类这是选择技术路径的首要问题。一个单任务助手你可能只需要一个脚本和OpenAI的API调用而一个多智能体系统几乎必然需要一套框架来管理其中的复杂性。2.2 核心组件拆解不用框架你需要自己实现什么无论用不用框架一个功能完整的Agent通常都包含以下几个核心组件大脑LLM集成层负责与大型语言模型交互。这不仅仅是发个HTTP请求那么简单你需要处理不同模型提供商OpenAI, Anthropic, 国内各大厂的API差异、统一的请求/响应封装、流式输出处理、Token计数与成本控制、失败重试与降级策略等。工具Tool/Function Calling让Agent能够操作外部世界。你需要定义工具的描述让LLM理解工具能做什么、调用规范输入输出格式、执行器实际运行代码并确保它们能安全、稳定地运行。记忆MemoryAgent的“经验”。包括对话历史短期记忆、向量数据库存储的长期知识、以及执行过程中的关键事实缓存。你需要设计数据的存储、检索、更新和淘汰机制。规划与控制流OrchestrationAgent的“思考”过程。对于简单任务可能是线性的链式调用LangChain的Chain对于复杂任务则需要像ReAct这样的循环推理-执行框架或者更复杂的任务分解与调度算法。评估与监控Evaluation Observability如何知道你的Agent工作得好不好你需要设计评估指标准确性、效率、成本并搭建日志、追踪Tracing系统来监控每一次交互的细节便于调试和优化。如果不用框架以上每一个组件你都需要从零开始设计和实现。这不仅仅是编码的工作量更是架构设计、抽象边界定义和长期维护的挑战。3. 主流Agent框架全景图与选型逻辑当前市面上的Agent框架可谓百花齐放各有侧重。我们可以将其大致分为三类框架类别代表项目核心特点适用场景学习与上手成本全能型/应用开发框架LangChain, LangGraph组件丰富生态庞大提供了从模型交互、提示工程、记忆、工具调用到工作流编排的全套工具箱。LangGraph特别擅长构建有状态的、循环的Agent。快速构建功能全面的Agent应用尤其是涉及复杂工作流和多步骤推理的场景。适合产品化探索。高。概念多抽象层次高初期需要花时间理解其设计哲学。轻量级/库型框架LlamaIndex, Semantic Kernel更专注于某一领域。LlamaIndex擅长数据索引与检索RAGSemantic Kernel微软强调将传统代码技能与AI技能Plugins结合。如果你的Agent核心是复杂的文档处理与问答LlamaIndex或是深度集成在.NET生态中Semantic Kernel。中。目标更明确但深入使用仍需理解其核心概念。自主智能体专用框架AutoGPT, BabyAGI提供了“自主智能体”的参考实现内置了目标分解、任务执行循环等机制。学习、研究自主智能体的运行原理或基于此进行二次开发。中高。通常结构相对固定定制化需要修改其核心循环逻辑。学术研究/新范式框架LangStream采用流式处理Streaming架构来处理AI工作流强调实时性和可观测性。对实时性要求高的复杂事件处理管道或希望用全新架构探索Agent系统的团队。很高。概念新颖社区和资料相对较少。注意框架生态日新月异Hermes Agent、CrewAI等也是近期热门选择。选型时除了看功能更要关注社区的活跃度、文档的完善程度以及版本迭代的稳定性。3.1 为什么选择框架不仅仅是“快”很多文章会说用框架是为了“提高开发效率”这没错但太片面了。根据我的经验框架带来的深层价值至少包括降低认知与设计负担框架提供了一套经过验证的抽象和设计模式。你不需要从零思考“记忆应该怎么存”、“工具怎么描述LLM才能懂”。你可以直接站在巨人的肩膀上专注于你的业务逻辑。获得即时可用的最佳实践一个成熟的框架其内置的组件往往集成了社区的经验。例如LangChain的ConversationBufferWindowMemory会自动处理长上下文截断避免你重复造轮子甚至踩坑。生态与工具链集成框架通常有丰富的集成列表比如各种向量数据库、消息队列、监控工具。使用框架你可以轻松地接入这些基础设施而不用自己写适配器。团队协作与知识沉淀使用统一的框架意味着团队有共同的语言和范式。新成员入职、代码审查、模块复用都会变得更容易。3.2 框架的“另一面”那些令人头疼的代价然而拥抱框架并非没有成本尤其是对于快速变化的AI领域。抽象泄漏与灵活性丧失所有框架都在做一件事在“通用性”和“易用性”之间做权衡。为了让你用起来简单它必须隐藏复杂性。但当你遇到一个框架设计时未考虑的边界情况时这种被隐藏的复杂性就会“泄漏”出来迫使你去钻研框架源码甚至用一些“Hack”的方式绕过限制。此时你可能发现自己花在理解框架“黑魔法”上的时间比从头实现还要多。版本迭代的阵痛AI领域迭代极快底层模型API、最佳实践都在快速变化。框架为了跟进版本迭代也非常频繁。你可能这个月刚基于某个版本的LangChain写完代码下个月就发现某个核心接口被弃用了。依赖管理成为持续的负担。性能开销与调试黑盒框架层带来的额外抽象必然引入一定的性能开销。更重要的是当Agent出现诡异的行为比如调用了错误的工具时你的调试栈会变得很深。你需要判断问题是出在你的提示词、你的工具代码、框架对工具的描述封装、还是框架与LLM的交互逻辑上。调试过程如同在迷雾中寻路。“框架思维”的禁锢初学者很容易陷入“框架能做什么我就做什么”的思维定式。比如LangChain早期强调的“Chain”概念让很多人把一切逻辑都硬塞进Chain里导致代码冗长且难以维护。框架的范式可能会限制你对问题更本质、更优雅的解决方案的探索。我亲身经历过一个项目初期为了快重度依赖LangChain。但在实现一个需要复杂自定义中断和状态回滚的业务流程时我们发现LangChain的Chain和Agent抽象变得非常笨重代码充满了为了迎合框架而写的胶水代码。最终我们剥离了框架只用其底层的LLM调用和工具定义库自己用简单的异步任务队列重写了核心调度逻辑系统反而变得清晰且高效。4. “不用框架”的实践从零搭建一个最小可行Agent那么不用框架到底怎么做我们来实操一下构建一个最简单的“单任务自动化助手”一个命令行天气查询Agent。它接收用户如“北京天气怎么样”的查询调用天气API并返回结果。我们会清晰地看到哪些部分其实很简单哪些部分会随着复杂度提升而迅速变得棘手。4.1 第一步核心大脑——直接调用LLM API我们完全不需要LangChain的LLMChain直接使用openai官方库或其他SDK即可。import openai import os from typing import Dict, Any class SimpleLLMClient: def __init__(self, api_key: str, model: str gpt-3.5-turbo): openai.api_key api_key self.model model def chat_completion(self, messages: list) - str: 最基础的聊天补全调用 try: response openai.ChatCompletion.create( modelself.model, messagesmessages, temperature0.1, # 低随机性保证工具调用稳定 max_tokens500, ) return response.choices[0].message.content.strip() except Exception as e: return fLLM调用失败: {e} # 初始化 llm_client SimpleLLMClient(api_keyos.getenv(OPENAI_API_KEY))看不到20行代码我们就有了一个可靠的大脑。我们可以完全控制请求参数、错误处理。如果明天想换Anthropic的Claude我们只需要再写一个类似的AnthropicClient并统一接口。这里的核心价值是你彻底理解了与LLM交互最基本、最直接的单元是什么。4.2 第二步定义与调用工具框架里花里胡哨的tool装饰器、Tool类其本质是什么就是让LLM能识别并触发一段Python函数。1. 定义工具函数import requests def get_current_weather(location: str) - str: 获取指定城市的当前天气情况。 Args: location: 城市名例如“北京”、“上海”。 Returns: 关于天气情况的字符串描述。 # 这里使用一个模拟的天气API。真实场景可替换为心知天气、和风天气等。 # 为简化示例我们返回模拟数据。 weather_data { 北京: 晴15°C西北风2级空气质量良。, 上海: 多云18°C东南风1级空气质量优。, 广州: 阵雨25°C南风3级空气质量良。 } return weather_data.get(location, f抱歉未找到{city}的天气信息。) # 工具库字典 TOOLS { get_current_weather: { function: get_current_weather, description: 获取某个城市的当前天气情况。, parameters: { type: object, properties: { location: {type: string, description: 城市名如‘北京’、‘上海’。} }, required: [location] } } }我们手动创建了一个工具字典包含了函数本身、描述、以及符合OpenAI Function Calling格式的参数模式。关键点在于你清晰地知道一个工具的本质就是一个函数加上一段能让LLM理解的元数据描述。2. 让LLM决定是否调用及如何调用这是核心逻辑。我们需要构造提示词让LLM以特定格式如JSON输出它的“决策”。import json def run_agent_with_tools(user_query: str) - str: # 1. 构造系统提示告诉LLM可用的工具和输出格式 system_prompt f 你是一个天气助手。请根据用户问题决定是否需要调用工具。 你可以使用的工具如下 {json.dumps([{name: k, description: v[description], parameters: v[parameters]} for k, v in TOOLS.items()], ensure_asciiFalse)} 请严格按以下JSON格式回复 {{ thought: 你的思考过程分析用户意图。, use_tool: true/false, tool_name: 如果需要调用工具填写工具名否则为null, tool_input: {{}} // 如果需要调用工具填写工具输入参数的字典 }} # 2. 调用LLM获取决策 messages [ {role: system, content: system_prompt}, {role: user, content: user_query} ] llm_decision_str llm_client.chat_completion(messages) # 3. 解析LLM的决策 try: decision json.loads(llm_decision_str) except json.JSONDecodeError: return 抱歉我无法理解你的请求。 # 4. 执行决策 if decision.get(use_tool) and decision.get(tool_name) in TOOLS: tool_name decision[tool_name] tool_input decision.get(tool_input, {}) tool_func TOOLS[tool_name][function] # 执行工具 tool_result tool_func(**tool_input) # 5. 将工具结果返回给LLM让它生成最终回复 final_messages messages [ {role: assistant, content: llm_decision_str}, {role: user, content: f工具调用结果{tool_result}。请根据这个结果回答用户最初的问题。} ] final_response llm_client.chat_completion(final_messages) return final_response else: # 不需要调用工具直接返回LLM的初始回复需从decision中提取或重新组织 return decision.get(thought, 我无法处理这个请求。)这个run_agent_with_tools函数就是一个最简化的Agent执行循环。它包含了任务理解、工具决策、工具执行、结果整合。虽然简陋但五脏俱全。4.3 第三步运行与迭代if __name__ __main__: query 请问上海今天天气如何 response run_agent_with_tools(query) print(f用户: {query}) print(f助手: {response})运行它你会看到整个流程是如何一步步执行的。这个练习的价值在于你亲手实现了ReAct模式的核心循环。你理解了工具调用中“描述”和“执行”的分离。你掌握了Agent最基础的状态流转。当你想增加“记忆”功能时你会自然地想到在messages列表里持久化历史对话。当你想支持“多个工具”时你会扩展TOOLS字典和提示词。当流程出错时你可以清晰地在你写的每一个步骤里打日志、设断点。5. 决策时刻一张帮你做选择的评估清单所以回到最初的问题你真的需要框架吗我的建议是不要问“要不要”而是问“什么时候要以及要什么”。你可以根据下面这个清单来评估考虑从零开始或仅用极简封装的情况✅项目处于极早期概念验证PoC阶段你的目标是快速验证“这个想法用AI能不能跑通”功能极其简单比如只有1-2个工具线性流程。自己写几个函数比引入一个框架更快。✅你对Agent的核心机制有强烈的学习欲望你想彻底弄懂工具调用、规划、记忆到底是怎么工作的。亲手实现一遍是最好的老师。✅你的需求非常特殊与主流框架的范式格格不入例如你需要极致的性能、非常规的通信协议、或者与现有遗留系统深度耦合。框架的抽象可能成为阻碍。✅项目规模很小且长期维护预期低一个一次性脚本或内部小工具。考虑引入一个成熟框架的情况✅你需要快速构建一个功能相对完整的演示或产品原型框架提供的现成组件聊天记忆、文档加载器、各种工具集成能帮你节省大量时间。✅项目复杂度中高涉及多步骤、有条件逻辑的工作流例如LangGraph提供的图状态机能帮你直观地设计和调试复杂流程比自己管理状态和跳转要可靠得多。✅团队协作开发需要统一的架构和代码规范框架提供了一套共同语言降低了沟通成本。✅你需要紧密跟随社区的最新实践和工具生态框架社区通常会快速集成最新的模型、工具和最佳实践。一个实用的混合策略在我的项目中我越来越倾向于一种“混合架构”核心交互层保持轻量对于LLM的调用、基础的工具定义和调用我倾向于自己封装一个薄薄的、符合项目需求的客户端。这让我对最核心的交互有完全的控制力和可调试性。在需要复杂编排时引入框架当业务逻辑涉及到复杂的、有状态的工作流时我会考虑引入像LangGraph这样的框架专门负责这一部分。把它当作一个“工作流引擎”来用而不是全盘接受它的所有抽象。把框架当作“组件库”而非“脚手架”不一定要全盘采用某个框架。可以只使用其中一两个解决特定问题的优秀组件比如LlamaIndex的RAG检索器或者LangChain里某个特别好用的文档加载器。最终衡量技术选型是否正确的唯一标准是它是否帮助你更高效、更可靠地解决了业务问题并且其长期维护成本在可接受范围内。对于Agent开发框架是强大的加速器但不是唯一的引擎。理解引擎本身如何工作能让你无论是否使用加速器都开得更稳、更远。在你下一个Agent项目启动前不妨先花半小时用最原始的方式勾勒出它的核心循环这或许会让你对是否需要框架、需要什么样的框架有一个完全不同的、更清晰的认识。