1. 从“不值钱”的接口调用说起一个普遍的技术幻觉最近和不少做AI应用的朋友聊天发现一个挺有意思的现象很多人吭哧吭哧调通了某个大模型的API把一段用户输入塞进去再把返回的文本展示出来就觉得自己已经“搞定”了LLM集成可以开始做产品了。但聊到商业模式或者技术壁垒时往往又底气不足因为大家心里都清楚这活儿技术含量不高门槛低可替代性太强。你调的是GPT-4还是Claude对用户来说可能没本质区别最后拼的可能是谁的接入更稳定、谁的包装更花哨或者更直接一点——谁的价格更低。这就是标题里说的“不值钱”的状态你的工作停留在简单的“传声筒”层面没有创造独特的、难以复制的价值。这种“不值钱”的根源在于对LLM能力的理解过于表层。你把LLM当作一个“更聪明的搜索引擎”或者一个“万能文本生成器”那它的价值上限就被框定在了“信息检索与重组”的范畴内。在这个范畴里竞争是高度同质化的。真正的价值跃迁发生在你把LLM从一个被动的“应答机”转变为一个主动的、有状态的、能调用工具并完成复杂任务的“智能体”Agent。这不仅仅是换个说法而是整个开发范式和价值逻辑的根本转变。今天我们就抛开那些高大上的概念从零开始聊聊怎么把LLM从一个“接口调用”变成真正有价值的“Agent”这才是当前AI应用开发的核心战场。2. 拆解Agent不止是“调用”更是“调度”与“执行”当我们谈论Agent时我们在谈论什么它不是一个具体的库或者框架而是一种架构思想。一个最简化的Agent核心循环通常包含三个部分感知Perception、规划Planning、执行Execution。LLM在其中扮演的是“大脑”的角色负责理解和规划但它自己“手无寸铁”。让Agent真正产生价值的是它为这个“大脑”装配的“四肢”和“工具箱”——也就是外部工具Tools的调用能力。2.1 从“问答”到“任务”的范式迁移传统接口调用是“一问一答”模式输入用户问题字符串。处理将字符串发送给LLM。输出LLM生成的回答字符串。价值点完全依赖于LLM的内置知识和文本生成能力。Agent模式是“任务达成”模式输入用户目标例如“帮我查一下北京明天飞上海的航班选中午前后的价格低于1000的并总结成表格”。处理感知/理解LLM解析用户目标识别出关键实体北京、上海、明天、中午、价格1000和意图查询、筛选、格式化。规划LLM制定计划。例如“第一步我需要调用‘航班查询API’参数是出发地、目的地、日期。第二步对返回的航班列表进行时间筛选保留‘中午前后’的。第三步进行价格筛选保留低于1000的。第四步将结果格式化成Markdown表格。”执行LLM根据规划按顺序调用相应的工具Tools。它自己不会查航班但它可以生成符合航班查询API要求的参数然后由系统去执行这个API调用把结果返回给LLM。LLM再根据结果进行下一步判断和工具调用。输出一个结构化的航班信息表格。价值点LLM的推理和规划能力 你集成的外部工具能力 你设计的任务流程管控能力。这三者的结合创造了一个LLM本身不具备的新能力——完成需要与外界交互的复杂任务。2.2 工具Tools是Agent的价值放大器没有工具的Agent就像只有战略家没有军队的司令部想法再好也落不了地。工具的定义非常广泛数据查询工具连接数据库、调用第三方API天气、股票、航班、电商。计算工具执行数学运算、调用专业计算库。软件操作工具通过代码操作浏览器、操作本地文件如读写Excel、Word、发送邮件。硬件控制工具在嵌入式或物联网场景中发送指令控制设备。你为Agent集成的工具集直接决定了它的能力边界和应用场景。一个只能聊天的Agent和一个能帮你自动分析数据报表、生成简报并发送邮件的Agent其价值天差地别。这里的开发工作就从“如何更好地提示LLM”变成了“如何为LLM设计一套好用、安全、可靠的工具调用机制”。3. 构建你的第一个Agent避开LangChain从核心逻辑入手市面上有很多优秀的Agent框架比如LangChain、LangGraph、Dify、Semantic Kernel等。它们封装了很多便利功能但一开始就扎进去容易让人迷失在框架的复杂性中而忽略了Agent的本质。我建议先从最原始的方式亲手实现一个核心循环把骨头架子搭起来。3.1 定义工具Tools的契约首先我们需要明确工具如何与LLM交互。一个通用的设计是每个工具需要提供名称nameLLM用来指代它的标识符。描述description用自然语言清晰描述这个工具的功能、输入和输出。这部分描述直接作为系统提示词的一部分是LLM能否正确使用该工具的关键。描述要具体比如“查询指定城市当前天气输入参数为城市名字符串返回该城市的温度和天气状况字符串”。参数模式parameters定义输入参数的JSON Schema。这有助于LLM生成结构化的调用请求也便于系统进行参数验证。执行函数function实际的代码逻辑接收解析后的参数执行操作并返回结果。下面是一个简单的天气查询工具的定义示例以Python伪代码风格呈现# 工具定义 weather_tool { name: get_current_weather, description: 获取指定城市的当前天气情况。输入应为包含location键的字典如{location: 北京}。返回该城市的天气描述。, parameters: { type: object, properties: { location: { type: string, description: 城市名称例如北京、上海 } }, required: [location] }, function: lambda args: call_weather_api(args[location]) # 实际调用API的函数 } # 工具调用执行器 def execute_tool(tool_name, arguments): for tool in available_tools: # available_tools 是你注册的所有工具列表 if tool[name] tool_name: # 这里可以加入参数验证、错误处理、日志等 return tool[function](arguments) raise ValueError(fTool {tool_name} not found.)3.2 设计系统提示词System Prompt系统提示词是Agent的“宪法”它规定了LLM在本次对话中的角色、能力和行为准则。一个基础的Agent系统提示词应包含你是一个有帮助的AI助手可以调用工具来帮助用户解决问题。 你拥有以下工具 {{tools_descriptions}} 调用工具时请严格按照以下JSON格式响应 { thought: 你的思考过程解释为什么现在要调用这个工具, tool: 工具名称, args: {参数1: 值1, 参数2: 值2} } 如果不需要调用工具就能直接回答用户或者所有工具调用已完成、任务已解决请用自然语言直接回复用户。 当前对话历史 {{chat_history}} 用户最新问题{{user_input}} 请开始你的响应。这里的关键是把所有工具的name和description动态插入到{{tools_descriptions}}位置。LLM会根据这些描述来决定何时、如何调用工具。3.3 实现主控循环Agent Loop这是Agent的大脑中枢负责与LLM交互并管理整个流程。def simple_agent_loop(user_input, chat_history[]): # 1. 构建包含工具描述和历史的完整提示词 full_prompt build_system_prompt(tools_descriptions, chat_history, user_input) # 2. 调用LLM获取响应 llm_response call_llm_api(full_prompt) # 3. 解析LLM响应 try: # 尝试解析为工具调用 action json.loads(llm_response) if tool in action and args in action: # 4. 执行工具调用 tool_result execute_tool(action[tool], action[args]) # 5. 将工具执行结果作为新的上下文再次调用LLM new_history chat_history [ {role: user, content: user_input}, {role: assistant, content: llm_response}, # LLM发出的工具调用请求 {role: tool, content: tool_result} # 工具执行结果 ] # 递归或循环进入下一轮LLM会根据工具结果决定下一步 return simple_agent_loop(继续处理, new_history) except json.JSONDecodeError: # 如果无法解析为JSON说明LLM直接给出了最终回答 pass # 6. 返回最终的自然语言结果 return llm_response这个循环虽然简单但涵盖了Agent最核心的“思考-行动-观察”循环。通过这个手写的过程你会深刻理解Agent开发的核心是设计LLM与外部环境工具的交互协议并可靠地管理这个交互过程的状态。4. 从简单循环到复杂工作流处理现实世界的挑战上面的简单循环能处理一步到位的工具调用。但现实任务往往是多步的、有条件分支的、甚至可能出错的。这时就需要引入更复杂的工作流管理。这就是为什么会有LangGraph这类框架它们本质上是在帮你管理一个“状态机”。4.1 状态State管理是关键在复杂任务中Agent需要记住之前做了什么、得到了什么结果、当前处在计划的哪一步。我们需要一个共享的“状态”对象在循环的每一步中被读取和更新。状态通常包括用户输入最初的目标。对话历史所有LLM消息、工具调用和结果的完整记录。中间结果例如第一步查询到的原始航班列表。当前步骤标识工作流进展到哪一步。4.2 实现一个带状态的多步Agent假设我们要完成“查询天气并推荐穿衣”的任务这需要两步1. 查天气2. 根据天气结果生成推荐。class AgentState: def __init__(self, user_input): self.original_input user_input self.messages [] # 对话历史 self.intermediate_data {} # 中间结果如 {weather_result: 北京晴25度} self.step start def multi_step_agent(state): while state.step ! finished: if state.step start: # 提示LLM去调用天气工具 prompt f用户想知道{state.original_input}。请调用天气查询工具。 llm_response, tool_call get_llm_response_with_tool(prompt, state.messages) if tool_call: weather_result execute_tool(tool_call[name], tool_call[args]) state.intermediate_data[weather_result] weather_result state.messages.append({role: tool, content: weather_result}) state.step analyze_weather # 状态转移 elif state.step analyze_weather: # 提示LLM根据天气结果生成推荐 prompt f这是查询到的天气{state.intermediate_data[weather_result]}。请根据这个天气为用户提供穿衣建议。 final_response call_llm_api(prompt, state.messages) state.messages.append({role: assistant, content: final_response}) state.step finished return state.messages[-1][content] # 返回最终回复在这个例子中我们显式地定义了状态和步骤转移。对于更复杂的、动态生成计划的任务我们需要LLM自己来决策下一步做什么这就是“规划”Planning能力。我们可以让LLM在每次响应时不仅决定调用哪个工具还能输出一个对当前任务完成度的判断或者下一步的打算主控循环根据这个判断来决定是继续还是结束。4.3 错误处理与鲁棒性这是区分玩具项目和可用系统的关键。工具调用可能失败API超时、参数错误、权限不足LLM的响应可能不符合预期不输出JSON、调用不存在的工具。你的Agent循环必须能处理这些异常。工具调用失败捕获异常将错误信息如“网络超时请重试”作为工具执行结果返回给LLM让LLM决定是重试、换种方式还是向用户求助。LLM响应解析失败可以设计一个“重试”机制用更明确的提示词如“请务必以指定的JSON格式回复”再次询问LLM或者降级为直接回复LLM的自然语言输出。无限循环防护设置最大循环次数或超时时间防止Agent陷入死循环。5. 超越基础提升Agent价值的实战技巧理解了基础架构我们就可以聊聊如何让你的Agent从“能跑”变得“好用”、“强大”从而创造真正的商业或技术价值。5.1 工具设计的艺术让LLM“好用”你的工具工具的描述description是LLM理解它的唯一途径。糟糕的描述会导致误用或不用。好描述“计算两个地点之间的驾车距离和时间。输入需要包含origin起点地址和destination终点地址两个字段。返回一个包含distance距离公里和duration时间分钟的字典。”差描述“算距离的。” 或者 “调用地图API。”好的描述要具体、无歧义、示例化。甚至可以提供几个调用示例。这本质上是在为LLM编写API文档。5.2 记忆Memory与上下文管理简单的对话历史记录很快会耗尽LLM的上下文窗口。对于长对话或复杂任务需要更智能的记忆机制。摘要式记忆定期将冗长的对话历史总结成一段精炼的摘要作为新的上下文开头。向量记忆将历史对话中的关键信息如用户偏好、已执行的操作结果转换成向量存入向量数据库。当需要相关信息时进行向量检索只把最相关的片段喂给LLM。这能极大扩展Agent的“记忆”容量。状态记忆将我们前面提到的AgentState持久化到数据库实现跨会话的任务恢复。比如一个处理了半小时的复杂数据分析任务用户可以中途离开下次回来时Agent能从断点继续。5.3 规划Planning能力的强化对于复杂任务让LLM一次性规划所有步骤Plan-and-Execute可能不靠谱容易“一步错步步错”。更先进的模式是ReAct模式让LLM在每一步都进行“思考”Reason解释当前状况和下一步行动的原因然后再行动Act。这提高了每一步决策的可解释性和正确率。我们在3.3节的示例中要求LLM输出thought字段就是ReAct的雏形。任务分解与反思让LLM先将大任务分解成子任务列表Tree of Thoughts然后逐个执行。每个子任务完成后可以进行“反思”Reflection检查结果是否合理是否需要调整后续计划。5.4 评估与监控Agent的“仪表盘”一个投入使用的Agent必须可观测、可评估。日志记录详细记录每一轮的用户输入、LLM的完整响应包括思维链、工具调用详情参数、结果、耗时、最终输出。关键指标统计任务完成率、工具调用准确率、平均对话轮数、用户满意度如果有反馈机制。错误分析定期查看失败案例分析是工具问题、提示词问题还是LLM本身的能力边界问题。这是迭代优化Agent的最重要依据。6. 技术栈选型与学习路径建议当你亲手实现过核心循环后再去看现有的框架就会豁然开朗知道它们各自在解决什么问题。LangChain / LangChain4j (Java): 提供了极其丰富的工具集成、记忆模块和链式组合能力。它的抽象层次很高能快速搭建原型但有时会让人觉得“黑盒”太多定制化复杂。适合需要快速集成多种数据源和工具构建复杂链式应用。LangGraph: 基于LangChain专注于构建有状态的、多智能体的工作流。它用图Graph来定义状态流转非常适合可视化复杂Agent的决策路径。适合构建涉及多步骤、有条件分支、甚至多个Agent协作的复杂系统。Semantic Kernel (微软): 设计理念类似与微软生态结合紧密。提供了很好的规划器和插件Plugins体系。Dify / Flowise (低代码平台): 通过可视化拖拽的方式编排工作流降低了使用门槛。适合产品经理、业务人员快速构建AI工作流原型或者对代码不熟悉的团队。但深度定制能力可能受限。自主开发轻量框架基于OpenAI的Function Calling、Anthropic的Tool Use或Google的Gemini Function Calling等原生支持工具调用的API自己封装状态管理和工作流引擎。适合对控制力要求高、场景相对固定的团队。学习路线建议理解核心概念吃透本文讲的Agent循环、工具、规划、状态这几个核心概念。手动实现迷你版用你最熟悉的语言Python/JS等基于任意一个LLM API推荐使用其原生工具调用支持实现一个3.3节那样的简单循环。这是最重要的环节。使用成熟框架选择一个主流框架如LangChain用它的方式重构你的迷你Agent理解它提供的各种模块Memory, Chains, Agents是如何封装这些核心概念的。深入特定场景选择一个你感兴趣的垂直领域如智能客服、数据分析助手、自动化办公用Agent的思路去设计解决方案并动手实现。在这个过程中你会遇到真实的数据、复杂的工具集成和诡异的边界情况这才是真正的学习。关注前沿与优化研究更高级的规划策略如ReAct, ToT、记忆优化方案、多智能体协作CrewAI, AutoGen等。回到最初的问题为什么单纯的LLM接口调用“不值钱”因为它的价值主体是LLM提供商如OpenAI创造的你只是渠道。而Agent开发的价值主体是你自己创造的——你定义了任务、集成了工具、设计了工作流、处理了异常、优化了体验。你构建的是一个基于LLM但远超LLM的、解决特定领域问题的智能系统。这个系统的设计能力、领域知识、工具生态和工程实现构成了你真正的、难以被简单复制的壁垒。这才是AI应用开发者应该全力投入的“正确姿势”。 从LLM接口调用到智能体：构建有价值AI应用的核心逻辑与实践
1. 从“不值钱”的接口调用说起一个普遍的技术幻觉最近和不少做AI应用的朋友聊天发现一个挺有意思的现象很多人吭哧吭哧调通了某个大模型的API把一段用户输入塞进去再把返回的文本展示出来就觉得自己已经“搞定”了LLM集成可以开始做产品了。但聊到商业模式或者技术壁垒时往往又底气不足因为大家心里都清楚这活儿技术含量不高门槛低可替代性太强。你调的是GPT-4还是Claude对用户来说可能没本质区别最后拼的可能是谁的接入更稳定、谁的包装更花哨或者更直接一点——谁的价格更低。这就是标题里说的“不值钱”的状态你的工作停留在简单的“传声筒”层面没有创造独特的、难以复制的价值。这种“不值钱”的根源在于对LLM能力的理解过于表层。你把LLM当作一个“更聪明的搜索引擎”或者一个“万能文本生成器”那它的价值上限就被框定在了“信息检索与重组”的范畴内。在这个范畴里竞争是高度同质化的。真正的价值跃迁发生在你把LLM从一个被动的“应答机”转变为一个主动的、有状态的、能调用工具并完成复杂任务的“智能体”Agent。这不仅仅是换个说法而是整个开发范式和价值逻辑的根本转变。今天我们就抛开那些高大上的概念从零开始聊聊怎么把LLM从一个“接口调用”变成真正有价值的“Agent”这才是当前AI应用开发的核心战场。2. 拆解Agent不止是“调用”更是“调度”与“执行”当我们谈论Agent时我们在谈论什么它不是一个具体的库或者框架而是一种架构思想。一个最简化的Agent核心循环通常包含三个部分感知Perception、规划Planning、执行Execution。LLM在其中扮演的是“大脑”的角色负责理解和规划但它自己“手无寸铁”。让Agent真正产生价值的是它为这个“大脑”装配的“四肢”和“工具箱”——也就是外部工具Tools的调用能力。2.1 从“问答”到“任务”的范式迁移传统接口调用是“一问一答”模式输入用户问题字符串。处理将字符串发送给LLM。输出LLM生成的回答字符串。价值点完全依赖于LLM的内置知识和文本生成能力。Agent模式是“任务达成”模式输入用户目标例如“帮我查一下北京明天飞上海的航班选中午前后的价格低于1000的并总结成表格”。处理感知/理解LLM解析用户目标识别出关键实体北京、上海、明天、中午、价格1000和意图查询、筛选、格式化。规划LLM制定计划。例如“第一步我需要调用‘航班查询API’参数是出发地、目的地、日期。第二步对返回的航班列表进行时间筛选保留‘中午前后’的。第三步进行价格筛选保留低于1000的。第四步将结果格式化成Markdown表格。”执行LLM根据规划按顺序调用相应的工具Tools。它自己不会查航班但它可以生成符合航班查询API要求的参数然后由系统去执行这个API调用把结果返回给LLM。LLM再根据结果进行下一步判断和工具调用。输出一个结构化的航班信息表格。价值点LLM的推理和规划能力 你集成的外部工具能力 你设计的任务流程管控能力。这三者的结合创造了一个LLM本身不具备的新能力——完成需要与外界交互的复杂任务。2.2 工具Tools是Agent的价值放大器没有工具的Agent就像只有战略家没有军队的司令部想法再好也落不了地。工具的定义非常广泛数据查询工具连接数据库、调用第三方API天气、股票、航班、电商。计算工具执行数学运算、调用专业计算库。软件操作工具通过代码操作浏览器、操作本地文件如读写Excel、Word、发送邮件。硬件控制工具在嵌入式或物联网场景中发送指令控制设备。你为Agent集成的工具集直接决定了它的能力边界和应用场景。一个只能聊天的Agent和一个能帮你自动分析数据报表、生成简报并发送邮件的Agent其价值天差地别。这里的开发工作就从“如何更好地提示LLM”变成了“如何为LLM设计一套好用、安全、可靠的工具调用机制”。3. 构建你的第一个Agent避开LangChain从核心逻辑入手市面上有很多优秀的Agent框架比如LangChain、LangGraph、Dify、Semantic Kernel等。它们封装了很多便利功能但一开始就扎进去容易让人迷失在框架的复杂性中而忽略了Agent的本质。我建议先从最原始的方式亲手实现一个核心循环把骨头架子搭起来。3.1 定义工具Tools的契约首先我们需要明确工具如何与LLM交互。一个通用的设计是每个工具需要提供名称nameLLM用来指代它的标识符。描述description用自然语言清晰描述这个工具的功能、输入和输出。这部分描述直接作为系统提示词的一部分是LLM能否正确使用该工具的关键。描述要具体比如“查询指定城市当前天气输入参数为城市名字符串返回该城市的温度和天气状况字符串”。参数模式parameters定义输入参数的JSON Schema。这有助于LLM生成结构化的调用请求也便于系统进行参数验证。执行函数function实际的代码逻辑接收解析后的参数执行操作并返回结果。下面是一个简单的天气查询工具的定义示例以Python伪代码风格呈现# 工具定义 weather_tool { name: get_current_weather, description: 获取指定城市的当前天气情况。输入应为包含location键的字典如{location: 北京}。返回该城市的天气描述。, parameters: { type: object, properties: { location: { type: string, description: 城市名称例如北京、上海 } }, required: [location] }, function: lambda args: call_weather_api(args[location]) # 实际调用API的函数 } # 工具调用执行器 def execute_tool(tool_name, arguments): for tool in available_tools: # available_tools 是你注册的所有工具列表 if tool[name] tool_name: # 这里可以加入参数验证、错误处理、日志等 return tool[function](arguments) raise ValueError(fTool {tool_name} not found.)3.2 设计系统提示词System Prompt系统提示词是Agent的“宪法”它规定了LLM在本次对话中的角色、能力和行为准则。一个基础的Agent系统提示词应包含你是一个有帮助的AI助手可以调用工具来帮助用户解决问题。 你拥有以下工具 {{tools_descriptions}} 调用工具时请严格按照以下JSON格式响应 { thought: 你的思考过程解释为什么现在要调用这个工具, tool: 工具名称, args: {参数1: 值1, 参数2: 值2} } 如果不需要调用工具就能直接回答用户或者所有工具调用已完成、任务已解决请用自然语言直接回复用户。 当前对话历史 {{chat_history}} 用户最新问题{{user_input}} 请开始你的响应。这里的关键是把所有工具的name和description动态插入到{{tools_descriptions}}位置。LLM会根据这些描述来决定何时、如何调用工具。3.3 实现主控循环Agent Loop这是Agent的大脑中枢负责与LLM交互并管理整个流程。def simple_agent_loop(user_input, chat_history[]): # 1. 构建包含工具描述和历史的完整提示词 full_prompt build_system_prompt(tools_descriptions, chat_history, user_input) # 2. 调用LLM获取响应 llm_response call_llm_api(full_prompt) # 3. 解析LLM响应 try: # 尝试解析为工具调用 action json.loads(llm_response) if tool in action and args in action: # 4. 执行工具调用 tool_result execute_tool(action[tool], action[args]) # 5. 将工具执行结果作为新的上下文再次调用LLM new_history chat_history [ {role: user, content: user_input}, {role: assistant, content: llm_response}, # LLM发出的工具调用请求 {role: tool, content: tool_result} # 工具执行结果 ] # 递归或循环进入下一轮LLM会根据工具结果决定下一步 return simple_agent_loop(继续处理, new_history) except json.JSONDecodeError: # 如果无法解析为JSON说明LLM直接给出了最终回答 pass # 6. 返回最终的自然语言结果 return llm_response这个循环虽然简单但涵盖了Agent最核心的“思考-行动-观察”循环。通过这个手写的过程你会深刻理解Agent开发的核心是设计LLM与外部环境工具的交互协议并可靠地管理这个交互过程的状态。4. 从简单循环到复杂工作流处理现实世界的挑战上面的简单循环能处理一步到位的工具调用。但现实任务往往是多步的、有条件分支的、甚至可能出错的。这时就需要引入更复杂的工作流管理。这就是为什么会有LangGraph这类框架它们本质上是在帮你管理一个“状态机”。4.1 状态State管理是关键在复杂任务中Agent需要记住之前做了什么、得到了什么结果、当前处在计划的哪一步。我们需要一个共享的“状态”对象在循环的每一步中被读取和更新。状态通常包括用户输入最初的目标。对话历史所有LLM消息、工具调用和结果的完整记录。中间结果例如第一步查询到的原始航班列表。当前步骤标识工作流进展到哪一步。4.2 实现一个带状态的多步Agent假设我们要完成“查询天气并推荐穿衣”的任务这需要两步1. 查天气2. 根据天气结果生成推荐。class AgentState: def __init__(self, user_input): self.original_input user_input self.messages [] # 对话历史 self.intermediate_data {} # 中间结果如 {weather_result: 北京晴25度} self.step start def multi_step_agent(state): while state.step ! finished: if state.step start: # 提示LLM去调用天气工具 prompt f用户想知道{state.original_input}。请调用天气查询工具。 llm_response, tool_call get_llm_response_with_tool(prompt, state.messages) if tool_call: weather_result execute_tool(tool_call[name], tool_call[args]) state.intermediate_data[weather_result] weather_result state.messages.append({role: tool, content: weather_result}) state.step analyze_weather # 状态转移 elif state.step analyze_weather: # 提示LLM根据天气结果生成推荐 prompt f这是查询到的天气{state.intermediate_data[weather_result]}。请根据这个天气为用户提供穿衣建议。 final_response call_llm_api(prompt, state.messages) state.messages.append({role: assistant, content: final_response}) state.step finished return state.messages[-1][content] # 返回最终回复在这个例子中我们显式地定义了状态和步骤转移。对于更复杂的、动态生成计划的任务我们需要LLM自己来决策下一步做什么这就是“规划”Planning能力。我们可以让LLM在每次响应时不仅决定调用哪个工具还能输出一个对当前任务完成度的判断或者下一步的打算主控循环根据这个判断来决定是继续还是结束。4.3 错误处理与鲁棒性这是区分玩具项目和可用系统的关键。工具调用可能失败API超时、参数错误、权限不足LLM的响应可能不符合预期不输出JSON、调用不存在的工具。你的Agent循环必须能处理这些异常。工具调用失败捕获异常将错误信息如“网络超时请重试”作为工具执行结果返回给LLM让LLM决定是重试、换种方式还是向用户求助。LLM响应解析失败可以设计一个“重试”机制用更明确的提示词如“请务必以指定的JSON格式回复”再次询问LLM或者降级为直接回复LLM的自然语言输出。无限循环防护设置最大循环次数或超时时间防止Agent陷入死循环。5. 超越基础提升Agent价值的实战技巧理解了基础架构我们就可以聊聊如何让你的Agent从“能跑”变得“好用”、“强大”从而创造真正的商业或技术价值。5.1 工具设计的艺术让LLM“好用”你的工具工具的描述description是LLM理解它的唯一途径。糟糕的描述会导致误用或不用。好描述“计算两个地点之间的驾车距离和时间。输入需要包含origin起点地址和destination终点地址两个字段。返回一个包含distance距离公里和duration时间分钟的字典。”差描述“算距离的。” 或者 “调用地图API。”好的描述要具体、无歧义、示例化。甚至可以提供几个调用示例。这本质上是在为LLM编写API文档。5.2 记忆Memory与上下文管理简单的对话历史记录很快会耗尽LLM的上下文窗口。对于长对话或复杂任务需要更智能的记忆机制。摘要式记忆定期将冗长的对话历史总结成一段精炼的摘要作为新的上下文开头。向量记忆将历史对话中的关键信息如用户偏好、已执行的操作结果转换成向量存入向量数据库。当需要相关信息时进行向量检索只把最相关的片段喂给LLM。这能极大扩展Agent的“记忆”容量。状态记忆将我们前面提到的AgentState持久化到数据库实现跨会话的任务恢复。比如一个处理了半小时的复杂数据分析任务用户可以中途离开下次回来时Agent能从断点继续。5.3 规划Planning能力的强化对于复杂任务让LLM一次性规划所有步骤Plan-and-Execute可能不靠谱容易“一步错步步错”。更先进的模式是ReAct模式让LLM在每一步都进行“思考”Reason解释当前状况和下一步行动的原因然后再行动Act。这提高了每一步决策的可解释性和正确率。我们在3.3节的示例中要求LLM输出thought字段就是ReAct的雏形。任务分解与反思让LLM先将大任务分解成子任务列表Tree of Thoughts然后逐个执行。每个子任务完成后可以进行“反思”Reflection检查结果是否合理是否需要调整后续计划。5.4 评估与监控Agent的“仪表盘”一个投入使用的Agent必须可观测、可评估。日志记录详细记录每一轮的用户输入、LLM的完整响应包括思维链、工具调用详情参数、结果、耗时、最终输出。关键指标统计任务完成率、工具调用准确率、平均对话轮数、用户满意度如果有反馈机制。错误分析定期查看失败案例分析是工具问题、提示词问题还是LLM本身的能力边界问题。这是迭代优化Agent的最重要依据。6. 技术栈选型与学习路径建议当你亲手实现过核心循环后再去看现有的框架就会豁然开朗知道它们各自在解决什么问题。LangChain / LangChain4j (Java): 提供了极其丰富的工具集成、记忆模块和链式组合能力。它的抽象层次很高能快速搭建原型但有时会让人觉得“黑盒”太多定制化复杂。适合需要快速集成多种数据源和工具构建复杂链式应用。LangGraph: 基于LangChain专注于构建有状态的、多智能体的工作流。它用图Graph来定义状态流转非常适合可视化复杂Agent的决策路径。适合构建涉及多步骤、有条件分支、甚至多个Agent协作的复杂系统。Semantic Kernel (微软): 设计理念类似与微软生态结合紧密。提供了很好的规划器和插件Plugins体系。Dify / Flowise (低代码平台): 通过可视化拖拽的方式编排工作流降低了使用门槛。适合产品经理、业务人员快速构建AI工作流原型或者对代码不熟悉的团队。但深度定制能力可能受限。自主开发轻量框架基于OpenAI的Function Calling、Anthropic的Tool Use或Google的Gemini Function Calling等原生支持工具调用的API自己封装状态管理和工作流引擎。适合对控制力要求高、场景相对固定的团队。学习路线建议理解核心概念吃透本文讲的Agent循环、工具、规划、状态这几个核心概念。手动实现迷你版用你最熟悉的语言Python/JS等基于任意一个LLM API推荐使用其原生工具调用支持实现一个3.3节那样的简单循环。这是最重要的环节。使用成熟框架选择一个主流框架如LangChain用它的方式重构你的迷你Agent理解它提供的各种模块Memory, Chains, Agents是如何封装这些核心概念的。深入特定场景选择一个你感兴趣的垂直领域如智能客服、数据分析助手、自动化办公用Agent的思路去设计解决方案并动手实现。在这个过程中你会遇到真实的数据、复杂的工具集成和诡异的边界情况这才是真正的学习。关注前沿与优化研究更高级的规划策略如ReAct, ToT、记忆优化方案、多智能体协作CrewAI, AutoGen等。回到最初的问题为什么单纯的LLM接口调用“不值钱”因为它的价值主体是LLM提供商如OpenAI创造的你只是渠道。而Agent开发的价值主体是你自己创造的——你定义了任务、集成了工具、设计了工作流、处理了异常、优化了体验。你构建的是一个基于LLM但远超LLM的、解决特定领域问题的智能系统。这个系统的设计能力、领域知识、工具生态和工程实现构成了你真正的、难以被简单复制的壁垒。这才是AI应用开发者应该全力投入的“正确姿势”。