1. 引言当“提示工程”不再是唯一答案最近在AI圈子里一个由Andrej Karpathy提出的概念——“大模型交互的第三种范式”引发了不小的讨论。很多人第一反应是这会不会又是技术圈的一次概念炒作毕竟从最初的“提示工程”到后来的“检索增强生成”我们已经习惯了围绕大模型构建交互方式的迭代。但当我深入研究了Karpathy的论述并结合自己近一年来在多个实际项目中应用大模型的经验后我发现这个概念并非空穴来风它确实指向了一个我们正在经历、但尚未被清晰定义的转变。简单来说Karpathy所说的“第三种范式”核心是将大语言模型从一个需要精心“提问”的问答机转变为一个可以自主、持续运行的“进程”或“代理”。这听起来有点抽象我举个生活中的例子以前我们用搜索引擎得像侦探一样精心构思关键词第一种范式指令-响应后来有了智能助手我们可以用自然语言对话让它帮我们查天气、定闹钟第二种范式多轮对话/提示工程。而现在第三种范式期望的是你告诉这个“代理”一个长期目标比如“帮我运营这个社交媒体账号目标是每周增长500个关注者”它就能自己制定计划、执行发布、分析数据、并不断调整策略像一个真正的数字员工一样持续工作只在关键节点向你汇报或请求确认。这种转变背后的驱动力是大模型本身能力的进化以及我们对其应用场景的深度挖掘。它不再满足于充当一个“更聪明的Siri”而是开始涉足需要长期记忆、复杂规划、工具使用和环境交互的领域。接下来我将结合具体的实践案例和技术细节拆解这种范式究竟是什么它如何工作以及对我们开发者、产品经理甚至普通用户意味着什么。2. 范式演进从“问答”到“进程”的技术脉络要理解为什么“第三种范式”是一个值得关注的新阶段我们需要回顾一下前两种范式是如何定义我们与AI的交互方式的。这不是简单的概念堆砌而是技术能力、应用场景和用户期望三者共同演进的结果。2.1 第一种范式指令-响应与“万物皆可Prompt”最早的交互方式极其直接用户输入一个问题或指令模型返回一个答案或结果。这很像使用一个超级增强版的命令行工具。它的核心假设是单次交互是独立且完整的。开发者需要做的是通过精巧的Prompt设计即“提示工程”将用户的模糊意图转化为模型能精确理解的指令。例如早期让模型总结一篇长文章我们需要写一个非常结构化的Prompt“请用不超过200字总结以下文章的核心观点并列出三个关键论据。” 这种范式的优势是简单、可控但局限性也很明显它缺乏上下文记忆每次交互都是“重启”它无法处理需要多步骤、依赖历史信息或与环境动态交互的复杂任务。整个生态围绕着“如何写出更好的Prompt”展开诞生了大量的Prompt模板库和调优指南。2.2 第二种范式会话上下文与检索增强生成随着模型上下文窗口的扩大从几千token发展到数十万甚至百万token以及像LangChain这类框架的出现第二种范式成熟起来。其核心特征是引入了“上下文”和“工具”的概念。交互不再是一次性的而是可以在一个会话中持续进行模型能记住之前的对话历史。更重要的是通过“检索增强生成”RAG技术模型可以实时从外部知识库如公司文档、产品手册中获取信息来生成更准确、更及时的答案。这个阶段的典型应用是智能客服助手和知识库问答系统。你问它“我们产品的退货政策是什么”它不会仅凭训练数据中的模糊记忆回答而是会先去检索最新的政策文档然后结合文档内容生成回答。这种范式解决了信息新鲜度和专业性的问题并将交互扩展到了多轮对话。然而它的本质仍然是“响应式”的——AI被动地等待用户提问然后执行“检索-生成”的循环。任务的发起者、规划者和主要决策者仍然是人类用户。2.3 第三种范式自主智能体与持续性进程Karpathy提出的第三种范式试图突破“响应式”的局限。在这种范式下大模型被赋予一个长期目标或身份并作为一个持续运行的“进程”被启动。这个进程拥有几个关键的新特质自主性与主动性智能体不再只是回答问题而是主动规划并执行任务。例如一个“自动化研究助手”被启动后它会自己制定文献搜索策略、阅读论文、提取关键信息、撰写综述报告并定期向你推送进展。状态持久性与记忆智能体拥有超越单次会话的长期记忆。它可以记住自己的目标、已完成的工作、从环境中学习到的经验并在后续决策中利用这些信息。这通常通过向量数据库或更复杂的记忆模块来实现。工具使用与环境交互智能体被赋予了使用各种工具的能力如调用API、操作软件、控制硬件使其能够直接影响外部环境而不仅仅是生成文本。它可以自己打开浏览器搜索用Python分析数据或者发送一封邮件。规划与反思智能体具备将宏观目标分解为可执行子任务的能力规划并能在任务失败或遇到意外时分析原因并调整策略反思。这构成了一个“感知-思考-行动”的循环。一个生动的类比是第一种范式像计算器你按一下它算一下第二种范式像高级科学计算器能记住你上一步的公式而第三种范式则像一个被你雇佣的、拥有专业知识的实习生你告诉他最终目标他会自己安排时间、查找资料、完成任务并给你交付成果。注意目前完全实现这种范式的系统仍处于探索阶段面临成本、可靠性、安全性等多重挑战。但它代表的方向——降低人类在复杂任务中的认知负荷和操作负担——是明确且极具吸引力的。3. 核心架构拆解智能体如何“思考”与“行动”理解了范式的概念我们深入到技术层面。一个典型的“第三种范式”智能体系统是如何构建的它并不是一个魔法黑盒其核心通常围绕一个“智能体循环”架构展开。我将以一个“自动化市场周报生成智能体”为例拆解其内部运作机制。3.1 规划模块从目标到任务树的分解当智能体接收到一个宏观指令如“生成一份关于AI编程工具的本周市场动态报告”时规划模块首先启动。它的作用是将模糊的目标转化为清晰、可执行的任务序列。这个过程不是随机的而是基于对目标的理解和内置的“任务分解知识”。一个常见的实现方式是使用大模型本身进行递归式任务分解。系统会设计一个用于规划的专用Prompt例如“你是一个项目规划专家。请将‘生成AI编程工具市场周报’这个目标分解为一系列具体的、顺序执行的子任务。每个子任务应该是原子化的并且明确其产出物。” 模型可能会输出如下任务树信息收集确定需要关注的AI编程工具类别如代码补全、调试、生成等。数据源确定列出需要爬取或监控的新闻网站、技术博客、GitHub趋势榜等。信息检索与摘要从各数据源获取过去一周的相关文章并提取核心内容。趋势分析与整合对比不同信息识别出本周的主要趋势、重磅更新或融资事件。报告撰写按照固定的报告模板引言、趋势概述、重点事件点评、未来展望组织内容。格式美化与检查将报告生成为格式良好的Markdown或PDF文件并进行基础的事实核对。实操心得规划的质量直接决定智能体执行的效率。在实践中我们发现让模型在规划时同时输出每个任务的“成功标准”非常有用。例如对于“信息检索”任务成功标准可以是“至少覆盖5个核心数据源并提取出10篇以上相关文章的摘要”。这为后续的“反思”环节提供了评估依据。3.2 工具调用模块智能体的“手”和“脚”规划好了任务智能体需要“动手”去执行。这就是工具调用模块的职责。它让大模型具备了操作数字世界的能力。这个模块的核心是一个工具注册表和一套调用规范。开发者需要预先将各种工具函数“描述”给大模型。例如工具名称search_web功能描述使用搜索引擎查询指定关键词返回前N条结果的标题、链接和摘要。参数query(搜索关键词)num_results(返回数量)。返回格式JSON列表。当大模型在执行“信息检索”任务时它可能会生成这样的内部指令“我需要搜索‘GitHub Copilot 本周更新’。应该调用search_web工具参数为query‘GitHub Copilot update week’ num_results5。” 系统会截取这段指令解析出工具调用请求执行对应的Python函数并将搜索结果JSON格式重新注入到模型的上下文中供其后续分析使用。常见的工具包括网络搜索、数据库查询、代码执行、文件读写、发送邮件/消息、调用第三方API如天气、股票等。框架如LangChain、LlamaIndex提供了大量现成的工具集成大大降低了开发门槛。3.3 记忆模块跨越会话的持久化经验如果智能体每次运行都像“金鱼”一样只有7秒记忆那它就无法完成需要长期上下文的任务。记忆模块负责存储和检索智能体的经验。它通常分为几种类型短期记忆/会话记忆存储当前任务循环中的上下文即本次规划、行动和观察的历史。这通常由模型的上下文窗口直接承担。长期记忆存储需要持久化、供未来任务参考的信息。这通常通过外部存储实现例如向量数据库用于存储智能体执行任务过程中产生的“经验片段”如“某API在高峰时段容易超时”并通过语义搜索在需要时快速检索相关经验。传统数据库用于存储结构化的任务历史、用户偏好、实体信息等。例如我们的市场周报智能体在运行几周后其长期记忆中可能存储了“数据源‘TechCrunch’对于融资新闻报道速度快但深度一般”、“关键词‘AI code assistant’比‘AI programming tool’搜到的结果更聚焦”。当下一次执行规划时它就可以检索这些记忆优化自己的数据源选择和关键词策略。3.4 反思与迭代模块智能体的“元认知”这是区分高级智能体与简单自动化脚本的关键。反思模块让智能体能够评估自身行动的结果并从失败或低效中学习。其工作流程通常是结果评估在一个任务或一个循环结束后系统会触发一个反思Prompt要求模型基于任务最初的“成功标准”评估执行结果。例如“刚才的网页搜索任务成功找到了5篇相关文章吗摘要的质量如何”根因分析如果结果不理想模型需要分析原因。是工具选择不当参数设置错误还是对目标的理解有偏差计划修正根据分析出的原因模型提出对后续计划的修正建议。例如“搜索到的文章多为旧闻因为关键词中缺少时间限定。建议在后续搜索中增加‘last week’或‘2024’等时间关键词。”通过这个“行动-观察-反思-再规划”的循环智能体能够动态适应环境变化逐步改进其策略表现出一定的学习和适应能力。这虽然离通用人工智能的“学习”还很远但在特定任务范围内已经能显著提升系统的鲁棒性和效率。4. 实战构建从零搭建一个简易自动化研究助手理论讲得再多不如动手实践。为了让大家更具体地感受“第三种范式”我将带你一步步构建一个简化版的“自动化研究助手”智能体。这个助手的目标是给定一个研究主题它能自动搜索近期相关论文下载并阅读摘要最后整理成一份结构化的文献列表。4.1 环境准备与工具选型我们选择Python作为开发语言因为它有最丰富的AI生态。核心框架我们使用LangChain因为它对智能体、工具和记忆模块提供了高层次抽象能极大简化开发。同时我们需要一个强大且支持工具调用的模型这里选择OpenAI的GPT-4或性能相近的替代品。其他工具包括搜索引擎工具我们将使用Serper API一个谷歌搜索的付费API它比直接爬取更稳定合规。当然你也可以用DuckDuckGo或其他搜索API。学术搜索工具为了找论文我们集成arXiv API这是一个免费的预印本论文库。记忆存储为了简单起见本次示例我们使用内存存储但会设计好接口便于后续替换为ChromaDB或Pinecone这类向量数据库。首先安装核心库并设置环境变量pip install langchain langchain-openai langchain-community requests arxiv export OPENAI_API_KEY你的OpenAI密钥 export SERPER_API_KEY你的Serper密钥 # 如果使用Serper4.2 定义智能体的工具集智能体的能力取决于它拥有什么工具。我们来定义三个核心工具通用网络搜索工具用于查找概念解释、新闻、博客文章等。学术论文搜索工具专门用于从arXiv查找特定主题的论文。总结工具虽然大模型本身可以总结但我们将其封装成一个明确的工具让智能体在需要时调用这有助于规划。以下是使用LangChain定义工具的示例代码from langchain.tools import Tool from langchain_community.utilities import SerperAPIWrapper import arxiv # 工具1通用网络搜索 search SerperAPIWrapper(serper_api_keyos.environ[SERPER_API_KEY]) search_tool Tool( nameWebSearch, funcsearch.run, description使用搜索引擎查询网络信息。输入应为明确的搜索查询字符串。 ) # 工具2学术论文搜索 def search_arxiv(query: str, max_results: int 5) - str: 在arXiv上搜索论文。 client arxiv.Client() search arxiv.Search( queryquery, max_resultsmax_results, sort_byarxiv.SortCriterion.SubmittedDate ) results [] for result in client.results(search): results.append({ title: result.title, authors: [a.name for a in result.authors], summary: result.summary[:500], # 截取部分摘要 published: result.published.strftime(%Y-%m-%d), pdf_url: result.pdf_url }) return str(results) # 转换为字符串供LLM阅读 arxiv_tool Tool( nameArxivSearch, funcsearch_arxiv, description在arXiv学术预印本库中搜索论文。输入为搜索关键词返回论文标题、作者、摘要和链接。 ) # 工具3文本总结工具示例实际可更复杂 from langchain.chains import LLMChain from langchain.prompts import PromptTemplate from langchain_openai import ChatOpenAI llm ChatOpenAI(modelgpt-4, temperature0) summary_prompt PromptTemplate.from_template(请用中文简要总结以下内容\n\n{text}) summary_chain LLMChain(llmllm, promptsummary_prompt) summary_tool Tool( nameTextSummarizer, funclambda text: summary_chain.run(texttext), description对长文本进行摘要总结。输入为需要总结的文本。 ) # 将工具组合成列表 tools [search_tool, arxiv_tool, summary_tool]4.3 构建智能体执行循环有了工具我们需要创建智能体并为其设计一个简单的执行循环。这里我们使用LangChain的ReAct代理框架它鼓励模型以“思考 - 行动 - 观察”的模式进行推理。from langchain.agents import initialize_agent, AgentType from langchain.memory import ConversationBufferMemory # 初始化记忆虽然简单但为未来扩展留出接口 memory ConversationBufferMemory(memory_keychat_history, return_messagesTrue) # 创建智能体 agent initialize_agent( tools, llm, agentAgentType.CHAT_CONVERSATIONAL_REACT_DESCRIPTION, # 适合对话和工具调用的代理类型 verboseTrue, # 打印详细执行过程便于调试 memorymemory, handle_parsing_errorsTrue # 优雅处理解析错误 ) # 定义智能体执行函数 def research_agent_execute(research_topic: str): 研究助手智能体的执行入口。 # 构造初始指令。注意我们给出了一个高层次的、目标导向的指令。 initial_instruction f 你是一个自动化研究助手。你的目标是围绕“{research_topic}”这个主题整理一份近期的研究概况。 请按以下步骤执行 1. 首先使用网络搜索工具了解该主题的基本定义、核心子领域和当前业界关注点。 2. 然后使用学术论文搜索工具查找该主题下最近3个月内的重要预印本论文。 3. 接着对找到的关键论文摘要进行阅读和总结。 4. 最后整合网络信息和学术信息生成一份简洁的报告内容包括主题概述、近期研究热点、以及3-5篇核心论文的标题与核心贡献。 请开始你的工作一步一步来在需要时使用工具。 try: response agent.run(initial_instruction) return response except Exception as e: return f智能体执行过程中出现错误{e} # 运行智能体 if __name__ __main__: topic 多模态大语言模型在机器人规划中的应用 result research_agent_execute(topic) print(\n *50) print(最终研究报告) print(*50) print(result)当你运行这段代码时通过设置verboseTrue你将在控制台看到智能体完整的思考过程思考用户要我研究“多模态大语言模型在机器人规划中的应用”。我需要先理解这个主题是什么。我应该使用WebSearch工具。 行动使用工具[WebSearch]输入“多模态大语言模型 机器人规划 应用 概述”。 观察[搜索引擎返回的结果...] 思考根据搜索结果我了解了基本概念。现在需要找近期的学术论文。使用ArxivSearch工具。 行动使用工具[ArxivSearch]输入“multimodal large language model robot planning”。 观察[arXiv返回的论文列表...] 思考我找到了5篇相关论文。其中三篇看起来特别相关。我需要阅读它们的摘要并总结。我可以调用TextSummarizer工具也可以自己总结。为了更可控我使用总结工具。 行动使用工具[TextSummarizer]输入“[论文1摘要]...” ...这个过程生动地展示了智能体如何自主规划、选择工具、执行行动并整合信息。4.4 关键参数调优与成本控制构建原型只是第一步要让智能体实用化必须关注两个核心问题效果和成本。效果调优Prompt工程给智能体的初始指令initial_instruction至关重要。指令越清晰、结构化智能体“跑偏”的概率越低。可以尝试加入“如果遇到X情况则采取Y策略”这样的条件性指引。工具设计工具的描述description要精确。模糊的描述会导致模型误用工具。好的描述应说明工具的用途、输入格式和预期输出。反思集成可以在每个主要步骤后加入简单的反思Prompt例如“基于你刚才搜索到的信息你对原计划有需要调整的地方吗”这能提升智能体的适应性。成本控制 大模型API调用和工具调用如搜索API都可能产生费用。在开发中必须考虑设置Token上限在初始化LLM时设置max_tokens参数防止智能体“话痨”产生过长的、昂贵的输出。缓存机制对相同的搜索查询或处理内容进行缓存避免重复调用。LangChain提供了多种缓存后端。任务超时与中断为智能体的执行循环设置超时时间防止其陷入死循环或无意义的重复操作。选择性详细输出在verbose模式下调试但在生产环境中关闭以减少不必要的输出解析开销。实操心得在早期测试中不要给智能体过于开放的目标如“研究AI”。这会导致它进行无边际的搜索成本激增且结果发散。应该从“研究AI在医疗影像诊断中近半年的进展”这样具体、有时间、有领域限定的任务开始。同时密切监控API的调用日志和费用面板。5. 挑战、局限与未来展望尽管“第三种范式”描绘了诱人的前景但我们必须清醒地认识到当前的技术仍处于非常早期的阶段距离稳定、可靠、大规模的应用还有很长的路要走。在实际部署中我们遇到了诸多挑战。5.1 当前面临的核心挑战可靠性问题“幻觉”与错误传播大模型固有的“幻觉”问题在智能体场景下被放大。一个规划错误或一个基于错误信息的工具调用可能导致整个任务链的失败。智能体缺乏对现实世界的真实“理解”和“常识”验证。高昂的成本与延迟智能体的“思考-行动”循环涉及多次LLM调用每次调用都有成本和时间开销。处理一个复杂任务可能需要数十轮交互总成本和延迟可能高到无法接受。这对于需要实时响应的应用是致命伤。可控性与安全性风险一个自主运行的智能体可能做出意想不到甚至有害的操作。例如一个被赋予邮件发送工具的智能体可能会因误解指令而向错误的人发送敏感信息。如何为智能体的行动设置安全护栏Guardrails进行权限控制和操作确认是亟待解决的安全课题。评估与调试困难传统的软件有明确的输入输出可以通过单元测试验证。智能体的行为是非确定性的其“思考”过程是一个黑箱。如何系统性地评估智能体的性能如何调试一个失败的任务是规划出错、工具调用出错还是反思逻辑出错这些都给开发和运维带来了巨大挑战。5.2 实用化落地的关键考量基于这些挑战在考虑将此类智能体投入实际生产时必须采取审慎的策略场景选择优先选择容错率较高、流程相对结构化、价值明确的场景。例如内部的数据分析报告生成、竞品信息监控、代码仓库的日常维护如自动生成CHANGELOG等。避免在涉及金融交易、法律文书、直接客户交互等高风险场景中初期就使用全自动智能体。人机协同最现实的路径是“人在环路”Human-in-the-loop。智能体负责执行繁琐、重复的信息收集和初步处理工作而将关键的决策点、结果审核和最终判断留给人。例如研究助手整理出论文列表和摘要由研究员来最终筛选和深度阅读。模块化与可解释性将智能体系统设计得尽可能模块化。清晰的规划、行动、观察日志能帮助开发者和用户理解智能体“在想什么”、“做了什么”在出现问题时可以快速定位和干预。5.3 技术演进的方向Karpathy提出这个概念更像是指出了一个演进方向而非宣告一个已经成熟的产品。这个方向正在吸引大量的研究和工程投入更强大的基础模型未来的模型需要在规划、工具使用和反思方面具备更强的原生能力减少对复杂Prompt工程的依赖并降低幻觉率。专用智能体框架会出现更多像AutoGPT、BabyAGI雏形但更稳定、更易用的专用框架它们会内置最佳实践处理好记忆、工具集成、安全限制等底层复杂性。仿真测试环境为了评估和训练智能体构建安全的数字仿真环境如模拟的浏览器、操作系统将成为关键让智能体能在其中“沙盒”演练学习技能而不造成实际损害。成本优化技术混合使用大小模型用小模型处理简单决策大模型处理复杂思考、更高效的上下文管理技术、以及模型本身的降价将共同推动智能体应用的成本曲线下降。所以回到最初的问题“这是不是夸大其词” 我认为Karpathy的观点并没有夸大趋势但他所描述的“第三种范式”的成熟形态确实还需要时间。它不是一个即将颠覆一切的“奇点”而是一个清晰的技术演进路标。它告诉我们AI应用的下一个前沿是创建能够自主处理复杂工作流的智能系统。对于开发者和创业者来说现在的价值不在于立刻做出一个全能的AI员工而在于深入理解这个范式从中识别出那些在当下技术条件下即可解决、且有商业价值的细分任务开始积累经验。比如一个能自动整理每日行业资讯的智能体或者一个能根据错误日志自动搜索解决方案并尝试修复的运维助手这些看似“小”的应用正是通往未来更宏大图景的坚实台阶。 从提示工程到自主智能体：大模型交互的第三种范式解析与实践
1. 引言当“提示工程”不再是唯一答案最近在AI圈子里一个由Andrej Karpathy提出的概念——“大模型交互的第三种范式”引发了不小的讨论。很多人第一反应是这会不会又是技术圈的一次概念炒作毕竟从最初的“提示工程”到后来的“检索增强生成”我们已经习惯了围绕大模型构建交互方式的迭代。但当我深入研究了Karpathy的论述并结合自己近一年来在多个实际项目中应用大模型的经验后我发现这个概念并非空穴来风它确实指向了一个我们正在经历、但尚未被清晰定义的转变。简单来说Karpathy所说的“第三种范式”核心是将大语言模型从一个需要精心“提问”的问答机转变为一个可以自主、持续运行的“进程”或“代理”。这听起来有点抽象我举个生活中的例子以前我们用搜索引擎得像侦探一样精心构思关键词第一种范式指令-响应后来有了智能助手我们可以用自然语言对话让它帮我们查天气、定闹钟第二种范式多轮对话/提示工程。而现在第三种范式期望的是你告诉这个“代理”一个长期目标比如“帮我运营这个社交媒体账号目标是每周增长500个关注者”它就能自己制定计划、执行发布、分析数据、并不断调整策略像一个真正的数字员工一样持续工作只在关键节点向你汇报或请求确认。这种转变背后的驱动力是大模型本身能力的进化以及我们对其应用场景的深度挖掘。它不再满足于充当一个“更聪明的Siri”而是开始涉足需要长期记忆、复杂规划、工具使用和环境交互的领域。接下来我将结合具体的实践案例和技术细节拆解这种范式究竟是什么它如何工作以及对我们开发者、产品经理甚至普通用户意味着什么。2. 范式演进从“问答”到“进程”的技术脉络要理解为什么“第三种范式”是一个值得关注的新阶段我们需要回顾一下前两种范式是如何定义我们与AI的交互方式的。这不是简单的概念堆砌而是技术能力、应用场景和用户期望三者共同演进的结果。2.1 第一种范式指令-响应与“万物皆可Prompt”最早的交互方式极其直接用户输入一个问题或指令模型返回一个答案或结果。这很像使用一个超级增强版的命令行工具。它的核心假设是单次交互是独立且完整的。开发者需要做的是通过精巧的Prompt设计即“提示工程”将用户的模糊意图转化为模型能精确理解的指令。例如早期让模型总结一篇长文章我们需要写一个非常结构化的Prompt“请用不超过200字总结以下文章的核心观点并列出三个关键论据。” 这种范式的优势是简单、可控但局限性也很明显它缺乏上下文记忆每次交互都是“重启”它无法处理需要多步骤、依赖历史信息或与环境动态交互的复杂任务。整个生态围绕着“如何写出更好的Prompt”展开诞生了大量的Prompt模板库和调优指南。2.2 第二种范式会话上下文与检索增强生成随着模型上下文窗口的扩大从几千token发展到数十万甚至百万token以及像LangChain这类框架的出现第二种范式成熟起来。其核心特征是引入了“上下文”和“工具”的概念。交互不再是一次性的而是可以在一个会话中持续进行模型能记住之前的对话历史。更重要的是通过“检索增强生成”RAG技术模型可以实时从外部知识库如公司文档、产品手册中获取信息来生成更准确、更及时的答案。这个阶段的典型应用是智能客服助手和知识库问答系统。你问它“我们产品的退货政策是什么”它不会仅凭训练数据中的模糊记忆回答而是会先去检索最新的政策文档然后结合文档内容生成回答。这种范式解决了信息新鲜度和专业性的问题并将交互扩展到了多轮对话。然而它的本质仍然是“响应式”的——AI被动地等待用户提问然后执行“检索-生成”的循环。任务的发起者、规划者和主要决策者仍然是人类用户。2.3 第三种范式自主智能体与持续性进程Karpathy提出的第三种范式试图突破“响应式”的局限。在这种范式下大模型被赋予一个长期目标或身份并作为一个持续运行的“进程”被启动。这个进程拥有几个关键的新特质自主性与主动性智能体不再只是回答问题而是主动规划并执行任务。例如一个“自动化研究助手”被启动后它会自己制定文献搜索策略、阅读论文、提取关键信息、撰写综述报告并定期向你推送进展。状态持久性与记忆智能体拥有超越单次会话的长期记忆。它可以记住自己的目标、已完成的工作、从环境中学习到的经验并在后续决策中利用这些信息。这通常通过向量数据库或更复杂的记忆模块来实现。工具使用与环境交互智能体被赋予了使用各种工具的能力如调用API、操作软件、控制硬件使其能够直接影响外部环境而不仅仅是生成文本。它可以自己打开浏览器搜索用Python分析数据或者发送一封邮件。规划与反思智能体具备将宏观目标分解为可执行子任务的能力规划并能在任务失败或遇到意外时分析原因并调整策略反思。这构成了一个“感知-思考-行动”的循环。一个生动的类比是第一种范式像计算器你按一下它算一下第二种范式像高级科学计算器能记住你上一步的公式而第三种范式则像一个被你雇佣的、拥有专业知识的实习生你告诉他最终目标他会自己安排时间、查找资料、完成任务并给你交付成果。注意目前完全实现这种范式的系统仍处于探索阶段面临成本、可靠性、安全性等多重挑战。但它代表的方向——降低人类在复杂任务中的认知负荷和操作负担——是明确且极具吸引力的。3. 核心架构拆解智能体如何“思考”与“行动”理解了范式的概念我们深入到技术层面。一个典型的“第三种范式”智能体系统是如何构建的它并不是一个魔法黑盒其核心通常围绕一个“智能体循环”架构展开。我将以一个“自动化市场周报生成智能体”为例拆解其内部运作机制。3.1 规划模块从目标到任务树的分解当智能体接收到一个宏观指令如“生成一份关于AI编程工具的本周市场动态报告”时规划模块首先启动。它的作用是将模糊的目标转化为清晰、可执行的任务序列。这个过程不是随机的而是基于对目标的理解和内置的“任务分解知识”。一个常见的实现方式是使用大模型本身进行递归式任务分解。系统会设计一个用于规划的专用Prompt例如“你是一个项目规划专家。请将‘生成AI编程工具市场周报’这个目标分解为一系列具体的、顺序执行的子任务。每个子任务应该是原子化的并且明确其产出物。” 模型可能会输出如下任务树信息收集确定需要关注的AI编程工具类别如代码补全、调试、生成等。数据源确定列出需要爬取或监控的新闻网站、技术博客、GitHub趋势榜等。信息检索与摘要从各数据源获取过去一周的相关文章并提取核心内容。趋势分析与整合对比不同信息识别出本周的主要趋势、重磅更新或融资事件。报告撰写按照固定的报告模板引言、趋势概述、重点事件点评、未来展望组织内容。格式美化与检查将报告生成为格式良好的Markdown或PDF文件并进行基础的事实核对。实操心得规划的质量直接决定智能体执行的效率。在实践中我们发现让模型在规划时同时输出每个任务的“成功标准”非常有用。例如对于“信息检索”任务成功标准可以是“至少覆盖5个核心数据源并提取出10篇以上相关文章的摘要”。这为后续的“反思”环节提供了评估依据。3.2 工具调用模块智能体的“手”和“脚”规划好了任务智能体需要“动手”去执行。这就是工具调用模块的职责。它让大模型具备了操作数字世界的能力。这个模块的核心是一个工具注册表和一套调用规范。开发者需要预先将各种工具函数“描述”给大模型。例如工具名称search_web功能描述使用搜索引擎查询指定关键词返回前N条结果的标题、链接和摘要。参数query(搜索关键词)num_results(返回数量)。返回格式JSON列表。当大模型在执行“信息检索”任务时它可能会生成这样的内部指令“我需要搜索‘GitHub Copilot 本周更新’。应该调用search_web工具参数为query‘GitHub Copilot update week’ num_results5。” 系统会截取这段指令解析出工具调用请求执行对应的Python函数并将搜索结果JSON格式重新注入到模型的上下文中供其后续分析使用。常见的工具包括网络搜索、数据库查询、代码执行、文件读写、发送邮件/消息、调用第三方API如天气、股票等。框架如LangChain、LlamaIndex提供了大量现成的工具集成大大降低了开发门槛。3.3 记忆模块跨越会话的持久化经验如果智能体每次运行都像“金鱼”一样只有7秒记忆那它就无法完成需要长期上下文的任务。记忆模块负责存储和检索智能体的经验。它通常分为几种类型短期记忆/会话记忆存储当前任务循环中的上下文即本次规划、行动和观察的历史。这通常由模型的上下文窗口直接承担。长期记忆存储需要持久化、供未来任务参考的信息。这通常通过外部存储实现例如向量数据库用于存储智能体执行任务过程中产生的“经验片段”如“某API在高峰时段容易超时”并通过语义搜索在需要时快速检索相关经验。传统数据库用于存储结构化的任务历史、用户偏好、实体信息等。例如我们的市场周报智能体在运行几周后其长期记忆中可能存储了“数据源‘TechCrunch’对于融资新闻报道速度快但深度一般”、“关键词‘AI code assistant’比‘AI programming tool’搜到的结果更聚焦”。当下一次执行规划时它就可以检索这些记忆优化自己的数据源选择和关键词策略。3.4 反思与迭代模块智能体的“元认知”这是区分高级智能体与简单自动化脚本的关键。反思模块让智能体能够评估自身行动的结果并从失败或低效中学习。其工作流程通常是结果评估在一个任务或一个循环结束后系统会触发一个反思Prompt要求模型基于任务最初的“成功标准”评估执行结果。例如“刚才的网页搜索任务成功找到了5篇相关文章吗摘要的质量如何”根因分析如果结果不理想模型需要分析原因。是工具选择不当参数设置错误还是对目标的理解有偏差计划修正根据分析出的原因模型提出对后续计划的修正建议。例如“搜索到的文章多为旧闻因为关键词中缺少时间限定。建议在后续搜索中增加‘last week’或‘2024’等时间关键词。”通过这个“行动-观察-反思-再规划”的循环智能体能够动态适应环境变化逐步改进其策略表现出一定的学习和适应能力。这虽然离通用人工智能的“学习”还很远但在特定任务范围内已经能显著提升系统的鲁棒性和效率。4. 实战构建从零搭建一个简易自动化研究助手理论讲得再多不如动手实践。为了让大家更具体地感受“第三种范式”我将带你一步步构建一个简化版的“自动化研究助手”智能体。这个助手的目标是给定一个研究主题它能自动搜索近期相关论文下载并阅读摘要最后整理成一份结构化的文献列表。4.1 环境准备与工具选型我们选择Python作为开发语言因为它有最丰富的AI生态。核心框架我们使用LangChain因为它对智能体、工具和记忆模块提供了高层次抽象能极大简化开发。同时我们需要一个强大且支持工具调用的模型这里选择OpenAI的GPT-4或性能相近的替代品。其他工具包括搜索引擎工具我们将使用Serper API一个谷歌搜索的付费API它比直接爬取更稳定合规。当然你也可以用DuckDuckGo或其他搜索API。学术搜索工具为了找论文我们集成arXiv API这是一个免费的预印本论文库。记忆存储为了简单起见本次示例我们使用内存存储但会设计好接口便于后续替换为ChromaDB或Pinecone这类向量数据库。首先安装核心库并设置环境变量pip install langchain langchain-openai langchain-community requests arxiv export OPENAI_API_KEY你的OpenAI密钥 export SERPER_API_KEY你的Serper密钥 # 如果使用Serper4.2 定义智能体的工具集智能体的能力取决于它拥有什么工具。我们来定义三个核心工具通用网络搜索工具用于查找概念解释、新闻、博客文章等。学术论文搜索工具专门用于从arXiv查找特定主题的论文。总结工具虽然大模型本身可以总结但我们将其封装成一个明确的工具让智能体在需要时调用这有助于规划。以下是使用LangChain定义工具的示例代码from langchain.tools import Tool from langchain_community.utilities import SerperAPIWrapper import arxiv # 工具1通用网络搜索 search SerperAPIWrapper(serper_api_keyos.environ[SERPER_API_KEY]) search_tool Tool( nameWebSearch, funcsearch.run, description使用搜索引擎查询网络信息。输入应为明确的搜索查询字符串。 ) # 工具2学术论文搜索 def search_arxiv(query: str, max_results: int 5) - str: 在arXiv上搜索论文。 client arxiv.Client() search arxiv.Search( queryquery, max_resultsmax_results, sort_byarxiv.SortCriterion.SubmittedDate ) results [] for result in client.results(search): results.append({ title: result.title, authors: [a.name for a in result.authors], summary: result.summary[:500], # 截取部分摘要 published: result.published.strftime(%Y-%m-%d), pdf_url: result.pdf_url }) return str(results) # 转换为字符串供LLM阅读 arxiv_tool Tool( nameArxivSearch, funcsearch_arxiv, description在arXiv学术预印本库中搜索论文。输入为搜索关键词返回论文标题、作者、摘要和链接。 ) # 工具3文本总结工具示例实际可更复杂 from langchain.chains import LLMChain from langchain.prompts import PromptTemplate from langchain_openai import ChatOpenAI llm ChatOpenAI(modelgpt-4, temperature0) summary_prompt PromptTemplate.from_template(请用中文简要总结以下内容\n\n{text}) summary_chain LLMChain(llmllm, promptsummary_prompt) summary_tool Tool( nameTextSummarizer, funclambda text: summary_chain.run(texttext), description对长文本进行摘要总结。输入为需要总结的文本。 ) # 将工具组合成列表 tools [search_tool, arxiv_tool, summary_tool]4.3 构建智能体执行循环有了工具我们需要创建智能体并为其设计一个简单的执行循环。这里我们使用LangChain的ReAct代理框架它鼓励模型以“思考 - 行动 - 观察”的模式进行推理。from langchain.agents import initialize_agent, AgentType from langchain.memory import ConversationBufferMemory # 初始化记忆虽然简单但为未来扩展留出接口 memory ConversationBufferMemory(memory_keychat_history, return_messagesTrue) # 创建智能体 agent initialize_agent( tools, llm, agentAgentType.CHAT_CONVERSATIONAL_REACT_DESCRIPTION, # 适合对话和工具调用的代理类型 verboseTrue, # 打印详细执行过程便于调试 memorymemory, handle_parsing_errorsTrue # 优雅处理解析错误 ) # 定义智能体执行函数 def research_agent_execute(research_topic: str): 研究助手智能体的执行入口。 # 构造初始指令。注意我们给出了一个高层次的、目标导向的指令。 initial_instruction f 你是一个自动化研究助手。你的目标是围绕“{research_topic}”这个主题整理一份近期的研究概况。 请按以下步骤执行 1. 首先使用网络搜索工具了解该主题的基本定义、核心子领域和当前业界关注点。 2. 然后使用学术论文搜索工具查找该主题下最近3个月内的重要预印本论文。 3. 接着对找到的关键论文摘要进行阅读和总结。 4. 最后整合网络信息和学术信息生成一份简洁的报告内容包括主题概述、近期研究热点、以及3-5篇核心论文的标题与核心贡献。 请开始你的工作一步一步来在需要时使用工具。 try: response agent.run(initial_instruction) return response except Exception as e: return f智能体执行过程中出现错误{e} # 运行智能体 if __name__ __main__: topic 多模态大语言模型在机器人规划中的应用 result research_agent_execute(topic) print(\n *50) print(最终研究报告) print(*50) print(result)当你运行这段代码时通过设置verboseTrue你将在控制台看到智能体完整的思考过程思考用户要我研究“多模态大语言模型在机器人规划中的应用”。我需要先理解这个主题是什么。我应该使用WebSearch工具。 行动使用工具[WebSearch]输入“多模态大语言模型 机器人规划 应用 概述”。 观察[搜索引擎返回的结果...] 思考根据搜索结果我了解了基本概念。现在需要找近期的学术论文。使用ArxivSearch工具。 行动使用工具[ArxivSearch]输入“multimodal large language model robot planning”。 观察[arXiv返回的论文列表...] 思考我找到了5篇相关论文。其中三篇看起来特别相关。我需要阅读它们的摘要并总结。我可以调用TextSummarizer工具也可以自己总结。为了更可控我使用总结工具。 行动使用工具[TextSummarizer]输入“[论文1摘要]...” ...这个过程生动地展示了智能体如何自主规划、选择工具、执行行动并整合信息。4.4 关键参数调优与成本控制构建原型只是第一步要让智能体实用化必须关注两个核心问题效果和成本。效果调优Prompt工程给智能体的初始指令initial_instruction至关重要。指令越清晰、结构化智能体“跑偏”的概率越低。可以尝试加入“如果遇到X情况则采取Y策略”这样的条件性指引。工具设计工具的描述description要精确。模糊的描述会导致模型误用工具。好的描述应说明工具的用途、输入格式和预期输出。反思集成可以在每个主要步骤后加入简单的反思Prompt例如“基于你刚才搜索到的信息你对原计划有需要调整的地方吗”这能提升智能体的适应性。成本控制 大模型API调用和工具调用如搜索API都可能产生费用。在开发中必须考虑设置Token上限在初始化LLM时设置max_tokens参数防止智能体“话痨”产生过长的、昂贵的输出。缓存机制对相同的搜索查询或处理内容进行缓存避免重复调用。LangChain提供了多种缓存后端。任务超时与中断为智能体的执行循环设置超时时间防止其陷入死循环或无意义的重复操作。选择性详细输出在verbose模式下调试但在生产环境中关闭以减少不必要的输出解析开销。实操心得在早期测试中不要给智能体过于开放的目标如“研究AI”。这会导致它进行无边际的搜索成本激增且结果发散。应该从“研究AI在医疗影像诊断中近半年的进展”这样具体、有时间、有领域限定的任务开始。同时密切监控API的调用日志和费用面板。5. 挑战、局限与未来展望尽管“第三种范式”描绘了诱人的前景但我们必须清醒地认识到当前的技术仍处于非常早期的阶段距离稳定、可靠、大规模的应用还有很长的路要走。在实际部署中我们遇到了诸多挑战。5.1 当前面临的核心挑战可靠性问题“幻觉”与错误传播大模型固有的“幻觉”问题在智能体场景下被放大。一个规划错误或一个基于错误信息的工具调用可能导致整个任务链的失败。智能体缺乏对现实世界的真实“理解”和“常识”验证。高昂的成本与延迟智能体的“思考-行动”循环涉及多次LLM调用每次调用都有成本和时间开销。处理一个复杂任务可能需要数十轮交互总成本和延迟可能高到无法接受。这对于需要实时响应的应用是致命伤。可控性与安全性风险一个自主运行的智能体可能做出意想不到甚至有害的操作。例如一个被赋予邮件发送工具的智能体可能会因误解指令而向错误的人发送敏感信息。如何为智能体的行动设置安全护栏Guardrails进行权限控制和操作确认是亟待解决的安全课题。评估与调试困难传统的软件有明确的输入输出可以通过单元测试验证。智能体的行为是非确定性的其“思考”过程是一个黑箱。如何系统性地评估智能体的性能如何调试一个失败的任务是规划出错、工具调用出错还是反思逻辑出错这些都给开发和运维带来了巨大挑战。5.2 实用化落地的关键考量基于这些挑战在考虑将此类智能体投入实际生产时必须采取审慎的策略场景选择优先选择容错率较高、流程相对结构化、价值明确的场景。例如内部的数据分析报告生成、竞品信息监控、代码仓库的日常维护如自动生成CHANGELOG等。避免在涉及金融交易、法律文书、直接客户交互等高风险场景中初期就使用全自动智能体。人机协同最现实的路径是“人在环路”Human-in-the-loop。智能体负责执行繁琐、重复的信息收集和初步处理工作而将关键的决策点、结果审核和最终判断留给人。例如研究助手整理出论文列表和摘要由研究员来最终筛选和深度阅读。模块化与可解释性将智能体系统设计得尽可能模块化。清晰的规划、行动、观察日志能帮助开发者和用户理解智能体“在想什么”、“做了什么”在出现问题时可以快速定位和干预。5.3 技术演进的方向Karpathy提出这个概念更像是指出了一个演进方向而非宣告一个已经成熟的产品。这个方向正在吸引大量的研究和工程投入更强大的基础模型未来的模型需要在规划、工具使用和反思方面具备更强的原生能力减少对复杂Prompt工程的依赖并降低幻觉率。专用智能体框架会出现更多像AutoGPT、BabyAGI雏形但更稳定、更易用的专用框架它们会内置最佳实践处理好记忆、工具集成、安全限制等底层复杂性。仿真测试环境为了评估和训练智能体构建安全的数字仿真环境如模拟的浏览器、操作系统将成为关键让智能体能在其中“沙盒”演练学习技能而不造成实际损害。成本优化技术混合使用大小模型用小模型处理简单决策大模型处理复杂思考、更高效的上下文管理技术、以及模型本身的降价将共同推动智能体应用的成本曲线下降。所以回到最初的问题“这是不是夸大其词” 我认为Karpathy的观点并没有夸大趋势但他所描述的“第三种范式”的成熟形态确实还需要时间。它不是一个即将颠覆一切的“奇点”而是一个清晰的技术演进路标。它告诉我们AI应用的下一个前沿是创建能够自主处理复杂工作流的智能系统。对于开发者和创业者来说现在的价值不在于立刻做出一个全能的AI员工而在于深入理解这个范式从中识别出那些在当下技术条件下即可解决、且有商业价值的细分任务开始积累经验。比如一个能自动整理每日行业资讯的智能体或者一个能根据错误日志自动搜索解决方案并尝试修复的运维助手这些看似“小”的应用正是通往未来更宏大图景的坚实台阶。