AI的下一次范式升级是 Jeff Dean 近两年公开讨论中出现频率很高的一个话题。若只把这句话理解成“模型更强了”会忽略真正重要的变化模型的能力重心正在从“生成文本”转向“参与完成任务”。这个变化会同时影响模型架构、训练方式、推理基础设施以及普通应用开发者在日常项目里写的代码结构。这篇文章不从新闻角度复述观点而是把话题拆成可执行的技术判断。适合正在做 AI 应用开发、大模型部署、Agent 类产品或者正在评估是否要把现有系统迁移到“模型 工具”架构的团队阅读。读完以后可以知道下一轮 AI 范式对工程侧的真正要求也能用一个最小 Agent 案例理解从模型调用、工具执行到结果验证的完整回路。1. 理解“范式升级”前先看清三个技术层面1.1 模型层从生成答案转向生成决策过去几年大语言模型给人最直接的印象是“什么都能答”。但在工程上这类能力本质上是条件文本生成模型根据输入 token 的概率分布预测下一个 token。它擅长的是把问题和答案之间的模式复现出来。Jeff Dean 及其团队过去关心的重点也正是如何扩大这种模式复现能力。从 Transformer 架构、稀疏激活到 TPU 集群和张量并行训练背后都指向同一件事让模型在更大数据、更大参数规模下仍然能稳定地学到规律。到了下一轮范式模型不只承担“生成答案”的职责还要承担一部分“生成决策”的职责。也就是说模型要判断当前任务缺少什么信息决定调用哪个工具分析工具返回是否合理然后决定下一步行动。这个变化意味着模型输出不再是一次性文本而是可以被外围系统解析、校验、执行的指令序列。这里容易出现误解。有人以为“Agent 化”就是给模型加一个 function call 接口。其实工具调用只是协议真正困难的是让模型在多步执行中保持目标一致性。它既要理解用户意图又要在中间结果不理想时修正计划。这种能力依赖模型本身的推理水平也依赖工程侧对上下文的组织方式。1.2 系统层从单次推理转向多步执行传统大模型应用最常见架构是“用户输入 - 调用模型 - 输出内容”。一次调用一个结果问题边界清晰。Agent 式应用改变了这条链路。模型输出可能只是一个工具调用系统需要执行这个工具把结果返回给模型模型再决定下一次调用。整个过程可能循环多次直到模型给出最终答案。这个变化对系统设计的影响是结构性的单次请求变成了多次模型调用延迟和成本都不再稳定。中间结果可能出错系统必须支持回退、重试、终止。用户不可能长时间等待需要状态机、任务队列或异步通知。工具的执行权限需要控制模型不能直接操作生产系统。排查问题时不能只看最后一次模型输出还要看整条链路上的调用记录。从工程角度看这不是简单的“把模型换大一号”而是把应用从数据流模型改造成控制流模型。数据流模型关心的是转换控制流模型关心的是状态、分支、循环和异常。这也是 Jeff Dean 技术路线里最有辨识度的部分不把模型当作一个孤立黑盒而是把它放进大规模分布式系统里考虑吞吐、容错、稳态和可观测性。换句话说AI 的下一次范式升级不只是算法升级更是系统架构升级。1.3 数据层从静态语料到实时证据大模型训练使用的是离线快照数据。即便模型经过海量语料训练它对训练结束后发生的新闻、系统状态、内部业务数据仍然一无所知。早期应用面对这个问题最常用做法是“定期重新训练”或者“把问题拆成更小的分类任务”。这两种方式成本都很高。下一轮范式里模型不再只依赖训练时固化的记忆而是学会在运行时主动获取证据。常见做法包括把用户问题先做语义检索从向量数据库或搜索引擎中拿到相关片段。把企业内部 API 暴露成模型可调用的函数让模型在需要时获取实时数据。把日志、指标、告警信息作为上下文注入辅助模型做运维判断。这带来的工程价值非常直接模型不需要“背下”所有业务数据只需要知道“怎么获取”业务数据。系统仍然保持权威数据源减少模型幻觉对关键业务的影响。因此下一代 AI 应用的开发重心将从“提示词技巧”转移一部分到“数据接入能力”。谁的检索质量高、工具接口稳定、数据权限清楚谁的大模型应用就更可靠。2. 支撑下一轮升级的四个关键方向2.1 推理时扩展在给出答案前多花算力“推理时扩展”是指模型在生成答案之前额外生成推理步骤或者搜索多个候选路径而不是直接从一个概率分布里采一个答案。OpenAI o1 系列模型之所以引发关注就是因为把这种能力产品化了模型会先生成内部思考链再给出最终结论。从实现角度看推理时扩展并不是单纯让模型“多输出几千字”而是让它在推理空间中尽量覆盖不同可能性再用额外机制判断哪个可能性更可靠。典型形态包括Chain-of-Thought让模型逐步拆解问题。Self-Consistency多次生成不同结果投票选出更稳定答案。搜索式推理模型结合外部工具做交互式验证。验证器奖励模型生成之后由另一个模型判断答案质量。代价是推理成本显著上升。没有免费的午餐模型在测试阶段消耗的算力换来的是复杂问题上的准确性提升。对应用开发者而言这里有一个具体判断方法如果你的问题可以分解成多个明确子步骤并且每一步都有验证标准就适合使用推理时扩展。如果问题只是简单分类、检索或超短文本生成额外的推理步骤反而会浪费延迟而且不一定更准。2.2 多模态与长上下文把记忆和感知做进上下文过去不同模态被当成不同模型处理。图像、视频、音频、文本分别走各自的 pipeline。Jeff Dean 团队关于统一模型的一贯思路是如果模型能把所有模态都转换成 token并且在同一个注意力层里处理那么不同模态之间就能互相检索和推理模型的多模态能力也就不需要靠外部串联。现在主流的大模型已经支持图文混合输入。更值得关注的是上下文长度。当上下文窗口从几千 token 扩展到百万级 token应用架构会发生实际变化可以把整份项目代码、全部接口文档或一整天日志直接放入上下文。可以减少传统 RAG 的切分、召回步骤。上下文里的信息越多模型越容易抓住全局关系。但“长上下文”不是解决一切问题的银弹。上下文过长会带来注意力分散、计算成本上升、关键信息被淹没等问题。工程实践里仍然需要分层高频核心资料放入系统提示。重要业务数据通过工具实时获取。大段历史记录用检索或摘要压缩。最新事务状态写入状态管理模块而不是全部塞进上下文。2.3 稀疏激活和多专家模型内部也要“分治”单一大模型的训练成本接近上限之后研究社区把注意力转向“稀疏激活”。核心想法很简单模型参数很多但处理某个输入时只激活其中一部分。这就是混合专家模型的基本思路。一个 MoE 模型通常包含多个专家网络和一个路由网络。路由网络收到输入后决定把 token 分配给哪几个专家。这样模型总参数量可以做得很大但实际推理计算量只和激活参数有关。这个设计对工程有直接影响模型文件变大显存容量要求提高。部署时可能需要多卡并行加载不同专家。路由的负载均衡会影响推理性能。如果某个专家被频繁调用可能成为热点需要对路由策略做约束。Jeff Dean 在 Pathways 等研究中多次强调未来不是训练一个“全能单模型”而是建立一组能力互补的模型和专家模块由系统按任务动态组合。这和 Agent 化的思路一致模型负责判断外围模块负责执行。2.4 Agent 回路模型决策加外围执行所谓 Agent 回路就是模型、工具、记忆、验证器之间的循环协作。它不是单个模型能力而是一个工程架构。一个常见的 Agent 回路可以描述为用户输入任务。模型判断当前信息是否足够。如果不足模型输出工具调用指令。系统执行工具返回结构化结果。模型把工具结果和原任务放一起继续判断。如果得到最终答案模型输出结论否则继续调用下一个工具。这里最容易被忽略的是验证器。AI 应用不能只依赖模型自我判断“我觉得完成了”。工程系统要能校验最终输出是否满足任务要求。例如如果任务是“生成 JSON 配置文件”系统应该解析 JSON 并校验必填字段如果任务是“提交数据库变更”系统应该先执行访问权限检查再在事务里执行并记录变更日志。把 Agent 回路做扎实模型只是大脑工具是手脚验证器才是质检员。三者缺一不可。3. 一个最小可运行的 Agent 式 AI 应用3.1 准备运行环境接下来的示例不追求复杂目标是用一套代码跑通“模型决策 - 工具调用 - 结果回填 - 最终回答”的完整流程。代码使用 Python 3.10 以上版本并假设你已经有可调用的 OpenAI 兼容接口。安装依赖只需要一个 SDKpip install openai在项目目录下创建.env文件写入模型接口配置。为了避免把密钥写进代码推荐通过环境变量读取export OPENAI_API_KEY你的接口密钥 export MODEL_NAMEgpt-4o-mini如果你使用本地部署的模型网关也可以把 base_url 指向本地地址client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL) )需要提醒的是不同模型对工具调用的支持程度不同。落地前要先确认你选用的模型版本和接口文档是否适配当前 SDK。3.2 项目结构和关键设计示例使用一个文件方便学习和调试。结构如下agent_demo/ ├── agent_demo.py # Agent 主程序 ├── .env # 环境变量 └── requirements.txt # Python 依赖核心设计包含三部分TOOLS工具定义告诉模型有哪些函数可用。execute_tool真实执行工具并返回结构化结果。run_agent循环调模型直到得到最终答案或达到步数上限。工具定义必须描述清晰。模型不看你代码实现它只根据 name、description 和 parameters 来决定是否调用。描述写得太模糊模型会乱选参数 schema 写错模型会生成无法解析的参数。import json import os from datetime import datetime from openai import OpenAI MODEL os.getenv(MODEL_NAME, gpt-4o-mini) client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) TOOLS [ { type: function, function: { name: search_knowledge_base, description: 在本地知识库中搜索关于指定主题的说明适合查询技术概念、产品介绍、项目背景等事实性问题, parameters: { type: object, properties: { keyword: { type: string, description: 查询关键词例如 Spring AI、Agent、RAG } }, required: [keyword] } } }, { type: function, function: { name: get_current_time, description: 获取服务器当前时间, parameters: { type: object, properties: {} } } } ] KNOWLEDGE_BASE { spring ai: Spring AI 是 Java 生态中的 AI 应用开发框架提供 ChatClient、Tool Calling、Advisors 等模块帮助把大模型能力集成进 Spring 应用。, agent: Agent 应用由模型循环调用工具并调整计划外围系统负责执行和校验。核心是模型决策、工具执行、结果验证的闭环。, rag: 检索增强生成通过从外部数据源获取与用户问题相关的片段再交给模型生成回答以缓解幻觉并补充实时信息。 } def execute_tool(name: str, args: dict): if name search_knowledge_base: keyword args.get(keyword, ) result KNOWLEDGE_BASE.get(keyword.strip().lower()) if result is None: return {found: False, message: f知识库中未找到与 {keyword} 相关的内容} return {found: True, content: result} if name get_current_time: return {time: datetime.now().strftime(%Y-%m-%d %H:%M:%S)} return {error: f未知工具: {name}}3.3 核心循环模型调用、工具执行、消息回填Agent 循环的关键点是消息处理。模型返回工具调用后系统必须把 assistant 消息和 tool 结果消息都回传给模型模型才能继续推理。常见做法是把模型返回的 message 原样追加到 message 列表。为每一个 tool_calls 元素追加对应 role 为 tool 的消息。tool_call_id 必须与模型返回一致。工具结果 content 建议使用 JSON 字符串保持结构可解析。def run_agent(user_input: str, max_steps: int 8): messages [ { role: system, content: 你是一个任务型助手。当问题需要实时时间或知识库内容时你必须先调用工具再根据工具结果回答用户。 }, { role: user, content: user_input } ] for step in range(max_steps): response client.chat.completions.create( modelMODEL, messagesmessages, toolsTOOLS, tool_choiceauto, ) msg response.choices[0].message if not msg.tool_calls: return msg.content # 1. 把携带 tool_calls 的 assistant 消息追加进去 messages.append(msg.model_dump()) # 2. 逐个执行工具并把结果追加为 tool 消息 for tool_call in msg.tool_calls: function_name tool_call.function.name function_args json.loads(tool_call.function.arguments or {}) tool_result execute_tool(function_name, function_args) messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(tool_result, ensure_asciiFalse) }) return 达到最大步骤数任务未能完成请稍后重试。 if __name__ __main__: question Spring AI 在 Java 开发中主要解决什么问题顺便告诉我当前时间。 answer run_agent(question) print(answer)代码有几个工程细节需要说明。第一msg.model_dump()会保留 assistant 消息的 tool_calls 字段后续模型调用才能理解这一次工具调用的上下文。如果把这个字段丢掉模型就无法关联 tool 结果。第二tool_call.function.arguments是字符串需要 json.loads。模型偶尔会返回不规范 JSON因此生产代码里要在这一步加 try-except并返回解析错误提示模型重试。第三max_steps是硬性护栏防止模型陷入无限调用。生产环境还需要把它换算成预算上限例如“最多调用多少次工具”“最多花费多少 token”。3.4 运行验证与预期结果运行命令python agent_demo.py正常情况下模型会识别出两个子任务查知识库、获取时间。它先输出两个 tool_calls系统执行后把结果回填模型再生成最终回答。预期输出类似于Spring AI 是 Java 生态中的 AI 应用开发框架提供 ChatClient、Tool Calling、Advisors 等模块帮助把大模型能力集成进 Spring 应用。 当前服务器时间是 2026-05-17 14:30:22。如果你的模型没有先调用工具而是直接编造了一个时间说明系统提示或模型能力有问题。不要因为最终输出看起来正常就认为代码可用。还要验证模型确实经历了工具调用过程。为了确认可以在 execute_tool 里增加一行日志print(f[tool_call] name{name}, args{json.dumps(args, ensure_asciiFalse)})这能直接看到模型决策链路避免“模型直接回答”造成的假成功。4. 验证 Agent 行为时最容易踩的问题4.1 从用户输入到最终输出的验证顺序Agent 应用和普通接口不同最终输出正确不代表过程正确。验证应该按下面顺序进行输入解析用户输入是否被正确识别为任务。工具选择模型是否选择了正确工具没有“多调”或“少调”。参数解析工具参数是否符合预期。工具执行工具本身是否正常返回。结果回填tool 消息是否被完整追加。最终判断模型是否基于工具结果回答而不是忽略结果。输出约束最终结果格式是否符合接入方要求。这七步中的任何一步出问题都会让 Agent 表现不稳定。只测“最终回答对不对”是不够的。4.2 常见问题与排查表下面表格总结了 Agent 工程里最常见的几类问题。问题现象常见原因检查方式处理建议模型不调用工具直接编造答案系统提示没有强调必须先调用工具模型能力不足打印 model_dump看 message.tool_calls 是否为空强化系统提示换用工具调用能力更强的模型模型返回非法 JSON 参数参数 schema 不清晰模型生成不稳定捕获 json.loads 异常并打印原始 argumentsschema 增加 description 和示例解析失败时返回错误提示模型重试工具被反复调用永不结束工具结果没有被模型理解工具返回不够明确打印每一步 messages查看 tool result 格式工具结果增加状态字段例如 found、success提高 max_steps 上限前先分析循环原因工具确实执行了但模型忽略结果assistant 消息没有携带 tool_callstool 消息追加顺序不对检查 messages 序列是否完整使用 msg.model_dump() 完整保留 assistant tool_calls 字段上下文超限工具返回超大结果或没有清理历史查看 token 用量和 messages 条数对工具结果截断、摘要、只保留关键字段必要时清理早期中间消息生产调用某个敏感工具前缺少审批没有在模型和真实工具之间加控制层审查 execute_tool 的权限判断逻辑敏感操作必须经过独立审批模块不能只靠模型自律4.3 日志应该记录什么Agent 排查比普通接口复杂因为没有统一的标准输入输出。一个最小可用日志结构建议包含request_id一次用户请求的唯一标识。step_index当前是第几步循环。model模型版本号。input_messages当前传入模型的 messages 数量或哈希。tool_call_name要调用的工具名。tool_call_args模型生成的参数。tool_result工具执行结果或异常信息。token_usage本轮消耗。timestamp时间戳。例如{ request_id: req_12345, step: 2, tool_call_name: search_knowledge_base, tool_call_args: {keyword: Spring AI}, tool_result: {found: true, content: Spring AI 是 Java 生态中的 AI 应用开发框架...}, token_usage: {prompt_tokens: 320, completion_tokens: 80}, timestamp: 2026-05-17T14:30:22.123Z }有了这些日志才能在用户报“又乱回答了”时快速断定问题是模型决策、工具数据还是回填逻辑导致的。5. 从示例走向生产需要补齐的工程能力5.1 学习环境、联调环境、生产环境的差异上面的示例适合学习但离生产环境还有一段距离。下面表格列出主要差异。维度学习环境生产环境模型版本随意切换锁定稳定版本灰度发布可回滚密钥管理环境变量密钥管理系统动态注入系统提示固定字符串按租户或业务渲染内容审核工具执行本地静态库独立服务超时、幂等、熔断、鉴权数据安全不入库脱敏、加密、权限隔离、删除策略可观测性print 日志结构化日志、Trace、指标、告警预算控制不关心token 和费用预算上限超限熔断输出验证人眼判断自动化断言格式校验业务规则校验生产环境有一个原则要守住模型可以建议系统才能执行。建议不需要代价执行会改变状态。因此Agent 架构里必须有一个独立的控制层在真正调用外部系统之前完成权限校验、配额检查、参数校验和人工审批判断。5.2 可落地的 Agent 工程实践清单结合上面的代码实现和踩坑经验整理一份可以直接用于项目评审的清单每个工具必须有明确的输入输出 schema并在系统里做参数校验。工具结果必须包含状态字段例如 success、found、error避免模型把异常当正常结果。工具执行设置超时和重试超时后返回可读错误信息而不是抛出裸异常。对敏感操作增加人工审批节点审批信息要带上完整上下文。Agent 设置最大步数、最大 token、最大费用三个硬限制。所有工具调用过程记录完整 Trace包括参数、结果和耗时。对最终输出做自动化校验至少校验格式和必填字段。定期用回归测试集评估 Agent 行为不只测单一样例。新工具接入前先跑一组边界用例观察模型是否会误用。上线前后做 A/B 对比用业务结果指标判断 Agent 是否真的优于旧逻辑。这里特别强调回归测试。Agent 的随机性比普通程序大得多。同一个输入改一个换行符或一个工具描述结果都可能不同。没有自动化评估就无法判断一次模型升级或提示词修改是变好还是变坏。5.3 用范式升级做技术选型时要问的问题团队在做技术评审时如果负责人说“我们要全部升级成 Agent 架构”不要急着响应。更好的做法是先回答几个问题当前业务问题里哪一部分是因为单次模型推理能力不够造成的如果引入工具调用多出来的延迟和成本是否可接受工具执行失败时用户看到什么系统如何兜底Agent 的一次错误判断会造成什么业务损失人工审核需要加入哪个环节成本是否值得有没有更简单的多阶段 pipeline 可以达到同样效果很多任务看起来像 Agent但实际上用固定流程就能解决。例如“先检索再生成”只需要两段代码不需要让模型自主判断。把 Agent 用在不该用的地方只会增加不可控性。6. 不要被范式升级绑架先解决问题再决定是否迁移Jeff Dean 谈到 AI 范式升级时重点始终在“如何用更合理的方式组织计算”。对一个普通技术团队来说真正值得借鉴的不是“必须立刻上 Agent”而是“先拆解任务再选择合适的技术组合”。如果你现在的工作流是“用户发问题 - 模型返回答案”那先做好上下文管理、检索质量、输出校验效果往往比硬套 Agent 更大。只有当任务确实需要多步决策、工具获取实时数据、并在执行过程中不断调整计划时Agent 式架构才会成为正确答案。这轮范式升级真正改变的是开发者的思维模型模型不再只是一个文本生成器而是一个能调度外围系统的决策引擎。谁能把模型决策、工具执行、结果验证这三件事组织得足够可靠谁就能把 AI 从演示推向生产。这不是靠一段提示词完成的而是靠扎实的数据接入、系统控制和可观测性设计完成的。
AI的下一次范式升级是 Jeff Dean 近两年公开讨论中出现频率很高的一个话题。若只把这句话理解成“模型更强了”会忽略真正重要的变化模型的能力重心正在从“生成文本”转向“参与完成任务”。这个变化会同时影响模型架构、训练方式、推理基础设施以及普通应用开发者在日常项目里写的代码结构。这篇文章不从新闻角度复述观点而是把话题拆成可执行的技术判断。适合正在做 AI 应用开发、大模型部署、Agent 类产品或者正在评估是否要把现有系统迁移到“模型 工具”架构的团队阅读。读完以后可以知道下一轮 AI 范式对工程侧的真正要求也能用一个最小 Agent 案例理解从模型调用、工具执行到结果验证的完整回路。1. 理解“范式升级”前先看清三个技术层面1.1 模型层从生成答案转向生成决策过去几年大语言模型给人最直接的印象是“什么都能答”。但在工程上这类能力本质上是条件文本生成模型根据输入 token 的概率分布预测下一个 token。它擅长的是把问题和答案之间的模式复现出来。Jeff Dean 及其团队过去关心的重点也正是如何扩大这种模式复现能力。从 Transformer 架构、稀疏激活到 TPU 集群和张量并行训练背后都指向同一件事让模型在更大数据、更大参数规模下仍然能稳定地学到规律。到了下一轮范式模型不只承担“生成答案”的职责还要承担一部分“生成决策”的职责。也就是说模型要判断当前任务缺少什么信息决定调用哪个工具分析工具返回是否合理然后决定下一步行动。这个变化意味着模型输出不再是一次性文本而是可以被外围系统解析、校验、执行的指令序列。这里容易出现误解。有人以为“Agent 化”就是给模型加一个 function call 接口。其实工具调用只是协议真正困难的是让模型在多步执行中保持目标一致性。它既要理解用户意图又要在中间结果不理想时修正计划。这种能力依赖模型本身的推理水平也依赖工程侧对上下文的组织方式。1.2 系统层从单次推理转向多步执行传统大模型应用最常见架构是“用户输入 - 调用模型 - 输出内容”。一次调用一个结果问题边界清晰。Agent 式应用改变了这条链路。模型输出可能只是一个工具调用系统需要执行这个工具把结果返回给模型模型再决定下一次调用。整个过程可能循环多次直到模型给出最终答案。这个变化对系统设计的影响是结构性的单次请求变成了多次模型调用延迟和成本都不再稳定。中间结果可能出错系统必须支持回退、重试、终止。用户不可能长时间等待需要状态机、任务队列或异步通知。工具的执行权限需要控制模型不能直接操作生产系统。排查问题时不能只看最后一次模型输出还要看整条链路上的调用记录。从工程角度看这不是简单的“把模型换大一号”而是把应用从数据流模型改造成控制流模型。数据流模型关心的是转换控制流模型关心的是状态、分支、循环和异常。这也是 Jeff Dean 技术路线里最有辨识度的部分不把模型当作一个孤立黑盒而是把它放进大规模分布式系统里考虑吞吐、容错、稳态和可观测性。换句话说AI 的下一次范式升级不只是算法升级更是系统架构升级。1.3 数据层从静态语料到实时证据大模型训练使用的是离线快照数据。即便模型经过海量语料训练它对训练结束后发生的新闻、系统状态、内部业务数据仍然一无所知。早期应用面对这个问题最常用做法是“定期重新训练”或者“把问题拆成更小的分类任务”。这两种方式成本都很高。下一轮范式里模型不再只依赖训练时固化的记忆而是学会在运行时主动获取证据。常见做法包括把用户问题先做语义检索从向量数据库或搜索引擎中拿到相关片段。把企业内部 API 暴露成模型可调用的函数让模型在需要时获取实时数据。把日志、指标、告警信息作为上下文注入辅助模型做运维判断。这带来的工程价值非常直接模型不需要“背下”所有业务数据只需要知道“怎么获取”业务数据。系统仍然保持权威数据源减少模型幻觉对关键业务的影响。因此下一代 AI 应用的开发重心将从“提示词技巧”转移一部分到“数据接入能力”。谁的检索质量高、工具接口稳定、数据权限清楚谁的大模型应用就更可靠。2. 支撑下一轮升级的四个关键方向2.1 推理时扩展在给出答案前多花算力“推理时扩展”是指模型在生成答案之前额外生成推理步骤或者搜索多个候选路径而不是直接从一个概率分布里采一个答案。OpenAI o1 系列模型之所以引发关注就是因为把这种能力产品化了模型会先生成内部思考链再给出最终结论。从实现角度看推理时扩展并不是单纯让模型“多输出几千字”而是让它在推理空间中尽量覆盖不同可能性再用额外机制判断哪个可能性更可靠。典型形态包括Chain-of-Thought让模型逐步拆解问题。Self-Consistency多次生成不同结果投票选出更稳定答案。搜索式推理模型结合外部工具做交互式验证。验证器奖励模型生成之后由另一个模型判断答案质量。代价是推理成本显著上升。没有免费的午餐模型在测试阶段消耗的算力换来的是复杂问题上的准确性提升。对应用开发者而言这里有一个具体判断方法如果你的问题可以分解成多个明确子步骤并且每一步都有验证标准就适合使用推理时扩展。如果问题只是简单分类、检索或超短文本生成额外的推理步骤反而会浪费延迟而且不一定更准。2.2 多模态与长上下文把记忆和感知做进上下文过去不同模态被当成不同模型处理。图像、视频、音频、文本分别走各自的 pipeline。Jeff Dean 团队关于统一模型的一贯思路是如果模型能把所有模态都转换成 token并且在同一个注意力层里处理那么不同模态之间就能互相检索和推理模型的多模态能力也就不需要靠外部串联。现在主流的大模型已经支持图文混合输入。更值得关注的是上下文长度。当上下文窗口从几千 token 扩展到百万级 token应用架构会发生实际变化可以把整份项目代码、全部接口文档或一整天日志直接放入上下文。可以减少传统 RAG 的切分、召回步骤。上下文里的信息越多模型越容易抓住全局关系。但“长上下文”不是解决一切问题的银弹。上下文过长会带来注意力分散、计算成本上升、关键信息被淹没等问题。工程实践里仍然需要分层高频核心资料放入系统提示。重要业务数据通过工具实时获取。大段历史记录用检索或摘要压缩。最新事务状态写入状态管理模块而不是全部塞进上下文。2.3 稀疏激活和多专家模型内部也要“分治”单一大模型的训练成本接近上限之后研究社区把注意力转向“稀疏激活”。核心想法很简单模型参数很多但处理某个输入时只激活其中一部分。这就是混合专家模型的基本思路。一个 MoE 模型通常包含多个专家网络和一个路由网络。路由网络收到输入后决定把 token 分配给哪几个专家。这样模型总参数量可以做得很大但实际推理计算量只和激活参数有关。这个设计对工程有直接影响模型文件变大显存容量要求提高。部署时可能需要多卡并行加载不同专家。路由的负载均衡会影响推理性能。如果某个专家被频繁调用可能成为热点需要对路由策略做约束。Jeff Dean 在 Pathways 等研究中多次强调未来不是训练一个“全能单模型”而是建立一组能力互补的模型和专家模块由系统按任务动态组合。这和 Agent 化的思路一致模型负责判断外围模块负责执行。2.4 Agent 回路模型决策加外围执行所谓 Agent 回路就是模型、工具、记忆、验证器之间的循环协作。它不是单个模型能力而是一个工程架构。一个常见的 Agent 回路可以描述为用户输入任务。模型判断当前信息是否足够。如果不足模型输出工具调用指令。系统执行工具返回结构化结果。模型把工具结果和原任务放一起继续判断。如果得到最终答案模型输出结论否则继续调用下一个工具。这里最容易被忽略的是验证器。AI 应用不能只依赖模型自我判断“我觉得完成了”。工程系统要能校验最终输出是否满足任务要求。例如如果任务是“生成 JSON 配置文件”系统应该解析 JSON 并校验必填字段如果任务是“提交数据库变更”系统应该先执行访问权限检查再在事务里执行并记录变更日志。把 Agent 回路做扎实模型只是大脑工具是手脚验证器才是质检员。三者缺一不可。3. 一个最小可运行的 Agent 式 AI 应用3.1 准备运行环境接下来的示例不追求复杂目标是用一套代码跑通“模型决策 - 工具调用 - 结果回填 - 最终回答”的完整流程。代码使用 Python 3.10 以上版本并假设你已经有可调用的 OpenAI 兼容接口。安装依赖只需要一个 SDKpip install openai在项目目录下创建.env文件写入模型接口配置。为了避免把密钥写进代码推荐通过环境变量读取export OPENAI_API_KEY你的接口密钥 export MODEL_NAMEgpt-4o-mini如果你使用本地部署的模型网关也可以把 base_url 指向本地地址client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL) )需要提醒的是不同模型对工具调用的支持程度不同。落地前要先确认你选用的模型版本和接口文档是否适配当前 SDK。3.2 项目结构和关键设计示例使用一个文件方便学习和调试。结构如下agent_demo/ ├── agent_demo.py # Agent 主程序 ├── .env # 环境变量 └── requirements.txt # Python 依赖核心设计包含三部分TOOLS工具定义告诉模型有哪些函数可用。execute_tool真实执行工具并返回结构化结果。run_agent循环调模型直到得到最终答案或达到步数上限。工具定义必须描述清晰。模型不看你代码实现它只根据 name、description 和 parameters 来决定是否调用。描述写得太模糊模型会乱选参数 schema 写错模型会生成无法解析的参数。import json import os from datetime import datetime from openai import OpenAI MODEL os.getenv(MODEL_NAME, gpt-4o-mini) client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) TOOLS [ { type: function, function: { name: search_knowledge_base, description: 在本地知识库中搜索关于指定主题的说明适合查询技术概念、产品介绍、项目背景等事实性问题, parameters: { type: object, properties: { keyword: { type: string, description: 查询关键词例如 Spring AI、Agent、RAG } }, required: [keyword] } } }, { type: function, function: { name: get_current_time, description: 获取服务器当前时间, parameters: { type: object, properties: {} } } } ] KNOWLEDGE_BASE { spring ai: Spring AI 是 Java 生态中的 AI 应用开发框架提供 ChatClient、Tool Calling、Advisors 等模块帮助把大模型能力集成进 Spring 应用。, agent: Agent 应用由模型循环调用工具并调整计划外围系统负责执行和校验。核心是模型决策、工具执行、结果验证的闭环。, rag: 检索增强生成通过从外部数据源获取与用户问题相关的片段再交给模型生成回答以缓解幻觉并补充实时信息。 } def execute_tool(name: str, args: dict): if name search_knowledge_base: keyword args.get(keyword, ) result KNOWLEDGE_BASE.get(keyword.strip().lower()) if result is None: return {found: False, message: f知识库中未找到与 {keyword} 相关的内容} return {found: True, content: result} if name get_current_time: return {time: datetime.now().strftime(%Y-%m-%d %H:%M:%S)} return {error: f未知工具: {name}}3.3 核心循环模型调用、工具执行、消息回填Agent 循环的关键点是消息处理。模型返回工具调用后系统必须把 assistant 消息和 tool 结果消息都回传给模型模型才能继续推理。常见做法是把模型返回的 message 原样追加到 message 列表。为每一个 tool_calls 元素追加对应 role 为 tool 的消息。tool_call_id 必须与模型返回一致。工具结果 content 建议使用 JSON 字符串保持结构可解析。def run_agent(user_input: str, max_steps: int 8): messages [ { role: system, content: 你是一个任务型助手。当问题需要实时时间或知识库内容时你必须先调用工具再根据工具结果回答用户。 }, { role: user, content: user_input } ] for step in range(max_steps): response client.chat.completions.create( modelMODEL, messagesmessages, toolsTOOLS, tool_choiceauto, ) msg response.choices[0].message if not msg.tool_calls: return msg.content # 1. 把携带 tool_calls 的 assistant 消息追加进去 messages.append(msg.model_dump()) # 2. 逐个执行工具并把结果追加为 tool 消息 for tool_call in msg.tool_calls: function_name tool_call.function.name function_args json.loads(tool_call.function.arguments or {}) tool_result execute_tool(function_name, function_args) messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(tool_result, ensure_asciiFalse) }) return 达到最大步骤数任务未能完成请稍后重试。 if __name__ __main__: question Spring AI 在 Java 开发中主要解决什么问题顺便告诉我当前时间。 answer run_agent(question) print(answer)代码有几个工程细节需要说明。第一msg.model_dump()会保留 assistant 消息的 tool_calls 字段后续模型调用才能理解这一次工具调用的上下文。如果把这个字段丢掉模型就无法关联 tool 结果。第二tool_call.function.arguments是字符串需要 json.loads。模型偶尔会返回不规范 JSON因此生产代码里要在这一步加 try-except并返回解析错误提示模型重试。第三max_steps是硬性护栏防止模型陷入无限调用。生产环境还需要把它换算成预算上限例如“最多调用多少次工具”“最多花费多少 token”。3.4 运行验证与预期结果运行命令python agent_demo.py正常情况下模型会识别出两个子任务查知识库、获取时间。它先输出两个 tool_calls系统执行后把结果回填模型再生成最终回答。预期输出类似于Spring AI 是 Java 生态中的 AI 应用开发框架提供 ChatClient、Tool Calling、Advisors 等模块帮助把大模型能力集成进 Spring 应用。 当前服务器时间是 2026-05-17 14:30:22。如果你的模型没有先调用工具而是直接编造了一个时间说明系统提示或模型能力有问题。不要因为最终输出看起来正常就认为代码可用。还要验证模型确实经历了工具调用过程。为了确认可以在 execute_tool 里增加一行日志print(f[tool_call] name{name}, args{json.dumps(args, ensure_asciiFalse)})这能直接看到模型决策链路避免“模型直接回答”造成的假成功。4. 验证 Agent 行为时最容易踩的问题4.1 从用户输入到最终输出的验证顺序Agent 应用和普通接口不同最终输出正确不代表过程正确。验证应该按下面顺序进行输入解析用户输入是否被正确识别为任务。工具选择模型是否选择了正确工具没有“多调”或“少调”。参数解析工具参数是否符合预期。工具执行工具本身是否正常返回。结果回填tool 消息是否被完整追加。最终判断模型是否基于工具结果回答而不是忽略结果。输出约束最终结果格式是否符合接入方要求。这七步中的任何一步出问题都会让 Agent 表现不稳定。只测“最终回答对不对”是不够的。4.2 常见问题与排查表下面表格总结了 Agent 工程里最常见的几类问题。问题现象常见原因检查方式处理建议模型不调用工具直接编造答案系统提示没有强调必须先调用工具模型能力不足打印 model_dump看 message.tool_calls 是否为空强化系统提示换用工具调用能力更强的模型模型返回非法 JSON 参数参数 schema 不清晰模型生成不稳定捕获 json.loads 异常并打印原始 argumentsschema 增加 description 和示例解析失败时返回错误提示模型重试工具被反复调用永不结束工具结果没有被模型理解工具返回不够明确打印每一步 messages查看 tool result 格式工具结果增加状态字段例如 found、success提高 max_steps 上限前先分析循环原因工具确实执行了但模型忽略结果assistant 消息没有携带 tool_callstool 消息追加顺序不对检查 messages 序列是否完整使用 msg.model_dump() 完整保留 assistant tool_calls 字段上下文超限工具返回超大结果或没有清理历史查看 token 用量和 messages 条数对工具结果截断、摘要、只保留关键字段必要时清理早期中间消息生产调用某个敏感工具前缺少审批没有在模型和真实工具之间加控制层审查 execute_tool 的权限判断逻辑敏感操作必须经过独立审批模块不能只靠模型自律4.3 日志应该记录什么Agent 排查比普通接口复杂因为没有统一的标准输入输出。一个最小可用日志结构建议包含request_id一次用户请求的唯一标识。step_index当前是第几步循环。model模型版本号。input_messages当前传入模型的 messages 数量或哈希。tool_call_name要调用的工具名。tool_call_args模型生成的参数。tool_result工具执行结果或异常信息。token_usage本轮消耗。timestamp时间戳。例如{ request_id: req_12345, step: 2, tool_call_name: search_knowledge_base, tool_call_args: {keyword: Spring AI}, tool_result: {found: true, content: Spring AI 是 Java 生态中的 AI 应用开发框架...}, token_usage: {prompt_tokens: 320, completion_tokens: 80}, timestamp: 2026-05-17T14:30:22.123Z }有了这些日志才能在用户报“又乱回答了”时快速断定问题是模型决策、工具数据还是回填逻辑导致的。5. 从示例走向生产需要补齐的工程能力5.1 学习环境、联调环境、生产环境的差异上面的示例适合学习但离生产环境还有一段距离。下面表格列出主要差异。维度学习环境生产环境模型版本随意切换锁定稳定版本灰度发布可回滚密钥管理环境变量密钥管理系统动态注入系统提示固定字符串按租户或业务渲染内容审核工具执行本地静态库独立服务超时、幂等、熔断、鉴权数据安全不入库脱敏、加密、权限隔离、删除策略可观测性print 日志结构化日志、Trace、指标、告警预算控制不关心token 和费用预算上限超限熔断输出验证人眼判断自动化断言格式校验业务规则校验生产环境有一个原则要守住模型可以建议系统才能执行。建议不需要代价执行会改变状态。因此Agent 架构里必须有一个独立的控制层在真正调用外部系统之前完成权限校验、配额检查、参数校验和人工审批判断。5.2 可落地的 Agent 工程实践清单结合上面的代码实现和踩坑经验整理一份可以直接用于项目评审的清单每个工具必须有明确的输入输出 schema并在系统里做参数校验。工具结果必须包含状态字段例如 success、found、error避免模型把异常当正常结果。工具执行设置超时和重试超时后返回可读错误信息而不是抛出裸异常。对敏感操作增加人工审批节点审批信息要带上完整上下文。Agent 设置最大步数、最大 token、最大费用三个硬限制。所有工具调用过程记录完整 Trace包括参数、结果和耗时。对最终输出做自动化校验至少校验格式和必填字段。定期用回归测试集评估 Agent 行为不只测单一样例。新工具接入前先跑一组边界用例观察模型是否会误用。上线前后做 A/B 对比用业务结果指标判断 Agent 是否真的优于旧逻辑。这里特别强调回归测试。Agent 的随机性比普通程序大得多。同一个输入改一个换行符或一个工具描述结果都可能不同。没有自动化评估就无法判断一次模型升级或提示词修改是变好还是变坏。5.3 用范式升级做技术选型时要问的问题团队在做技术评审时如果负责人说“我们要全部升级成 Agent 架构”不要急着响应。更好的做法是先回答几个问题当前业务问题里哪一部分是因为单次模型推理能力不够造成的如果引入工具调用多出来的延迟和成本是否可接受工具执行失败时用户看到什么系统如何兜底Agent 的一次错误判断会造成什么业务损失人工审核需要加入哪个环节成本是否值得有没有更简单的多阶段 pipeline 可以达到同样效果很多任务看起来像 Agent但实际上用固定流程就能解决。例如“先检索再生成”只需要两段代码不需要让模型自主判断。把 Agent 用在不该用的地方只会增加不可控性。6. 不要被范式升级绑架先解决问题再决定是否迁移Jeff Dean 谈到 AI 范式升级时重点始终在“如何用更合理的方式组织计算”。对一个普通技术团队来说真正值得借鉴的不是“必须立刻上 Agent”而是“先拆解任务再选择合适的技术组合”。如果你现在的工作流是“用户发问题 - 模型返回答案”那先做好上下文管理、检索质量、输出校验效果往往比硬套 Agent 更大。只有当任务确实需要多步决策、工具获取实时数据、并在执行过程中不断调整计划时Agent 式架构才会成为正确答案。这轮范式升级真正改变的是开发者的思维模型模型不再只是一个文本生成器而是一个能调度外围系统的决策引擎。谁能把模型决策、工具执行、结果验证这三件事组织得足够可靠谁就能把 AI 从演示推向生产。这不是靠一段提示词完成的而是靠扎实的数据接入、系统控制和可观测性设计完成的。
