30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度如果你还在把 ChatGPT 当作一个“更聪明的聊天机器人”那么你可能已经落后了。最近OpenAI 内部的一则重磅消息正在彻底改写我们对 AI 产品的认知ChatGPT 和 Codex 即将合并一个统一的“超级应用”正在浮出水面。这远不止是产品功能的简单叠加而是一次从“对话”到“执行”的范式转移。它意味着那个我们熟悉的、以问答为核心的 ChatGPT 时代正在被一个能真正“做事”的 AI Agent 时代所取代。对于开发者而言这不仅仅是新闻头条。它预示着未来 AI 应用的开发模式、技术栈选择乃至职业发展路径都将发生深刻变化。当 AI 从“回答问题”进化到“完成任务”我们该如何构建、调用和管理这些具备自主行动能力的智能体这背后涉及的技术架构、权限控制、任务规划与回滚机制正是我们接下来需要深入理解的核心。本文将从技术视角为你深度解析 OpenAI 这一战略调整背后的技术逻辑并提供一个从零开始构建一个简易 AI Agent 的实战指南。你将不仅理解“超级应用”的构成更能亲手搭建一个具备规划、执行和反思能力的 AI 助手原型。1. 这篇文章真正要解决的问题为什么 OpenAI 合并 ChatGPT 和 Codex 对开发者如此重要表面上看这只是一次产品整合但本质上它标志着 AI 应用开发的核心矛盾已经从“模型能力”转向了“任务执行”。过去三年我们见证了模型参数从千亿到万亿的飞跃但用户与 AI 的交互大多仍停留在“一问一答”的层面。用户提出需求AI 生成文本、代码或图片然后由用户手动执行后续步骤——复制代码到 IDE、整理数据到表格、点击网页按钮。这个“最后一公里”的断层极大地限制了 AI 的生产力释放。Codex 的出现最初是为了解决代码生成与执行的问题但它所沉淀的“长时间运行、多步骤规划、上下文保持、权限确认、结果验收”等能力恰恰是构建通用 AI Agent 的基石。OpenAI 的这次合并意图非常明确将 ChatGPT 强大的意图理解与自然交互能力与 Codex 的任务拆解与执行引擎相结合打造一个能闭环处理复杂任务的超级入口。对于开发者这意味着技术重心转移单纯调用大模型 API 生成文本将变得基础如何设计 Agent 的工作流、工具调用Tool Calling、状态管理和错误处理将成为新的技术壁垒。新的开发范式应用开发可能从“编写业务逻辑代码”转向“配置 AI Agent 的技能Skills与工作流Workflows”。安全与权限挑战当 AI 能够直接操作你的文件系统、数据库和第三方 API 时权限粒度、操作审计和回滚机制变得至关重要。因此本文旨在解决的核心问题是在 AI 从聊天走向执行的转折点上作为一名开发者如何理解背后的技术架构并快速掌握构建可执行、可信任的 AI Agent 的核心技能我们将通过一个完整的实战项目带你跨越从概念到实现的门槛。2. 基础概念与核心原理从 LLM 到 AI Agent在深入实战之前我们需要厘清几个关键概念。很多人容易混淆“大语言模型LLM”、“AI 助手”和“AI Agent”。大语言模型LLM如 GPT-4、Claude 等本质是一个基于概率预测下一个词Token的模型。它擅长理解和生成文本但自身没有目标、没有记忆除非通过上下文窗口、不会主动调用工具。AI 助手Chatbot基于 LLM 构建的交互界面例如初代的 ChatGPT。它通过对话历史上下文来维持短期记忆能够进行多轮对话但其核心能力依然是“说”而不是“做”。它无法自主操作浏览器、修改本地文件或调用 API。AI Agent智能体这是一个更高级的概念。一个真正的 AI Agent 具备以下核心特征目标导向接收一个高级目标如“为我分析上个月的销售数据并生成报告”。自主规划能够将目标拆解为一系列可执行的子任务连接数据库、查询数据、清洗数据、分析趋势、生成图表、撰写文字。工具调用具备调用外部工具的能力如执行 Python 代码、读写文件、调用搜索引擎 API、操作浏览器等。状态感知与反思能够根据工具执行的结果成功/失败感知当前状态并动态调整后续计划。例如如果数据库连接失败它会尝试另一种连接方式或报告错误。长时记忆能够将本次任务的经验和结果存储下来供未来类似任务参考而不仅仅依赖于有限的对话上下文。用一个简单的类比LLM 是汽车的“发动机”AI 助手是有了“方向盘和座椅”的汽车而AI Agent 则是搭载了“自动驾驶系统”的汽车。自动驾驶系统Agent需要理解目的地目标规划路线规划控制油门刹车工具调用并根据路况环境反馈实时调整。OpenAI 推动 ChatGPT 与 Codex 合并正是希望将 ChatGPT 从一辆“能聊天的车”升级为具备“自动驾驶系统”的智能座驾。Codex 在此扮演的正是这套自动驾驶系统的核心执行与规划模块。3. 环境准备与前置条件为了构建我们的第一个 AI Agent我们将使用当前最主流、对开发者最友好的框架之一LangChain。它抽象了与多种 LLM 的交互、工具调用、记忆存储等复杂逻辑让我们能更专注于 Agent 的设计。本项目环境要求操作系统Windows 10/11, macOS, 或 Linux (本文示例基于 macOS/Linux 命令行)。Python版本 3.8 或更高。这是硬性要求。包管理工具pip(Python 自带)。代码编辑器VS Code、PyCharm 或任何你熟悉的编辑器。OpenAI API Key这是调用 GPT 模型所必需的。你需要注册 OpenAI 平台并获取 API Key。请注意保管不要泄露。第一步创建并激活 Python 虚拟环境强烈建议使用虚拟环境来管理项目依赖避免包冲突。# 创建项目目录并进入 mkdir my-first-ai-agent cd my-first-ai-agent # 创建虚拟环境以 venv 为例 python3 -m venv venv # 激活虚拟环境 # 在 macOS/Linux 上 source venv/bin/activate # 在 Windows 上 # venv\Scripts\activate # 激活后命令行提示符前通常会出现 (venv) 标识第二步安装核心依赖我们将安装langchain、langchain-openai用于连接 OpenAI以及langchain-community包含一些社区工具。pip install langchain langchain-openai langchain-community第三步设置 OpenAI API Key不要将 API Key 硬编码在代码中。最佳实践是使用环境变量。# 在 macOS/Linux 上 export OPENAI_API_KEY你的-api-key-here # 在 Windows (PowerShell) 上 # $env:OPENAI_API_KEY你的-api-key-here或者在代码中通过os.environ设置仅用于演示生产环境请勿使用import os os.environ[OPENAI_API_KEY] 你的-api-key-here环境准备就绪接下来我们将进入核心部分设计并实现一个能真正“做事”的 Agent。4. 核心流程拆解构建一个数学计算与文件操作 Agent我们将构建一个相对简单但功能完整的 Agent它能够理解用户关于数学计算和简单文件操作的需求并自主调用工具完成任务。这个 Agent 将具备以下能力进行数学运算如(12 3) * 4。读取指定文本文件的内容。将文本内容写入新文件。这个例子虽小但完整涵盖了目标理解 - 工具选择 - 执行 - 返回结果的 Agent 核心工作流。整体工作流如下初始化 Agent加载 LLM我们使用 GPT-3.5-turbo成本较低并为其装备工具Tools。定义工具创建三个工具函数并用tool装饰器包装让 LLM 能识别和调用。创建 Agent 执行器使用 LangChain 的create_react_agent来构建一个采用 ReAct 推理框架的 Agent。ReActReasoning Acting是一种让 LLM 在思考Reasoning和行动Acting间交替进行的范式能显著提升复杂任务的处理能力。运行 Agent向 Agent 输入一个包含多个步骤的复杂指令观察其自主规划与执行过程。解析与输出获取 Agent 的完整思考链和最终结果。5. 完整示例与代码实现现在让我们开始编写代码。在项目根目录下创建一个名为math_file_agent.py的文件。# math_file_agent.py import os from langchain import hub from langchain.agents import create_react_agent, AgentExecutor from langchain.tools import tool from langchain_openai import ChatOpenAI from langchain_core.prompts import PromptTemplate # 确保已设置 OPENAI_API_KEY 环境变量 # 初始化 LLM使用 gpt-3.5-turbo 以控制成本 llm ChatOpenAI(modelgpt-3.5-turbo, temperature0) # --- 第1步定义工具Tools--- # 工具是 Agent 的“手”和“脚”。每个工具都是一个函数用 tool 装饰器标记。 tool def calculate(expression: str) - str: 执行一个数学表达式计算。支持加减乘除和括号。 try: # 警告使用 eval 存在安全风险此处仅用于演示。 # 在生产环境中必须使用更安全的表达式求值库如 ast.literal_eval或严格验证输入。 result eval(expression) return f计算 {expression} 的结果是{result} except Exception as e: return f计算表达式 {expression} 时出错{e} tool def read_file(filepath: str) - str: 读取指定路径的文本文件并返回其内容。 try: with open(filepath, r, encodingutf-8) as f: content f.read() return f文件 {filepath} 的内容是\n\n{content}\n except FileNotFoundError: return f错误找不到文件 {filepath}。 except Exception as e: return f读取文件 {filepath} 时出错{e} tool def write_file(filepath: str, content: str) - str: 将内容写入指定路径的文本文件。如果文件已存在会被覆盖。 try: with open(filepath, w, encodingutf-8) as f: f.write(content) return f成功将内容写入文件 {filepath}。 except Exception as e: return f写入文件 {filepath} 时出错{e} # 将工具放入列表供 Agent 使用 tools [calculate, read_file, write_file] # --- 第2步创建 Agent --- # ReAct 是一种流行的 Agent 框架它鼓励模型“思考”一步再“行动”一步。 # LangChain 提供了预设的 ReAct 提示词模板我们从 Hub 拉取。 prompt hub.pull(hwchase17/react) # 使用工具和提示词创建 ReAct Agent agent create_react_agent(llm, tools, prompt) # 创建 Agent 执行器它负责运行 Agent 的循环思考 - 选择工具 - 执行 - 观察 - 再思考... agent_executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) # --- 第3步运行 Agent --- print( AI Agent 演示开始 ) # 我们给 Agent 一个需要多步规划的任务 query 请帮我完成以下任务 1. 计算表达式 (15 7) * 3 的值。 2. 读取当前目录下名为 input.txt 的文件内容。 3. 将第一步的计算结果和第二步读取的文件内容一起写入一个新文件 output.txt 中。 请按顺序执行。 print(f用户指令\n{query}\n) print(Agent 执行过程) result agent_executor.invoke({input: query}) # --- 第4步输出最终结果 --- print(\n 最终执行结果 ) print(result[output])代码关键逻辑解释工具定义 (tool)tool装饰器不仅将普通函数标记为 Agent 可用的工具还会自动根据函数名和文档字符串内的内容为 LLM 生成工具的描述。LLM 依靠这些描述来决定在什么情况下调用哪个工具。文档字符串至关重要必须清晰描述工具的功能和输入格式。安全警告calculate工具中使用了eval()这在演示中很方便但在真实生产环境是极度危险的因为它会执行任意代码。实际项目中应替换为安全的数学表达式解析库如ast.literal_eval用于简单表达式或numexpr。Agent 创建 (create_react_agent)我们使用了 LangChain 的高级 API 来快速构建一个基于 ReAct 策略的 Agent。hwchase17/react是一个社区维护的优质提示词模板它指导 LLM 按照“Thought思考”、“Action行动”、“Observation观察”的步骤循环。AgentExecutor这是驱动 Agent 运行的核心组件。verboseTrue会打印出 Agent 详细的思考过程这对于调试和理解 Agent 行为非常有用。handle_parsing_errorsTrue能处理 LLM 输出格式偶尔不符合预期的情况增强鲁棒性。复杂查询我们设计的查询指令包含了三个有依赖关系的子任务计算 - 读文件 - 写文件这要求 Agent 必须进行任务规划和状态管理而不能简单地进行一次工具调用。6. 运行结果与效果验证在运行 Agent 之前我们需要先创建一个input.txt文件供它读取。# 在项目根目录下创建一个简单的输入文件 echo 这是来自 input.txt 的原始内容。 input.txt现在运行我们的 Agent 脚本python math_file_agent.py你将看到类似以下的详细输出为简洁起见略有删减 AI Agent 演示开始 用户指令 此处显示你的查询 Agent 执行过程 进入新的 AgentExecutor 链... 思考我需要按顺序完成用户要求的三个任务。首先计算表达式 (15 7) * 3。 行动调用工具 calculate。 行动输入{expression: (15 7) * 3} 观察计算 (15 7) * 3 的结果是66 思考第一步完成。现在进行第二步读取 input.txt 文件。 行动调用工具 read_file。 行动输入{filepath: input.txt} 观察文件 input.txt 的内容是这是来自 input.txt 的原始内容。思考第二步完成。现在进行第三步将计算结果66和文件内容写入 output.txt。我需要将两者组合成一段文本。 行动调用工具 write_file。 行动输入{filepath: output.txt, content: 计算结果66\n原文件内容这是来自 input.txt 的原始内容。} 观察成功将内容写入文件 output.txt。 思考所有三个任务都已完成。我可以给用户最终答复了。 链结束。 最终执行结果 我已按顺序完成了您要求的任务 1. 计算了表达式 (15 7) * 3结果是 66。 2. 读取了文件 input.txt 的内容。 3. 已将计算结果和原文件内容合并并写入新文件 output.txt。验证结果控制台输出Agent 清晰地展示了其“思考-行动-观察”的完整链条证明了其自主规划能力。生成文件检查项目目录会发现新生成了一个output.txt文件。cat output.txt输出应为计算结果66 原文件内容这是来自 input.txt 的原始内容。至此你已经成功构建并运行了一个具备多步规划与执行能力的 AI Agent。它理解了你的复合指令自主拆解任务正确选择了工具并按顺序执行最终完成了目标。7. 常见问题与排查思路在开发 AI Agent 过程中你可能会遇到以下典型问题问题现象可能原因排查方式解决方案ModuleNotFoundError: No module named ‘langchain’依赖未安装或虚拟环境未激活。1. 确认命令行提示符前有(venv)。2. 运行pip list | grep langchain检查。1. 激活虚拟环境source venv/bin/activate。2. 重新安装pip install langchain ...。AuthenticationError: Incorrect API key providedOpenAI API Key 未设置或错误。1. 检查echo $OPENAI_API_KEY(Linux/macOS) 或echo %OPENAI_API_KEY%(Windows)。2. 确认 Key 是否有余额或权限。1. 重新设置环境变量。2. 在 OpenAI 平台检查 API Key 状态和额度。Agent 陷入循环不断重复调用同一个工具1. 工具描述不清LLM 无法理解。2. 提示词Prompt引导不力。3. 任务本身模糊或无法完成。1. 查看verboseTrue的日志观察 Agent 的“思考”内容。2. 检查工具的文档字符串是否准确描述了功能和输入格式。1. 优化工具的描述使其更精确。2. 在系统提示词中加强约束如“如果你连续3次尝试失败请停止并总结问题”。3. 简化初始任务确保其可完成。Agent 选择了错误的工具工具功能描述相似或 LLM 理解偏差。观察 Agent 选择工具时的“思考”步骤看它为何做出该选择。1. 为每个工具起更具区分度的名字。2. 在工具描述中明确其适用场景和不适用场景。3. 使用更强大的模型如 GPT-4可能提高工具选择的准确性。eval()安全风险警告代码中存在eval()可能执行恶意输入。审查代码中所有eval()或exec()的使用。必须替换。对于数学表达式使用ast.literal_eval()仅支持简单结构或专门的库如numexpr、sympy。文件操作权限错误Agent 尝试读写其无权访问的路径。查看错误信息确认目标文件/目录的读写权限。1. 将 Agent 的操作限制在特定的安全沙箱目录内。2. 在工具函数内部进行路径校验和权限检查。8. 最佳实践与工程建议将实验性的 Agent 推向生产环境需要严谨的工程化考量。以下是一些关键的最佳实践工具设计的原子性与安全性原子性每个工具应只完成一件明确、独立的事情。避免创建“瑞士军刀”式的巨型工具。这有助于 LLM 更准确地理解和调用。安全性这是重中之重。任何接受用户输入的工具都必须进行严格的验证、清洗和转义。特别是涉及系统命令执行、文件操作、数据库访问和网络请求的工具。遵循最小权限原则Agent 不应拥有超过其完成任务所需之外的权限。使用更强大的模型进行规划对于复杂任务负责顶层规划的 Agent或称“大脑”可以使用能力更强但更贵的模型如 GPT-4而负责具体执行子任务的工具调用可以使用更经济快速的模型如 GPT-3.5-Turbo。这种分层架构能平衡成本与效果。为 Agent 注入记忆当前的 Agent 是“无状态”的每次对话都是新的开始。LangChain 提供了多种记忆组件如ConversationBufferMemory保存对话历史、ConversationSummaryMemory总结历史等可以让 Agent 在长对话中保持连贯性。from langchain.memory import ConversationBufferMemory memory ConversationBufferMemory(memory_keychat_history, return_messagesTrue) # 创建 Agent 时将 memory 传入实现验证与回滚机制对于关键操作如删除文件、修改数据库Agent 在执行前应主动向用户确认或由另一个“验证器”模块进行复核。设计操作日志和快照机制以便在出错时能够回滚到之前的状态。这是 Codex 这类生产级 Agent 的核心能力之一。结构化输出与解析让 LLM 输出结构化的数据如 JSON而非纯文本可以极大地简化后续处理。LangChain 的PydanticOutputParser或StructuredOutputParser可以很好地实现这一点。超时与看门狗为 Agent 的执行设置超时限制防止其因陷入循环或等待而无限挂起。可以设计一个“看门狗”进程来监控 Agent 的运行状态。9. 总结与后续学习方向通过本文的实战我们亲历了从“聊天”到“执行”的跨越。我们不仅理解了 OpenAI 合并 ChatGPT 与 Codex 背后的技术动因——即构建以 AI Agent 为核心的超级应用还亲手搭建了一个具备规划、工具调用和执行能力的简易 Agent。这个简单的math_file_agent只是一个起点。OpenAI 设想的超级应用是集成了更强大的规划引擎Codex、自然交互界面ChatGPT和现实世界连接器如 Atlas 浏览器的复杂系统。作为开发者我们的学习路径可以沿着以下几个方向深入深入 LangChain/LlamaIndex 生态掌握更多类型的 Agent如 Plan-and-Execute, OpenAI Tools Agent学习使用向量数据库如 Chroma, Pinecone为 Agent 提供长时记忆和知识检索能力。探索自主 Agent 框架研究AutoGPT、BabyAGI等项目的设计思想理解更复杂的任务分解、优先级排序和递归执行循环。集成真实世界工具将 Agent 与你的日常工作流结合。例如构建能自动处理 Jira 工单、发送 Slack 通知、从 Confluence 抓取信息、或操作公司内部 API 的专用 Agent。关注多模态与具身智能未来的 Agent 不仅处理文本还能理解和生成图像、音频甚至控制机器人。关注GPT-4V、CLIP等多模态模型的应用。AI 正在从“回答问题的百科全书”演变为“替你解决问题的数字员工”。这场变革的技术核心正是 AI Agent。现在你已经拿到了入场券。下一步是选择一个你工作中最重复、最耗时的任务尝试用今天学到的知识为你自己打造第一个专属的 AI 助手。 30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度
30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度如果你还在把 ChatGPT 当作一个“更聪明的聊天机器人”那么你可能已经落后了。最近OpenAI 内部的一则重磅消息正在彻底改写我们对 AI 产品的认知ChatGPT 和 Codex 即将合并一个统一的“超级应用”正在浮出水面。这远不止是产品功能的简单叠加而是一次从“对话”到“执行”的范式转移。它意味着那个我们熟悉的、以问答为核心的 ChatGPT 时代正在被一个能真正“做事”的 AI Agent 时代所取代。对于开发者而言这不仅仅是新闻头条。它预示着未来 AI 应用的开发模式、技术栈选择乃至职业发展路径都将发生深刻变化。当 AI 从“回答问题”进化到“完成任务”我们该如何构建、调用和管理这些具备自主行动能力的智能体这背后涉及的技术架构、权限控制、任务规划与回滚机制正是我们接下来需要深入理解的核心。本文将从技术视角为你深度解析 OpenAI 这一战略调整背后的技术逻辑并提供一个从零开始构建一个简易 AI Agent 的实战指南。你将不仅理解“超级应用”的构成更能亲手搭建一个具备规划、执行和反思能力的 AI 助手原型。1. 这篇文章真正要解决的问题为什么 OpenAI 合并 ChatGPT 和 Codex 对开发者如此重要表面上看这只是一次产品整合但本质上它标志着 AI 应用开发的核心矛盾已经从“模型能力”转向了“任务执行”。过去三年我们见证了模型参数从千亿到万亿的飞跃但用户与 AI 的交互大多仍停留在“一问一答”的层面。用户提出需求AI 生成文本、代码或图片然后由用户手动执行后续步骤——复制代码到 IDE、整理数据到表格、点击网页按钮。这个“最后一公里”的断层极大地限制了 AI 的生产力释放。Codex 的出现最初是为了解决代码生成与执行的问题但它所沉淀的“长时间运行、多步骤规划、上下文保持、权限确认、结果验收”等能力恰恰是构建通用 AI Agent 的基石。OpenAI 的这次合并意图非常明确将 ChatGPT 强大的意图理解与自然交互能力与 Codex 的任务拆解与执行引擎相结合打造一个能闭环处理复杂任务的超级入口。对于开发者这意味着技术重心转移单纯调用大模型 API 生成文本将变得基础如何设计 Agent 的工作流、工具调用Tool Calling、状态管理和错误处理将成为新的技术壁垒。新的开发范式应用开发可能从“编写业务逻辑代码”转向“配置 AI Agent 的技能Skills与工作流Workflows”。安全与权限挑战当 AI 能够直接操作你的文件系统、数据库和第三方 API 时权限粒度、操作审计和回滚机制变得至关重要。因此本文旨在解决的核心问题是在 AI 从聊天走向执行的转折点上作为一名开发者如何理解背后的技术架构并快速掌握构建可执行、可信任的 AI Agent 的核心技能我们将通过一个完整的实战项目带你跨越从概念到实现的门槛。2. 基础概念与核心原理从 LLM 到 AI Agent在深入实战之前我们需要厘清几个关键概念。很多人容易混淆“大语言模型LLM”、“AI 助手”和“AI Agent”。大语言模型LLM如 GPT-4、Claude 等本质是一个基于概率预测下一个词Token的模型。它擅长理解和生成文本但自身没有目标、没有记忆除非通过上下文窗口、不会主动调用工具。AI 助手Chatbot基于 LLM 构建的交互界面例如初代的 ChatGPT。它通过对话历史上下文来维持短期记忆能够进行多轮对话但其核心能力依然是“说”而不是“做”。它无法自主操作浏览器、修改本地文件或调用 API。AI Agent智能体这是一个更高级的概念。一个真正的 AI Agent 具备以下核心特征目标导向接收一个高级目标如“为我分析上个月的销售数据并生成报告”。自主规划能够将目标拆解为一系列可执行的子任务连接数据库、查询数据、清洗数据、分析趋势、生成图表、撰写文字。工具调用具备调用外部工具的能力如执行 Python 代码、读写文件、调用搜索引擎 API、操作浏览器等。状态感知与反思能够根据工具执行的结果成功/失败感知当前状态并动态调整后续计划。例如如果数据库连接失败它会尝试另一种连接方式或报告错误。长时记忆能够将本次任务的经验和结果存储下来供未来类似任务参考而不仅仅依赖于有限的对话上下文。用一个简单的类比LLM 是汽车的“发动机”AI 助手是有了“方向盘和座椅”的汽车而AI Agent 则是搭载了“自动驾驶系统”的汽车。自动驾驶系统Agent需要理解目的地目标规划路线规划控制油门刹车工具调用并根据路况环境反馈实时调整。OpenAI 推动 ChatGPT 与 Codex 合并正是希望将 ChatGPT 从一辆“能聊天的车”升级为具备“自动驾驶系统”的智能座驾。Codex 在此扮演的正是这套自动驾驶系统的核心执行与规划模块。3. 环境准备与前置条件为了构建我们的第一个 AI Agent我们将使用当前最主流、对开发者最友好的框架之一LangChain。它抽象了与多种 LLM 的交互、工具调用、记忆存储等复杂逻辑让我们能更专注于 Agent 的设计。本项目环境要求操作系统Windows 10/11, macOS, 或 Linux (本文示例基于 macOS/Linux 命令行)。Python版本 3.8 或更高。这是硬性要求。包管理工具pip(Python 自带)。代码编辑器VS Code、PyCharm 或任何你熟悉的编辑器。OpenAI API Key这是调用 GPT 模型所必需的。你需要注册 OpenAI 平台并获取 API Key。请注意保管不要泄露。第一步创建并激活 Python 虚拟环境强烈建议使用虚拟环境来管理项目依赖避免包冲突。# 创建项目目录并进入 mkdir my-first-ai-agent cd my-first-ai-agent # 创建虚拟环境以 venv 为例 python3 -m venv venv # 激活虚拟环境 # 在 macOS/Linux 上 source venv/bin/activate # 在 Windows 上 # venv\Scripts\activate # 激活后命令行提示符前通常会出现 (venv) 标识第二步安装核心依赖我们将安装langchain、langchain-openai用于连接 OpenAI以及langchain-community包含一些社区工具。pip install langchain langchain-openai langchain-community第三步设置 OpenAI API Key不要将 API Key 硬编码在代码中。最佳实践是使用环境变量。# 在 macOS/Linux 上 export OPENAI_API_KEY你的-api-key-here # 在 Windows (PowerShell) 上 # $env:OPENAI_API_KEY你的-api-key-here或者在代码中通过os.environ设置仅用于演示生产环境请勿使用import os os.environ[OPENAI_API_KEY] 你的-api-key-here环境准备就绪接下来我们将进入核心部分设计并实现一个能真正“做事”的 Agent。4. 核心流程拆解构建一个数学计算与文件操作 Agent我们将构建一个相对简单但功能完整的 Agent它能够理解用户关于数学计算和简单文件操作的需求并自主调用工具完成任务。这个 Agent 将具备以下能力进行数学运算如(12 3) * 4。读取指定文本文件的内容。将文本内容写入新文件。这个例子虽小但完整涵盖了目标理解 - 工具选择 - 执行 - 返回结果的 Agent 核心工作流。整体工作流如下初始化 Agent加载 LLM我们使用 GPT-3.5-turbo成本较低并为其装备工具Tools。定义工具创建三个工具函数并用tool装饰器包装让 LLM 能识别和调用。创建 Agent 执行器使用 LangChain 的create_react_agent来构建一个采用 ReAct 推理框架的 Agent。ReActReasoning Acting是一种让 LLM 在思考Reasoning和行动Acting间交替进行的范式能显著提升复杂任务的处理能力。运行 Agent向 Agent 输入一个包含多个步骤的复杂指令观察其自主规划与执行过程。解析与输出获取 Agent 的完整思考链和最终结果。5. 完整示例与代码实现现在让我们开始编写代码。在项目根目录下创建一个名为math_file_agent.py的文件。# math_file_agent.py import os from langchain import hub from langchain.agents import create_react_agent, AgentExecutor from langchain.tools import tool from langchain_openai import ChatOpenAI from langchain_core.prompts import PromptTemplate # 确保已设置 OPENAI_API_KEY 环境变量 # 初始化 LLM使用 gpt-3.5-turbo 以控制成本 llm ChatOpenAI(modelgpt-3.5-turbo, temperature0) # --- 第1步定义工具Tools--- # 工具是 Agent 的“手”和“脚”。每个工具都是一个函数用 tool 装饰器标记。 tool def calculate(expression: str) - str: 执行一个数学表达式计算。支持加减乘除和括号。 try: # 警告使用 eval 存在安全风险此处仅用于演示。 # 在生产环境中必须使用更安全的表达式求值库如 ast.literal_eval或严格验证输入。 result eval(expression) return f计算 {expression} 的结果是{result} except Exception as e: return f计算表达式 {expression} 时出错{e} tool def read_file(filepath: str) - str: 读取指定路径的文本文件并返回其内容。 try: with open(filepath, r, encodingutf-8) as f: content f.read() return f文件 {filepath} 的内容是\n\n{content}\n except FileNotFoundError: return f错误找不到文件 {filepath}。 except Exception as e: return f读取文件 {filepath} 时出错{e} tool def write_file(filepath: str, content: str) - str: 将内容写入指定路径的文本文件。如果文件已存在会被覆盖。 try: with open(filepath, w, encodingutf-8) as f: f.write(content) return f成功将内容写入文件 {filepath}。 except Exception as e: return f写入文件 {filepath} 时出错{e} # 将工具放入列表供 Agent 使用 tools [calculate, read_file, write_file] # --- 第2步创建 Agent --- # ReAct 是一种流行的 Agent 框架它鼓励模型“思考”一步再“行动”一步。 # LangChain 提供了预设的 ReAct 提示词模板我们从 Hub 拉取。 prompt hub.pull(hwchase17/react) # 使用工具和提示词创建 ReAct Agent agent create_react_agent(llm, tools, prompt) # 创建 Agent 执行器它负责运行 Agent 的循环思考 - 选择工具 - 执行 - 观察 - 再思考... agent_executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) # --- 第3步运行 Agent --- print( AI Agent 演示开始 ) # 我们给 Agent 一个需要多步规划的任务 query 请帮我完成以下任务 1. 计算表达式 (15 7) * 3 的值。 2. 读取当前目录下名为 input.txt 的文件内容。 3. 将第一步的计算结果和第二步读取的文件内容一起写入一个新文件 output.txt 中。 请按顺序执行。 print(f用户指令\n{query}\n) print(Agent 执行过程) result agent_executor.invoke({input: query}) # --- 第4步输出最终结果 --- print(\n 最终执行结果 ) print(result[output])代码关键逻辑解释工具定义 (tool)tool装饰器不仅将普通函数标记为 Agent 可用的工具还会自动根据函数名和文档字符串内的内容为 LLM 生成工具的描述。LLM 依靠这些描述来决定在什么情况下调用哪个工具。文档字符串至关重要必须清晰描述工具的功能和输入格式。安全警告calculate工具中使用了eval()这在演示中很方便但在真实生产环境是极度危险的因为它会执行任意代码。实际项目中应替换为安全的数学表达式解析库如ast.literal_eval用于简单表达式或numexpr。Agent 创建 (create_react_agent)我们使用了 LangChain 的高级 API 来快速构建一个基于 ReAct 策略的 Agent。hwchase17/react是一个社区维护的优质提示词模板它指导 LLM 按照“Thought思考”、“Action行动”、“Observation观察”的步骤循环。AgentExecutor这是驱动 Agent 运行的核心组件。verboseTrue会打印出 Agent 详细的思考过程这对于调试和理解 Agent 行为非常有用。handle_parsing_errorsTrue能处理 LLM 输出格式偶尔不符合预期的情况增强鲁棒性。复杂查询我们设计的查询指令包含了三个有依赖关系的子任务计算 - 读文件 - 写文件这要求 Agent 必须进行任务规划和状态管理而不能简单地进行一次工具调用。6. 运行结果与效果验证在运行 Agent 之前我们需要先创建一个input.txt文件供它读取。# 在项目根目录下创建一个简单的输入文件 echo 这是来自 input.txt 的原始内容。 input.txt现在运行我们的 Agent 脚本python math_file_agent.py你将看到类似以下的详细输出为简洁起见略有删减 AI Agent 演示开始 用户指令 此处显示你的查询 Agent 执行过程 进入新的 AgentExecutor 链... 思考我需要按顺序完成用户要求的三个任务。首先计算表达式 (15 7) * 3。 行动调用工具 calculate。 行动输入{expression: (15 7) * 3} 观察计算 (15 7) * 3 的结果是66 思考第一步完成。现在进行第二步读取 input.txt 文件。 行动调用工具 read_file。 行动输入{filepath: input.txt} 观察文件 input.txt 的内容是这是来自 input.txt 的原始内容。思考第二步完成。现在进行第三步将计算结果66和文件内容写入 output.txt。我需要将两者组合成一段文本。 行动调用工具 write_file。 行动输入{filepath: output.txt, content: 计算结果66\n原文件内容这是来自 input.txt 的原始内容。} 观察成功将内容写入文件 output.txt。 思考所有三个任务都已完成。我可以给用户最终答复了。 链结束。 最终执行结果 我已按顺序完成了您要求的任务 1. 计算了表达式 (15 7) * 3结果是 66。 2. 读取了文件 input.txt 的内容。 3. 已将计算结果和原文件内容合并并写入新文件 output.txt。验证结果控制台输出Agent 清晰地展示了其“思考-行动-观察”的完整链条证明了其自主规划能力。生成文件检查项目目录会发现新生成了一个output.txt文件。cat output.txt输出应为计算结果66 原文件内容这是来自 input.txt 的原始内容。至此你已经成功构建并运行了一个具备多步规划与执行能力的 AI Agent。它理解了你的复合指令自主拆解任务正确选择了工具并按顺序执行最终完成了目标。7. 常见问题与排查思路在开发 AI Agent 过程中你可能会遇到以下典型问题问题现象可能原因排查方式解决方案ModuleNotFoundError: No module named ‘langchain’依赖未安装或虚拟环境未激活。1. 确认命令行提示符前有(venv)。2. 运行pip list | grep langchain检查。1. 激活虚拟环境source venv/bin/activate。2. 重新安装pip install langchain ...。AuthenticationError: Incorrect API key providedOpenAI API Key 未设置或错误。1. 检查echo $OPENAI_API_KEY(Linux/macOS) 或echo %OPENAI_API_KEY%(Windows)。2. 确认 Key 是否有余额或权限。1. 重新设置环境变量。2. 在 OpenAI 平台检查 API Key 状态和额度。Agent 陷入循环不断重复调用同一个工具1. 工具描述不清LLM 无法理解。2. 提示词Prompt引导不力。3. 任务本身模糊或无法完成。1. 查看verboseTrue的日志观察 Agent 的“思考”内容。2. 检查工具的文档字符串是否准确描述了功能和输入格式。1. 优化工具的描述使其更精确。2. 在系统提示词中加强约束如“如果你连续3次尝试失败请停止并总结问题”。3. 简化初始任务确保其可完成。Agent 选择了错误的工具工具功能描述相似或 LLM 理解偏差。观察 Agent 选择工具时的“思考”步骤看它为何做出该选择。1. 为每个工具起更具区分度的名字。2. 在工具描述中明确其适用场景和不适用场景。3. 使用更强大的模型如 GPT-4可能提高工具选择的准确性。eval()安全风险警告代码中存在eval()可能执行恶意输入。审查代码中所有eval()或exec()的使用。必须替换。对于数学表达式使用ast.literal_eval()仅支持简单结构或专门的库如numexpr、sympy。文件操作权限错误Agent 尝试读写其无权访问的路径。查看错误信息确认目标文件/目录的读写权限。1. 将 Agent 的操作限制在特定的安全沙箱目录内。2. 在工具函数内部进行路径校验和权限检查。8. 最佳实践与工程建议将实验性的 Agent 推向生产环境需要严谨的工程化考量。以下是一些关键的最佳实践工具设计的原子性与安全性原子性每个工具应只完成一件明确、独立的事情。避免创建“瑞士军刀”式的巨型工具。这有助于 LLM 更准确地理解和调用。安全性这是重中之重。任何接受用户输入的工具都必须进行严格的验证、清洗和转义。特别是涉及系统命令执行、文件操作、数据库访问和网络请求的工具。遵循最小权限原则Agent 不应拥有超过其完成任务所需之外的权限。使用更强大的模型进行规划对于复杂任务负责顶层规划的 Agent或称“大脑”可以使用能力更强但更贵的模型如 GPT-4而负责具体执行子任务的工具调用可以使用更经济快速的模型如 GPT-3.5-Turbo。这种分层架构能平衡成本与效果。为 Agent 注入记忆当前的 Agent 是“无状态”的每次对话都是新的开始。LangChain 提供了多种记忆组件如ConversationBufferMemory保存对话历史、ConversationSummaryMemory总结历史等可以让 Agent 在长对话中保持连贯性。from langchain.memory import ConversationBufferMemory memory ConversationBufferMemory(memory_keychat_history, return_messagesTrue) # 创建 Agent 时将 memory 传入实现验证与回滚机制对于关键操作如删除文件、修改数据库Agent 在执行前应主动向用户确认或由另一个“验证器”模块进行复核。设计操作日志和快照机制以便在出错时能够回滚到之前的状态。这是 Codex 这类生产级 Agent 的核心能力之一。结构化输出与解析让 LLM 输出结构化的数据如 JSON而非纯文本可以极大地简化后续处理。LangChain 的PydanticOutputParser或StructuredOutputParser可以很好地实现这一点。超时与看门狗为 Agent 的执行设置超时限制防止其因陷入循环或等待而无限挂起。可以设计一个“看门狗”进程来监控 Agent 的运行状态。9. 总结与后续学习方向通过本文的实战我们亲历了从“聊天”到“执行”的跨越。我们不仅理解了 OpenAI 合并 ChatGPT 与 Codex 背后的技术动因——即构建以 AI Agent 为核心的超级应用还亲手搭建了一个具备规划、工具调用和执行能力的简易 Agent。这个简单的math_file_agent只是一个起点。OpenAI 设想的超级应用是集成了更强大的规划引擎Codex、自然交互界面ChatGPT和现实世界连接器如 Atlas 浏览器的复杂系统。作为开发者我们的学习路径可以沿着以下几个方向深入深入 LangChain/LlamaIndex 生态掌握更多类型的 Agent如 Plan-and-Execute, OpenAI Tools Agent学习使用向量数据库如 Chroma, Pinecone为 Agent 提供长时记忆和知识检索能力。探索自主 Agent 框架研究AutoGPT、BabyAGI等项目的设计思想理解更复杂的任务分解、优先级排序和递归执行循环。集成真实世界工具将 Agent 与你的日常工作流结合。例如构建能自动处理 Jira 工单、发送 Slack 通知、从 Confluence 抓取信息、或操作公司内部 API 的专用 Agent。关注多模态与具身智能未来的 Agent 不仅处理文本还能理解和生成图像、音频甚至控制机器人。关注GPT-4V、CLIP等多模态模型的应用。AI 正在从“回答问题的百科全书”演变为“替你解决问题的数字员工”。这场变革的技术核心正是 AI Agent。现在你已经拿到了入场券。下一步是选择一个你工作中最重复、最耗时的任务尝试用今天学到的知识为你自己打造第一个专属的 AI 助手。 30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度
与强化学习的自动化设计实践)
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
