1. 从“指令”到“交互”范式转移的临界点最近AI圈子里关于“大模型交互范式”的讨论又热了起来源头是Karpathy的一篇分享。他提出了一个观点认为我们正在进入大模型交互的“第三种范式”。乍一听这标题有点唬人是不是又在炒概念但作为一个从GPT-2时代就开始折腾这些模型一路看着它们从“玩具”变成“生产力工具”的老兵我仔细琢磨了一下他说的东西再结合自己最近在项目里踩的坑和做的尝试发现这个“第三种范式”的提法还真不是空穴来风它确实点出了我们使用大模型方式上一个正在发生的、根本性的变化。简单来说我们经历了什么最早是“单次问答”One-shot QA你问它答一锤子买卖。后来进化到“上下文学习”In-Context Learning和“思维链”Chain-of-Thought我们学会了在对话里给它举例子、加引导让它一步步推理。但这两种本质上还是“人类驱动模型执行”的模式。人类是总指挥模型是士兵每一步都需要你明确下令。而Karpathy所说的“第三种范式”我理解其核心是“模型作为智能体与环境持续交互”。模型不再只是被动响应你的单次提示而是被赋予一个目标、一些工具比如搜索、执行代码、操作API然后它自己规划、执行、观察结果、调整策略在一个循环中自主完成任务。这听起来是不是很像AI智能体Agent没错但它的意义不止于此。它意味着交互的“单位”变了。以前我们交互的基本单位是“一次对话”或“一个复杂提示”现在变成了“一个目标驱动的持续性过程”。这对我们开发者、产品经理、甚至普通用户来说都意味着工作流和思维模式的彻底重塑。接下来我就结合自己的实践拆解一下这种范式到底是什么、为什么现在才成为可能、以及我们具体该怎么上手和避坑。2. 范式演进史我们是如何走到今天的要理解为什么“第三种范式”是个大事我们得回头看看前两种范式解决了什么又留下了什么坑。这不是学术回顾而是理解当前技术选择必然性的关键。2.1 范式一单次提示与零样本/少样本学习在大模型早期交互简单粗暴。你写一个提示Prompt比如“把这段英文翻译成中文”模型直接给出答案。高级点会用“少样本学习”在提示里给几个例子比如请将英文翻译成中文。 例子1 输入: Hello, world! 输出: 你好世界 例子2 输入: The weather is nice today. 输出: 今天天气很好。 现在请翻译 输入: This is the third paradigm. 输出:这个范式的核心逻辑是“模式匹配与补全”。模型根据你给的输入和有限的例子去匹配它海量预训练数据中学到的模式然后生成最可能的续写。它的优势是直接、简单、延迟低。但问题也显而易见任务复杂度受限对于需要多步骤、依赖外部信息或动态环境反馈的任务单次提示无能为力。比如“帮我查查今天某支股票的价格并分析其近期走势”模型没有实时数据只能胡编乱造或拒绝回答。可靠性差输出是“生成”的不是“执行”的结果。没有验证机制模型可能会“一本正经地胡说八道”幻觉。人类负担重要想结果好需要精心设计提示成了“提示工程”。任务越复杂提示就越像一门玄学。在实际项目中这种范式至今仍在大量简单、确定的场景中使用比如文本润色、基础分类、格式转换。它的定位很清晰处理定义明确、无需外部状态的轻型任务。2.2 范式二思维链与复杂提示工程当任务变复杂人们发现让模型“把思考过程说出来”能极大提升准确率。这就是思维链。同时通过设计复杂的提示模板将系统指令、用户查询、历史对话、工具描述等打包成一个上下文形成了更强大的交互方式。例如一个简单的规划任务提示可能包含你是一个智能助手。请按照以下步骤回答用户问题 1. 理解用户意图。 2. 如果需要事实信息请调用搜索工具。 3. 根据信息进行分析。 4. 给出最终答案。 工具描述 - 搜索工具[web_search]输入查询词返回相关摘要。 历史对话 用户特斯拉的CEO是谁 助手特斯拉的CEO是埃隆·马斯克。 当前问题他最近有什么公开言论这个范式的核心逻辑是“在上下文内进行显式推理与规划”。它通过延长上下文窗口让模型能够进行多轮“内心戏”并意识到工具的存在。这带来了巨大进步可处理多步骤任务通过引导模型能分解问题。可控性增强通过系统提示可以设定角色、约束输出格式。初步的工具使用模型知道有工具可用并能在提示中声明要调用。但它的本质缺陷在于所有“思考”都发生在一次前向传播中是脱离现实的“沙盘推演”。模型说“我要调用搜索工具”但这只是一个文本输出。真正的调用、执行、获取结果还需要外部系统来解析这个输出执行后再把结果塞回上下文进行下一轮。这个过程是断裂的。更致命的是对于需要反复试错、长期监控、状态维护的任务比如“监控这个API如果出错就发告警并尝试重启”这种“推演-执行”割裂的模式就非常笨重甚至无法实现。我在一个自动化报表项目中深有体会。最初我用复杂提示让模型生成SQL查询但它经常因为不了解数据库最新表结构而生成错误查询。我需要手动把错误信息反馈给它它再调整。这个过程无法自动化闭环始终需要我这个人肉“继电器”。2.3 范式三的萌芽交互与执行的闭环于是第三种范式的需求就呼之欲出了让模型的“思考”和“行动”在一个自主循环中紧密耦合。模型不仅输出“要做什么”还能直接驱动动作执行并基于执行结果决定下一步。这不仅仅是给模型加了工具调用能力更是赋予它一个“运行时环境”和“持续的目标”。一个典型的第三种范式应用看起来是这样的目标每周五下午3点自动分析GitHub仓库本周的Issue活跃度并生成一份摘要报告发到Slack频道。 赋予智能体的能力 1. 访问GitHub API读取Issue、PR。 2. 执行Python代码进行数据分析。 3. 调用Slack API发送消息。 4. 一个持久化的记忆单元记录历史分析结论。智能体被激活后它会自己规划检查时间周五下午3点到了该执行任务了。行动调用GitHub API获取本周数据。观察收到数据发现某个Issue评论数暴增。再规划这可能是热点问题需要重点分析。执行数据分析代码计算趋势。再行动与观察生成报告调用Slack发送。将“本周热点是X问题”存入记忆。终止任务完成进入休眠等待下一个触发点。整个过程中没有人类在每一步说“现在去取数据”、“现在去分析”。人类只定义了一次性的目标和边界规则、可用工具剩下的交给智能体与环境GitHub、Slack、时钟的持续交互来完成。这才是范式转移的关键交互的主体从“人-模型”变成了“模型-环境”人退居为定义者和监督者。3. 第三种范式的技术基石为什么是现在Karpathy此时提出这个观点绝非偶然。第三种范式从概念到可实践依赖于近几年一系列关键技术的成熟和汇聚缺一不可。3.1 核心引擎强大且可控的基座模型范式三要求模型不仅能理解复杂指令还要能进行可靠的规划、工具选择和多轮状态跟踪。这需要模型具备强大的指令遵循能力精准理解目标约束不跑偏。稳定的规划能力能将模糊目标分解为合理的步骤序列。可靠的工具使用能力准确理解工具规格并格式化调用。良好的上下文管理能力在长程交互中不遗忘关键信息。直到GPT-4、Claude 3等模型出现这些能力才达到了一个可用的阈值。早期的模型在工具调用上经常格式错误或逻辑混乱无法承担自主运行的重任。3.2 关键赋能函数调用与结构化输出过去模型输出非结构化文本外部程序需要像“猜谜”一样用正则表达式或关键词去解析“请搜索XXX”这样的指令极其脆弱。现在主流的模型API都提供了函数调用Function Calling或结构化输出JSON Mode功能。开发者可以预先定义好工具的函数签名名称、描述、参数schema。模型在需要时会输出一个结构化的调用请求例如{ function: web_search, arguments: { query: 特斯拉 2024年第一季度 交付量 } }外部程序收到这个标准的JSON对象就可以无缝地执行对应函数并将结果以结构化格式返回给模型。这解决了“行动”接口标准化的问题是闭环自动化的技术前提。没有这个智能体就只是“纸上谈兵”。3.3 运行环境智能体框架的成熟单独一个会调用函数的模型还不是智能体。它需要一个“大脑皮层”来管理循环流程决定何时思考、何时行动、如何将历史观察纳入考虑。这就是智能体框架Agent Framework的价值。像LangChain、LlamaIndex、AutoGen以及新兴的CrewAI、LangGraph等它们提供了以下关键组件智能体Agent封装了模型和提示策略是决策核心。工具Tools将API、函数、数据库查询等封装成智能体可调用的标准接口。记忆Memory短期记忆对话历史、长期记忆向量数据库等用于维护状态。执行器Executor驱动“思考-行动-观察”循环的运行时引擎。这些框架将范式三所需的复杂编排标准化、模块化让开发者可以像搭积木一样构建智能体应用而不必从零开始处理状态机和循环逻辑。这是降低开发门槛、推动范式普及的关键。3.4 成本与速度让持续交互变得经济可行持续的交互意味着大量的API调用。如果每个“思考-行动”步骤都昂贵且缓慢这种范式就无法落地。随着模型推理优化如vLLM等推理引擎、API成本下降以及小型化模型如DeepSeek、Qwen2.5能力的提升运行一个长期智能体的经济成本和时间成本正在进入可接受范围。这使得从“演示概念”到“生产部署”成为可能。4. 实战构建设计一个范式三的智能体光说不练假把式。我们以一个具体的场景为例看看如何从零构建一个第三种范式的应用。假设我们要做一个“智能内容运营助手”它的目标是自动监控竞品动态并生成分析简报。4.1 定义目标与边界首先必须明确、无歧义地定义智能体的目标。模糊的目标会导致智能体行为失控。坏目标“帮我关注一下竞争对手。” 太模糊关注什么怎么关注好目标“每天上午10点自动爬取A、B、C三个竞品公司的官方博客和技术社区主页提取过去24小时内发布的新文章标题、链接和核心摘要。分析这些内容的主题倾向如产品发布、技术解读、市场活动并与我方上周发布内容进行对比生成一份不超过500字的每日竞品动态简报通过邮件发送给运营团队。”这个目标包含了触发条件每天10点、输入源三个特定网址、任务步骤爬取、提取、分析、对比、生成、输出格式500字简报和交付方式邮件。边界清晰是成功的第一步。4.2 工具集设计与封装根据目标我们需要为智能体配备以下工具网页爬取工具用于获取竞品页面内容。这里不能简单用requests因为现代网站多是动态加载。可以考虑用playwright或selenium无头浏览器或者更轻量的requests-html。关键是要处理好反爬和页面解析。# 示例一个简化的爬取工具封装 from playwright.sync_api import sync_playwright import asyncio class WebScraperTool: name scrape_website description 爬取指定URL的网页主要内容支持JavaScript渲染 def __init__(self): self.playwright None self.browser None async def __call__(self, url: str): 执行爬取 if not self.browser: self.playwright await sync_playwright().start() self.browser await self.playwright.chromium.launch(headlessTrue) page await self.browser.new_page() try: await page.goto(url, wait_untilnetworkidle) # 尝试获取文章主体内容这里策略很关键 content await page.inner_text(body) # 简单示例实际需更精细选择器 return {success: True, content: content[:10000]} # 限制长度 except Exception as e: return {success: False, error: str(e)} finally: await page.close()注意网页爬取涉及法律和道德边界。务必遵守网站的robots.txt协议控制请求频率仅用于获取公开信息。对于有API的站点优先使用API。文本分析与摘要工具从爬取的HTML中提取文章正文和摘要。可以用BeautifulSoup解析结合readability之类的库提取主体内容再用大模型进行摘要。from bs4 import BeautifulSoup import re class ContentExtractorTool: name extract_main_content description 从HTML文本中提取文章主标题和正文 def __call__(self, html_text: str): soup BeautifulSoup(html_text, html.parser) # 移除脚本、样式等 for script in soup([script, style]): script.decompose() # 简单启发式找最长的文本块 text soup.get_text() lines (line.strip() for line in text.splitlines()) chunks (phrase.strip() for line in lines for phrase in line.split( )) text .join(chunk for chunk in chunks if chunk) # 这里可以更复杂比如用readability-lxml title soup.title.string if soup.title else No Title return {title: title, content: text[:2000]} # 截断大模型调用工具核心用于内容分析和简报生成。这里需要封装两个功能一是分析单篇文章主题二是综合多篇文章生成简报。import openai # 或使用其他模型API class AnalysisTool: name analyze_and_summarize description 使用大模型分析内容主题并生成摘要 def __init__(self, api_key): self.client openai.OpenAI(api_keyapi_key) def analyze_single(self, title, content): prompt f请分析以下文章的主题倾向 标题{title} 内容摘要{content[:500]} 请从【产品发布】、【技术解读】、【市场活动】、【行业观点】、【其他】中选择最匹配的类别并给出简要理由。 response self.client.chat.completions.create( modelgpt-4-turbo, messages[{role: user, content: prompt}], temperature0.2 ) return response.choices[0].message.content def generate_digest(self, analyzed_items): prompt f基于以下竞品动态生成一份每日简报 {analyzed_items} 要求总结今日竞品关注焦点分析与我方内容的差异点指出可借鉴或需警惕的方向。字数500以内。 response self.client.chat.completions.create( modelgpt-4-turbo, messages[{role: user, content: prompt}], temperature0.5 ) return response.choices[0].message.content邮件发送工具将最终简报发送出去。可以使用smtplib或第三方邮件服务API如SendGrid。记忆工具需要一个地方存储“我方上周发布内容”用于对比。可以用一个简单的JSON文件或数据库记录每次智能体启动时读取。4.3 智能体流程编排有了工具就需要一个“大脑”来串联它们。我们使用LangGraph来构建一个清晰的工作流。LangGraph允许我们用有向图的方式定义智能体的执行步骤。from langgraph.graph import StateGraph, END from typing import TypedDict, List import asyncio # 定义智能体状态 class AgentState(TypedDict): target_urls: List[str] scraped_data: List[dict] # 存储每个URL爬取结果 extracted_contents: List[dict] # 存储提取后的内容 analysis_results: List[str] # 存储每篇文章分析结果 final_digest: str error: str # 初始化图 workflow StateGraph(AgentState) # 定义节点函数 def scrape_node(state: AgentState): 节点1并发爬取所有目标URL scraper WebScraperTool() tasks [scraper(url) for url in state[target_urls]] results asyncio.run(asyncio.gather(*tasks)) state[scraped_data] results return state def extract_node(state: AgentState): 节点2从爬取结果中提取正文 extractor ContentExtractorTool() contents [] for data in state[scraped_data]: if data[success]: content extractor(data[content]) contents.append(content) state[extracted_contents] contents return state def analyze_node(state: AgentState): 节点3分析每篇文章并生成综合简报 analyzer AnalysisTool(api_keyyour_key) analyses [] for item in state[extracted_contents]: analysis analyzer.analyze_single(item[title], item[content]) analyses.append(f- 标题{item[title]}\n 分析{analysis}) # 读取我方历史内容这里简化 our_last_week_content 我方上周主要发布了产品X的优化详情... full_context \n.join(analyses) f\n\n我方上周内容{our_last_week_content} digest analyzer.generate_digest(full_context) state[analysis_results] analyses state[final_digest] digest return state def send_node(state: AgentState): 节点4发送邮件 mailer EmailTool() success mailer.send( subject每日竞品动态简报, bodystate[final_digest], recipients[teamcompany.com] ) if not success: state[error] 邮件发送失败 return state def decide_next_node(state: AgentState): 路由逻辑根据是否有错误决定下一步 if state.get(error): return handle_error # 可以定义一个错误处理节点 else: return END # 添加节点到图 workflow.add_node(scrape, scrape_node) workflow.add_node(extract, extract_node) workflow.add_node(analyze, analyze_node) workflow.add_node(send, send_node) # 设置边执行顺序 workflow.add_edge(scrape, extract) workflow.add_edge(extract, analyze) workflow.add_edge(analyze, send) workflow.add_edge(send, END) # 发送后结束 # 设置入口 workflow.set_entry_point(scrape) # 编译图 app workflow.compile()这个图定义了一个线性的、确定性的工作流。在更复杂的场景中你可以加入条件分支比如如果爬取失败则重试如果分析结果为空则跳过发送等。4.4 调度与触发最后我们需要让这个智能体按计划每天上午10点自动运行。这可以通过成熟的调度系统实现例如Linux Crontab最简单在服务器上设置定时任务。Celery Beat如果应用本身使用Celery作为任务队列。Apache Airflow / Prefect如果需要更复杂的工作流依赖、监控和重试机制。云函数定时触发器如果部署在云上如AWS Lambda、Google Cloud Functions可以使用其内置的定时触发器。一个简单的Crontab配置如下0 10 * * * /usr/bin/python3 /path/to/your/agent_runner.py /var/log/agent.log 21在agent_runner.py中你只需要初始化状态并运行编译好的图initial_state {target_urls: [https://竞品A博客, https://竞品B社区]} final_state app.invoke(initial_state) if final_state.get(error): # 发送告警 send_alert(final_state[error])至此一个完整的、符合“第三种范式”的智能体应用就构建完成了。它每天自动唤醒执行“感知爬取-理解分析-决策生成简报-行动发送”的完整闭环无需人工干预。5. 范式跃迁中的核心挑战与应对策略转向第三种范式听起来很美好但实际落地时坑非常多。下面是我从几个失败和成功的项目中总结出的核心挑战和应对策略。5.1 挑战一智能体的不可预测性与“幻觉”这是最大的风险。模型在自主运行时可能会做出匪夷所思的决策。例如在爬取任务中它可能突然决定去访问一个不在列表内的、甚至是不安全的URL。或者在分析时脱离事实进行过度臆测。应对策略设定严格的行动边界与验证层工具层面白名单在工具函数内部进行强制校验。比如爬取工具在收到URL参数时首先检查域名是否在预先批准的allow_list中否则直接拒绝执行并返回错误。系统提示词约束在给智能体的系统指令中明确写出不可为的事项。例如“你只能使用提供的工具。严禁尝试访问任何未明确列出的网址或资源。严禁执行任何文件写入或系统命令除非该工具明确允许。”输出格式强制结构化利用模型的JSON输出模式要求其所有行动请求都必须符合预定义的Schema。这能极大减少模型“胡言乱语”导致解析失败的情况。关键步骤人工审核渐进式自动化在初期对于最终动作如发送邮件、发布内容可以设置为“草稿模式”或“需人工确认模式”。智能体生成内容后先存入数据库或发送到审批频道由人点击确认后再执行。随着智能体可靠性提升再逐步放开全自动。5.2 挑战二长程任务中的状态管理与遗忘智能体在运行一个长流程时如何记住之前步骤的细节比如在分析多篇文章时如何保持对整体方向的把握简单的将全部历史对话扔进上下文会很快耗尽令牌限制并增加成本。应对策略设计分层记忆系统短期工作记忆保存在上下文窗口内的最近几次“思考-行动-观察”循环。这用于维持当前任务的连贯性。长期摘要记忆对于已经完成且重要的子任务结果调用模型自身生成一个精炼的摘要存储到向量数据库如ChromaDB、Pinecone或传统数据库中。当后续步骤需要参考时可以通过语义检索Recall快速找到相关记忆而非塞入全部历史。核心元数据记忆将关键信息如“已爬取的URL列表”、“已分析的文章ID”以结构化的方式如字典、列表保存在程序变量或轻量数据库中。这是最可靠、成本最低的记忆方式。 一个良好的记忆设计能让智能体像人类一样既有对当前焦点的清晰认知又能随时调用过去的经验。5.3 挑战三错误处理与鲁棒性网络会波动API会限速网站会改版。一个生产级智能体必须能优雅地处理失败而不是直接崩溃。应对策略实现具备重试与降级能力的执行流工具调用重试为每个工具调用包装重试逻辑如tenacity库针对网络超时、速率限制等临时性错误。降级方案当主要工具失败时有备用方案。例如主爬取工具Playwright失败后自动降级到更简单的requestsBeautifulSoup组合虽然可能无法获取JS渲染内容但至少能拿到基础HTML。超时与看门狗为整个智能体任务或单个节点设置超时。如果某个步骤卡住比如模型思考时间过长看门狗机制能中断当前流程记录错误并尝试跳过或进入清理状态。完善的日志与监控每个步骤的输入、输出、错误都必须详细日志记录。同时对接监控系统如Prometheus对任务成功率、耗时、工具调用次数等关键指标进行监控和告警。5.4 挑战四评估与持续改进如何知道你的智能体做得好不好不能只靠感觉。应对策略建立量化的评估体系过程指标任务完成率、平均步骤数、工具调用成功率、单次任务耗时、令牌消耗量。结果指标根据任务目标定义。对于简报生成任务可以定义内容完整性预设的关键信息点如竞品名称、文章主题、发布时间的覆盖比例。分析准确性人工抽样检查判断其分析类别产品发布/技术解读等是否准确。简报可用性让运营团队对简报质量进行评分1-5分。A/B测试当你优化了提示词或工作流后可以并行运行新旧两个版本的智能体一段时间对比上述指标用数据驱动决策。6. 范式三的边界与未来它真的能替代一切吗尽管第三种范式带来了强大的自动化能力但我们必须清醒地认识到它的边界。目前它并非万能更适合以下场景目标明确、流程可拆解任务可以清晰地分解为一系列子步骤。环境可数字化、工具可封装智能体需要交互的对象网站、API、数据库能以程序化方式访问。容错率相对较高或有人工复核环节完全无人值守、零错误要求的场景风险极高。而对于以下场景传统范式或混合模式可能更优高度创意或探索性任务比如“帮我想一个全新的产品创意”这需要人类与模型进行开放、发散、反复的对话碰撞不适合固定流程的智能体。实时性要求极高的简单查询问一句“现在几点”用单次提示比启动一个智能体循环快得多。涉及复杂伦理、安全或法律判断的任务最终决策权必须牢牢掌握在人类手中。所以未来的常态不会是“范式三一统天下”而会是混合范式架构。一个复杂的应用可能由多个智能体范式三协作完成核心流程同时保留直接的人机对话接口范式一、二用于监控、干预和特殊查询。智能体负责“执行”人类负责“监督”和“战略”。从我个人的实践来看Karpathy提出的“第三种范式”确实标志着一个重要的拐点。它不再是实验室里的概念而是有了坚实的技术底座和丰富的框架支持正在快速渗透到自动化运维、智能数据分析、个性化营销、客户服务等众多领域。它的出现不是要取代程序员或分析师而是将我们从重复、机械、流程化的劳动中解放出来让我们能更专注于定义问题、设计架构和处置异常——那些真正需要人类创造力和判断力的部分。开始拥抱这种范式最好的方式就是选一个你日常工作中那些枯燥、重复但又有点复杂的小任务尝试用智能体的思路去自动化它。你会立刻感受到那种“设定好就不用管”的魔力当然也会立刻遇到前面提到的各种坑。但正是这个过程能让你真正理解这次范式转移到底意味着什么。