这次我们来看一个关于 AI Agent、Skill 和 Workflow 的深度技术教程。如果你正在寻找如何构建一个能理解复杂指令、调用工具、并自主完成多步骤任务的智能体这篇文章就是为你准备的。它不只是一个概念介绍而是聚焦于如何从零开始搭建一个具备实际能力的 Multi-Agent 系统涵盖从核心架构、工具Tool定义、技能Skill编排到工作流Workflow设计的完整链路。对于开发者而言最关心的几个问题通常是这套架构的代码门槛高不高是否需要庞大的算力支持能否在本地环境快速跑通一个原型以及它能否处理真实的批量任务并对外提供稳定的 API 服务本文将围绕这些核心关切点展开通过一个模拟的“智能内容助理”项目带你一步步验证 Agent 系统的核心能力。我们将重点关注 Agent 的“大脑”大模型如何与“手脚”Tools/Skills协同以及如何通过 Workflow 来编排复杂的多智能体任务。文章会提供清晰的模块划分、可运行的代码示例、以及关键的调试思路确保你能在理解原理的同时获得可直接复用的工程经验。1. 核心能力速览在深入细节之前我们先通过一个表格快速了解基于 AI 大模型的 Agent 系统所具备的核心能力和技术特征。这有助于你判断它是否适合解决你手头的问题。能力项说明与解读核心定位构建能够理解自然语言目标、自主规划并执行任务通过调用工具的智能体Agent系统。架构模式通常采用Multi-Agent多智能体协作架构不同 Agent 负责不同专长如规划、执行、审核。核心组件Agent智能体决策中枢Tool/Skill工具/技能可执行的动作单元Workflow工作流任务流程的编排器。大模型依赖高度依赖AI 大模型如 GPT、Claude、国产大模型作为 Agent 的“大脑”提供理解、规划和决策能力。算力门槛开发/测试阶段可通过调用云端大模型 API如 OpenAI, DeepSeek进行对本地算力要求低。本地部署阶段如需本地运行大模型则需相应 GPU 资源显存要求从 8GB 到 24GB 不等取决于模型尺寸。启动与部署通常为项目代码启动通过 Python 脚本或框架如 LangChain, AutoGen, CrewAI启动 Agent 服务。可封装为Web API 服务供外部调用。接口能力支持HTTP API调用可接收任务描述返回执行结果。是集成到现有系统的关键。批量任务通过工作流引擎和任务队列如 Celery, Redis天然支持批量异步任务处理。适合场景智能客服、自动化报告生成、数据分析与可视化、跨系统信息检索与操作、个性化内容创作等需要多步骤决策的场景。2. 适用场景与使用边界Agent 系统并非万能理解其能力边界是成功应用的第一步。它非常适合以下场景流程自动化将固定的、但需少量判断的办公流程自动化例如根据会议纪要自动生成待办事项并分配。信息整合与创作从多个来源数据库、网页、文档搜集信息并整合成一份结构化的报告或文章。复杂决策支持基于实时数据如市场行情、系统日志进行分析并提供多套解决方案及其利弊分析。交互式助手构建能深入对话、理解上下文、并调用工具完成具体操作如查天气、订会议室、画图表的对话机器人。它可能不擅长或需要谨慎处理的场景高精度、零容错的原子操作如金融交易扣款、工业设备紧急制动。Agent 的决策存在不确定性此类操作应有确定性的系统把关。完全无监督的创造性工作虽然能辅助创作但生成内容的独创性、版权和事实准确性需要人工审核。对实时性要求极高的场景大模型推理和多次工具调用会带来延迟不适合毫秒级响应的系统。重要的合规与安全边界数据隐私确保 Agent 处理的数据尤其是通过 Tool 访问的数据符合隐私政策避免敏感信息泄露。工具权限严格控制每个 Agent 所能调用的 Tool 的权限特别是涉及写操作、删除操作或外部系统调用的 Tool。内容安全对 Agent 生成的内容文本、代码等进行必要的安全与合规性过滤防止产生有害信息。授权使用如果 Agent 生成的成果用于商业发布务必确保其使用的数据、素材和生成的內容拥有合法授权或符合版权规定。3. 环境准备与前置条件我们将以一个模拟的“智能内容助理”项目为例演示如何搭建一个具备“联网搜索”、“内容总结”和“多格式导出”技能的 Agent 系统。以下是准备工作的清单。基础开发环境操作系统Windows 10/11, macOS, 或 Linux (Ubuntu 20.04)。本文示例以 Linux/macOS 命令为主Windows 用户可使用 WSL2 或相应调整。Python版本 3.8 - 3.11。推荐使用 3.10这是多数 AI 框架兼容性最好的版本。包管理工具pip最新版。强烈建议使用虚拟环境venv或conda隔离项目依赖。关键依赖框架我们将使用LangChain和LangGraph作为核心框架因为它们提供了构建 Agent 和 Workflow 的优秀抽象。LangChain用于连接大模型、定义 Tools、构建基础 Agent。LangGraph基于 LangChain用于构建有状态、可循环、多参与者的复杂工作流即 Multi-Agent 系统。大模型 API需要一个可访问的大模型 API。示例将使用OpenAI API你也可以替换为DeepSeek、智谱AI、通义千问等国内可用 API。硬件与网络要求开发测试主要依赖网络调用云端 API普通笔记本电脑即可。确保网络能稳定访问你选择的大模型服务。本地部署大模型如果计划后期本地部署大模型例如使用Ollama部署Qwen2.5、Llama3则需要准备具有足够显存的 GPU。例如运行 7B 参数的模型通常需要 8GB 以上显存。磁盘空间预留至少 2-5 GB 空间用于安装 Python 包和可能的本地模型文件。4. 安装部署与启动方式首先我们创建项目并安装核心依赖。步骤 1创建并激活虚拟环境# 创建项目目录 mkdir ai_content_agent cd ai_content_agent # 创建虚拟环境 (以 venv 为例) python -m venv venv # 激活虚拟环境 # Linux/macOS source venv/bin/activate # Windows # venv\Scripts\activate步骤 2安装依赖包创建一个requirements.txt文件内容如下langchain0.1.0 langchain-openai0.0.5 langgraph0.0.26 langchain-community0.0.10 python-dotenv1.0.0 httpx0.24.0然后安装pip install -r requirements.txt步骤 3配置环境变量在项目根目录创建.env文件用于安全存储你的 API 密钥。切勿将密钥提交到代码仓库。# .env 文件内容 OPENAI_API_KEYsk-your-openai-api-key-here # 如果使用其他模型例如 DeepSeek DEEPSEEK_API_KEYyour-deepseek-api-key DEEPSEEK_API_BASEhttps://api.deepseek.com步骤 4构建第一个可运行的 Agent 脚本创建一个basic_agent.py文件作为我们系统的起点。这个 Agent 将拥有一个简单的“计算器”工具。# basic_agent.py import os from dotenv import load_dotenv from langchain_openai import ChatOpenAI from langchain.agents import AgentExecutor, create_tool_calling_agent from langchain_core.prompts import ChatPromptTemplate from langchain.tools import tool # 1. 加载环境变量 load_dotenv() # 2. 定义一个简单的工具 (Tool) tool def calculate(expression: str) - str: 计算一个数学表达式。例如calculate(\3 * 7 5\) try: # 警告使用 eval 有安全风险仅用于演示。生产环境应使用安全计算库。 result eval(expression) return f计算结果: {result} except Exception as e: return f计算错误: {e} # 3. 初始化大模型 llm ChatOpenAI(modelgpt-4o-mini, temperature0) # 使用 gpt-4o-mini成本较低 # 4. 准备提示词模板 prompt ChatPromptTemplate.from_messages([ (system, 你是一个乐于助人的助手可以回答问题和进行计算。), (placeholder, {chat_history}), (human, {input}), (placeholder, {agent_scratchpad}), ]) # 5. 创建 Agent tools [calculate] agent create_tool_calling_agent(llmllm, toolstools, promptprompt) # 6. 创建 Agent 执行器 agent_executor AgentExecutor(agentagent, toolstools, verboseTrue) # 7. 运行测试 if __name__ __main__: # 测试一个需要调用工具的问题 result agent_executor.invoke({input: 请问 15 的平方加上 20 除以 4 等于多少}) print(\n Agent 执行结果 ) print(result[output]) # 测试一个纯聊天问题 result2 agent_executor.invoke({input: 你好请介绍一下你自己。}) print(\n Agent 自我介绍 ) print(result2[output])步骤 5启动与测试在终端运行这个脚本python basic_agent.py如果一切正常你将看到类似以下的输出其中Agent识别出需要计算调用了calculate工具并给出了最终答案 Entering new AgentExecutor chain... 我需要计算 15 的平方加上 20 除以 4。 首先计算 15 的平方15 * 15 225。 然后计算 20 除以 420 / 4 5。 最后将两者相加225 5 230。 Action: calculate Action Input: 15**2 20/4 Observation: 计算结果: 230.0 Thought:我已经得到了计算结果是 230.0。 现在可以回答用户的问题了。 Finished chain. Agent 执行结果 15 的平方是 22520 除以 4 是 5两者相加等于 230。恭喜你已经成功启动了一个最基本的、具备工具调用能力的 AI Agent。5. 功能测试与效果验证构建 Multi-Agent 工作流单一 Agent 能力有限。现在我们构建一个更真实的Multi-Agent Workflow模拟一个“智能内容助理”团队。这个团队包含三个角色研究员 (Researcher Agent)负责根据主题进行联网搜索收集信息。撰稿人 (Writer Agent)负责根据收集的信息撰写一篇结构清晰的短文。格式员 (Formatter Agent)负责将短文转换成指定的格式如 Markdown、HTML。我们将使用LangGraph来编排这个工作流。5.1 定义智能体与工具首先创建multi_agent_workflow.py文件。定义工具为研究员 Agent 定义一个模拟的网络搜索工具。# multi_agent_workflow.py (部分代码) import os from dotenv import load_dotenv from typing import TypedDict, Annotated, List import operator from langgraph.graph import StateGraph, END from langchain_openai import ChatOpenAI from langchain_core.messages import HumanMessage, SystemMessage from langchain.tools import tool from langchain_community.tools import DuckDuckGoSearchRun # 一个真实的搜索工具 load_dotenv() llm ChatOpenAI(modelgpt-4o-mini, temperature0.7) # 使用一个真实的搜索工具需要安装 duckduckgo-search # pip install duckduckgo-search search DuckDuckGoSearchRun() tool def web_search(query: str) - str: 执行一次网络搜索并返回摘要。用于查找最新信息。 # 在实际应用中这里可以接入 SerperAPI、Google Search API 等 # 此处使用 DuckDuckGo 作为示例 try: result search.run(query) # 限制返回长度避免上下文过长 return result[:1500] if result else 未找到相关信息。 except Exception as e: return f搜索过程中出现错误: {e} # 撰稿人和格式员不需要特定工具它们主要依靠 LLM 的能力。定义智能体函数每个 Agent 本质上是一个接收状态、调用 LLM、并返回更新后状态的函数。# 定义工作流的状态结构 class AgentState(TypedDict): topic: str search_results: str draft: str final_output: str format: str # 研究员 Agent def research_agent(state: AgentState): 根据主题进行搜索收集信息。 print(f\n[研究员] 正在研究主题: {state[topic]}) query f{state[topic]} 最新发展 关键技术 search_info web_search.invoke(query) return {search_results: search_info} # 撰稿人 Agent def writer_agent(state: AgentState): 根据研究结果撰写草稿。 print(f\n[撰稿人] 正在根据研究结果撰写草稿...) system_msg SystemMessage(content你是一位技术文章撰稿人。请根据提供的研究资料撰写一篇关于给定主题的、结构清晰、通俗易懂的短文约300字。包含引言、主体和结论。) human_msg HumanMessage(contentf主题{state[topic]}\n\n研究资料\n{state[search_results]}\n\n请开始撰写) response llm.invoke([system_msg, human_msg]) return {draft: response.content} # 格式员 Agent def formatter_agent(state: AgentState): 将草稿转换为指定格式。 target_format state.get(format, markdown) print(f\n[格式员] 正在将草稿转换为 {target_format.upper()} 格式...) system_msg SystemMessage(contentf你是一位文档格式专家。请将给定的文章内容严格按照 {target_format.upper()} 的语法和格式要求进行转换。只输出转换后的内容。) human_msg HumanMessage(contentf文章内容\n{state[draft]}\n\n请转换为 {target_format.upper()} 格式) response llm.invoke([system_msg, human_msg]) return {final_output: response.content}5.2 构建并运行工作流使用LangGraph将上述智能体连接成一个有序的工作流。# 构建工作流图 def build_content_team_workflow(): workflow StateGraph(AgentState) # 添加节点即各个智能体函数 workflow.add_node(researcher, research_agent) workflow.add_node(writer, writer_agent) workflow.add_node(formatter, formatter_agent) # 设置边的连接关系研究员 - 撰稿人 - 格式员 - 结束 workflow.set_entry_point(researcher) workflow.add_edge(researcher, writer) workflow.add_edge(writer, formatter) workflow.add_edge(formatter, END) # 编译工作流 return workflow.compile() # 运行工作流 if __name__ __main__: # 1. 构建工作流 app build_content_team_workflow() # 2. 定义初始状态 initial_state: AgentState { topic: AI Agent 在自动化办公中的应用, search_results: , draft: , final_output: , format: markdown # 可以改为 html } # 3. 运行工作流 print(*50) print(启动智能内容助理工作流...) print(f处理主题: {initial_state[topic]}) print(*50) final_state app.invoke(initial_state) # 4. 输出最终结果 print(\n *50) print(工作流执行完成) print(*50) print(\n【最终输出】) print(final_state[final_output])执行与验证 运行python multi_agent_workflow.py。你将看到控制台打印出每个 Agent 的启动日志并最终输出一篇关于“AI Agent 在自动化办公中的应用”的 Markdown 格式短文。测试要点与成功标准流程贯通工作流应能按研究员-撰稿人-格式员的顺序自动执行无错误中断。工具调用研究员 Agent 应成功调用web_search工具并返回有效信息可能因网络有延迟。内容连贯撰稿人生成的草稿应基于研究结果而非凭空捏造。格式转换格式员输出的内容应符合 Markdown 语法如包含#标题、-列表等。状态传递每个环节的产出search_results,draft应正确传递给下一个环节。如果任何一步失败检查1) API 密钥是否正确2) 网络连接3) 搜索工具依赖是否安装 (pip install duckduckgo-search)4) 控制台错误信息。6. 接口 API 与批量任务一个成熟的 Agent 系统必须能够以服务的形式提供能力。我们将使用FastAPI将上述工作流封装成 HTTP API并探讨批量任务的处理。6.1 封装为 FastAPI 服务创建agent_api.py文件。# agent_api.py from fastapi import FastAPI, BackgroundTasks from pydantic import BaseModel from typing import Optional import uuid import asyncio from multi_agent_workflow import build_content_team_workflow # 导入之前构建的工作流 app FastAPI(title智能内容助理 API) # 内存中存储任务状态生产环境应使用数据库或 Redis tasks {} class ContentRequest(BaseModel): topic: str format: Optional[str] markdown class TaskResponse(BaseModel): task_id: str status: str message: str result: Optional[str] None def run_agent_workflow(task_id: str, topic: str, output_format: str): 在后台运行工作流的函数 try: app build_content_team_workflow() initial_state { topic: topic, search_results: , draft: , final_output: , format: output_format } final_state app.invoke(initial_state) tasks[task_id][status] SUCCESS tasks[task_id][result] final_state[final_output] tasks[task_id][message] 任务处理完成 except Exception as e: tasks[task_id][status] FAILED tasks[task_id][message] f处理失败: {str(e)} app.post(/generate_content, response_modelTaskResponse) async def generate_content(request: ContentRequest, background_tasks: BackgroundTasks): 提交一个内容生成任务异步 task_id str(uuid.uuid4()) tasks[task_id] {status: PENDING, message: 任务已提交, result: None} # 将耗时任务放入后台 background_tasks.add_task(run_agent_workflow, task_id, request.topic, request.format) return TaskResponse(task_idtask_id, statusPENDING, message任务正在后台处理中) app.get(/task/{task_id}, response_modelTaskResponse) async def get_task_status(task_id: str): 查询任务状态和结果 task tasks.get(task_id) if not task: return TaskResponse(task_idtask_id, statusNOT_FOUND, message任务不存在) return TaskResponse( task_idtask_id, statustask[status], messagetask[message], resulttask.get(result) ) if __name__ __main__: import uvicorn uvicorn.run(app, host127.0.0.1, port8000)启动 API 服务# 安装 FastAPI 和 Uvicorn pip install fastapi uvicorn # 启动服务 python agent_api.py服务将在http://127.0.0.1:8000启动。访问http://127.0.0.1:8000/docs可以看到自动生成的 API 文档。6.2 调用 API 与批量任务单个任务调用示例 (使用 curl)# 1. 提交任务 curl -X POST http://127.0.0.1:8000/generate_content \ -H Content-Type: application/json \ -d {topic: 大语言模型如何改变软件开发, format: markdown} # 返回示例{task_id:abc-123, status:PENDING, message:任务正在后台处理中} # 2. 轮询查询结果使用上一步返回的 task_id curl -X GET http://127.0.0.1:8000/task/abc-123批量任务处理策略 对于需要处理大量任务的场景如处理一个包含 100 个主题的列表不建议在短时间内同步调用 API 100 次这可能导致服务过载或 API 限流。正确的做法是任务队列使用CeleryRedis或RQ等任务队列系统。将每个主题作为一个任务发布到队列中。生产者-消费者模式API 接收端作为生产者将任务放入队列。启动多个工作进程消费者从队列中取出任务调用本地的run_agent_workflow函数进行处理。结果存储将任务状态和结果存储在数据库如 PostgreSQL或 Redis 中而非内存字典以便持久化和多进程访问。速率限制在工作进程中对大模型 API 的调用进行速率限制避免触发服务商的限制。一个简化的批量任务生产者示例# batch_producer.py import requests import json api_base http://127.0.0.1:8000 topics [ AI 在医疗诊断中的应用, 区块链技术的最新趋势, 自动驾驶的安全挑战, # ... 更多主题 ] task_ids [] for topic in topics: payload {topic: topic, format: markdown} try: response requests.post(f{api_base}/generate_content, jsonpayload, timeout10) if response.status_code 200: task_id response.json()[task_id] task_ids.append(task_id) print(f主题 {topic} 已提交任务ID: {task_id}) else: print(f提交主题 {topic} 失败: {response.status_code}) except Exception as e: print(f提交主题 {topic} 时发生错误: {e}) # 将任务ID列表保存供后续查询使用 with open(task_ids.json, w) as f: json.dump(task_ids, f) print(f批量提交完成共 {len(task_ids)} 个任务。任务ID列表已保存至 task_ids.json)7. 资源占用与性能观察Agent 系统的性能主要取决于两个环节大模型推理和工具调用。大模型推理开销云端 API延迟和成本是主要考量。每次 Agent 的“思考”调用 LLM都会产生 API 调用。使用gpt-4o-mini等较小模型可以降低成本但能力可能稍弱。需要监控 API 的响应时间通常 1-5 秒和费用。本地模型资源占用是核心。运行一个 7B 参数的量化模型在 GPU 上可能需要 6-8 GB 显存推理速度Tokens per second取决于 GPU 算力。在 CPU 上运行会慢很多但内存占用可能达到 10GB。使用nvidia-smi(GPU) 或任务管理器 (CPU) 监控资源使用情况。工具调用开销网络请求如搜索、查询数据库是主要的延迟来源。为工具调用设置合理的超时时间如 10-30 秒并实现重试机制。文件 I/O、复杂计算等本地工具也会消耗 CPU/内存。优化建议缓存对频繁且结果不变的查询如某些知识库问答引入缓存如Redis。异步调用对于 I/O 密集型的工具如多个并行的网络请求使用异步模式asyncio可以大幅提升整体吞吐量。流式输出对于需要长时间生成内容的场景让 API 支持流式响应Server-Sent Events提升用户体验。监控与日志记录每个 Agent 决策、工具调用、LLM 响应的耗时便于定位性能瓶颈。8. 常见问题与排查方法在开发和运行 Agent 系统时你可能会遇到以下典型问题。问题现象可能原因排查方式解决方案Agent 不调用工具直接回答1. 提示词Prompt未明确要求使用工具。2. 工具描述不够清晰LLM 无法理解何时调用。3. 使用的模型如gpt-3.5-turbo工具调用能力较弱。检查 Agent 构建时的prompt模板是否包含{agent_scratchpad}等占位符。查看 LLM 的完整思考过程日志verboseTrue。1. 在 System Prompt 中强调“你必须使用提供的工具”。2. 优化工具函数的docstring使其描述更精准。3. 升级到工具调用能力更强的模型如gpt-4o,gpt-4-turbo,claude-3.5-sonnet。工作流卡住或进入死循环1. Agent 的决策逻辑不清晰导致在几个状态间来回跳转。2. LangGraph 的图结构定义有误形成了循环。启用 LangGraph 的调试模式打印每个节点的输入输出。可视化工作流图。1. 为 Agent 设置明确的停止条件或最大迭代次数。2. 仔细检查workflow.add_edge()的连接确保流向最终指向END。使用workflow.add_conditional_edges()处理条件分支。API 服务调用超时1. 单个任务处理时间过长如搜索慢、LLM 响应慢。2. 未设置合理的超时时间。3. 服务进程崩溃。查看服务端日志定位是哪个环节耗时过长。使用time命令或代码记录各阶段耗时。1. 为外部工具调用设置超时和重试。2. 将同步 API 改为异步 API并使用后台任务处理长时请求。3. 使用gunicorn/uvicorn多进程部署并设置进程监控。批量任务失败率高1. 同时发起太多请求触发大模型 API 的速率限制。2. 网络不稳定。3. 任务本身参数有问题如主题过于模糊。分析失败任务的日志和错误信息。检查 API 返回的status_code和错误信息。1. 实现任务队列并控制工作进程的并发数。2. 为每个任务实现指数退避的重试机制。3. 在任务提交前增加简单的输入验证。本地模型显存不足 (OOM)1. 模型太大超出 GPU 显存。2. 上下文长度设置过长。3. 批量处理时未控制 batch size。运行nvidia-smi观察显存占用峰值。1. 使用量化版本模型如 GPTQ, AWQ, GGUF 格式。2. 减小max_tokens或上下文窗口。3. 将批量处理改为串行或减小 batch size。9. 最佳实践与使用建议基于上述实践总结出以下工程化建议帮助你构建更稳健、高效的 Agent 系统从简单开始逐步复杂化不要一开始就设计庞大的 Multi-Agent 系统。先构建一个能完成核心任务的单一 Agent确保其工具调用和基础逻辑稳定再逐步拆分为多个协作的 Agent。设计清晰的工具契约每个 Tool 的输入、输出、功能、异常情况都应有严格定义。这相当于给 LLM 的“说明书”越清晰Agent 调用越准确。实现全面的日志记录记录每个 Agent 的输入、思考过程、工具调用详情和输出。这对于调试复杂的工作流和优化提示词至关重要。可以考虑使用LangSmith进行可视化追踪。为工作流设置检查点对于长时任务在工作流的关键节点保存中间状态。这样即使进程中断也可以从上一个检查点恢复避免重头开始。建立评估与回馈机制设计自动或人工的评估流程对 Agent 的产出质量进行评分。可以利用这些评分数据对提示词进行微调Prompt Engineering甚至对本地模型进行微调Fine-tuning持续提升系统表现。安全与权限隔离在生产环境中严格限制每个 Agent 所能访问的 Tool 和数据源。考虑使用沙箱环境运行不可信的 Tool 代码。成本监控如果使用云端大模型 API务必设置预算告警和用量监控。优化提示词、缓存常见回答、使用小模型处理简单任务都是控制成本的有效手段。10. 总结与下一步通过本文的实践我们完成了一个从零到一的 AI Agent 系统搭建。你不仅看到了一个能调用计算器的简单 Agent更构建了一个能自动完成“研究-撰稿-格式化”多步骤任务的智能团队。这套以LangChain/LangGraph为框架、以大模型为大脑、以Tool 为手脚、以Workflow 为协作流程的架构是当前构建复杂 Agent 应用的主流范式。最值得尝试的下一步接入真实工具将示例中的搜索工具替换为真实的内部系统 API如查询数据库、发送邮件、生成图表等让 Agent 真正为你干活。探索更优的本地模型如果你有 GPU 资源尝试使用Ollama或vLLM本地部署Qwen2.5、Llama3等开源模型替代 OpenAI API实现完全自主可控。引入 Human-in-the-loop在关键决策点如发布内容前加入人工审核节点实现人机协同。优化提示词工程系统的表现极度依赖提示词。深入研究ReAct,Chain-of-Thought等框架设计更高效的提示词来提升 Agent 的规划和推理能力。最容易踩的坑过度复杂化在需求不明确时过早陷入设计复杂 Agent 协作图的泥潭。忽视错误处理未对工具调用失败、LLM 输出格式错误等情况做充分处理导致系统脆弱。成本失控在未评估效果的情况下盲目使用最强大的模型处理所有请求导致账单激增。构建 AI Agent 系统是一个迭代过程。建议你从一个小而具体的业务痛点开始快速实现一个可运行的闭环然后在此基础上持续扩展和优化。本文提供的代码和思路可以作为你探索之旅的坚实起点。