1. 项目概述从“AI应用”到“AI智能体”的范式跃迁最近和几个做产品和技术的老朋友聊天话题总绕不开“AI agent”。这个词现在火得不行但聊深了发现大家理解其实挺割裂的。有人觉得就是给大模型套个壳加个记忆和工具调用有人觉得是通往通用人工智能的必经之路还有人觉得这不过是新瓶装旧酒把十几年前的智能体概念用大模型重做了一遍。我干了十多年软件开发和系统架构从早期的规则引擎到后来的推荐系统再到这两年深度折腾大模型应用我的体会是AI agent开发本质上是在构建一种具备自主感知、规划、决策和执行能力的“数字员工”。它不再是传统意义上被动响应、功能单一的“应用”而是一个能理解复杂意图、拆解任务、调用资源并持续学习的主动系统。这不仅仅是技术栈的升级更是一种开发范式的根本性转变。过去我们开发一个应用核心是设计清晰的功能流程和用户界面用户需要一步步告诉系统“做什么”。而开发一个AI agent核心是赋予系统“理解为什么做”和“决定怎么做”的能力。用户可能只需要给出一个模糊的目标比如“帮我分析一下上季度的销售数据找出问题并给出下季度的营销建议”剩下的任务拆解、数据获取、分析、报告生成甚至后续的跟进动作都可以由agent自主完成。这个转变对开发者提出了全新的要求我们不再仅仅是流程的实现者更是智能行为的“教练”和“环境搭建者”。2. 核心架构设计构建一个“会思考”的系统开发AI agent切忌一上来就埋头写提示词Prompt或调API。和盖房子一样先有蓝图才能施工。一个健壮、可扩展的AI agent架构通常需要包含以下几个核心层它们共同协作模拟了人类处理任务的认知过程。2.1 感知与理解层从“听到”到“听懂”这是agent与外界用户、其他系统、环境交互的入口。它的任务不仅仅是接收文本或语音输入更要准确理解用户的深层意图和任务上下文。意图识别与槽位填充这是传统对话系统的核心在agent中依然重要。例如用户说“定一张明天下午北京飞上海、价格不超过1500的机票”。系统需要识别出“订机票”这个意图并提取出“出发时间明天下午”、“出发地北京”、“目的地上海”、“最大价格1500”这几个关键信息槽位。对于简单、结构化的任务基于规则或传统机器学习模型的方法可能更高效、稳定。大模型驱动的深度语义理解对于复杂、模糊或隐含的指令大模型LLM的理解能力无可替代。比如用户说“我感觉最近网站流量有点疲软你帮我想想办法”。这里没有明确的“分析数据”、“生成报告”等指令词。感知层需要利用LLM将这句模糊的话解析成一系列可操作的任务例如“1. 获取最近30天的网站流量数据PV/UV2. 进行趋势分析和同比/环比3. 识别流量下降的主要渠道如搜索引擎、社交媒体4. 基于分析结果生成初步的优化建议列表”。多模态感知未来的agent不应局限于文本。能“看懂”截图、图表“听懂”语音中的情绪甚至处理视频流信息将是标配。这需要集成视觉模型VLM、语音模型等。实操心得不要过度依赖大模型做所有理解工作。对于高频、固定的任务流程用规则或小模型进行第一道过滤和结构化再将复杂、非常规的请求抛给大模型是成本、效率和稳定性兼顾的最佳实践。我们称之为“混合理解策略”。2.2 规划与推理层任务拆解的“大脑”这是agent的“思考”中枢。它接收来自感知层的、已理解的任务目标然后进行规划和推理将其分解为一系列可执行的子任务并确定执行顺序和逻辑。任务分解Task Decomposition这是规划层的核心功能。大模型在此扮演关键角色。我们可以通过思维链Chain-of-Thought或更高级的思维树Tree of Thoughts等提示工程技术引导模型进行逐步推理和拆解。例如面对“帮我策划一个下周的公司团队建设活动”这个目标规划层可能输出如下计划子任务A与用户交互确认团队规模、预算范围、偏好类型室内/户外、运动/休闲、时间约束。子任务B基于确认的信息调用网络搜索工具查找本地符合条件的活动场地或方案。子任务C整合搜索到的信息生成2-3个详细的活动提案包含地点、行程、预算估算。子任务D将提案提交给用户选择并根据用户反馈进行修改。子任务E用户确认后执行预订操作如发送预订邮件、填写报名表。规划算法与状态管理对于复杂、多步骤且可能失败的任务需要引入更严谨的规划算法。这不仅仅是简单的列表可能涉及条件分支如果A失败则尝试B、循环直到满足某个条件为止和并行任务。同时规划层需要维护一个“任务状态机”清晰知道每个子任务处于“待执行”、“执行中”、“成功”、“失败”哪种状态并能根据状态决定下一步动作。2.3 记忆与知识层让agent拥有“经验”一个没有记忆的agent每次对话都是“初次见面”无法进行连贯的、个性化的服务。记忆层赋予了agent持续学习和个人化的能力。短期记忆对话记忆保存当前会话的上下文。通常使用类似“滑动窗口”的机制保留最近N轮对话的历史确保agent能理解指代如“上面的那个方案”和延续话题。技术实现上可以直接将历史对话文本拼接在本次查询的提示词中。长期记忆向量知识库这是agent的“个人知识库”。它将agent执行任务过程中获取的重要信息、用户的个人偏好、历史决策记录等通过文本嵌入模型转化为向量存储到向量数据库如Chroma, Pinecone, Weaviate中。当遇到相关问题时通过向量相似度检索将这些“记忆”作为上下文提供给大模型从而实现个性化服务。例如用户说过“我对海鲜过敏”这个信息被存入长期记忆。下次当agent推荐餐厅时会自动过滤掉海鲜馆子。反思与总结记忆这是更高级的记忆形式。让agent在完成一个任务或经历失败后主动进行“反思”这次任务成功/失败的关键是什么有哪些可以改进的流程将反思的结论结构化后存入知识库用于优化未来的规划和决策。这相当于让agent具备了从经验中学习的能力。2.4 工具与执行层agent的“双手”规划得再好无法落地就是空谈。工具与执行层为agent提供了与真实世界交互的“手”和“脚”。大模型本身不擅长精确计算、实时信息获取或操作外部系统这些都需要通过调用工具Tools/APIs来完成。工具抽象与封装将各种外部能力封装成统一的、agent可以理解和调用的工具。一个工具通常包括工具名称、功能描述、必需的输入参数及其格式、调用方法如函数、API端点。例如工具名称:search_web描述: “使用搜索引擎获取最新的网络信息。”参数:query: str(搜索关键词)调用: 一个封装了SerpAPI或Google Search API的函数。工具的选择与调用这是执行层的核心决策点。当规划层产生一个子任务如“查询今日天气”时执行层需要从可用的工具列表中选择最合适的工具get_weather并按照工具要求的格式生成调用参数{“city”: “北京”}。这个过程通常由大模型驱动我们将可用工具的描述作为上下文提供给模型让它来决定使用哪个工具以及参数是什么。动作执行与结果处理调用工具后会得到返回结果可能是JSON、文本、错误码。执行层需要对这些结果进行初步处理和格式化使其易于被上层特别是规划层和记忆层理解和使用。例如将API返回的JSON数据提炼成一句简洁的自然语言描述“北京今天晴气温15-25摄氏度。”2.5 评估与安全层为智能加上“护栏”这是确保agent可靠、可控、安全的“刹车系统”和“方向盘”。一个完全自主的agent如果没有约束可能会执行危险操作、产生有害内容或陷入无效循环。子任务结果评估每个子任务执行后都需要评估其完成质量和有效性。例如调用搜索工具后返回的结果是否相关、是否充足调用代码解释器执行计算后结果是否合理这可以通过规则如检查结果是否为空、小模型如相关性分类模型或让另一个LLM实例进行校验来实现。整体目标对齐评估定期检查agent的当前行动和中间结果是否仍然与用户的原始目标保持一致防止“迷失方向”。例如用户让agent写一份报告agent却花大量时间去搜索不相关的背景资料。安全与合规过滤在所有输入用户输入和输出agent行动决策、生成内容环节设置过滤器。防止agent被诱导执行危险命令如“删除所有文件”、生成不当内容或泄露记忆中的敏感信息。这需要结合关键词过滤、敏感内容分类模型以及针对LLM输出的安全提示词工程。循环与超时控制必须设置“熔断”机制。当agent陷入规划-执行-失败的循环或任务步骤超过预设的最大值时强制终止任务并向用户报告失败避免无限消耗资源。3. 主流技术栈与框架选型实战了解了架构接下来就是选择趁手的“兵器”。目前AI agent开发领域还没有绝对的垄断者但已经形成了几类清晰的工具和框架各有侧重。3.1 基础模型层Agent的“智力源泉”选择什么样的大模型作为agent的“大脑”是第一个关键决策。这不仅仅是选择ChatGPT还是Claude的问题更关乎成本、性能、可控性和定制化需求。闭源云API如OpenAI GPT-4, Anthropic Claude, Google Gemini优点开箱即用能力强大且通用无需操心基础设施和训练。迭代快能快速用到模型的最新改进。非常适合原型验证、对效果要求高、且无强烈数据隐私顾虑的场景。缺点成本随使用量增长存在API调用延迟和速率限制。数据需发送到第三方有隐私和安全风险。模型行为是“黑盒”难以深度定制和微调。选型建议对于需要最强通用推理和创造力的Agent如高级创意助手、复杂研究分析员GPT-4 Turbo或Claude 3 Opus仍是首选。对于需要超长上下文如分析整本书或长代码库的AgentClaude或Gemini 1.5 Pro是更好的选择。开源模型如Llama 3, Qwen, DeepSeek优点数据完全私有可部署在内网安全性最高。可进行全参数微调或LoRA等高效微调让模型深度适配特定领域知识和工作流程。长期成本可能更低尤其是自有算力的情况下。缺点需要自建推理服务涉及GPU资源、部署运维和性能优化。同等参数规模下顶尖开源模型的通用能力通常仍略逊于顶尖闭源模型。需要团队具备一定的模型部署和调优能力。选型建议对于金融、医疗、法律等数据敏感的垂直行业Agent或需要将Agent深度集成到现有私有化产品中的场景开源模型是必由之路。目前Meta的Llama 3系列70B/405B在开源模型中综合表现领先而国内的Qwen2.5和DeepSeek-V2也是极具竞争力的选择。实操心得不要盲目追求最大参数模型。对于许多任务明确的Agent一个70亿参数7B的精调模型其表现可能远超一个未经调优的700亿参数70B基础模型。关键在于“对齐”——让模型的理解和输出方式完全契合你的任务需求。我们一个内部流程自动化Agent就是用Qwen2.5-7B-Instruct微调而来的在特定任务上准确率超过95%而成本仅为使用GPT-4 API的十分之一。3.2 开发框架层Agent的“骨架”与“神经系统”框架帮你处理了记忆、工具调用、规划流程等通用模块让你能更专注于Agent本身的业务逻辑。LangChain / LangGraph定位目前生态最丰富、应用最广泛的AI应用开发框架。它将LLM、工具、记忆等组件模块化通过“链”Chain的方式组合起来。LangGraph在此基础上增加了循环、分支等更复杂的流程控制能力非常适合构建有状态的、多步骤的Agent。优点社区庞大教程和示例极多。集成了海量的工具、数据加载器和第三方服务。灵活性高几乎可以构建任何类型的Agent。缺点抽象层次有时较高新手可能感觉“黑盒”。在构建极其复杂的、需要精细控制的Agent时可能会感到框架的约束。适用场景快速原型开发、研究性质的Agent、以及大多数需要集成多种工具和数据的复杂业务Agent。LlamaIndex定位更侧重于“数据层面”的Agent。它擅长将私有数据文档、数据库、API与LLM连接构建基于知识的智能体。其核心优势在于高效的数据索引、检索和上下文构建。优点在RAG检索增强生成场景下表现优异提供了多种高级检索策略如句子窗口、自动合并检索。与LangChain集成良好常作为LangChain的数据处理插件使用。缺点在纯粹的、无需复杂知识检索的任务规划和工具调用方面不如LangGraph直接。适用场景文档问答Agent、企业知识库助手、任何需要深度结合私有数据源的Agent。AutoGen / CrewAI定位专注于“多智能体协作”的框架。它们认为复杂的任务应该由多个各司其职的Agent如研究员、写手、校对员通过对话和协作来完成。优点为多Agent系统提供了成熟的对话、协调和管理模式。能更自然地模拟人类团队的工作方式处理超复杂任务时结构更清晰。缺点系统复杂度更高调试更困难需要跟踪多个Agent的对话。执行效率可能较低因为Agent间的大量通信会增加LLM调用次数和延迟。适用场景需要模拟评审流程如代码审查、方案评审、分工明确的创意生产如视频脚本团队、或涉及多方协调的复杂任务。Semantic Kernel / DSPy定位更偏研究和工程化的框架。Semantic Kernel来自微软强调将传统编程技能函数、插件与语义技能LLM结合。DSPy则提出了“用代码编程提示词”的理念将提示词和LLM调用模块化、可优化让整个Agent流程更可预测、可测试。优点与现有代码和工程实践结合更紧密。DSPy的“优化器”概念非常强大可以自动寻找最优的提示词结构和模块组合提升Agent性能。缺点学习曲线较陡峭社区和资源相对较少。更适合有较强工程和机器学习背景的团队。适用场景追求极致性能和可控性的生产级Agent、希望将Agent能力深度嵌入到现有软件系统中的场景。框架选型速查表框架名称核心特点最佳适用场景上手难度社区生态LangChain/LangGraph模块化、灵活性高、生态丰富快速原型、复杂业务流程Agent、工具集成中等极好LlamaIndex数据连接与检索能力强知识库问答、文档分析、RAG密集型Agent中等好AutoGen/CrewAI多智能体协作与对话模拟团队工作、复杂创意任务、评审流程较高中等Semantic Kernel与传统代码集成好.NET生态、企业级应用集成中等中等DSPy提示词编程化、可优化性强研究、对性能有严苛要求的生产系统高成长中3.3 核心工具与基础设施向量数据库Agent长期记忆的基石。Pinecone是全托管服务省心但贵Chroma轻量易用适合入门和中小项目Weaviate功能强大自带混合搜索向量关键词和元数据过滤是生产环境的强力候选Qdrant性能优异资源控制精细。选型时需考虑数据规模、查询性能、过滤能力以及云服务或自部署的需求。编排与部署当Agent从脚本变成需要7x24小时运行的服务时就需要考虑部署。FastAPI是构建Agent后端API的绝佳选择。对于需要调度、排队、重试的复杂异步任务流Apache Airflow或Prefect是不错的编排器。容器化Docker和编排Kubernetes则是保证可扩展性和可靠性的标准答案。4. 从零到一构建一个“技术调研助手”Agent理论说得再多不如动手做一个。我们以构建一个“技术调研助手”Agent为例看看如何将上述架构和框架落地。这个Agent的目标是用户输入一个技术话题如“向量数据库的最新发展趋势”Agent能自动搜索最新资料、阅读关键文章、整理核心观点并生成一份结构化的调研摘要。4.1 第一步定义目标与设计工作流首先我们需要明确Agent的输入、输出和核心工作步骤规划输入用户的一个技术调研主题。规划将主题拆解为a) 生成搜索关键词b) 执行网络搜索c) 筛选并获取关键链接内容d) 分析与总结。工具需要搜索工具和网页内容提取工具。记忆需要短期记忆维持对话上下文长期记忆可存储历史调研主题和结论以供参考。输出一份包含核心观点、技术对比、趋势分析和参考来源的Markdown格式报告。我们选择使用LangGraph来构建因为它能清晰地描述带循环和状态的工作流。4.2 第二步搭建基础环境与定义状态# 安装核心库 # pip install langchain langchain-openai langchain-community langgraph chromadb beautifulsoup4 from typing import TypedDict, List, Annotated import operator from langchain_openai import ChatOpenAI from langchain_community.tools import DuckDuckGoSearchRun, BraveSearch from langchain_community.document_loaders import WebBaseLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.chains import create_extraction_chain from langgraph.graph import StateGraph, END import json # 1. 定义Agent的“状态”即工作流中传递和更新的数据 class AgentState(TypedDict): topic: str # 用户输入的主题 search_queries: List[str] # 生成的搜索关键词列表 search_results: List[dict] # 原始搜索结果标题、链接、摘要 relevant_urls: List[str] # 筛选后的相关链接 article_contents: List[str] # 从链接提取的正文内容 analysis: str # 最终的分析报告 iterations: Annotated[int, operator.add] # 循环次数计数器用于控制流程 # 2. 初始化核心组件 llm ChatOpenAI(modelgpt-4-turbo, temperature0) # 使用GPT-4作为“大脑”温度调低保证稳定性 search_tool DuckDuckGoSearchRun() # 搜索工具也可换用SerpAPI等 text_splitter RecursiveCharacterTextSplitter(chunk_size2000, chunk_overlap200) # 用于切分长文档4.3 第三步实现核心节点函数在LangGraph中每个步骤是一个“节点”函数它们通过边连接成图。# 节点1生成搜索关键词 def generate_search_queries(state: AgentState): 基于用户主题生成3-5个不同的搜索关键词以覆盖更广的信息面。 prompt f 你是一个资深技术研究员。针对以下技术主题生成3到5个精准的搜索关键词用于在互联网上查找最新、最相关的资料。 主题{state[topic]} 请以JSON列表格式返回例如[关键词1, 关键词2, 关键词3] response llm.invoke(prompt) try: queries json.loads(response.content) except: # 如果模型返回的不是标准JSON做简单处理 queries [q.strip([] ) for q in response.content.split(,)] return {search_queries: queries} # 节点2执行网络搜索 def execute_web_search(state: AgentState): 使用搜索工具对每个关键词进行搜索并合并去重结果。 all_results [] seen_urls set() for query in state[search_queries]: print(f正在搜索: {query}) result search_tool.run(query) # 注意DuckDuckGoSearchRun返回的是文本这里需要解析。 # 在实际项目中更推荐使用返回结构化结果如标题、链接、摘要的搜索工具如SerpAPI。 # 此处为简化我们假设result_text包含链接。更佳实践是使用BraveSearch或SerpAPI。 # 这里我们模拟一下结构化结果。 simulated_results [ {title: f关于 {query} 的文章A, url: fhttps://example.com/{query}_a, snippet: 这是摘要A...}, {title: f关于 {query} 的文章B, url: fhttps://example.com/{query}_b, snippet: 这是摘要B...}, ] for res in simulated_results: if res[url] not in seen_urls: seen_urls.add(res[url]) all_results.append(res) return {search_results: all_results} # 节点3筛选相关链接 def filter_relevant_urls(state: AgentState): 让LLM根据主题和摘要从搜索结果中筛选出最相关的3-5个链接。 results_str \n.join([f{i1}. 标题{r[title]}\n 链接{r[url]}\n 摘要{r[snippet][:150]}... for i, r in enumerate(state[search_results])]) prompt f 主题{state[topic]} 以下是搜索到的结果列表 {results_str} 请从中选出与主题最直接相关、信息质量可能最高的3到5个链接。 请只返回链接的序号列表例如[1, 3, 5] response llm.invoke(prompt) try: selected_indices json.loads(response.content) selected_urls [state[search_results][i-1][url] for i in selected_indices if 0 i len(state[search_results])] except: selected_urls [state[search_results][0][url]] # 出错则选第一个 return {relevant_urls: selected_urls} # 节点4获取并处理网页内容 def fetch_and_process_content(state: AgentState): 使用文档加载器获取网页正文并进行清理和分块。 contents [] for url in state[relevant_urls]: try: loader WebBaseLoader(url) docs loader.load() # 合并所有页面的文本并进行分块便于后续分析或嵌入 full_text \n.join([doc.page_content for doc in docs]) # 简单清理移除过多空白字符 cleaned_text .join(full_text.split()) contents.append(cleaned_text[:5000]) # 限制长度避免上下文过长 except Exception as e: print(f抓取 {url} 失败: {e}) contents.append(f[无法获取此链接内容: {url}]) return {article_contents: contents} # 节点5分析与生成报告 def analyze_and_summarize(state: AgentState): 基于抓取的内容生成最终的技术调研报告。 content_block \n\n---\n\n.join([f来源内容 {i1}:\n{cont[:2000]}... for i, cont in enumerate(state[article_contents])]) prompt f 你是一位技术分析师。请基于以下关于“{state[topic]}”的搜集到的资料撰写一份详细的技术调研摘要报告。 报告要求 1. 使用Markdown格式。 2. 包含以下章节核心概念与定义、当前主要技术方案对比、最新发展趋势、面临的挑战与未来展望、参考资料。 3. 观点需有原文内容支撑表述客观严谨。 4. 在报告末尾列出所有参考的链接。 搜集到的资料内容 {content_block} response llm.invoke(prompt) return {analysis: response.content} # 节点6判断是否需重新搜索条件边 def should_retry_search(state: AgentState) - str: 根据当前分析结果的质量决定是否需要重新搜索更多资料。 # 一个简单的启发式规则如果分析报告非常短比如少于300字或者包含“信息不足”等字样则重试。 # 同时限制最大重试次数。 if state[iterations] 2: # 最多循环2次 return finish if len(state.get(analysis, )) 300 or 信息不足 in state.get(analysis, ): return retry return finish4.4 第四步组装工作流图并运行# 创建图 workflow StateGraph(AgentState) # 添加节点 workflow.add_node(generate_queries, generate_search_queries) workflow.add_node(execute_search, execute_web_search) workflow.add_node(filter_urls, filter_relevant_urls) workflow.add_node(fetch_content, fetch_and_process_content) workflow.add_node(analyze, analyze_and_summarize) # 设置入口点 workflow.set_entry_point(generate_queries) # 添加普通边线性流程 workflow.add_edge(generate_queries, execute_search) workflow.add_edge(execute_search, filter_urls) workflow.add_edge(filter_urls, fetch_content) workflow.add_edge(fetch_content, analyze) # 添加条件边从analyze节点出发根据条件决定下一步 workflow.add_conditional_edges( analyze, should_retry_search, # 条件判断函数 { finish: END, # 结束 retry: generate_queries # 返回第一步重新生成查询可考虑调整查询策略 } ) # 编译图 app workflow.compile() # 运行Agent initial_state AgentState(topic向量数据库的最新发展趋势, search_queries[], search_results[], relevant_urls[], article_contents[], analysis, iterations0) final_state app.invoke(initial_state) print(调研报告生成完成) print(*50) print(final_state[analysis])这个简单的Agent已经具备了感知理解主题、规划拆解为搜索、过滤、分析步骤、工具使用搜索、网页抓取和执行的能力。你可以通过增加记忆节点将历史报告存入向量库、优化筛选逻辑、加入更多分析工具如代码分析、图表生成来让它变得更强大。5. 避坑指南与效能优化实战录在实际开发和运营AI Agent的过程中你会遇到许多教科书上不会提的“坑”。下面是我从多个项目中总结出的核心经验。5.1 可靠性陷阱Agent的“幻觉”与失控这是Agent开发中最头疼的问题。LLM的“幻觉”在自主运行的Agent中会被放大可能导致一连串错误行动。问题表现工具调用错误让LLM选择工具和生成参数时它可能调用一个不存在的工具或生成参数格式完全错误。无效循环Agent陷入“生成任务 - 执行失败 - 重新生成相同任务 - 再次失败”的死循环。目标偏离在执行复杂任务中途忘记了最初的目标开始做一些无关的事情。解决方案结构化输出与参数验证强制LLM以严格的JSON格式输出工具调用指令。在代码层面对返回的JSON进行模式验证使用Pydantic检查必填字段、类型是否正确。对于参数可以设定允许的值枚举或正则表达式进行校验。from pydantic import BaseModel, Field class SearchToolInput(BaseModel): query: str Field(description搜索关键词) max_results: int Field(5, ge1, le10, description最大结果数1-10之间) # 在调用工具前用Pydantic解析和验证LLM的输出设置明确的超时与最大步数在Agent的顶层循环中必须设置硬性限制。例如任何任务最多执行15步或总运行时间不超过2分钟。达到限制后强制终止并报错。定期目标对齐检查在关键节点如每完成3个子任务让Agent做一个“自我检查”用一句话简述当前在做什么以及这是否仍然服务于最终目标。可以将这个检查结果反馈给LLM或由另一个更简单的模型/规则来判断是否偏离。引入“人工确认”节点对于高风险操作如发送邮件、修改数据库、支付在流程中设计“中断点”必须等待用户确认后才能继续执行。5.2 成本与延迟让Agent“又快又省”Agent的每次思考LLM调用、每次工具使用API调用都产生成本和延迟。一个设计不佳的Agent可能又慢又贵。优化策略分层模型策略不要所有任务都用最强大、最贵的模型如GPT-4。采用“路由”机制简单的分类、提取任务用小型/廉价模型如GPT-3.5-Turbo甚至开源小模型复杂的规划、创意、推理任务再用大模型。我们内部的一个Agent系统通过路由将70%的请求导向了成本只有GPT-4 1/50的小模型整体成本下降60%而用户体验无明显差异。上下文长度管理这是成本的大头。定期清理对话历史中的“废话”只保留关键信息。对于长期记忆使用向量检索精准召回相关片段而不是把整个记忆库都塞进上下文。压缩技术如用LLM提取摘要也值得考虑。异步与流式响应对于耗时较长的任务如深度调研不要让用户干等。设计成异步任务先快速返回一个任务ID让Agent在后台执行完成后通过通知或让用户主动查询结果。对于生成式任务使用流式输出让用户能边看边等。缓存机制对于相同或相似的输入其输出结果很可能是相同的。可以建立缓存层如Redis将(模型, 提示词, 参数)的哈希值作为键输出结果作为值。这对于常见问答、模板化任务效果极佳。5.3 评估与测试如何知道你的Agent“好不好”传统软件的测试单元测试、集成测试对Agent不完全适用因为其输出具有非确定性。评估体系构建定义核心指标任务完成率给定100个标准任务Agent能独立正确完成多少个步骤效率完成一个任务平均需要多少步LLM调用/工具调用步数越少通常说明规划越高效。成本与耗时单次任务的平均成本和运行时间。人工审核通过率随机抽样结果由人工判断是否合格的比率。构建测试集收集一批具有代表性的用户查询和期望的输出或成功标准。这个测试集需要持续维护和扩充。自动化评估对于简单任务可以编写规则或使用另一个LLM作为“裁判”进行自动评分。例如对于“查天气”Agent可以检查返回结果是否包含温度、城市名等关键字段。对于摘要任务可以用ROUGE、BLEU等指标对比生成摘要与参考摘要的相似度。A/B测试与用户反馈在允许的情况下进行线上A/B测试对比新旧版本Agent的关键业务指标如用户满意度、任务完成后的留存率。内置便捷的用户反馈渠道如“这个结果有帮助吗”的点赞/点踩按钮。5.4 安全与伦理不可逾越的红线Agent能自主行动其安全隐患远大于普通软件。关键防护措施工具权限最小化严格限制每个Agent可访问的工具和API权限。一个负责“数据查询”的Agent绝不应该拥有“数据删除”的权限。在操作系统或容器层面进行沙箱隔离。输入/输出过滤与监控对所有用户输入和Agent输出进行实时内容安全过滤防止提示词注入攻击、生成恶意内容或泄露敏感信息。建立监控告警对异常高频的工具调用、敏感操作如大量下载、发送外部邮件进行实时报警。可解释性与审计日志Agent的每一步决策、每一次工具调用、每一次LLM的输入输出都必须完整记录到不可篡改的审计日志中。当出现问题时可以完整追溯“当时Agent为什么这么做”。明确的责任声明与用户知情权向用户明确说明这是AI Agent其输出可能存在错误重要决策需人工复核。对于涉及个人数据或重要操作的任务必须获得用户的明确授权。6. 未来展望Agent将走向何方站在当前这个节点AI Agent的发展让我想起了智能手机的早期阶段。我们已经有了强大的“芯片”大模型和“操作系统”框架但杀手级的“应用”Agent还在不断涌现。我认为接下来会看到几个清晰的趋势垂直化与场景深钻通用的“万事通”Agent会存在但价值最大的将是深入特定行业的“专家级”Agent。比如一个能读懂医学影像报告、结合患者病史给出初步诊断建议的医疗Agent一个能实时分析生产线传感器数据、预测故障并调度维修的工业Agent。它们的核心壁垒不在于通用模型多强而在于对领域知识、工作流程和专用工具的深度集成。多模态能力成为标配未来的Agent一定是“眼观六路耳听八方”。能够处理和理解图像、视频、音频、传感器数据等多模态信息并在此基础上进行规划和行动。例如一个家庭机器人Agent需要看懂房间布局视觉听懂语音指令听觉拿起实物触觉/操作。从“自动”到“自治”当前的Agent大多还是“按需触发”用户给一个指令它跑一个流程。下一步是向“自治”演进即Agent能够基于长期目标主动感知环境变化自发地规划并执行任务。比如一个个人健康管理Agent不仅在你询问时给出建议还能持续监测你的运动手环数据、饮食记录在你连续熬夜时主动提醒甚至帮你自动调整明天的日程安排。人机协作范式重构Agent不会完全取代人而是重塑人机协作的方式。从“人操作机器”变为“人设定目标机器自主执行人负责监督和关键决策”。这对产品设计和交互提出了新要求如何让人类高效地向Agent传达意图如何让Agent清晰地向人类汇报进展和寻求帮助如何建立可靠的信任机制开发AI Agent的道路就像在训练一个数字世界的实习生。它开始时会犯很多错需要你耐心地设计流程、设定规则、纠正偏差。但随着它不断学习和进化终将成为你乃至整个组织中不可或缺的高效协作者。这场变革才刚刚开始而最好的学习方式就是现在动手从构建你的第一个Agent开始。 AI智能体开发实战：从核心架构到技术栈选型
1. 项目概述从“AI应用”到“AI智能体”的范式跃迁最近和几个做产品和技术的老朋友聊天话题总绕不开“AI agent”。这个词现在火得不行但聊深了发现大家理解其实挺割裂的。有人觉得就是给大模型套个壳加个记忆和工具调用有人觉得是通往通用人工智能的必经之路还有人觉得这不过是新瓶装旧酒把十几年前的智能体概念用大模型重做了一遍。我干了十多年软件开发和系统架构从早期的规则引擎到后来的推荐系统再到这两年深度折腾大模型应用我的体会是AI agent开发本质上是在构建一种具备自主感知、规划、决策和执行能力的“数字员工”。它不再是传统意义上被动响应、功能单一的“应用”而是一个能理解复杂意图、拆解任务、调用资源并持续学习的主动系统。这不仅仅是技术栈的升级更是一种开发范式的根本性转变。过去我们开发一个应用核心是设计清晰的功能流程和用户界面用户需要一步步告诉系统“做什么”。而开发一个AI agent核心是赋予系统“理解为什么做”和“决定怎么做”的能力。用户可能只需要给出一个模糊的目标比如“帮我分析一下上季度的销售数据找出问题并给出下季度的营销建议”剩下的任务拆解、数据获取、分析、报告生成甚至后续的跟进动作都可以由agent自主完成。这个转变对开发者提出了全新的要求我们不再仅仅是流程的实现者更是智能行为的“教练”和“环境搭建者”。2. 核心架构设计构建一个“会思考”的系统开发AI agent切忌一上来就埋头写提示词Prompt或调API。和盖房子一样先有蓝图才能施工。一个健壮、可扩展的AI agent架构通常需要包含以下几个核心层它们共同协作模拟了人类处理任务的认知过程。2.1 感知与理解层从“听到”到“听懂”这是agent与外界用户、其他系统、环境交互的入口。它的任务不仅仅是接收文本或语音输入更要准确理解用户的深层意图和任务上下文。意图识别与槽位填充这是传统对话系统的核心在agent中依然重要。例如用户说“定一张明天下午北京飞上海、价格不超过1500的机票”。系统需要识别出“订机票”这个意图并提取出“出发时间明天下午”、“出发地北京”、“目的地上海”、“最大价格1500”这几个关键信息槽位。对于简单、结构化的任务基于规则或传统机器学习模型的方法可能更高效、稳定。大模型驱动的深度语义理解对于复杂、模糊或隐含的指令大模型LLM的理解能力无可替代。比如用户说“我感觉最近网站流量有点疲软你帮我想想办法”。这里没有明确的“分析数据”、“生成报告”等指令词。感知层需要利用LLM将这句模糊的话解析成一系列可操作的任务例如“1. 获取最近30天的网站流量数据PV/UV2. 进行趋势分析和同比/环比3. 识别流量下降的主要渠道如搜索引擎、社交媒体4. 基于分析结果生成初步的优化建议列表”。多模态感知未来的agent不应局限于文本。能“看懂”截图、图表“听懂”语音中的情绪甚至处理视频流信息将是标配。这需要集成视觉模型VLM、语音模型等。实操心得不要过度依赖大模型做所有理解工作。对于高频、固定的任务流程用规则或小模型进行第一道过滤和结构化再将复杂、非常规的请求抛给大模型是成本、效率和稳定性兼顾的最佳实践。我们称之为“混合理解策略”。2.2 规划与推理层任务拆解的“大脑”这是agent的“思考”中枢。它接收来自感知层的、已理解的任务目标然后进行规划和推理将其分解为一系列可执行的子任务并确定执行顺序和逻辑。任务分解Task Decomposition这是规划层的核心功能。大模型在此扮演关键角色。我们可以通过思维链Chain-of-Thought或更高级的思维树Tree of Thoughts等提示工程技术引导模型进行逐步推理和拆解。例如面对“帮我策划一个下周的公司团队建设活动”这个目标规划层可能输出如下计划子任务A与用户交互确认团队规模、预算范围、偏好类型室内/户外、运动/休闲、时间约束。子任务B基于确认的信息调用网络搜索工具查找本地符合条件的活动场地或方案。子任务C整合搜索到的信息生成2-3个详细的活动提案包含地点、行程、预算估算。子任务D将提案提交给用户选择并根据用户反馈进行修改。子任务E用户确认后执行预订操作如发送预订邮件、填写报名表。规划算法与状态管理对于复杂、多步骤且可能失败的任务需要引入更严谨的规划算法。这不仅仅是简单的列表可能涉及条件分支如果A失败则尝试B、循环直到满足某个条件为止和并行任务。同时规划层需要维护一个“任务状态机”清晰知道每个子任务处于“待执行”、“执行中”、“成功”、“失败”哪种状态并能根据状态决定下一步动作。2.3 记忆与知识层让agent拥有“经验”一个没有记忆的agent每次对话都是“初次见面”无法进行连贯的、个性化的服务。记忆层赋予了agent持续学习和个人化的能力。短期记忆对话记忆保存当前会话的上下文。通常使用类似“滑动窗口”的机制保留最近N轮对话的历史确保agent能理解指代如“上面的那个方案”和延续话题。技术实现上可以直接将历史对话文本拼接在本次查询的提示词中。长期记忆向量知识库这是agent的“个人知识库”。它将agent执行任务过程中获取的重要信息、用户的个人偏好、历史决策记录等通过文本嵌入模型转化为向量存储到向量数据库如Chroma, Pinecone, Weaviate中。当遇到相关问题时通过向量相似度检索将这些“记忆”作为上下文提供给大模型从而实现个性化服务。例如用户说过“我对海鲜过敏”这个信息被存入长期记忆。下次当agent推荐餐厅时会自动过滤掉海鲜馆子。反思与总结记忆这是更高级的记忆形式。让agent在完成一个任务或经历失败后主动进行“反思”这次任务成功/失败的关键是什么有哪些可以改进的流程将反思的结论结构化后存入知识库用于优化未来的规划和决策。这相当于让agent具备了从经验中学习的能力。2.4 工具与执行层agent的“双手”规划得再好无法落地就是空谈。工具与执行层为agent提供了与真实世界交互的“手”和“脚”。大模型本身不擅长精确计算、实时信息获取或操作外部系统这些都需要通过调用工具Tools/APIs来完成。工具抽象与封装将各种外部能力封装成统一的、agent可以理解和调用的工具。一个工具通常包括工具名称、功能描述、必需的输入参数及其格式、调用方法如函数、API端点。例如工具名称:search_web描述: “使用搜索引擎获取最新的网络信息。”参数:query: str(搜索关键词)调用: 一个封装了SerpAPI或Google Search API的函数。工具的选择与调用这是执行层的核心决策点。当规划层产生一个子任务如“查询今日天气”时执行层需要从可用的工具列表中选择最合适的工具get_weather并按照工具要求的格式生成调用参数{“city”: “北京”}。这个过程通常由大模型驱动我们将可用工具的描述作为上下文提供给模型让它来决定使用哪个工具以及参数是什么。动作执行与结果处理调用工具后会得到返回结果可能是JSON、文本、错误码。执行层需要对这些结果进行初步处理和格式化使其易于被上层特别是规划层和记忆层理解和使用。例如将API返回的JSON数据提炼成一句简洁的自然语言描述“北京今天晴气温15-25摄氏度。”2.5 评估与安全层为智能加上“护栏”这是确保agent可靠、可控、安全的“刹车系统”和“方向盘”。一个完全自主的agent如果没有约束可能会执行危险操作、产生有害内容或陷入无效循环。子任务结果评估每个子任务执行后都需要评估其完成质量和有效性。例如调用搜索工具后返回的结果是否相关、是否充足调用代码解释器执行计算后结果是否合理这可以通过规则如检查结果是否为空、小模型如相关性分类模型或让另一个LLM实例进行校验来实现。整体目标对齐评估定期检查agent的当前行动和中间结果是否仍然与用户的原始目标保持一致防止“迷失方向”。例如用户让agent写一份报告agent却花大量时间去搜索不相关的背景资料。安全与合规过滤在所有输入用户输入和输出agent行动决策、生成内容环节设置过滤器。防止agent被诱导执行危险命令如“删除所有文件”、生成不当内容或泄露记忆中的敏感信息。这需要结合关键词过滤、敏感内容分类模型以及针对LLM输出的安全提示词工程。循环与超时控制必须设置“熔断”机制。当agent陷入规划-执行-失败的循环或任务步骤超过预设的最大值时强制终止任务并向用户报告失败避免无限消耗资源。3. 主流技术栈与框架选型实战了解了架构接下来就是选择趁手的“兵器”。目前AI agent开发领域还没有绝对的垄断者但已经形成了几类清晰的工具和框架各有侧重。3.1 基础模型层Agent的“智力源泉”选择什么样的大模型作为agent的“大脑”是第一个关键决策。这不仅仅是选择ChatGPT还是Claude的问题更关乎成本、性能、可控性和定制化需求。闭源云API如OpenAI GPT-4, Anthropic Claude, Google Gemini优点开箱即用能力强大且通用无需操心基础设施和训练。迭代快能快速用到模型的最新改进。非常适合原型验证、对效果要求高、且无强烈数据隐私顾虑的场景。缺点成本随使用量增长存在API调用延迟和速率限制。数据需发送到第三方有隐私和安全风险。模型行为是“黑盒”难以深度定制和微调。选型建议对于需要最强通用推理和创造力的Agent如高级创意助手、复杂研究分析员GPT-4 Turbo或Claude 3 Opus仍是首选。对于需要超长上下文如分析整本书或长代码库的AgentClaude或Gemini 1.5 Pro是更好的选择。开源模型如Llama 3, Qwen, DeepSeek优点数据完全私有可部署在内网安全性最高。可进行全参数微调或LoRA等高效微调让模型深度适配特定领域知识和工作流程。长期成本可能更低尤其是自有算力的情况下。缺点需要自建推理服务涉及GPU资源、部署运维和性能优化。同等参数规模下顶尖开源模型的通用能力通常仍略逊于顶尖闭源模型。需要团队具备一定的模型部署和调优能力。选型建议对于金融、医疗、法律等数据敏感的垂直行业Agent或需要将Agent深度集成到现有私有化产品中的场景开源模型是必由之路。目前Meta的Llama 3系列70B/405B在开源模型中综合表现领先而国内的Qwen2.5和DeepSeek-V2也是极具竞争力的选择。实操心得不要盲目追求最大参数模型。对于许多任务明确的Agent一个70亿参数7B的精调模型其表现可能远超一个未经调优的700亿参数70B基础模型。关键在于“对齐”——让模型的理解和输出方式完全契合你的任务需求。我们一个内部流程自动化Agent就是用Qwen2.5-7B-Instruct微调而来的在特定任务上准确率超过95%而成本仅为使用GPT-4 API的十分之一。3.2 开发框架层Agent的“骨架”与“神经系统”框架帮你处理了记忆、工具调用、规划流程等通用模块让你能更专注于Agent本身的业务逻辑。LangChain / LangGraph定位目前生态最丰富、应用最广泛的AI应用开发框架。它将LLM、工具、记忆等组件模块化通过“链”Chain的方式组合起来。LangGraph在此基础上增加了循环、分支等更复杂的流程控制能力非常适合构建有状态的、多步骤的Agent。优点社区庞大教程和示例极多。集成了海量的工具、数据加载器和第三方服务。灵活性高几乎可以构建任何类型的Agent。缺点抽象层次有时较高新手可能感觉“黑盒”。在构建极其复杂的、需要精细控制的Agent时可能会感到框架的约束。适用场景快速原型开发、研究性质的Agent、以及大多数需要集成多种工具和数据的复杂业务Agent。LlamaIndex定位更侧重于“数据层面”的Agent。它擅长将私有数据文档、数据库、API与LLM连接构建基于知识的智能体。其核心优势在于高效的数据索引、检索和上下文构建。优点在RAG检索增强生成场景下表现优异提供了多种高级检索策略如句子窗口、自动合并检索。与LangChain集成良好常作为LangChain的数据处理插件使用。缺点在纯粹的、无需复杂知识检索的任务规划和工具调用方面不如LangGraph直接。适用场景文档问答Agent、企业知识库助手、任何需要深度结合私有数据源的Agent。AutoGen / CrewAI定位专注于“多智能体协作”的框架。它们认为复杂的任务应该由多个各司其职的Agent如研究员、写手、校对员通过对话和协作来完成。优点为多Agent系统提供了成熟的对话、协调和管理模式。能更自然地模拟人类团队的工作方式处理超复杂任务时结构更清晰。缺点系统复杂度更高调试更困难需要跟踪多个Agent的对话。执行效率可能较低因为Agent间的大量通信会增加LLM调用次数和延迟。适用场景需要模拟评审流程如代码审查、方案评审、分工明确的创意生产如视频脚本团队、或涉及多方协调的复杂任务。Semantic Kernel / DSPy定位更偏研究和工程化的框架。Semantic Kernel来自微软强调将传统编程技能函数、插件与语义技能LLM结合。DSPy则提出了“用代码编程提示词”的理念将提示词和LLM调用模块化、可优化让整个Agent流程更可预测、可测试。优点与现有代码和工程实践结合更紧密。DSPy的“优化器”概念非常强大可以自动寻找最优的提示词结构和模块组合提升Agent性能。缺点学习曲线较陡峭社区和资源相对较少。更适合有较强工程和机器学习背景的团队。适用场景追求极致性能和可控性的生产级Agent、希望将Agent能力深度嵌入到现有软件系统中的场景。框架选型速查表框架名称核心特点最佳适用场景上手难度社区生态LangChain/LangGraph模块化、灵活性高、生态丰富快速原型、复杂业务流程Agent、工具集成中等极好LlamaIndex数据连接与检索能力强知识库问答、文档分析、RAG密集型Agent中等好AutoGen/CrewAI多智能体协作与对话模拟团队工作、复杂创意任务、评审流程较高中等Semantic Kernel与传统代码集成好.NET生态、企业级应用集成中等中等DSPy提示词编程化、可优化性强研究、对性能有严苛要求的生产系统高成长中3.3 核心工具与基础设施向量数据库Agent长期记忆的基石。Pinecone是全托管服务省心但贵Chroma轻量易用适合入门和中小项目Weaviate功能强大自带混合搜索向量关键词和元数据过滤是生产环境的强力候选Qdrant性能优异资源控制精细。选型时需考虑数据规模、查询性能、过滤能力以及云服务或自部署的需求。编排与部署当Agent从脚本变成需要7x24小时运行的服务时就需要考虑部署。FastAPI是构建Agent后端API的绝佳选择。对于需要调度、排队、重试的复杂异步任务流Apache Airflow或Prefect是不错的编排器。容器化Docker和编排Kubernetes则是保证可扩展性和可靠性的标准答案。4. 从零到一构建一个“技术调研助手”Agent理论说得再多不如动手做一个。我们以构建一个“技术调研助手”Agent为例看看如何将上述架构和框架落地。这个Agent的目标是用户输入一个技术话题如“向量数据库的最新发展趋势”Agent能自动搜索最新资料、阅读关键文章、整理核心观点并生成一份结构化的调研摘要。4.1 第一步定义目标与设计工作流首先我们需要明确Agent的输入、输出和核心工作步骤规划输入用户的一个技术调研主题。规划将主题拆解为a) 生成搜索关键词b) 执行网络搜索c) 筛选并获取关键链接内容d) 分析与总结。工具需要搜索工具和网页内容提取工具。记忆需要短期记忆维持对话上下文长期记忆可存储历史调研主题和结论以供参考。输出一份包含核心观点、技术对比、趋势分析和参考来源的Markdown格式报告。我们选择使用LangGraph来构建因为它能清晰地描述带循环和状态的工作流。4.2 第二步搭建基础环境与定义状态# 安装核心库 # pip install langchain langchain-openai langchain-community langgraph chromadb beautifulsoup4 from typing import TypedDict, List, Annotated import operator from langchain_openai import ChatOpenAI from langchain_community.tools import DuckDuckGoSearchRun, BraveSearch from langchain_community.document_loaders import WebBaseLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.chains import create_extraction_chain from langgraph.graph import StateGraph, END import json # 1. 定义Agent的“状态”即工作流中传递和更新的数据 class AgentState(TypedDict): topic: str # 用户输入的主题 search_queries: List[str] # 生成的搜索关键词列表 search_results: List[dict] # 原始搜索结果标题、链接、摘要 relevant_urls: List[str] # 筛选后的相关链接 article_contents: List[str] # 从链接提取的正文内容 analysis: str # 最终的分析报告 iterations: Annotated[int, operator.add] # 循环次数计数器用于控制流程 # 2. 初始化核心组件 llm ChatOpenAI(modelgpt-4-turbo, temperature0) # 使用GPT-4作为“大脑”温度调低保证稳定性 search_tool DuckDuckGoSearchRun() # 搜索工具也可换用SerpAPI等 text_splitter RecursiveCharacterTextSplitter(chunk_size2000, chunk_overlap200) # 用于切分长文档4.3 第三步实现核心节点函数在LangGraph中每个步骤是一个“节点”函数它们通过边连接成图。# 节点1生成搜索关键词 def generate_search_queries(state: AgentState): 基于用户主题生成3-5个不同的搜索关键词以覆盖更广的信息面。 prompt f 你是一个资深技术研究员。针对以下技术主题生成3到5个精准的搜索关键词用于在互联网上查找最新、最相关的资料。 主题{state[topic]} 请以JSON列表格式返回例如[关键词1, 关键词2, 关键词3] response llm.invoke(prompt) try: queries json.loads(response.content) except: # 如果模型返回的不是标准JSON做简单处理 queries [q.strip([] ) for q in response.content.split(,)] return {search_queries: queries} # 节点2执行网络搜索 def execute_web_search(state: AgentState): 使用搜索工具对每个关键词进行搜索并合并去重结果。 all_results [] seen_urls set() for query in state[search_queries]: print(f正在搜索: {query}) result search_tool.run(query) # 注意DuckDuckGoSearchRun返回的是文本这里需要解析。 # 在实际项目中更推荐使用返回结构化结果如标题、链接、摘要的搜索工具如SerpAPI。 # 此处为简化我们假设result_text包含链接。更佳实践是使用BraveSearch或SerpAPI。 # 这里我们模拟一下结构化结果。 simulated_results [ {title: f关于 {query} 的文章A, url: fhttps://example.com/{query}_a, snippet: 这是摘要A...}, {title: f关于 {query} 的文章B, url: fhttps://example.com/{query}_b, snippet: 这是摘要B...}, ] for res in simulated_results: if res[url] not in seen_urls: seen_urls.add(res[url]) all_results.append(res) return {search_results: all_results} # 节点3筛选相关链接 def filter_relevant_urls(state: AgentState): 让LLM根据主题和摘要从搜索结果中筛选出最相关的3-5个链接。 results_str \n.join([f{i1}. 标题{r[title]}\n 链接{r[url]}\n 摘要{r[snippet][:150]}... for i, r in enumerate(state[search_results])]) prompt f 主题{state[topic]} 以下是搜索到的结果列表 {results_str} 请从中选出与主题最直接相关、信息质量可能最高的3到5个链接。 请只返回链接的序号列表例如[1, 3, 5] response llm.invoke(prompt) try: selected_indices json.loads(response.content) selected_urls [state[search_results][i-1][url] for i in selected_indices if 0 i len(state[search_results])] except: selected_urls [state[search_results][0][url]] # 出错则选第一个 return {relevant_urls: selected_urls} # 节点4获取并处理网页内容 def fetch_and_process_content(state: AgentState): 使用文档加载器获取网页正文并进行清理和分块。 contents [] for url in state[relevant_urls]: try: loader WebBaseLoader(url) docs loader.load() # 合并所有页面的文本并进行分块便于后续分析或嵌入 full_text \n.join([doc.page_content for doc in docs]) # 简单清理移除过多空白字符 cleaned_text .join(full_text.split()) contents.append(cleaned_text[:5000]) # 限制长度避免上下文过长 except Exception as e: print(f抓取 {url} 失败: {e}) contents.append(f[无法获取此链接内容: {url}]) return {article_contents: contents} # 节点5分析与生成报告 def analyze_and_summarize(state: AgentState): 基于抓取的内容生成最终的技术调研报告。 content_block \n\n---\n\n.join([f来源内容 {i1}:\n{cont[:2000]}... for i, cont in enumerate(state[article_contents])]) prompt f 你是一位技术分析师。请基于以下关于“{state[topic]}”的搜集到的资料撰写一份详细的技术调研摘要报告。 报告要求 1. 使用Markdown格式。 2. 包含以下章节核心概念与定义、当前主要技术方案对比、最新发展趋势、面临的挑战与未来展望、参考资料。 3. 观点需有原文内容支撑表述客观严谨。 4. 在报告末尾列出所有参考的链接。 搜集到的资料内容 {content_block} response llm.invoke(prompt) return {analysis: response.content} # 节点6判断是否需重新搜索条件边 def should_retry_search(state: AgentState) - str: 根据当前分析结果的质量决定是否需要重新搜索更多资料。 # 一个简单的启发式规则如果分析报告非常短比如少于300字或者包含“信息不足”等字样则重试。 # 同时限制最大重试次数。 if state[iterations] 2: # 最多循环2次 return finish if len(state.get(analysis, )) 300 or 信息不足 in state.get(analysis, ): return retry return finish4.4 第四步组装工作流图并运行# 创建图 workflow StateGraph(AgentState) # 添加节点 workflow.add_node(generate_queries, generate_search_queries) workflow.add_node(execute_search, execute_web_search) workflow.add_node(filter_urls, filter_relevant_urls) workflow.add_node(fetch_content, fetch_and_process_content) workflow.add_node(analyze, analyze_and_summarize) # 设置入口点 workflow.set_entry_point(generate_queries) # 添加普通边线性流程 workflow.add_edge(generate_queries, execute_search) workflow.add_edge(execute_search, filter_urls) workflow.add_edge(filter_urls, fetch_content) workflow.add_edge(fetch_content, analyze) # 添加条件边从analyze节点出发根据条件决定下一步 workflow.add_conditional_edges( analyze, should_retry_search, # 条件判断函数 { finish: END, # 结束 retry: generate_queries # 返回第一步重新生成查询可考虑调整查询策略 } ) # 编译图 app workflow.compile() # 运行Agent initial_state AgentState(topic向量数据库的最新发展趋势, search_queries[], search_results[], relevant_urls[], article_contents[], analysis, iterations0) final_state app.invoke(initial_state) print(调研报告生成完成) print(*50) print(final_state[analysis])这个简单的Agent已经具备了感知理解主题、规划拆解为搜索、过滤、分析步骤、工具使用搜索、网页抓取和执行的能力。你可以通过增加记忆节点将历史报告存入向量库、优化筛选逻辑、加入更多分析工具如代码分析、图表生成来让它变得更强大。5. 避坑指南与效能优化实战录在实际开发和运营AI Agent的过程中你会遇到许多教科书上不会提的“坑”。下面是我从多个项目中总结出的核心经验。5.1 可靠性陷阱Agent的“幻觉”与失控这是Agent开发中最头疼的问题。LLM的“幻觉”在自主运行的Agent中会被放大可能导致一连串错误行动。问题表现工具调用错误让LLM选择工具和生成参数时它可能调用一个不存在的工具或生成参数格式完全错误。无效循环Agent陷入“生成任务 - 执行失败 - 重新生成相同任务 - 再次失败”的死循环。目标偏离在执行复杂任务中途忘记了最初的目标开始做一些无关的事情。解决方案结构化输出与参数验证强制LLM以严格的JSON格式输出工具调用指令。在代码层面对返回的JSON进行模式验证使用Pydantic检查必填字段、类型是否正确。对于参数可以设定允许的值枚举或正则表达式进行校验。from pydantic import BaseModel, Field class SearchToolInput(BaseModel): query: str Field(description搜索关键词) max_results: int Field(5, ge1, le10, description最大结果数1-10之间) # 在调用工具前用Pydantic解析和验证LLM的输出设置明确的超时与最大步数在Agent的顶层循环中必须设置硬性限制。例如任何任务最多执行15步或总运行时间不超过2分钟。达到限制后强制终止并报错。定期目标对齐检查在关键节点如每完成3个子任务让Agent做一个“自我检查”用一句话简述当前在做什么以及这是否仍然服务于最终目标。可以将这个检查结果反馈给LLM或由另一个更简单的模型/规则来判断是否偏离。引入“人工确认”节点对于高风险操作如发送邮件、修改数据库、支付在流程中设计“中断点”必须等待用户确认后才能继续执行。5.2 成本与延迟让Agent“又快又省”Agent的每次思考LLM调用、每次工具使用API调用都产生成本和延迟。一个设计不佳的Agent可能又慢又贵。优化策略分层模型策略不要所有任务都用最强大、最贵的模型如GPT-4。采用“路由”机制简单的分类、提取任务用小型/廉价模型如GPT-3.5-Turbo甚至开源小模型复杂的规划、创意、推理任务再用大模型。我们内部的一个Agent系统通过路由将70%的请求导向了成本只有GPT-4 1/50的小模型整体成本下降60%而用户体验无明显差异。上下文长度管理这是成本的大头。定期清理对话历史中的“废话”只保留关键信息。对于长期记忆使用向量检索精准召回相关片段而不是把整个记忆库都塞进上下文。压缩技术如用LLM提取摘要也值得考虑。异步与流式响应对于耗时较长的任务如深度调研不要让用户干等。设计成异步任务先快速返回一个任务ID让Agent在后台执行完成后通过通知或让用户主动查询结果。对于生成式任务使用流式输出让用户能边看边等。缓存机制对于相同或相似的输入其输出结果很可能是相同的。可以建立缓存层如Redis将(模型, 提示词, 参数)的哈希值作为键输出结果作为值。这对于常见问答、模板化任务效果极佳。5.3 评估与测试如何知道你的Agent“好不好”传统软件的测试单元测试、集成测试对Agent不完全适用因为其输出具有非确定性。评估体系构建定义核心指标任务完成率给定100个标准任务Agent能独立正确完成多少个步骤效率完成一个任务平均需要多少步LLM调用/工具调用步数越少通常说明规划越高效。成本与耗时单次任务的平均成本和运行时间。人工审核通过率随机抽样结果由人工判断是否合格的比率。构建测试集收集一批具有代表性的用户查询和期望的输出或成功标准。这个测试集需要持续维护和扩充。自动化评估对于简单任务可以编写规则或使用另一个LLM作为“裁判”进行自动评分。例如对于“查天气”Agent可以检查返回结果是否包含温度、城市名等关键字段。对于摘要任务可以用ROUGE、BLEU等指标对比生成摘要与参考摘要的相似度。A/B测试与用户反馈在允许的情况下进行线上A/B测试对比新旧版本Agent的关键业务指标如用户满意度、任务完成后的留存率。内置便捷的用户反馈渠道如“这个结果有帮助吗”的点赞/点踩按钮。5.4 安全与伦理不可逾越的红线Agent能自主行动其安全隐患远大于普通软件。关键防护措施工具权限最小化严格限制每个Agent可访问的工具和API权限。一个负责“数据查询”的Agent绝不应该拥有“数据删除”的权限。在操作系统或容器层面进行沙箱隔离。输入/输出过滤与监控对所有用户输入和Agent输出进行实时内容安全过滤防止提示词注入攻击、生成恶意内容或泄露敏感信息。建立监控告警对异常高频的工具调用、敏感操作如大量下载、发送外部邮件进行实时报警。可解释性与审计日志Agent的每一步决策、每一次工具调用、每一次LLM的输入输出都必须完整记录到不可篡改的审计日志中。当出现问题时可以完整追溯“当时Agent为什么这么做”。明确的责任声明与用户知情权向用户明确说明这是AI Agent其输出可能存在错误重要决策需人工复核。对于涉及个人数据或重要操作的任务必须获得用户的明确授权。6. 未来展望Agent将走向何方站在当前这个节点AI Agent的发展让我想起了智能手机的早期阶段。我们已经有了强大的“芯片”大模型和“操作系统”框架但杀手级的“应用”Agent还在不断涌现。我认为接下来会看到几个清晰的趋势垂直化与场景深钻通用的“万事通”Agent会存在但价值最大的将是深入特定行业的“专家级”Agent。比如一个能读懂医学影像报告、结合患者病史给出初步诊断建议的医疗Agent一个能实时分析生产线传感器数据、预测故障并调度维修的工业Agent。它们的核心壁垒不在于通用模型多强而在于对领域知识、工作流程和专用工具的深度集成。多模态能力成为标配未来的Agent一定是“眼观六路耳听八方”。能够处理和理解图像、视频、音频、传感器数据等多模态信息并在此基础上进行规划和行动。例如一个家庭机器人Agent需要看懂房间布局视觉听懂语音指令听觉拿起实物触觉/操作。从“自动”到“自治”当前的Agent大多还是“按需触发”用户给一个指令它跑一个流程。下一步是向“自治”演进即Agent能够基于长期目标主动感知环境变化自发地规划并执行任务。比如一个个人健康管理Agent不仅在你询问时给出建议还能持续监测你的运动手环数据、饮食记录在你连续熬夜时主动提醒甚至帮你自动调整明天的日程安排。人机协作范式重构Agent不会完全取代人而是重塑人机协作的方式。从“人操作机器”变为“人设定目标机器自主执行人负责监督和关键决策”。这对产品设计和交互提出了新要求如何让人类高效地向Agent传达意图如何让Agent清晰地向人类汇报进展和寻求帮助如何建立可靠的信任机制开发AI Agent的道路就像在训练一个数字世界的实习生。它开始时会犯很多错需要你耐心地设计流程、设定规则、纠正偏差。但随着它不断学习和进化终将成为你乃至整个组织中不可或缺的高效协作者。这场变革才刚刚开始而最好的学习方式就是现在动手从构建你的第一个Agent开始。