如果你最近在折腾大模型应用大概率遇到过这样的场景单轮问答模型表现惊艳但一旦把任务拉长到“查资料、算数据、对比方案、写结论”这种多步骤流程模型就开始丢三落四。前面的推理结果到后面被遗忘工具调用的中间过程没有沉淀整个 Agent 跑起来像没有短期记忆的人。很多人把这个问题归结为“模型不够聪明”但更底层的判断是当前的主流交互范式还是“一次问答得到一个答案”而不是“一个持续推理的过程”。Perplexity CEO 最近关于“持续推理”和智能体未来的表态恰好点中了这个行业痛点。它不只是一个搜索公司对产品的展望而是对整个 Agent 运行范式的一个判断未来的智能体不是“你问我答”的聊天机器人而是一个能带着上下文、工具和状态持续运行的推理系统。本文会从概念、信号、平台选型、代码实现到工程化建议把“持续推理智能体”这件事拆开讲清楚并给出一个可以直接运行的最小示例。1. 这篇文章真正要解决的问题先想一个问题为什么现在很多 Agent 框架看起来很强大demo 视频里跑得行云流水真正接到业务里却频繁“断片”原因不是模型参数量不够也不是 Agent 框架缺功能而是推理过程被切碎了。传统思路里用户提问、模型作答、可能调用一次工具整个流程就结束了。消息之间的关联靠把历史对话塞进 prompt但模型既不知道当前任务处在哪个阶段也不知道哪些中间结论已经被验证过。结果就是一个下单流程模型可能在第三步重新“理解”用户想干什么导致工具调用逻辑前后不一致。持续推理要解决的就是这个问题。它把“推理”从一次性的动作变成了一个持续运行的状态机模型在执行任务的过程中不断根据新信息修正目标、更新记忆、选择下一个动作直到任务被验证完成。这个转变不是修辞层面的而是架构层面的。这篇文章适合以下几类读者正在用 Dify、Coze、LangChain 等平台搭建智能体但发现复杂任务容易中断的开发者。想从“调用 API 做问答”进阶到“搭建带工具调用和状态管理的 Agent”的工程师。关注行业趋势想理解“持续推理”为什么会成为下一阶段关键词的产品和技术负责人。读完这篇文章你会得到四个可以带走的东西对持续推理这个概念的技术化理解一个判断智能体架构好坏的参考框架一份主流平台选型对比以及一个用 Python 实现的、带记忆和工具调用的持续推理 Agent 最小代码。2. 持续推理与智能体的核心概念2.1 持续推理不是“更长的思考链”很多文章把持续推理和大模型的“思维链”Chain of Thought混在一起这是最常见的误解。思维链解决的是“单次回答里让模型把推理过程显式写出来”它仍然是一次性生成只是输出内容更结构化。而持续推理解决的是“一个任务可能需要多轮推理、多次工具调用、多阶段验证”的问题它强调的是跨时间的状态保持而不是单轮内的逻辑展开。可以这样类比思维链像一个学生考试时在草稿纸上写清楚每一步计算持续推理像一个项目负责人他不仅要做决策还要管理项目进度表、记住每个成员的反馈、根据新情况调整计划。前者是单次解题后者是持续运营。2.2 Agent 从“问答处理器”变成“任务执行器”传统 LLM 应用的核心接口是“输入问题输出回答”。Agent 智能体的核心接口变成了“输入目标输出结果”中间允许任意多轮推理和工具调用。在这个转变里Agent 至少需要四个能力任务拆解把用户给的目标拆成可执行的子步骤。状态管理记住当前执行到哪一步、已经获取了哪些信息。工具调用根据推理结果调用搜索、数据库、API、计算器等外部能力。自我验证判断结果是否满足任务要求不满足就继续修正。持续推理本质上是把“单次模型生成”放进了“任务循环”里。模型每次只生成当前这一步的决策系统负责保存上下文、执行工具、把结果反馈给模型然后进入下一轮。模型不是一次性输出完整答案而是在循环中逐步逼近最终结果。2.3 新的上下文机制传统对话的上下文是“消息列表”每次请求把所有历史消息都发给模型。持续推理场景下上下文的结构需要更丰富任务目标上下文用户最初想解决什么问题不能被中间过程带偏。状态上下文当前已完成哪些步骤、下一步候选动作是什么。工具结果上下文每次工具调用的返回结果哪些是可靠的、哪些需要重新验证。约束上下文成本上限、时间限制、安全边界。对比一下传统模式和持续推理模式的区别维度传统问答模式持续推理模式核心交互一次提问一次回答多轮循环逼近一个目标上下文历史消息列表目标 状态 工具结果 约束工具调用偶尔、单次频繁、按需编排失败处理直接返回错误根据反馈修正后重试对模型的依赖全部靠模型理解靠“循环 工具 上下文”兜底从这张表能看出持续推理的真正价值在于模型不再需要在一个 prompt 里“记住”所有东西而是通过系统结构来分担记忆和验证的压力。这正是它更适合复杂业务场景的原因。3. Perplexity 展望背后的三个技术判断Perplexity 这家公司的产品核心是搜索与答案引擎它比一般聊天机器人更早面对一个问题答案不是一次性生成的而是需要检索、筛选、推理再检索、再推理最后才能得到一个可靠结论。因此它的 CEO 强调持续推理和智能体方向在逻辑上是连贯的。这部分我不打算逐句复述某次演讲的内容而是从公开信息和行业讨论中提炼三个更值得开发者关注的判断。3.1 搜索与推理将融合为同一个循环过去的使用模式是用户在搜索框里输入问题得到一组链接然后自己阅读、判断、得出结论。后来大模型做搜索增强变成“模型读一遍链接直接给你答案”但这个过程仍然是单轮的一次检索一次生成。持续推理的思路是搜索不再是“找到一个答案”的动作而是“验证一个结论”的手段。Agent 先基于已有知识生成一个假设然后用搜索去验证如果结果和假设冲突就修正假设再搜索。搜索、推理、验证形成一个循环而不是线性的一条线。这意味着搜索 API 不再是给“问答机器人”用的而是给“智能体验证系统”用的。如果你正在开发 Agent早一点把搜索设计成“可反复调用的验证工具”而不是“一次性的信息获取入口”会更容易跟上这个方向。3.2 上下文管理会成为 Agent 的核心工程问题当推理变成持续过程prompt 就不再是写一次就完了。每一次循环系统都要动态决定哪些历史信息要保留哪些中间结果可以被压缩哪些工具输出太长需要截断哪些信息已经过时需要重新获取。从工程角度看Agent 的开发重心会从“如何写出好的 prompt”逐渐转向“如何设计好的上下文生命周期”。哪个 Agent 能把上下文管理得更精准、更省 token、更不容易丢失关键信息哪个 Agent 在真实业务里就更稳定。这个判断对所有 Agent 开发者都适用不管你是用现成平台还是自研框架。3.3 智能体的竞争焦点会从“能用”变成“可控”持续推理让 Agent 越来越像一个自主运行的子系统于是“可控”会成为比“聪明”更重要的指标。关键在两点。第一执行过程可观测每一步为什么做出这个决策、调用了哪个工具、结果是什么都要有日志记录。第二行为边界可约束一个持续推理的 Agent 可能循环很多轮如果每一轮都有工具调用权限累积风险会非常高。所以未来的 Agent 系统一定需要更细粒度的权限控制、工具白名单、预算限制和人工介入机制。这里也回应了很多开发者对“持续推理会不会失控”的担忧。答案不是取消自主性而是用工程手段给 Agent 加上刹车和仪表盘。4. 开发者现在能做什么平台选型与实现路径持续推理是一个方向但真正的问题是现在能落地到自己的项目里吗答案是能。有三条路径适合不同背景的开发者。4.1 路径一用 Agent 平台快速验证如果你还没有很强的工程团队或者只是想快速验证业务效果使用 Dify、Coze 这类智能体平台是更高效的选择。这些平台已经内置了工作流编排、工具接入、记忆管理和日志查看能力你不需要从零写循环。在这个路径里要注意几个关键点工作流节点需要设计“状态记录节点”把每一步的关键输出写进变量供后续节点引用。工具调用节点要配置清晰输入输出参数避免模型自由发挥。多智能体协作场景要关注节点之间的数据传递而不是每个子 Agent 都对用户可见。从热词来看目前社区里大量讨论集中在“智能体搭建实战”“工作流搭建”“低代码模式开发”这说明平台化搭建已经成为很大一部分开发者的首选路径。它的优点是快速缺点是遇到复杂状态管理时可视化编排可能不如代码灵活。4.2 路径二基于 LangChain / LangGraph 自研如果你的业务场景比较复杂例如需要自定义状态机、动态工具编排、或者深度整合内部系统建议基于 LangChain 或 LangGraph 这类框架自研。LangGraph 尤其适合持续推理场景因为它把 Agent 建模成图结构节点是推理或工具执行边是状态转移。这种模型和“多轮推理循环”天然契合。使用框架的好处是社区生态丰富坏处是学习曲线陡峭而且框架版本迭代快依赖管理要特别小心。4.3 路径三自己实现一个最小循环如果你只是想深入理解持续推理的原理或者你的 team 不想引入重量级框架完全可以自己实现一个最小循环。核心逻辑不复杂把模型输出解析成一个结构化动作。根据动作调用对应工具。把工具返回结果拼接到对话上下文。循环直到模型输出“完成”信号或达到轮次上限。下一章会给出完整代码。这个方案适合学习但生产环境需要补很多细节比如记忆压缩、并发控制、错误重试、审计日志等。下面是三条路径的对比路径适合场景门槛灵活度落地速度Dify / Coze 平台业务验证、低代码搭建低中快LangChain / LangGraph复杂自定义 Agent高高中自研最小循环学习原理、轻量场景中极高慢5. 持续推理 Agent 最小示例代码实现为了让“持续推理”不只是一个概念我们实现一个最小但仍然完整的 Agent 循环。这个示例完全基于 OpenAI 兼容接口只需要一个 API Key 就能运行。它解决的问题是用户输入一个任务Agent 自主决定调用哪个工具、不断修正最终输出完成结果。5.1 环境准备建议使用 Python 3.9 以上版本。安装依赖pip install requests python-dotenv在项目根目录创建.env文件LLM_API_KEY你的_API_Key LLM_API_URLhttps://api.openai.com/v1/chat/completions LLM_MODELgpt-4o-mini如果你使用的是兼容 OpenAI 协议的其他服务只需要修改LLM_API_URL和LLM_MODEL两个环境变量。5.2 完整代码文件路径agent_demo.pyimport os import json import requests from dotenv import load_dotenv load_dotenv() API_KEY os.getenv(LLM_API_KEY, ) API_URL os.getenv(LLM_API_URL, https://api.openai.com/v1/chat/completions) MODEL os.getenv(LLM_MODEL, gpt-4o-mini) MAX_ROUNDS 6 SYSTEM_PROMPT 你是一个持续推理智能体。 你可以多次调用工具来获取信息然后再决定下一步动作。 每次输出必须是一个 JSON 对象格式如下 1. 如果需要调用工具 {tool: calculator, args: {expression: 10 5}} 2. 如果任务已完成 {tool: finish, args: {result: 最终结果}} 可用工具 - calculator计算数学表达式args 中的 expression 必须是空格分隔的三元表达式如 10 5 - get_order_status查询订单状态args 中的 order_id 是订单号 注意你每次只能输出一个 JSON 对象不要输出多余文字。 def call_llm(messages): 调用 OpenAI 兼容接口返回模型回复文本。 payload { model: MODEL, messages: messages, temperature: 0.2, } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } resp requests.post(API_URL, headersheaders, jsonpayload, timeout30) resp.raise_for_status() return resp.json()[choices][0][message][content] def safe_calculate(expression): 只支持 数字 运算符 数字 的安全计算避免直接 eval。 parts expression.split() if len(parts) ! 3: return 表达式格式错误请输入如 10 5 的格式 a, op, b parts try: a float(a) b float(b) except ValueError: return 操作数必须是数字 ops { : lambda x, y: x y, -: lambda x, y: x - y, *: lambda x, y: x * y, /: lambda x, y: x / y if y ! 0 else 除数不能为 0, } if op not in ops: return f不支持的操作符: {op} return ops[op](a, b) def get_order_status(order_id): 模拟订单查询工具。 mock_data { A1001: 已发货, A1002: 待支付, A1003: 已完成, } return mock_data.get(order_id, 订单不存在) TOOL_REGISTRY { calculator: lambda args: safe_calculate(args.get(expression, )), get_order_status: lambda args: get_order_status(args.get(order_id, )), } def parse_action(text): 从模型输出中解析 JSON 动作。 start text.find({) end text.rfind(}) if start -1 or end -1: return None try: return json.loads(text[start:end 1]) except json.JSONDecodeError: return None def run_agent(user_task): messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_task}, ] for round_idx in range(1, MAX_ROUNDS 1): print(f\n[第 {round_idx} 轮] 模型推理中...) try: content call_llm(messages) except Exception as e: return f调用模型失败: {e} print(f[模型输出] {content}) action parse_action(content) if action is None: messages.append({role: assistant, content: content}) messages.append({role: user, content: 输出不是合法 JSON请重新按格式输出}) continue tool_name action.get(tool) args action.get(args, {}) messages.append({role: assistant, content: content}) if tool_name finish: return args.get(result, 任务完成) if tool_name not in TOOL_REGISTRY: messages.append({role: user, content: f未知工具 {tool_name}请从可用工具中选择}) continue print(f[调用工具] {tool_name} 参数: {args}) tool_result TOOL_REGISTRY[tool_name](args) print(f[工具返回] {tool_result}) messages.append({ role: user, content: f工具返回结果: {json.dumps(tool_result, ensure_asciiFalse)}。请继续推理。, }) return 达到最大轮次任务未能完成。 if __name__ __main__: task 请先计算 (12 500) * 3 的结果然后查询订单 A1002 的状态最后把结果整理成一句话。 result run_agent(task) print(\n) print(最终结果:, result)5.3 代码逻辑说明这个示例的核心并不复杂但每一步都是持续推理的关键组成。call_llm函数是模型的统一入口只要 API 兼容 OpenAI 协议就能替换。parse_action强制模型输出结构化 JSON优点是正则和工具调用逻辑都不依赖特定模型能力市面上的主流模型都能跑通。TOOL_REGISTRY是工具注册表新增工具只需要注册一个函数生产环境建议改成独立的工具服务或插件式加载。循环的关键在messages列表的变化。每一轮系统把工具返回结果追加到消息里并明确要求模型继续推理。这样模型始终能看到“自己上一轮做了什么、工具返回了什么、下一步该做什么”这正是持续推理和普通问答的核心区别模型不是被动接收用户指令而是在系统构造的循环里主动推进任务。需要说明的是这个示例刻意把工具调用设计成“模型输出 JSON → 系统解析 → 系统执行”的流程而不是使用 function calling 协议。原因有两个一是兼容性更好不依赖特定模型是否支持 function calling二是让读者更容易理解“推理”和“执行”是如何分离的。6. 运行结果与效果验证运行这个 Agentpython agent_demo.py一个通顺的预期输出大致如下[第 1 轮] 模型推理中... [模型输出] {tool: calculator, args: {expression: 12 500}} [调用工具] calculator 参数: {expression: 12 500} [工具返回] 512.0 [第 2 轮] 模型推理中... [模型输出] {tool: calculator, args: {expression: 512.0 * 3}} [调用工具] calculator 参数: {expression: 512.0 * 3} [工具返回] 1536.0 [第 3 轮] 模型推理中... [模型输出] {tool: get_order_status, args: {order_id: A1002}} [调用工具] get_order_status 参数: {order_id: A1002} [工具返回] 待支付 [第 4 轮] 模型推理中... [模型输出] {tool: finish, args: {result: 订单 A1002 当前状态为待支付。计算得到结果是 1536.0即 (12500)*31536。}} 最终结果: 订单 A1002 当前状态为待支付。计算得到结果是 1536.0即 (12500)*31536。怎么判断它真正符合“持续推理”关键看两点。第一计算步骤被拆成了多轮而不是希望模型一次性算完。第二每一步模型都能看到前一步的工具返回结果再决定下一步动作。如果模型在某一轮输出乱码或者找不到工具系统会通过追加错误信息让它自我修正而不是直接崩溃。如果运行失败按以下顺序排查请求超时或返回 401检查.env里的 API Key 是否正确LLM_API_URL是否可达。输出“调用模型失败”检查模型名称是否有效网络是否能访问 API 地址。模型一直不输出 JSON把temperature调到 0或者手动在 system prompt 里加一句“只输出 JSON不要输出任何解释”。7. 常见问题与排查思路持续推理 Agent 的常见问题很多不是模型不够聪明而是系统设计上有疏漏。下面五类问题出现频率最高。问题现象可能原因排查方式解决方案多轮循环后上下文越来越长token 消耗激增历史消息全部保留没有压缩或裁剪输出每轮消息长度统计工具返回大小对工具返回做截断只保留关键字段定期压缩旧的中间结果模型在多个工具之间反复调用不结束任务缺少终止判断逻辑系统的“完成”信号不够强查看日志里的工具调用序列增加最大轮次限制在 prompt 中强调“只有拿到最终答案才调用 finish”工具参数经常传错模型对工具入参格式理解不充分打印模型输出的 JSON 和实际调用参数在工具描述里给出参数示例解析层做参数校验和默认值兜底工具返回结果格式不稳定模型解析失败工具返回了非结构化文本或异常数据捕获工具返回检查是否包含不可见字符所有工具统一返回 JSON 字符串失败时返回结构化错误信息Agent 在生产环境误调用了危险操作工具权限粒度过粗Agent 可以自由调用写操作审计操作日志确认调用链将写操作和读操作分离引入人工审批节点和工具调用白名单这里额外提醒一个安全边界问题。持续推理意味着工具调用次数会显著增加如果不做权限控制Agent 可能在一次任务中调用了很多次本不应该触达的敏感接口。生产环境的建议是默认不授予 Agent 执行写操作的能力所有写操作走单独审批流程涉及数据库操作的 Agent必须使用只读账号并对敏感字段脱敏。8. 持续推理智能体的工程最佳实践从最小示例走向生产环境中间还需要补上很多工程细节。以下五个实践方向是当前 Agent 自动化程度下最容易踩坑也最值得投资的地方。8.1 上下文生命周期管理持续推理是一把双刃剑推理越多上下文越长token 成本越高模型也越容易在长上下文中迷失。建议为 Agent 设计一套上下文管理策略核心目标始终保持任务最初的目标描述放进一个单独变量不随中间轮次被覆盖。工具返回做摘要长文本工具返回优先抽摘要而不是全文送进模型。旧轮次压缩超过一定轮次后把早期推理过程压缩成一句话摘要保留关键结论丢弃冗余信息。预算预警每轮记录 token 消耗超过阈值时自动停止循环转人工处理。8.2 工具设计要面向可观测性工具注册表里的每个工具都应该输出结构化、可被审计的结果。推荐统一返回这样的 JSON 结构{ status: success, data: {}, cost_ms: 120, source: tool_name }这样 Agent 的日志系统可以清楚记录每一次工具调用的来源、耗时和结果也方便复现问题。不要把工具返回设计成自然语言段落模型解析自然语言的开销远大于解析 JSON。8.3 多智能体协作时的状态隔离当系统升级到多智能体协作比如一个 Planner Agent 负责拆任务一个 Executor Agent 负责执行一个 Reviewer Agent 负责验证结果时状态管理会更复杂。核心原则是状态要以“任务 ID”为粒度隔离不能跨任务混用。用一组简单的配置来描述协作结构# 多智能体编排示意结构 pipeline: - name: planner role: 任务拆解 output_vars: - sub_tasks - name: executor role: 工具执行 input_vars: - sub_tasks output_vars: - exec_result - name: reviewer role: 结果验证 input_vars: - exec_result output_vars: - review_passed - name: finisher role: 汇总输出 input_vars: - exec_result - review_passed这里的要点是每个 Agent 只读取自己需要的变量只写入自己负责的变量。如果放任所有 Agent 共享一个全局状态随着协作规模增大状态冲突几乎不可避免。8.4 错误重试与降级持续推理会出现单轮失败但整个任务不一定需要终止。推荐设计分级重试策略第一次失败把错误信息以“用户消息”的形式回传给模型让模型自行修正。连续失败两次检查是否进入了循环陷阱尝试切换更低的 temperature 或换一个模型。达到最大轮次终止执行输出已完成的中间结果和失败原因而不是直接抛出异常。8.5 人工介入机制不管 Agent 多么自主生产环境都要留人工介入的入口。推荐做法是Agent 在遇到不确定操作、写操作、高成本操作时不是硬着头皮执行而是生成一个“待确认请求”由人工审批后继续。在 Dify、Coze 这类平台里这个机制通常对应“审批节点”或“暂停 → 继续”的能力在自研系统里则在循环中加入一个特殊动作Agent 输出“需要审批”信号系统挂起任务等待人工回调。9. 总结与下一步学习方向回到开头那个问题现在的 Agent 为什么一到复杂任务就崩很大程度不是模型不够强而是我们还在用“问答范式”设计“任务执行系统”。Perplexity CEO 关于持续推理智能体的展望真正值得关注的地方不是某一家公司的判断而是它指出的方向智能体必须从“一次性生成答案”进化为“在循环中持续推理、调用工具、自我修正”的系统。这篇文章从概念、行业信号、平台选型、最小代码实现到工程最佳实践给出了一个相对完整的路线图。如果你今天只能做一件事建议先运行一遍第 5 章的示例把“模型输出 JSON → 系统调用工具 → 结果回填 → 继续推理”这个循环在本地跑通。这是理解持续推理最直观的方式也是后续所有复杂 Agent 架构的基础。下一步可以沿着三个方向继续深入第一把示例里的工具换成真实业务 API比如订单查询、库存查询、知识库检索第二给 Agent 增加长短期记忆比如用向量数据库保存历史任务结论第三尝试多智能体协作让不同 Agent 分别负责规划、执行和验证。如果对平台化搭建更感兴趣可以基于 Dify 或 Coze 把同样的循环建模成可视化工作流对比一下平台方案和自研方案的差异这会对你在不同场景下的技术选型很有帮助。 持续推理智能体：从多轮循环到Agent工作流落地
如果你最近在折腾大模型应用大概率遇到过这样的场景单轮问答模型表现惊艳但一旦把任务拉长到“查资料、算数据、对比方案、写结论”这种多步骤流程模型就开始丢三落四。前面的推理结果到后面被遗忘工具调用的中间过程没有沉淀整个 Agent 跑起来像没有短期记忆的人。很多人把这个问题归结为“模型不够聪明”但更底层的判断是当前的主流交互范式还是“一次问答得到一个答案”而不是“一个持续推理的过程”。Perplexity CEO 最近关于“持续推理”和智能体未来的表态恰好点中了这个行业痛点。它不只是一个搜索公司对产品的展望而是对整个 Agent 运行范式的一个判断未来的智能体不是“你问我答”的聊天机器人而是一个能带着上下文、工具和状态持续运行的推理系统。本文会从概念、信号、平台选型、代码实现到工程化建议把“持续推理智能体”这件事拆开讲清楚并给出一个可以直接运行的最小示例。1. 这篇文章真正要解决的问题先想一个问题为什么现在很多 Agent 框架看起来很强大demo 视频里跑得行云流水真正接到业务里却频繁“断片”原因不是模型参数量不够也不是 Agent 框架缺功能而是推理过程被切碎了。传统思路里用户提问、模型作答、可能调用一次工具整个流程就结束了。消息之间的关联靠把历史对话塞进 prompt但模型既不知道当前任务处在哪个阶段也不知道哪些中间结论已经被验证过。结果就是一个下单流程模型可能在第三步重新“理解”用户想干什么导致工具调用逻辑前后不一致。持续推理要解决的就是这个问题。它把“推理”从一次性的动作变成了一个持续运行的状态机模型在执行任务的过程中不断根据新信息修正目标、更新记忆、选择下一个动作直到任务被验证完成。这个转变不是修辞层面的而是架构层面的。这篇文章适合以下几类读者正在用 Dify、Coze、LangChain 等平台搭建智能体但发现复杂任务容易中断的开发者。想从“调用 API 做问答”进阶到“搭建带工具调用和状态管理的 Agent”的工程师。关注行业趋势想理解“持续推理”为什么会成为下一阶段关键词的产品和技术负责人。读完这篇文章你会得到四个可以带走的东西对持续推理这个概念的技术化理解一个判断智能体架构好坏的参考框架一份主流平台选型对比以及一个用 Python 实现的、带记忆和工具调用的持续推理 Agent 最小代码。2. 持续推理与智能体的核心概念2.1 持续推理不是“更长的思考链”很多文章把持续推理和大模型的“思维链”Chain of Thought混在一起这是最常见的误解。思维链解决的是“单次回答里让模型把推理过程显式写出来”它仍然是一次性生成只是输出内容更结构化。而持续推理解决的是“一个任务可能需要多轮推理、多次工具调用、多阶段验证”的问题它强调的是跨时间的状态保持而不是单轮内的逻辑展开。可以这样类比思维链像一个学生考试时在草稿纸上写清楚每一步计算持续推理像一个项目负责人他不仅要做决策还要管理项目进度表、记住每个成员的反馈、根据新情况调整计划。前者是单次解题后者是持续运营。2.2 Agent 从“问答处理器”变成“任务执行器”传统 LLM 应用的核心接口是“输入问题输出回答”。Agent 智能体的核心接口变成了“输入目标输出结果”中间允许任意多轮推理和工具调用。在这个转变里Agent 至少需要四个能力任务拆解把用户给的目标拆成可执行的子步骤。状态管理记住当前执行到哪一步、已经获取了哪些信息。工具调用根据推理结果调用搜索、数据库、API、计算器等外部能力。自我验证判断结果是否满足任务要求不满足就继续修正。持续推理本质上是把“单次模型生成”放进了“任务循环”里。模型每次只生成当前这一步的决策系统负责保存上下文、执行工具、把结果反馈给模型然后进入下一轮。模型不是一次性输出完整答案而是在循环中逐步逼近最终结果。2.3 新的上下文机制传统对话的上下文是“消息列表”每次请求把所有历史消息都发给模型。持续推理场景下上下文的结构需要更丰富任务目标上下文用户最初想解决什么问题不能被中间过程带偏。状态上下文当前已完成哪些步骤、下一步候选动作是什么。工具结果上下文每次工具调用的返回结果哪些是可靠的、哪些需要重新验证。约束上下文成本上限、时间限制、安全边界。对比一下传统模式和持续推理模式的区别维度传统问答模式持续推理模式核心交互一次提问一次回答多轮循环逼近一个目标上下文历史消息列表目标 状态 工具结果 约束工具调用偶尔、单次频繁、按需编排失败处理直接返回错误根据反馈修正后重试对模型的依赖全部靠模型理解靠“循环 工具 上下文”兜底从这张表能看出持续推理的真正价值在于模型不再需要在一个 prompt 里“记住”所有东西而是通过系统结构来分担记忆和验证的压力。这正是它更适合复杂业务场景的原因。3. Perplexity 展望背后的三个技术判断Perplexity 这家公司的产品核心是搜索与答案引擎它比一般聊天机器人更早面对一个问题答案不是一次性生成的而是需要检索、筛选、推理再检索、再推理最后才能得到一个可靠结论。因此它的 CEO 强调持续推理和智能体方向在逻辑上是连贯的。这部分我不打算逐句复述某次演讲的内容而是从公开信息和行业讨论中提炼三个更值得开发者关注的判断。3.1 搜索与推理将融合为同一个循环过去的使用模式是用户在搜索框里输入问题得到一组链接然后自己阅读、判断、得出结论。后来大模型做搜索增强变成“模型读一遍链接直接给你答案”但这个过程仍然是单轮的一次检索一次生成。持续推理的思路是搜索不再是“找到一个答案”的动作而是“验证一个结论”的手段。Agent 先基于已有知识生成一个假设然后用搜索去验证如果结果和假设冲突就修正假设再搜索。搜索、推理、验证形成一个循环而不是线性的一条线。这意味着搜索 API 不再是给“问答机器人”用的而是给“智能体验证系统”用的。如果你正在开发 Agent早一点把搜索设计成“可反复调用的验证工具”而不是“一次性的信息获取入口”会更容易跟上这个方向。3.2 上下文管理会成为 Agent 的核心工程问题当推理变成持续过程prompt 就不再是写一次就完了。每一次循环系统都要动态决定哪些历史信息要保留哪些中间结果可以被压缩哪些工具输出太长需要截断哪些信息已经过时需要重新获取。从工程角度看Agent 的开发重心会从“如何写出好的 prompt”逐渐转向“如何设计好的上下文生命周期”。哪个 Agent 能把上下文管理得更精准、更省 token、更不容易丢失关键信息哪个 Agent 在真实业务里就更稳定。这个判断对所有 Agent 开发者都适用不管你是用现成平台还是自研框架。3.3 智能体的竞争焦点会从“能用”变成“可控”持续推理让 Agent 越来越像一个自主运行的子系统于是“可控”会成为比“聪明”更重要的指标。关键在两点。第一执行过程可观测每一步为什么做出这个决策、调用了哪个工具、结果是什么都要有日志记录。第二行为边界可约束一个持续推理的 Agent 可能循环很多轮如果每一轮都有工具调用权限累积风险会非常高。所以未来的 Agent 系统一定需要更细粒度的权限控制、工具白名单、预算限制和人工介入机制。这里也回应了很多开发者对“持续推理会不会失控”的担忧。答案不是取消自主性而是用工程手段给 Agent 加上刹车和仪表盘。4. 开发者现在能做什么平台选型与实现路径持续推理是一个方向但真正的问题是现在能落地到自己的项目里吗答案是能。有三条路径适合不同背景的开发者。4.1 路径一用 Agent 平台快速验证如果你还没有很强的工程团队或者只是想快速验证业务效果使用 Dify、Coze 这类智能体平台是更高效的选择。这些平台已经内置了工作流编排、工具接入、记忆管理和日志查看能力你不需要从零写循环。在这个路径里要注意几个关键点工作流节点需要设计“状态记录节点”把每一步的关键输出写进变量供后续节点引用。工具调用节点要配置清晰输入输出参数避免模型自由发挥。多智能体协作场景要关注节点之间的数据传递而不是每个子 Agent 都对用户可见。从热词来看目前社区里大量讨论集中在“智能体搭建实战”“工作流搭建”“低代码模式开发”这说明平台化搭建已经成为很大一部分开发者的首选路径。它的优点是快速缺点是遇到复杂状态管理时可视化编排可能不如代码灵活。4.2 路径二基于 LangChain / LangGraph 自研如果你的业务场景比较复杂例如需要自定义状态机、动态工具编排、或者深度整合内部系统建议基于 LangChain 或 LangGraph 这类框架自研。LangGraph 尤其适合持续推理场景因为它把 Agent 建模成图结构节点是推理或工具执行边是状态转移。这种模型和“多轮推理循环”天然契合。使用框架的好处是社区生态丰富坏处是学习曲线陡峭而且框架版本迭代快依赖管理要特别小心。4.3 路径三自己实现一个最小循环如果你只是想深入理解持续推理的原理或者你的 team 不想引入重量级框架完全可以自己实现一个最小循环。核心逻辑不复杂把模型输出解析成一个结构化动作。根据动作调用对应工具。把工具返回结果拼接到对话上下文。循环直到模型输出“完成”信号或达到轮次上限。下一章会给出完整代码。这个方案适合学习但生产环境需要补很多细节比如记忆压缩、并发控制、错误重试、审计日志等。下面是三条路径的对比路径适合场景门槛灵活度落地速度Dify / Coze 平台业务验证、低代码搭建低中快LangChain / LangGraph复杂自定义 Agent高高中自研最小循环学习原理、轻量场景中极高慢5. 持续推理 Agent 最小示例代码实现为了让“持续推理”不只是一个概念我们实现一个最小但仍然完整的 Agent 循环。这个示例完全基于 OpenAI 兼容接口只需要一个 API Key 就能运行。它解决的问题是用户输入一个任务Agent 自主决定调用哪个工具、不断修正最终输出完成结果。5.1 环境准备建议使用 Python 3.9 以上版本。安装依赖pip install requests python-dotenv在项目根目录创建.env文件LLM_API_KEY你的_API_Key LLM_API_URLhttps://api.openai.com/v1/chat/completions LLM_MODELgpt-4o-mini如果你使用的是兼容 OpenAI 协议的其他服务只需要修改LLM_API_URL和LLM_MODEL两个环境变量。5.2 完整代码文件路径agent_demo.pyimport os import json import requests from dotenv import load_dotenv load_dotenv() API_KEY os.getenv(LLM_API_KEY, ) API_URL os.getenv(LLM_API_URL, https://api.openai.com/v1/chat/completions) MODEL os.getenv(LLM_MODEL, gpt-4o-mini) MAX_ROUNDS 6 SYSTEM_PROMPT 你是一个持续推理智能体。 你可以多次调用工具来获取信息然后再决定下一步动作。 每次输出必须是一个 JSON 对象格式如下 1. 如果需要调用工具 {tool: calculator, args: {expression: 10 5}} 2. 如果任务已完成 {tool: finish, args: {result: 最终结果}} 可用工具 - calculator计算数学表达式args 中的 expression 必须是空格分隔的三元表达式如 10 5 - get_order_status查询订单状态args 中的 order_id 是订单号 注意你每次只能输出一个 JSON 对象不要输出多余文字。 def call_llm(messages): 调用 OpenAI 兼容接口返回模型回复文本。 payload { model: MODEL, messages: messages, temperature: 0.2, } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } resp requests.post(API_URL, headersheaders, jsonpayload, timeout30) resp.raise_for_status() return resp.json()[choices][0][message][content] def safe_calculate(expression): 只支持 数字 运算符 数字 的安全计算避免直接 eval。 parts expression.split() if len(parts) ! 3: return 表达式格式错误请输入如 10 5 的格式 a, op, b parts try: a float(a) b float(b) except ValueError: return 操作数必须是数字 ops { : lambda x, y: x y, -: lambda x, y: x - y, *: lambda x, y: x * y, /: lambda x, y: x / y if y ! 0 else 除数不能为 0, } if op not in ops: return f不支持的操作符: {op} return ops[op](a, b) def get_order_status(order_id): 模拟订单查询工具。 mock_data { A1001: 已发货, A1002: 待支付, A1003: 已完成, } return mock_data.get(order_id, 订单不存在) TOOL_REGISTRY { calculator: lambda args: safe_calculate(args.get(expression, )), get_order_status: lambda args: get_order_status(args.get(order_id, )), } def parse_action(text): 从模型输出中解析 JSON 动作。 start text.find({) end text.rfind(}) if start -1 or end -1: return None try: return json.loads(text[start:end 1]) except json.JSONDecodeError: return None def run_agent(user_task): messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_task}, ] for round_idx in range(1, MAX_ROUNDS 1): print(f\n[第 {round_idx} 轮] 模型推理中...) try: content call_llm(messages) except Exception as e: return f调用模型失败: {e} print(f[模型输出] {content}) action parse_action(content) if action is None: messages.append({role: assistant, content: content}) messages.append({role: user, content: 输出不是合法 JSON请重新按格式输出}) continue tool_name action.get(tool) args action.get(args, {}) messages.append({role: assistant, content: content}) if tool_name finish: return args.get(result, 任务完成) if tool_name not in TOOL_REGISTRY: messages.append({role: user, content: f未知工具 {tool_name}请从可用工具中选择}) continue print(f[调用工具] {tool_name} 参数: {args}) tool_result TOOL_REGISTRY[tool_name](args) print(f[工具返回] {tool_result}) messages.append({ role: user, content: f工具返回结果: {json.dumps(tool_result, ensure_asciiFalse)}。请继续推理。, }) return 达到最大轮次任务未能完成。 if __name__ __main__: task 请先计算 (12 500) * 3 的结果然后查询订单 A1002 的状态最后把结果整理成一句话。 result run_agent(task) print(\n) print(最终结果:, result)5.3 代码逻辑说明这个示例的核心并不复杂但每一步都是持续推理的关键组成。call_llm函数是模型的统一入口只要 API 兼容 OpenAI 协议就能替换。parse_action强制模型输出结构化 JSON优点是正则和工具调用逻辑都不依赖特定模型能力市面上的主流模型都能跑通。TOOL_REGISTRY是工具注册表新增工具只需要注册一个函数生产环境建议改成独立的工具服务或插件式加载。循环的关键在messages列表的变化。每一轮系统把工具返回结果追加到消息里并明确要求模型继续推理。这样模型始终能看到“自己上一轮做了什么、工具返回了什么、下一步该做什么”这正是持续推理和普通问答的核心区别模型不是被动接收用户指令而是在系统构造的循环里主动推进任务。需要说明的是这个示例刻意把工具调用设计成“模型输出 JSON → 系统解析 → 系统执行”的流程而不是使用 function calling 协议。原因有两个一是兼容性更好不依赖特定模型是否支持 function calling二是让读者更容易理解“推理”和“执行”是如何分离的。6. 运行结果与效果验证运行这个 Agentpython agent_demo.py一个通顺的预期输出大致如下[第 1 轮] 模型推理中... [模型输出] {tool: calculator, args: {expression: 12 500}} [调用工具] calculator 参数: {expression: 12 500} [工具返回] 512.0 [第 2 轮] 模型推理中... [模型输出] {tool: calculator, args: {expression: 512.0 * 3}} [调用工具] calculator 参数: {expression: 512.0 * 3} [工具返回] 1536.0 [第 3 轮] 模型推理中... [模型输出] {tool: get_order_status, args: {order_id: A1002}} [调用工具] get_order_status 参数: {order_id: A1002} [工具返回] 待支付 [第 4 轮] 模型推理中... [模型输出] {tool: finish, args: {result: 订单 A1002 当前状态为待支付。计算得到结果是 1536.0即 (12500)*31536。}} 最终结果: 订单 A1002 当前状态为待支付。计算得到结果是 1536.0即 (12500)*31536。怎么判断它真正符合“持续推理”关键看两点。第一计算步骤被拆成了多轮而不是希望模型一次性算完。第二每一步模型都能看到前一步的工具返回结果再决定下一步动作。如果模型在某一轮输出乱码或者找不到工具系统会通过追加错误信息让它自我修正而不是直接崩溃。如果运行失败按以下顺序排查请求超时或返回 401检查.env里的 API Key 是否正确LLM_API_URL是否可达。输出“调用模型失败”检查模型名称是否有效网络是否能访问 API 地址。模型一直不输出 JSON把temperature调到 0或者手动在 system prompt 里加一句“只输出 JSON不要输出任何解释”。7. 常见问题与排查思路持续推理 Agent 的常见问题很多不是模型不够聪明而是系统设计上有疏漏。下面五类问题出现频率最高。问题现象可能原因排查方式解决方案多轮循环后上下文越来越长token 消耗激增历史消息全部保留没有压缩或裁剪输出每轮消息长度统计工具返回大小对工具返回做截断只保留关键字段定期压缩旧的中间结果模型在多个工具之间反复调用不结束任务缺少终止判断逻辑系统的“完成”信号不够强查看日志里的工具调用序列增加最大轮次限制在 prompt 中强调“只有拿到最终答案才调用 finish”工具参数经常传错模型对工具入参格式理解不充分打印模型输出的 JSON 和实际调用参数在工具描述里给出参数示例解析层做参数校验和默认值兜底工具返回结果格式不稳定模型解析失败工具返回了非结构化文本或异常数据捕获工具返回检查是否包含不可见字符所有工具统一返回 JSON 字符串失败时返回结构化错误信息Agent 在生产环境误调用了危险操作工具权限粒度过粗Agent 可以自由调用写操作审计操作日志确认调用链将写操作和读操作分离引入人工审批节点和工具调用白名单这里额外提醒一个安全边界问题。持续推理意味着工具调用次数会显著增加如果不做权限控制Agent 可能在一次任务中调用了很多次本不应该触达的敏感接口。生产环境的建议是默认不授予 Agent 执行写操作的能力所有写操作走单独审批流程涉及数据库操作的 Agent必须使用只读账号并对敏感字段脱敏。8. 持续推理智能体的工程最佳实践从最小示例走向生产环境中间还需要补上很多工程细节。以下五个实践方向是当前 Agent 自动化程度下最容易踩坑也最值得投资的地方。8.1 上下文生命周期管理持续推理是一把双刃剑推理越多上下文越长token 成本越高模型也越容易在长上下文中迷失。建议为 Agent 设计一套上下文管理策略核心目标始终保持任务最初的目标描述放进一个单独变量不随中间轮次被覆盖。工具返回做摘要长文本工具返回优先抽摘要而不是全文送进模型。旧轮次压缩超过一定轮次后把早期推理过程压缩成一句话摘要保留关键结论丢弃冗余信息。预算预警每轮记录 token 消耗超过阈值时自动停止循环转人工处理。8.2 工具设计要面向可观测性工具注册表里的每个工具都应该输出结构化、可被审计的结果。推荐统一返回这样的 JSON 结构{ status: success, data: {}, cost_ms: 120, source: tool_name }这样 Agent 的日志系统可以清楚记录每一次工具调用的来源、耗时和结果也方便复现问题。不要把工具返回设计成自然语言段落模型解析自然语言的开销远大于解析 JSON。8.3 多智能体协作时的状态隔离当系统升级到多智能体协作比如一个 Planner Agent 负责拆任务一个 Executor Agent 负责执行一个 Reviewer Agent 负责验证结果时状态管理会更复杂。核心原则是状态要以“任务 ID”为粒度隔离不能跨任务混用。用一组简单的配置来描述协作结构# 多智能体编排示意结构 pipeline: - name: planner role: 任务拆解 output_vars: - sub_tasks - name: executor role: 工具执行 input_vars: - sub_tasks output_vars: - exec_result - name: reviewer role: 结果验证 input_vars: - exec_result output_vars: - review_passed - name: finisher role: 汇总输出 input_vars: - exec_result - review_passed这里的要点是每个 Agent 只读取自己需要的变量只写入自己负责的变量。如果放任所有 Agent 共享一个全局状态随着协作规模增大状态冲突几乎不可避免。8.4 错误重试与降级持续推理会出现单轮失败但整个任务不一定需要终止。推荐设计分级重试策略第一次失败把错误信息以“用户消息”的形式回传给模型让模型自行修正。连续失败两次检查是否进入了循环陷阱尝试切换更低的 temperature 或换一个模型。达到最大轮次终止执行输出已完成的中间结果和失败原因而不是直接抛出异常。8.5 人工介入机制不管 Agent 多么自主生产环境都要留人工介入的入口。推荐做法是Agent 在遇到不确定操作、写操作、高成本操作时不是硬着头皮执行而是生成一个“待确认请求”由人工审批后继续。在 Dify、Coze 这类平台里这个机制通常对应“审批节点”或“暂停 → 继续”的能力在自研系统里则在循环中加入一个特殊动作Agent 输出“需要审批”信号系统挂起任务等待人工回调。9. 总结与下一步学习方向回到开头那个问题现在的 Agent 为什么一到复杂任务就崩很大程度不是模型不够强而是我们还在用“问答范式”设计“任务执行系统”。Perplexity CEO 关于持续推理智能体的展望真正值得关注的地方不是某一家公司的判断而是它指出的方向智能体必须从“一次性生成答案”进化为“在循环中持续推理、调用工具、自我修正”的系统。这篇文章从概念、行业信号、平台选型、最小代码实现到工程最佳实践给出了一个相对完整的路线图。如果你今天只能做一件事建议先运行一遍第 5 章的示例把“模型输出 JSON → 系统调用工具 → 结果回填 → 继续推理”这个循环在本地跑通。这是理解持续推理最直观的方式也是后续所有复杂 Agent 架构的基础。下一步可以沿着三个方向继续深入第一把示例里的工具换成真实业务 API比如订单查询、库存查询、知识库检索第二给 Agent 增加长短期记忆比如用向量数据库保存历史任务结论第三尝试多智能体协作让不同 Agent 分别负责规划、执行和验证。如果对平台化搭建更感兴趣可以基于 Dify 或 Coze 把同样的循环建模成可视化工作流对比一下平台方案和自研方案的差异这会对你在不同场景下的技术选型很有帮助。