1. 先搞清楚这个工作流到底解决什么问题如果你在找一种能直接上手、照着做就能跑起来的智能体开发流程那 Matt Pocock 和 David Ondrej 分享的这个工作流值得你花时间研究一下。它不是那种只讲概念、不落地的理论而是一个从环境搭建、工具选择到代码结构都给你安排好的“操作手册”。这个工作流的核心价值在于“直接照搬”。它把很多智能体开发中那些琐碎但又关键的环节——比如如何组织项目结构、如何管理依赖、如何设计交互循环、如何处理错误和日志——都打包成了一套可复用的模式。你不需要从零开始纠结每个技术选型而是可以基于这套经过验证的骨架快速搭建起自己的智能体应用把精力集中在业务逻辑和模型能力集成上。它特别适合两类人一是刚接触智能体工程被各种框架和概念搞得眼花缭乱需要一个清晰起点的开发者二是已经做过一些原型但代码结构混乱、难以维护和扩展希望引入更工程化实践的人。这套工作流提供了一种“最佳实践”的参考让你能跳过很多摸索的坑。2. 工作流的核心骨架与关键设计虽然原始材料没有提供完整的代码清单但根据“智能体工程工作流”这个主题和“直接照搬”的提示我们可以推断出这套流程的几个核心组成部分。一个典型的、可工程化的智能体工作流通常会围绕以下几个模块来构建2.1 清晰的项目结构与依赖管理这是“照搬”的第一步。一个混乱的目录会迅速拖慢开发速度。一个经过设计的工作流通常会强制或建议一种清晰的结构your_agent_project/ ├── src/ │ ├── agent/ # 智能体核心逻辑 │ │ ├── core.py # 主循环、状态机 │ │ ├── tools/ # 工具集搜索、计算、API调用等 │ │ └── memory/ # 记忆管理对话历史、知识库 │ ├── models/ # 与LLM交互的封装 │ ├── config/ # 配置文件API密钥、模型参数 │ └── utils/ # 通用工具函数 ├── tests/ # 单元测试和集成测试 ├── scripts/ # 部署、数据预处理等脚本 ├── requirements.txt # Python依赖 └── .env.example # 环境变量示例这种结构的好处是职责分离。agent/目录只关心“做什么决策”models/只关心“如何调用模型”tools/是具体的执行单元。当你需要增加一个新功能比如联网搜索你很清楚应该去tools/目录下新建一个文件而不是把代码胡乱塞进主循环里。依赖管理上工作流会明确核心库比如openai、langchain或更轻量的替代品、pydantic用于数据验证、loguru用于结构化日志等并在requirements.txt中固定版本避免环境差异导致“在我机器上能跑”的问题。2.2 基于状态机的智能体主循环这是智能体的“大脑”。一个健壮的工作流不会用一堆if-else来硬编码流程而是会定义一个明确的状态机。智能体在每个“回合”都处于某个状态如思考、执行工具、等待用户输入、结束并根据当前状态和上下文决定下一个动作。一个简化的核心循环可能长这样class AgentState(Enum): INITIALIZING initializing THINKING thinking ACTING acting OBSERVING observing FINALIZING finalizing class Agent: def __init__(self, llm_client, tools): self.state AgentState.INITIALIZING self.llm llm_client self.tools tools self.memory [] async def run(self, user_input): self.memory.append({role: user, content: user_input}) self.state AgentState.THINKING while self.state ! AgentState.FINALIZING: if self.state AgentState.THINKING: # 调用LLM决定下一步是回复用户还是使用工具 llm_response await self._call_llm_for_decision() if llm_response.suggested_tool: self.state AgentState.ACTING tool_name llm_response.suggested_tool else: # 直接生成最终回复 self.state AgentState.FINALIZING final_answer llm_response.content elif self.state AgentState.ACTING: # 执行选定的工具 tool_result await self._execute_tool(tool_name) self.memory.append({role: tool, content: tool_result}) self.state AgentState.OBSERVING elif self.state AgentState.OBSERVING: # 基于工具结果重新思考 self.state AgentState.THINKING # 清理并返回最终结果 return self._format_final_output(final_answer)这种设计让逻辑变得清晰可追踪。调试时你只需要打印出agent.state的变化序列就能知道智能体卡在了哪个环节。2.3 工具Tools的标准化封装工具是智能体的“手和脚”。工作流会强调工具的标准化每个工具都是一个独立的函数或类有明确的输入、输出格式和错误处理。通常使用Pydantic模型来定义工具的输入参数确保类型安全。from pydantic import BaseModel from typing import Optional import httpx class WebSearchInput(BaseModel): query: str max_results: Optional[int] 5 async def web_search_tool(input_data: WebSearchInput) - str: 执行网络搜索并返回摘要。 try: # 调用搜索API async with httpx.AsyncClient(timeout30.0) as client: # ... 实际API调用逻辑 results await client.get(fhttps://api.search.example/?q{input_data.query}) results.raise_for_status() # 处理并格式化结果 formatted _format_search_results(results.json()) return formatted except httpx.RequestError as e: # 明确的错误处理返回结构化的错误信息供Agent理解 return f搜索工具出错网络请求失败 ({str(e)}) except Exception as e: return f搜索工具内部错误{str(e)}把所有工具都进行这样的封装后智能体核心循环调用工具时就非常简单和安全。这也方便了单元测试——你可以单独测试每个工具函数而不需要启动整个智能体。2.4 配置与秘密管理直接硬编码 API Key 是项目无法共享和部署的根源。一个好的工作流会强制使用环境变量或配置文件来管理敏感信息和可变参数。使用python-dotenv从.env文件加载环境变量。在代码中通过os.getenv(“OPENAI_API_KEY”)读取。提供一个.env.example文件列出所有需要的环境变量名但不包含真实值方便协作者快速设置。# config.py import os from dotenv import load_dotenv load_dotenv() # 加载 .env 文件中的变量 class Settings: OPENAI_API_KEY os.getenv(OPENAI_API_KEY) OPENAI_BASE_URL os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) MODEL_NAME os.getenv(MODEL_NAME, gpt-4o-mini) LOG_LEVEL os.getenv(LOG_LEVEL, INFO) settings Settings()这样当你把代码提交到Git仓库时.env文件会被.gitignore排除确保了安全性。3. 如何“照搬”从零搭建你的第一个工程化智能体现在我们把这套工作流落地。假设我们要构建一个能查询天气和进行简单计算的智能体。3.1 第一步初始化项目与环境不要一上来就写复杂的智能体逻辑。先搭好架子。# 1. 创建项目目录 mkdir my_engineering_agent cd my_engineering_agent # 2. 创建虚拟环境强烈推荐避免包冲突 python -m venv venv # Windows: venv\Scripts\activate # macOS/Linux: source venv/bin/activate # 3. 创建基础目录结构 mkdir -p src/agent/{tools,memory} src/models src/config src/utils tests scripts # 4. 创建关键文件 touch requirements.txt .env.example .gitignore touch src/agent/core.py src/agent/__init__.py touch src/config/settings.py编辑.gitignore至少包含venv/ __pycache__/ *.pyc .env .DS_Store编辑.env.example:OPENAI_API_KEYyour_openai_api_key_here OPENAI_BASE_URLhttps://api.openai.com/v1 MODEL_NAMEgpt-4o-mini LOG_LEVELINFO编辑requirements.txt加入核心依赖openai1.0.0 pydantic2.0.0 python-dotenv1.0.0 loguru0.7.0 httpx0.25.0然后安装pip install -r requirements.txt3.2 第二步实现配置与工具按照工作流的思路我们先实现配置和工具层。1. 配置管理 (src/config/settings.py):import os from dotenv import load_dotenv from loguru import logger load_dotenv() class Settings: OPENAI_API_KEY os.getenv(OPENAI_API_KEY) if not OPENAI_API_KEY: logger.warning(OPENAI_API_KEY 未设置部分功能可能无法工作。) OPENAI_BASE_URL os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) MODEL_NAME os.getenv(MODEL_NAME, gpt-4o-mini) LOG_LEVEL os.getenv(LOG_LEVEL, INFO) settings Settings()2. 实现两个工具 (src/agent/tools/calculator.py和src/agent/tools/weather.py):# src/agent/tools/calculator.py from pydantic import BaseModel, Field import ast import operator class CalculatorInput(BaseModel): expression: str Field(description一个有效的数学表达式例如(3 5) * 2) async def calculate(input_data: CalculatorInput) - str: 计算一个数学表达式的结果。 try: # 安全地评估表达式限制仅使用数学操作符 node ast.parse(input_data.expression, modeeval) allowed_names {__builtins__: None} allowed_operators { ast.Add: operator.add, ast.Sub: operator.sub, ast.Mult: operator.mul, ast.Div: operator.truediv, ast.Pow: operator.pow, ast.Mod: operator.mod, ast.USub: operator.neg } def _eval(node): if isinstance(node, ast.Num): return node.n elif isinstance(node, ast.BinOp): left _eval(node.left) right _eval(node.right) return allowed_operators[type(node.op)](left, right) elif isinstance(node, ast.UnaryOp): operand _eval(node.operand) return allowed_operators[type(node.op)](operand) else: raise TypeError(f不支持的表达式类型: {type(node).__name__}) result _eval(node.body) return f计算结果{input_data.expression} {result} except (SyntaxError, TypeError, ZeroDivisionError, KeyError) as e: return f计算失败表达式 {input_data.expression} 无效或包含不支持的操作。错误{str(e)}# src/agent/tools/weather.py from pydantic import BaseModel, Field import httpx from src.config.settings import settings class WeatherInput(BaseModel): city: str Field(description城市名称例如北京) async def get_weather(input_data: WeatherInput) - str: 获取指定城市的天气信息示例使用模拟数据。 # 注意这里使用一个模拟API。真实场景应替换为如OpenWeatherMap的API。 # 重点是展示工具的模式输入验证、网络请求、错误处理、格式化输出。 api_url https://api.example.com/weather # 示例URL params {city: input_data.city, units: metric} try: async with httpx.AsyncClient(timeout10.0) as client: # 真实调用resp await client.get(api_url, paramsparams) # 模拟响应 await asyncio.sleep(0.5) # 模拟网络延迟 # 假设返回数据 mock_data { city: input_data.city, temperature: 22, condition: 晴朗, humidity: 65 } return (f{mock_data[city]}的天气{mock_data[condition]} f温度 {mock_data[temperature]}°C湿度 {mock_data[humidity]}%。) except httpx.RequestError as e: return f天气查询失败无法连接到服务 ({str(e)}) except Exception as e: return f天气查询处理出错{str(e)}3. 工具注册与管理 (src/agent/tools/__init__.py):from .calculator import calculate, CalculatorInput from .weather import get_weather, WeatherInput # 工具注册表 TOOL_REGISTRY { calculate: { function: calculate, input_schema: CalculatorInput, description: 计算一个数学表达式的结果。 }, get_weather: { function: get_weather, input_schema: WeatherInput, description: 获取指定城市的天气信息。 } } def get_tool(name): 根据名称获取工具函数及其输入模式。 return TOOL_REGISTRY.get(name)3.3 第三步构建智能体核心现在实现智能体的“大脑” (src/agent/core.py)。import asyncio from enum import Enum from typing import Dict, Any, Optional from loguru import logger from openai import AsyncOpenAI from src.config.settings import settings from src.agent.tools import get_tool, TOOL_REGISTRY class AgentState(Enum): THINKING thinking ACTING acting OBSERVING observing FINALIZING finalizing class EngineeringAgent: def __init__(self): self.state AgentState.THINKING self.client AsyncOpenAI( api_keysettings.OPENAI_API_KEY, base_urlsettings.OPENAI_BASE_URL ) self.conversation_history [] self.current_tool_name None self.current_tool_input None def _format_tools_for_llm(self) - list: 将工具注册表格式化为LLM能理解的Function Calling格式。 tools [] for name, info in TOOL_REGISTRY.items(): # 将Pydantic模型转换为JSON Schema schema info[input_schema].model_json_schema() # 清理schema移除不必要的顶级字段 schema.pop(title, None) schema.pop(description, None) tools.append({ type: function, function: { name: name, description: info[description], parameters: schema } }) return tools async def _call_llm_for_decision(self, user_message: str) - Dict[str, Any]: 调用LLM决定下一步是回复还是使用工具。 messages self.conversation_history [{role: user, content: user_message}] tools self._format_tools_for_llm() try: response await self.client.chat.completions.create( modelsettings.MODEL_NAME, messagesmessages, toolstools, tool_choiceauto, # 让模型自行决定是否调用工具 ) message response.choices[0].message return message except Exception as e: logger.error(f调用LLM失败: {e}) # 返回一个兜底的回复 return {role: assistant, content: f抱歉思考过程出现错误{str(e)}} async def _execute_tool(self, tool_name: str, tool_arguments: Dict) - str: 执行指定的工具。 tool_info get_tool(tool_name) if not tool_info: return f错误未找到名为 {tool_name} 的工具。 tool_func tool_info[function] input_model tool_info[input_schema] try: # 验证并转换输入参数 validated_input input_model(**tool_arguments) # 执行工具函数 result await tool_func(validated_input) return result except Exception as e: logger.error(f执行工具 {tool_name} 时出错: {e}) return f工具 {tool_name} 执行过程中发生错误{str(e)} async def run(self, user_input: str) - str: 运行智能体处理一次用户输入。 logger.info(f用户输入: {user_input}) self.conversation_history.append({role: user, content: user_input}) # 初始状态思考 self.state AgentState.THINKING llm_response await self._call_llm_for_decision(user_input) # 检查LLM是否决定调用工具 if hasattr(llm_response, tool_calls) and llm_response.tool_calls: # 选择第一个工具调用简单处理 tool_call llm_response.tool_calls[0] self.current_tool_name tool_call.function.name self.current_tool_input tool_call.function.arguments logger.info(f决定使用工具: {self.current_tool_name}, 参数: {self.current_tool_input}) self.state AgentState.ACTING # 执行工具 tool_result await self._execute_tool(self.current_tool_name, self.current_tool_input) logger.info(f工具执行结果: {tool_result}) # 将工具调用和结果加入历史进入观察状态 self.conversation_history.append(llm_response) # 包含tool_calls的消息 self.conversation_history.append({ role: tool, tool_call_id: tool_call.id, content: tool_result }) self.state AgentState.OBSERVING # 基于工具结果让LLM再次思考并生成最终回复 final_llm_response await self._call_llm_for_decision() final_answer final_llm_response.content self.conversation_history.append({role: assistant, content: final_answer}) self.state AgentState.FINALIZING return final_answer else: # LLM直接生成回复 final_answer llm_response.content self.conversation_history.append({role: assistant, content: final_answer}) self.state AgentState.FINALIZING return final_answer3.4 第四步创建入口点并测试在项目根目录创建main.py# main.py import asyncio import sys from loguru import logger from src.agent.core import EngineeringAgent # 配置日志 logger.remove() logger.add(sys.stderr, levelINFO) async def main(): agent EngineeringAgent() print(工程化智能体已启动。输入 quit 或 exit 退出。) print(- * 40) while True: try: user_input input(\n您: ).strip() if user_input.lower() in [quit, exit]: print(再见) break if not user_input: continue response await agent.run(user_input) print(f智能体: {response}) except KeyboardInterrupt: print(\n程序被中断。) break except Exception as e: logger.error(f主循环发生未预期错误: {e}) print(抱歉处理过程中出现了问题。) if __name__ __main__: asyncio.run(main())现在确保你的.env文件已正确配置 OpenAI API Key然后运行python main.py你应该能和一个具备计算和模拟查询天气能力的智能体对话了。例如您: 北京天气怎么样 智能体: 北京的天气晴朗温度 22°C湿度 65%。 您: 计算一下 (128)*3 等于多少 智能体: 计算结果(128)*3 604. 从“能跑”到“好用”工程化扩展与避坑要点一个能对话的Demo只是开始。要让这个工作流真正具备工程价值成为你能“照搬”到真实项目的基础还需要考虑以下几个层面。4.1 记忆Memory管理上面的例子使用了简单的对话历史列表作为记忆。但在真实场景中你需要更强大的记忆管理长短时记忆分离将整个对话历史每次都传给LLM长时记忆成本高且可能超出上下文窗口。需要实现摘要、提炼或向量检索。记忆持久化将对话历史保存到数据库如SQLite、PostgreSQL或向量数据库如Chroma、Pinecone以便会话恢复和长期学习。记忆检索当对话轮次变多时不是把所有历史都塞给LLM而是根据当前问题从记忆库中检索最相关的片段。一个简单的改进是在Agent类中引入一个MemoryManager类负责存储、检索和压缩历史。4.2 健壮的错误处理与重试网络请求、API限流、模型超时都是家常便饭。工作流必须包含系统性的错误处理。工具级重试在_execute_tool函数中对网络请求加入指数退避重试机制。LLM调用重试OpenAI API 可能返回临时错误如rate_limit_exceeded需要捕获并重试。降级策略当主要工具如天气API失败时是否有备用数据源或能给出友好提示。输入验证与清理在用户输入进入LLM或工具前进行基本的清理和验证防止Prompt注入或无效参数导致崩溃。4.3 可观测性与日志“为什么智能体会做出这个决策” 没有日志调试就是噩梦。结构化日志使用loguru或structlog记录关键事件状态转换、工具调用、LLM请求/响应、错误。请求/响应追踪记录每次LLM调用的输入Prompt和完整输出便于事后分析。性能监控记录每个工具调用和LLM调用的耗时找出性能瓶颈。日志分级开发时用DEBUG级别看细节生产环境用INFO或WARNING。4.4 测试策略智能体测试比普通软件测试更复杂因为涉及非确定性LLM输出和外部API。单元测试工具函数这是最可靠的。模拟输入断言输出。确保calculate和get_weather模拟部分逻辑正确。集成测试Agent流程使用Mock对象替换AsyncOpenAI客户端模拟LLM返回预定义的、包含工具调用的响应验证整个run方法的执行路径是否正确。端到端E2E测试在测试环境中使用真实的LLM API但用低成本模型针对一组标准问题检查最终回复是否符合预期。这类测试不稳定主要用于回归而非每次构建。4.5 部署与生产化当智能体需要对外提供服务时工作流需要扩展。API封装将Agent类包装成FastAPI或Flask应用提供HTTP端点。异步与并发确保你的Web框架如FastAPI能正确处理异步的Agentrun方法并管理好并发请求下的资源如LLM客户端连接池。配置管理生产环境不再使用.env文件而是通过配置中心、Kubernetes ConfigMap或环境变量注入。健康检查与就绪探针为你的服务添加/health端点检查LLM API连通性、数据库连接等。5. 常见问题与排查清单当你“照搬”这套工作流并开始修改时肯定会遇到问题。以下是几个高频问题及排查思路。问题1智能体不调用工具总是直接回复。检查1工具描述。确认TOOL_REGISTRY中每个工具的description字段清晰、准确。LLM根据描述决定是否调用。检查2Prompt引导。在系统消息conversation_history开头中明确指示智能体“你拥有计算和查询天气的工具在需要时请主动使用它们。”检查3LLM响应解析。打印出llm_response的原始内容看tool_calls字段是否存在。如果不存在说明LLM认为不需要或不知道如何使用工具。问题2工具执行出错返回“未找到工具”或参数错误。检查1工具名称匹配。LLM返回的tool_call.function.name必须与TOOL_REGISTRY中的键名完全一致大小写敏感。检查2参数格式。tool_call.function.arguments应该是一个JSON字符串能被正确解析并传入Pydantic模型。打印出来验证格式。检查3Pydantic模型验证。确保你的CalculatorInput等模型能正确处理边界情况如空字符串、非法字符。问题3程序运行慢尤其是连续对话时。检查1历史上下文长度。conversation_history会越来越长导致每次请求LLM的Token数暴涨。实现历史总结或只保留最近N轮对话。检查2网络延迟。工具调用如天气API或LLM API调用可能很慢。为httpx.AsyncClient和OpenAI客户端设置合理的超时如30秒并考虑加入重试。检查3同步阻塞。确保所有I/O操作网络请求、文件读写都是异步的使用async/await避免阻塞事件循环。问题4部署后多个用户请求相互干扰。检查1Agent实例化。确保每个用户会话或每个HTTP请求都创建独立的EngineeringAgent实例而不是共享全局实例。否则用户A的历史会混入用户B的对话中。检查2内存管理。如果使用全局缓存或向量数据库注意键Key的设计要包含用户或会话ID。检查3资源限制。监控你的LLM API的速率限制Rate Limit并在代码中实现队列或限流防止突发请求被API提供商拒绝。这套由 Matt Pocock 和 David Ondrej 倡导的工作流其精髓不在于某个具体的代码片段而在于这种分层、模块化、配置驱动、可观测的工程思想。当你开始一个新智能体项目时最值得花时间的不是急于调通第一个Prompt而是按照这个骨架把项目目录、配置管理、工具接口和核心循环的状态机先搭好。这会让你后续的迭代、调试和协作效率提升一个数量级。先让流程可重复、可测试再去追求智能体的“智能”。
1. 先搞清楚这个工作流到底解决什么问题如果你在找一种能直接上手、照着做就能跑起来的智能体开发流程那 Matt Pocock 和 David Ondrej 分享的这个工作流值得你花时间研究一下。它不是那种只讲概念、不落地的理论而是一个从环境搭建、工具选择到代码结构都给你安排好的“操作手册”。这个工作流的核心价值在于“直接照搬”。它把很多智能体开发中那些琐碎但又关键的环节——比如如何组织项目结构、如何管理依赖、如何设计交互循环、如何处理错误和日志——都打包成了一套可复用的模式。你不需要从零开始纠结每个技术选型而是可以基于这套经过验证的骨架快速搭建起自己的智能体应用把精力集中在业务逻辑和模型能力集成上。它特别适合两类人一是刚接触智能体工程被各种框架和概念搞得眼花缭乱需要一个清晰起点的开发者二是已经做过一些原型但代码结构混乱、难以维护和扩展希望引入更工程化实践的人。这套工作流提供了一种“最佳实践”的参考让你能跳过很多摸索的坑。2. 工作流的核心骨架与关键设计虽然原始材料没有提供完整的代码清单但根据“智能体工程工作流”这个主题和“直接照搬”的提示我们可以推断出这套流程的几个核心组成部分。一个典型的、可工程化的智能体工作流通常会围绕以下几个模块来构建2.1 清晰的项目结构与依赖管理这是“照搬”的第一步。一个混乱的目录会迅速拖慢开发速度。一个经过设计的工作流通常会强制或建议一种清晰的结构your_agent_project/ ├── src/ │ ├── agent/ # 智能体核心逻辑 │ │ ├── core.py # 主循环、状态机 │ │ ├── tools/ # 工具集搜索、计算、API调用等 │ │ └── memory/ # 记忆管理对话历史、知识库 │ ├── models/ # 与LLM交互的封装 │ ├── config/ # 配置文件API密钥、模型参数 │ └── utils/ # 通用工具函数 ├── tests/ # 单元测试和集成测试 ├── scripts/ # 部署、数据预处理等脚本 ├── requirements.txt # Python依赖 └── .env.example # 环境变量示例这种结构的好处是职责分离。agent/目录只关心“做什么决策”models/只关心“如何调用模型”tools/是具体的执行单元。当你需要增加一个新功能比如联网搜索你很清楚应该去tools/目录下新建一个文件而不是把代码胡乱塞进主循环里。依赖管理上工作流会明确核心库比如openai、langchain或更轻量的替代品、pydantic用于数据验证、loguru用于结构化日志等并在requirements.txt中固定版本避免环境差异导致“在我机器上能跑”的问题。2.2 基于状态机的智能体主循环这是智能体的“大脑”。一个健壮的工作流不会用一堆if-else来硬编码流程而是会定义一个明确的状态机。智能体在每个“回合”都处于某个状态如思考、执行工具、等待用户输入、结束并根据当前状态和上下文决定下一个动作。一个简化的核心循环可能长这样class AgentState(Enum): INITIALIZING initializing THINKING thinking ACTING acting OBSERVING observing FINALIZING finalizing class Agent: def __init__(self, llm_client, tools): self.state AgentState.INITIALIZING self.llm llm_client self.tools tools self.memory [] async def run(self, user_input): self.memory.append({role: user, content: user_input}) self.state AgentState.THINKING while self.state ! AgentState.FINALIZING: if self.state AgentState.THINKING: # 调用LLM决定下一步是回复用户还是使用工具 llm_response await self._call_llm_for_decision() if llm_response.suggested_tool: self.state AgentState.ACTING tool_name llm_response.suggested_tool else: # 直接生成最终回复 self.state AgentState.FINALIZING final_answer llm_response.content elif self.state AgentState.ACTING: # 执行选定的工具 tool_result await self._execute_tool(tool_name) self.memory.append({role: tool, content: tool_result}) self.state AgentState.OBSERVING elif self.state AgentState.OBSERVING: # 基于工具结果重新思考 self.state AgentState.THINKING # 清理并返回最终结果 return self._format_final_output(final_answer)这种设计让逻辑变得清晰可追踪。调试时你只需要打印出agent.state的变化序列就能知道智能体卡在了哪个环节。2.3 工具Tools的标准化封装工具是智能体的“手和脚”。工作流会强调工具的标准化每个工具都是一个独立的函数或类有明确的输入、输出格式和错误处理。通常使用Pydantic模型来定义工具的输入参数确保类型安全。from pydantic import BaseModel from typing import Optional import httpx class WebSearchInput(BaseModel): query: str max_results: Optional[int] 5 async def web_search_tool(input_data: WebSearchInput) - str: 执行网络搜索并返回摘要。 try: # 调用搜索API async with httpx.AsyncClient(timeout30.0) as client: # ... 实际API调用逻辑 results await client.get(fhttps://api.search.example/?q{input_data.query}) results.raise_for_status() # 处理并格式化结果 formatted _format_search_results(results.json()) return formatted except httpx.RequestError as e: # 明确的错误处理返回结构化的错误信息供Agent理解 return f搜索工具出错网络请求失败 ({str(e)}) except Exception as e: return f搜索工具内部错误{str(e)}把所有工具都进行这样的封装后智能体核心循环调用工具时就非常简单和安全。这也方便了单元测试——你可以单独测试每个工具函数而不需要启动整个智能体。2.4 配置与秘密管理直接硬编码 API Key 是项目无法共享和部署的根源。一个好的工作流会强制使用环境变量或配置文件来管理敏感信息和可变参数。使用python-dotenv从.env文件加载环境变量。在代码中通过os.getenv(“OPENAI_API_KEY”)读取。提供一个.env.example文件列出所有需要的环境变量名但不包含真实值方便协作者快速设置。# config.py import os from dotenv import load_dotenv load_dotenv() # 加载 .env 文件中的变量 class Settings: OPENAI_API_KEY os.getenv(OPENAI_API_KEY) OPENAI_BASE_URL os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) MODEL_NAME os.getenv(MODEL_NAME, gpt-4o-mini) LOG_LEVEL os.getenv(LOG_LEVEL, INFO) settings Settings()这样当你把代码提交到Git仓库时.env文件会被.gitignore排除确保了安全性。3. 如何“照搬”从零搭建你的第一个工程化智能体现在我们把这套工作流落地。假设我们要构建一个能查询天气和进行简单计算的智能体。3.1 第一步初始化项目与环境不要一上来就写复杂的智能体逻辑。先搭好架子。# 1. 创建项目目录 mkdir my_engineering_agent cd my_engineering_agent # 2. 创建虚拟环境强烈推荐避免包冲突 python -m venv venv # Windows: venv\Scripts\activate # macOS/Linux: source venv/bin/activate # 3. 创建基础目录结构 mkdir -p src/agent/{tools,memory} src/models src/config src/utils tests scripts # 4. 创建关键文件 touch requirements.txt .env.example .gitignore touch src/agent/core.py src/agent/__init__.py touch src/config/settings.py编辑.gitignore至少包含venv/ __pycache__/ *.pyc .env .DS_Store编辑.env.example:OPENAI_API_KEYyour_openai_api_key_here OPENAI_BASE_URLhttps://api.openai.com/v1 MODEL_NAMEgpt-4o-mini LOG_LEVELINFO编辑requirements.txt加入核心依赖openai1.0.0 pydantic2.0.0 python-dotenv1.0.0 loguru0.7.0 httpx0.25.0然后安装pip install -r requirements.txt3.2 第二步实现配置与工具按照工作流的思路我们先实现配置和工具层。1. 配置管理 (src/config/settings.py):import os from dotenv import load_dotenv from loguru import logger load_dotenv() class Settings: OPENAI_API_KEY os.getenv(OPENAI_API_KEY) if not OPENAI_API_KEY: logger.warning(OPENAI_API_KEY 未设置部分功能可能无法工作。) OPENAI_BASE_URL os.getenv(OPENAI_BASE_URL, https://api.openai.com/v1) MODEL_NAME os.getenv(MODEL_NAME, gpt-4o-mini) LOG_LEVEL os.getenv(LOG_LEVEL, INFO) settings Settings()2. 实现两个工具 (src/agent/tools/calculator.py和src/agent/tools/weather.py):# src/agent/tools/calculator.py from pydantic import BaseModel, Field import ast import operator class CalculatorInput(BaseModel): expression: str Field(description一个有效的数学表达式例如(3 5) * 2) async def calculate(input_data: CalculatorInput) - str: 计算一个数学表达式的结果。 try: # 安全地评估表达式限制仅使用数学操作符 node ast.parse(input_data.expression, modeeval) allowed_names {__builtins__: None} allowed_operators { ast.Add: operator.add, ast.Sub: operator.sub, ast.Mult: operator.mul, ast.Div: operator.truediv, ast.Pow: operator.pow, ast.Mod: operator.mod, ast.USub: operator.neg } def _eval(node): if isinstance(node, ast.Num): return node.n elif isinstance(node, ast.BinOp): left _eval(node.left) right _eval(node.right) return allowed_operators[type(node.op)](left, right) elif isinstance(node, ast.UnaryOp): operand _eval(node.operand) return allowed_operators[type(node.op)](operand) else: raise TypeError(f不支持的表达式类型: {type(node).__name__}) result _eval(node.body) return f计算结果{input_data.expression} {result} except (SyntaxError, TypeError, ZeroDivisionError, KeyError) as e: return f计算失败表达式 {input_data.expression} 无效或包含不支持的操作。错误{str(e)}# src/agent/tools/weather.py from pydantic import BaseModel, Field import httpx from src.config.settings import settings class WeatherInput(BaseModel): city: str Field(description城市名称例如北京) async def get_weather(input_data: WeatherInput) - str: 获取指定城市的天气信息示例使用模拟数据。 # 注意这里使用一个模拟API。真实场景应替换为如OpenWeatherMap的API。 # 重点是展示工具的模式输入验证、网络请求、错误处理、格式化输出。 api_url https://api.example.com/weather # 示例URL params {city: input_data.city, units: metric} try: async with httpx.AsyncClient(timeout10.0) as client: # 真实调用resp await client.get(api_url, paramsparams) # 模拟响应 await asyncio.sleep(0.5) # 模拟网络延迟 # 假设返回数据 mock_data { city: input_data.city, temperature: 22, condition: 晴朗, humidity: 65 } return (f{mock_data[city]}的天气{mock_data[condition]} f温度 {mock_data[temperature]}°C湿度 {mock_data[humidity]}%。) except httpx.RequestError as e: return f天气查询失败无法连接到服务 ({str(e)}) except Exception as e: return f天气查询处理出错{str(e)}3. 工具注册与管理 (src/agent/tools/__init__.py):from .calculator import calculate, CalculatorInput from .weather import get_weather, WeatherInput # 工具注册表 TOOL_REGISTRY { calculate: { function: calculate, input_schema: CalculatorInput, description: 计算一个数学表达式的结果。 }, get_weather: { function: get_weather, input_schema: WeatherInput, description: 获取指定城市的天气信息。 } } def get_tool(name): 根据名称获取工具函数及其输入模式。 return TOOL_REGISTRY.get(name)3.3 第三步构建智能体核心现在实现智能体的“大脑” (src/agent/core.py)。import asyncio from enum import Enum from typing import Dict, Any, Optional from loguru import logger from openai import AsyncOpenAI from src.config.settings import settings from src.agent.tools import get_tool, TOOL_REGISTRY class AgentState(Enum): THINKING thinking ACTING acting OBSERVING observing FINALIZING finalizing class EngineeringAgent: def __init__(self): self.state AgentState.THINKING self.client AsyncOpenAI( api_keysettings.OPENAI_API_KEY, base_urlsettings.OPENAI_BASE_URL ) self.conversation_history [] self.current_tool_name None self.current_tool_input None def _format_tools_for_llm(self) - list: 将工具注册表格式化为LLM能理解的Function Calling格式。 tools [] for name, info in TOOL_REGISTRY.items(): # 将Pydantic模型转换为JSON Schema schema info[input_schema].model_json_schema() # 清理schema移除不必要的顶级字段 schema.pop(title, None) schema.pop(description, None) tools.append({ type: function, function: { name: name, description: info[description], parameters: schema } }) return tools async def _call_llm_for_decision(self, user_message: str) - Dict[str, Any]: 调用LLM决定下一步是回复还是使用工具。 messages self.conversation_history [{role: user, content: user_message}] tools self._format_tools_for_llm() try: response await self.client.chat.completions.create( modelsettings.MODEL_NAME, messagesmessages, toolstools, tool_choiceauto, # 让模型自行决定是否调用工具 ) message response.choices[0].message return message except Exception as e: logger.error(f调用LLM失败: {e}) # 返回一个兜底的回复 return {role: assistant, content: f抱歉思考过程出现错误{str(e)}} async def _execute_tool(self, tool_name: str, tool_arguments: Dict) - str: 执行指定的工具。 tool_info get_tool(tool_name) if not tool_info: return f错误未找到名为 {tool_name} 的工具。 tool_func tool_info[function] input_model tool_info[input_schema] try: # 验证并转换输入参数 validated_input input_model(**tool_arguments) # 执行工具函数 result await tool_func(validated_input) return result except Exception as e: logger.error(f执行工具 {tool_name} 时出错: {e}) return f工具 {tool_name} 执行过程中发生错误{str(e)} async def run(self, user_input: str) - str: 运行智能体处理一次用户输入。 logger.info(f用户输入: {user_input}) self.conversation_history.append({role: user, content: user_input}) # 初始状态思考 self.state AgentState.THINKING llm_response await self._call_llm_for_decision(user_input) # 检查LLM是否决定调用工具 if hasattr(llm_response, tool_calls) and llm_response.tool_calls: # 选择第一个工具调用简单处理 tool_call llm_response.tool_calls[0] self.current_tool_name tool_call.function.name self.current_tool_input tool_call.function.arguments logger.info(f决定使用工具: {self.current_tool_name}, 参数: {self.current_tool_input}) self.state AgentState.ACTING # 执行工具 tool_result await self._execute_tool(self.current_tool_name, self.current_tool_input) logger.info(f工具执行结果: {tool_result}) # 将工具调用和结果加入历史进入观察状态 self.conversation_history.append(llm_response) # 包含tool_calls的消息 self.conversation_history.append({ role: tool, tool_call_id: tool_call.id, content: tool_result }) self.state AgentState.OBSERVING # 基于工具结果让LLM再次思考并生成最终回复 final_llm_response await self._call_llm_for_decision() final_answer final_llm_response.content self.conversation_history.append({role: assistant, content: final_answer}) self.state AgentState.FINALIZING return final_answer else: # LLM直接生成回复 final_answer llm_response.content self.conversation_history.append({role: assistant, content: final_answer}) self.state AgentState.FINALIZING return final_answer3.4 第四步创建入口点并测试在项目根目录创建main.py# main.py import asyncio import sys from loguru import logger from src.agent.core import EngineeringAgent # 配置日志 logger.remove() logger.add(sys.stderr, levelINFO) async def main(): agent EngineeringAgent() print(工程化智能体已启动。输入 quit 或 exit 退出。) print(- * 40) while True: try: user_input input(\n您: ).strip() if user_input.lower() in [quit, exit]: print(再见) break if not user_input: continue response await agent.run(user_input) print(f智能体: {response}) except KeyboardInterrupt: print(\n程序被中断。) break except Exception as e: logger.error(f主循环发生未预期错误: {e}) print(抱歉处理过程中出现了问题。) if __name__ __main__: asyncio.run(main())现在确保你的.env文件已正确配置 OpenAI API Key然后运行python main.py你应该能和一个具备计算和模拟查询天气能力的智能体对话了。例如您: 北京天气怎么样 智能体: 北京的天气晴朗温度 22°C湿度 65%。 您: 计算一下 (128)*3 等于多少 智能体: 计算结果(128)*3 604. 从“能跑”到“好用”工程化扩展与避坑要点一个能对话的Demo只是开始。要让这个工作流真正具备工程价值成为你能“照搬”到真实项目的基础还需要考虑以下几个层面。4.1 记忆Memory管理上面的例子使用了简单的对话历史列表作为记忆。但在真实场景中你需要更强大的记忆管理长短时记忆分离将整个对话历史每次都传给LLM长时记忆成本高且可能超出上下文窗口。需要实现摘要、提炼或向量检索。记忆持久化将对话历史保存到数据库如SQLite、PostgreSQL或向量数据库如Chroma、Pinecone以便会话恢复和长期学习。记忆检索当对话轮次变多时不是把所有历史都塞给LLM而是根据当前问题从记忆库中检索最相关的片段。一个简单的改进是在Agent类中引入一个MemoryManager类负责存储、检索和压缩历史。4.2 健壮的错误处理与重试网络请求、API限流、模型超时都是家常便饭。工作流必须包含系统性的错误处理。工具级重试在_execute_tool函数中对网络请求加入指数退避重试机制。LLM调用重试OpenAI API 可能返回临时错误如rate_limit_exceeded需要捕获并重试。降级策略当主要工具如天气API失败时是否有备用数据源或能给出友好提示。输入验证与清理在用户输入进入LLM或工具前进行基本的清理和验证防止Prompt注入或无效参数导致崩溃。4.3 可观测性与日志“为什么智能体会做出这个决策” 没有日志调试就是噩梦。结构化日志使用loguru或structlog记录关键事件状态转换、工具调用、LLM请求/响应、错误。请求/响应追踪记录每次LLM调用的输入Prompt和完整输出便于事后分析。性能监控记录每个工具调用和LLM调用的耗时找出性能瓶颈。日志分级开发时用DEBUG级别看细节生产环境用INFO或WARNING。4.4 测试策略智能体测试比普通软件测试更复杂因为涉及非确定性LLM输出和外部API。单元测试工具函数这是最可靠的。模拟输入断言输出。确保calculate和get_weather模拟部分逻辑正确。集成测试Agent流程使用Mock对象替换AsyncOpenAI客户端模拟LLM返回预定义的、包含工具调用的响应验证整个run方法的执行路径是否正确。端到端E2E测试在测试环境中使用真实的LLM API但用低成本模型针对一组标准问题检查最终回复是否符合预期。这类测试不稳定主要用于回归而非每次构建。4.5 部署与生产化当智能体需要对外提供服务时工作流需要扩展。API封装将Agent类包装成FastAPI或Flask应用提供HTTP端点。异步与并发确保你的Web框架如FastAPI能正确处理异步的Agentrun方法并管理好并发请求下的资源如LLM客户端连接池。配置管理生产环境不再使用.env文件而是通过配置中心、Kubernetes ConfigMap或环境变量注入。健康检查与就绪探针为你的服务添加/health端点检查LLM API连通性、数据库连接等。5. 常见问题与排查清单当你“照搬”这套工作流并开始修改时肯定会遇到问题。以下是几个高频问题及排查思路。问题1智能体不调用工具总是直接回复。检查1工具描述。确认TOOL_REGISTRY中每个工具的description字段清晰、准确。LLM根据描述决定是否调用。检查2Prompt引导。在系统消息conversation_history开头中明确指示智能体“你拥有计算和查询天气的工具在需要时请主动使用它们。”检查3LLM响应解析。打印出llm_response的原始内容看tool_calls字段是否存在。如果不存在说明LLM认为不需要或不知道如何使用工具。问题2工具执行出错返回“未找到工具”或参数错误。检查1工具名称匹配。LLM返回的tool_call.function.name必须与TOOL_REGISTRY中的键名完全一致大小写敏感。检查2参数格式。tool_call.function.arguments应该是一个JSON字符串能被正确解析并传入Pydantic模型。打印出来验证格式。检查3Pydantic模型验证。确保你的CalculatorInput等模型能正确处理边界情况如空字符串、非法字符。问题3程序运行慢尤其是连续对话时。检查1历史上下文长度。conversation_history会越来越长导致每次请求LLM的Token数暴涨。实现历史总结或只保留最近N轮对话。检查2网络延迟。工具调用如天气API或LLM API调用可能很慢。为httpx.AsyncClient和OpenAI客户端设置合理的超时如30秒并考虑加入重试。检查3同步阻塞。确保所有I/O操作网络请求、文件读写都是异步的使用async/await避免阻塞事件循环。问题4部署后多个用户请求相互干扰。检查1Agent实例化。确保每个用户会话或每个HTTP请求都创建独立的EngineeringAgent实例而不是共享全局实例。否则用户A的历史会混入用户B的对话中。检查2内存管理。如果使用全局缓存或向量数据库注意键Key的设计要包含用户或会话ID。检查3资源限制。监控你的LLM API的速率限制Rate Limit并在代码中实现队列或限流防止突发请求被API提供商拒绝。这套由 Matt Pocock 和 David Ondrej 倡导的工作流其精髓不在于某个具体的代码片段而在于这种分层、模块化、配置驱动、可观测的工程思想。当你开始一个新智能体项目时最值得花时间的不是急于调通第一个Prompt而是按照这个骨架把项目目录、配置管理、工具接口和核心循环的状态机先搭好。这会让你后续的迭代、调试和协作效率提升一个数量级。先让流程可重复、可测试再去追求智能体的“智能”。
