2025 年人工智能十大趋势和 AI 智能体级别这两个词最近在各种场合被反复提起。上周还有个做企业内训的朋友问我能不能用一页纸讲明白今年到底该往哪儿投人、投钱、投时间。我当时的回答是趋势清单本身不值钱值钱的是你拿什么判据去判断哪一条跟你有关同样智能体分级也不是拿来贴标签的而是拿来定验收标准的。这篇就按这个思路把 2025 年人工智能十大趋势拆开来讲同时把我自己在项目里一直在用的 AI 智能体级别划分方法、每一级的判定标准、最小可运行代码、参数预算公式和踩过的坑一次性摊开说清楚。不管你是刚接触大模型的业务同学还是已经在写推理服务链路的工程同学看完之后至少能做到两件事知道今年哪些方向是真变化、哪些是旧瓶装新酒知道手里的项目该做成第几级智能体以及第几级到底怎么验收。1. 先把趋势清单和智能体分级这两件事说清楚很多人对趋势类内容有天然的反感觉得是玄学。我部分同意但有一个前提得先讲清楚趋势的价值不在于预测未来而在于帮你做减法。一年下来新技术名词几百个你真正能落地的可能就两三个趋势清单的作用是把噪音过滤掉让你把注意力压在少数几个会持续投入的方向上。所以我讲趋势不会讲“某技术将改变世界”而是讲“这条趋势落地之后工程上的做法会发生什么变化你要补什么能力”。1.1 为什么今年要换个读法过去两年看趋势大家习惯盯模型榜单。榜单第一换人了就代表方向变了。2025 年这个逻辑基本失效了原因很直接头部模型之间的差距在日常任务上已经被压缩得很小你再花大力气去追那零点几个百分点的差距投入产出比非常差。真正拉开差距的地方挪到了模型之外——上下文怎么组织、工具怎么接、失败怎么恢复、成本怎么控、结果怎么验。我自己内部做技术选型时有一个很土的办法叫“三层过滤”。第一层问这条趋势是不是改变了我的输入输出形态比如从纯文本变成多模态输入输出这属于形态变化必须跟。第二层问是不是改变了我的系统结构比如从单次调用变成一个带循环的执行体这属于架构变化得评估。第三层问是不是只改变了参数和配置比如换个量化精度、调个温度值这种就归到日常优化不值得单独开会讨论。用这个过滤器过一遍十条趋势里真正需要动手的通常不超过四条剩下的都是背景信息。这个习惯我建议你也养成能省掉大量无效的技术焦虑。1.2 智能体级别的划分逻辑与判据说完趋势怎么读再说分级。市面上讲智能体分级的内容不少多数是从“自主性”这一个维度去分我觉得不够用。自主性高不等于好用一个完全放飞、什么都能自己决定但结果不可复现的智能体在企业里基本没人敢用。所以我习惯用六个维度一起判单次任务的最大自主步数、可调用工具的数量与危险等级、失败后的自恢复能力、记忆的跨会话跨度、人工介入的频率与位置、结果的验收方式。这六个维度组合起来才能描述一个智能体到底成熟到什么程度。我用的一张分级表大致是这样需要说明的是这套划分是我在多个项目里迭代出来的内部工具不是任何官方标准你完全可以按自己的业务改权重级别名称自主步数工具范围失败恢复记忆跨度人工介入验收方式L1辅助型1-2只读检索无报错即止单轮每步都由人执行人读一遍L2受控执行型3-8读 低危写单次重试单会话关键动作前确认结果 轨迹抽查L3任务自主型8-30读 受限写策略化重试 换路单任务跨会话人在环外监督结果断言 回归集L4长期协同型30-200多系统 子智能体自我诊断 降级跨任务长期只设目标与边界指标看板 审计L5组织级自治200资源调度级自愈 自我改进组织记忆治理层介入多层审计 抽检这张表最有用的一列其实是最后一列“验收方式”。级别越高你越不可能靠人肉读结果来判断对错必须提前把断言、回归集、看板、审计做出来。换句话说级别不是能力标签是验收成本标签。你想升到 L3先问问自己有没有一套能自动跑的回归集没有那就老老实实待在 L2。2. 十大趋势里技术侧的五条趋势我按两个维度分组技术侧五条讲的是能力边界怎么被推动的工程与产业侧五条讲的是这些能力怎么变成可交付的东西。分组本身没有严格界限只是方便讲。2.1 趋势一推理时计算成为新的一等公民第一个变化是推理阶段的计算量开始被显式地当成一个可调参数。以前大家默认“训练一次、推理无数次”推理就是一次前向越快越省钱越好。2025 年的做法明显变了遇到难题先让模型多想一会儿生成更长的中间推理甚至并行采样多条路径再投票用推理时间换正确率。这在数学、代码、复杂检索问答上收益最明显。工程上这意味着什么你的服务不再是“请求进来、模型出去”的一条直线而变成了一个带有预算控制的分支结构。我现在的做法是给每个请求打一个“难度预估”简单问题走快路径复杂问题走慢路径慢路径要设三个硬上限思考步数上限、总 token 上限、总耗时上限。没有这三个上限一个死循环就能把账单干穿。这个坑我踩过一次某次灰度上线一个边界 case 让模型反复自我纠错单次请求跑了四十多步费用是正常请求的三十多倍。从那以后任何带循环的调用我都强制加上限宁可返回“我不会”也不能放任它无限思考。2.2 趋势二多模态从“能看”走向“能操作”多模态这两年一直在讲但 2025 年的变化点不在“识别”而在“操作”。识别是看图说话操作是看着界面告诉你点哪里、填什么、下一步该做什么。这两者的工程量差一个数量级。识别错了顶多答错操作错了会真的把数据改坏。落到具体场景比如表单填写、后台配置、报表核对这类重复性工作多模态理解加上界面元素定位已经能做到“给一遍示范后续照着做”。但我在实际项目里的结论是凡是涉及写操作的必须保留人工确认至少保留第一周的确认。因为界面元素是会变的按钮挪个位置、文案改一个字定位就可能失效失效之后如果直接执行后果不可控。稳妥的做法是让模型输出结构化的动作意图比如“在某个字段填入某个值”再交给一个确定性的执行器去落地模型永远不直接碰键盘鼠标。这个分层是我认为最值得抄的做法。2.3 趋势三上下文工程取代提示词工程“提示词工程”这个词今年明显降温了取而代之的是上下文工程。区别在哪提示词工程关心的是怎么把一句话说得更清楚上下文工程关心的是在这一轮对话里到底该塞进去哪些信息、按什么顺序塞、塞多少。后者更接近信息检索和内存管理更像系统设计而不是写作技巧。我自己的一个实际案例同样一个合同条款审查任务早期我就是把整份合同丢进去效果一般而且长文档后半段经常被忽略。后来改成三段式先用检索把可能相关的条款段落捞出来再按“当前待审条款、相关法条片段、历史相似案例结论”的顺序拼装上下文最后才让模型判断。同样的模型准确率提升非常明显token 消耗还降了将近四成。这就是上下文工程的价值——它不是让模型更聪明是让模型少看废话。顺序也很关键实测把最关键的判断依据放在上下文末尾比放在开头效果好因为模型对末尾内容的注意力更集中。2.4 趋势四小模型与端侧推理的重新崛起小模型今年又热了但驱动力跟几年前不一样。几年前是小模型便宜现在是很多任务根本不需要大模型。分类、抽取、格式转换、意图识别这些活一个几亿参数级别的模型微调一下就能干得很好延迟低到几十毫秒还能放在本地跑数据不出设备。我在一个内部工具里做过对比用大模型做意图分类单次延迟两秒多一天几万次调用成本不低换成小模型加少量样本微调延迟降到一百毫秒以内准确率在业务分布上只差一点点而且那一点点差异集中在极少数长尾意图上加一条兜底规则就解决了。这件事给我的启发是架构上应该默认做“路由”先判难度简单的给小模型复杂的才升级到大模型。这个模式现在几乎是我所有项目的标配成本能压下来一半以上体验还更好因为大部分请求变快了。2.5 趋势五评测体系从刷榜走向任务交付榜单分数今年越来越没人看了原因很简单榜单分数高不代表任务能交付。真正被重视的是任务级评测——给一批真实任务看端到端的完成率、平均耗时、人工返工率、单位任务成本。这四个指标比任何榜单都实在。我现在的项目里上线前必须准备三样东西一个至少五十条的真实任务集、一套结果断言能自动判对错的规则、一份人工抽检记录。断言覆盖不了的就靠抽检。抽检比例我一般定在百分之十跑一周稳定后降到百分之三。这套东西做起来枯燥但它是唯一能让你在模型升级、上下文改动、工具变更之后快速知道“是不是变差了”的手段。没有它你所有的优化都是凭感觉。我见过太多团队改了一版提示词主观觉得变好了实际任务完成率掉了七八个点两周后才发现返工成本远比当初做评测高。3. 工程与产业侧的五条技术侧讲的是“能做到什么”这五条讲的是“怎么把它变成能交付、能算账、能管住的东西”。我个人认为这部分对绝大多数团队的价值更大因为技术侧你追不动工程侧你是可以自己决定的。3.1 趋势六工具协议与运行时开始标准化今年一个很明显的信号是智能体跟外部工具打交道的方式在收敛。以前每接一个系统都要写一套胶水代码现在逐渐形成了相对统一的描述方式工具叫什么、需要什么参数、返回什么结构、出错怎么表达。这件事的意义不在于省了多少行代码而在于工具可以被复用、被发现、被组合。我在实际项目里最看重的是两点一是工具的入参出参必须强结构化不能是自由文本否则模型理解成本极高二是每个工具必须声明“危险等级”和“是否幂等”。幂等这件事特别关键智能体重试是常态如果重试的动作不幂等就可能重复下单、重复扣款。我的做法是给每个工具打三个标记只读、可重入写、不可重入写。前两类允许自动重试第三类必须走人工确认或者先查状态再决定。这个规范写下来只有一页纸但省掉的线上事故不止一次。3.2 趋势七数据飞轮从标注转向轨迹以前做数据闭环核心是人工标注。今年越来越多团队的重心转向“轨迹”——也就是智能体执行任务的全过程记录它想了什么、调了什么工具、拿到什么结果、在哪一步出错、人是怎么纠正的。轨迹数据的价值远高于单条标注因为它包含了决策过程可以直接用来做偏好优化和小样本示范。我建议从第一天就把轨迹存下来字段至少包括任务标识、每一步的输入摘要、工具名与参数、工具返回摘要、模型输出、耗时、token 数、是否人工干预、干预内容。这些字段看起来多但真出事的时候你唯一能依靠的就是它。有一次线上一个批量任务出现零星空结果靠日志根本看不出问题最后是把轨迹拉出来逐步比对才发现是某个工具的返回在特定分页情况下结构变了模型没识别出来就当成空数据继续往下走了。没有轨迹这个 bug 估计要查一周。3.3 趋势八AI 原生形态的软件在重写交互这条讲的是产品形态。以前做软件交互是“人找功能”菜单、按钮、表单。现在越来越多的产品在试“人给目标系统给路径”。这对工程的影响是你的系统要有能力被调用而不只是被人点。接口设计、权限粒度、审计日志这些以前是后台才关心的事现在直接决定产品能不能被智能体驱动。我参与过一个内部系统的改造最初的做法是给每个页面做一个接口结果发现粒度太粗智能体没法组合。后来改成按“业务动作”拆查询单据、创建草稿、提交审批、撤回每个动作一个接口权限按动作授日志按动作记。改完之后同样一套接口既能支撑界面也能支撑智能体还顺带把权限审计做细了。这件事的经验是接口按“动作”设计不按“页面”设计这个原则对智能体时代特别重要。3.4 趋势九成本结构从按次计费走向按任务计费这是一个容易被忽略但影响很大的变化。按次计费时你优化的是单次调用的成本按任务计费时你优化的是任务的总成本包括失败重试、人工复核、工具调用。这两种视角下最优策略完全不同。按次看慢思考是浪费按任务看慢思考只要能减少返工就是省钱。我一般会算一个“单任务全成本”公式大致是模型调用成本 工具调用成本 人工复核成本 × 复核率 失败重做的期望成本。代入具体项目后经常出现反直觉的结论一个看起来更贵的模型因为一次通过率高反而总成本更低。有个抽取任务便宜的模型单次成本只有三分之一但需要人工返工的比例接近四成换成贵的模型返工率降到一成算下来总成本反而低了两成多。所以选模型别只看单价看单任务全成本。3.5 趋势十治理与可观测性内生化最后一条是治理。以前治理是事后补的现在越来越多团队在架构阶段就把可观测性做进去每一步的输入输出、每次工具调用、每个决策分支都要留痕而且要能按任务串起来。这不只是为了合规更是为了排查和优化。我的做法很简单所有智能体执行都带一个统一的追踪标识从入口一路透传到每个工具调用日志按这个标识聚合。另外设三个告警阈值单任务步数超限、单任务成本超限、失败率突增。这三条告警救过我很多次尤其是成本超限那条能第一时间发现异常循环。治理这件事听起来不性感但它是你能不能把智能体从 demo 推到生产的分水岭。4. 五级智能体的落地判据与实操前面提了分级表这里展开讲每一级到底怎么判、怎么搭。分级的意义在于对齐预期业务方说“我要一个智能体”你得先问清楚他要的是 L1 的辅助还是 L3 的自主执行。这两者的工期、成本、风险差十倍不止。4.1 每一级的能力边界与验收清单L1 辅助型本质是“人在干活模型在旁边递工具”。典型形态是问答、检索、改写、翻译。判据很简单模型不调用任何有副作用的工具输出由人复制粘贴使用。这一级的验收就是人读一遍觉得可用就行。别小看这一级企业内部百分之六十的需求其实停在这里硬要做到 L2 纯属浪费。L2 受控执行型是“模型能动手但动手前后都有人把关”。典型形态是自动填表、自动生成工单草稿、自动拉取数据做初步分析。判据是能连续完成三到八步能调用只读工具和低危写工具关键写操作前必须停下来等人确认。验收看两样结果对不对轨迹里有没有多余动作。这一级是投入产出比最高的我现在做项目基本都从这一级起步。L3 任务自主型是“给目标自己跑人只看结果”。判据是能连续执行八到三十步能自主选择工具、自主判断是否需要换一条路失败后能按预设策略重试而不是直接崩。这一级必须配回归集否则不敢让它跑。验收靠断言加抽检人可以不在现场但不能没有监控。L4 长期协同型是“跨任务、有记忆、能主动”。判据是跨会话保持记忆能主动发起下一步动作能调度多个子智能体分工。这一级的核心风险是“漂移”跑久了行为偏离初衷所以必须有边界约束和行为审计人只在设定目标和划边界时介入。L5 组织级自治坦白说我目前只在极少数封闭场景里见过接近的形态比如高度标准化的运维自愈。它要求系统能自我诊断、自我改进、资源自调度同时可被治理层审计。绝大多数团队三年内不需要考虑这一级讨论它更多是为了有个方向感。4.2 每一级的典型架构与关键参数架构上L1 最简单一次调用加检索就够。L2 开始需要执行循环规划、调用工具、观察结果、再规划循环体外面套上限控制。L3 在 L2 基础上加三样东西任务状态持久化中途崩了能续、失败分类处理区分可重试、需换路、必须放弃、工具选择的策略层不是每步都让模型重新挑常见路径可以走预设流程省 token。L4 再加记忆层和子任务调度。关键参数我列几个常用的经验值供你起步时参考具体要按业务调参数建议起点调整依据单任务最大步数L2 取 8L3 取 30超过则强制中止并转人工单步最大 token输入 8k输出 2k超出说明上下文没收敛单任务成本上限预估均值的 3 倍触线告警并中止工具超时10-30 秒按依赖系统响应时间的 P99 定重试次数2 次指数退避只对幂等动作生效人工确认触发任何不可重入写一票否决不做例外这些数字不是拍脑袋来的都是我在项目里被事故教育之后定下来的保守值。起步阶段宁可设紧一点跑顺了再逐步放宽反过来会很痛苦因为你不知道放宽之后哪一步会失控。4.3 怎么判断项目该做第几级判断方法我总结成三问。第一问这个任务的错误代价有多大如果错了要赔钱、要担责就往下压一级加人工确认。第二问这个任务的输入分布稳定吗如果每天来的东西千奇百怪别急着上 L3先把 L2 跑稳积累足够的轨迹再做自主化。第三问你有没有自动判对错的能力如果连断言都写不出来只能靠人看那 L3 的“自主”就是个伪命题因为你根本不知道它做对没做对。这三问过下来很多看起来很酷的需求会自动降级到 L2这恰恰是对的。我在一个数据处理项目上就吃过亏一开始直接奔着 L3 设计结果因为没有可靠的断言每天靠人工抽查人比原来还累。后来退回 L2把人工确认点放在最关键的一步整体效率反而提升了。5. 从零搭一个 L2 级智能体的最小闭环讲完理论上一段能跑的代码。这个例子是通用的最小闭环不绑定任何具体厂商接口留成可替换的形式你可以接自己的模型服务。5.1 环境与依赖需要的东西很少一个能发 HTTP 请求的客户端、一个 JSON 处理库Python 3.10 以上就够。工具层我用一个注册表来管理核心是给每个工具声明名称、参数结构、危险等级和是否幂等这三样是所有安全控制的基础。from dataclasses import dataclass, field from typing import Callable, Any dataclass class Tool: name: str func: Callable[..., Any] danger: str # read / write / write_no_retry idempotent: bool timeout: int 20 schema: dict field(default_factorydict) TOOLS: dict[str, Tool] {} def register(tool: Tool): TOOLS[tool.name] tool return tool这段代码很短但danger和idempotent两个字段是整个安全体系的地基。后面所有的“能不能自动重试”“要不要人工确认”全靠它们判断不要图省事省掉。5.2 核心循环实现循环体我写成一个显式的状态机不用递归方便控制步数和调试。整体逻辑是拿任务目标、生成下一步动作、如果是工具调用就执行并观察、如果是最终答案就返回。每一步都记录轨迹。import time, json, uuid def run_agent(goal: str, max_steps: int 8, cost_budget: float 1.0, confirm_hookNone): trace_id uuid.uuid4().hex trace, cost, step [], 0.0, 0 messages [{role: user, content: goal}] while step max_steps: step 1 action call_model(messages) # 返回结构化动作 cost estimate_cost(action) trace.append({step: step, action: action, cost: cost}) if cost cost_budget: return {status: budget_exceeded, trace: trace, trace_id: trace_id} if action[type] final: return {status: done, answer: action[content], trace: trace, trace_id: trace_id} if action[type] tool: tool TOOLS.get(action[name]) if tool is None: messages.append({role: tool, content: 未知工具请重新选择}) continue need_confirm (tool.danger ! read or not tool.idempotent) if need_confirm and confirm_hook: if not confirm_hook(action): messages.append({role: tool, content: 用户拒绝执行该操作}) continue result safe_call(tool, action[args]) messages.append({role: tool, content: json.dumps(result, ensure_asciiFalse)[:2000]}) return {status: max_steps, trace: trace, trace_id: trace_id}几个设计点值得说一下。第一max_steps和cost_budget是双保险一个控步数一个控钱缺一不可因为有的动作很便宜但步数多有的步数少但单步很贵。第二工具返回结果做了截断只留前面两千字符这是为了防止某个工具返回超大文本把上下文撑爆撑爆之后模型的行为会变得非常奇怪。第三confirm_hook是一个回调把“要不要人工确认”这件事从循环里解耦出来方便你在不同场景下换策略比如测试环境直接返回 True生产环境弹窗。5.3 参数计算与预算估算成本预算怎么定我给一个可复用的估算方法。先估单步的 token 消耗系统提示加历史上下文加工具返回通常在两千到八千之间取个中位数四千输出平均五百。一个八步任务的总输入 token 大约是 3.2 万输出四千。再乘单价得到单任务模型成本。设输入单价为 a 元每百万 token输出单价为 b 元每百万 token则单任务模型成本约等于 0.032a 0.004b。如果 a 取 2、b 取 8结果约是 0.096 元。这只是模型部分还要加工具调用和人工确认的成本。人工确认一次按分钟算如果一分钟人力成本是 1 元每任务确认一次就是 1 元这时候模型成本占比不到一成你在模型上抠那几分钱意义不大真正该优化的是确认次数。耗时也要算单步模型调用三到八秒工具调用一到五秒八步任务端到端大概四十到九十秒。这个量级适合异步任务不适合实时交互。如果你的场景要求三秒内出结果那就别做多步回到单次调用加检索。这个判断在方案评审阶段就该做掉不要等做完了才发现延迟不达标。6. 常见问题与排查技巧实录带了这么多项目问题类型就那么几种整理成表遇到时对着查会快很多。6.1 典型问题速查表现象最可能原因排查动作处理方式步数跑满还没结果目标描述含糊或工具能力不匹配看轨迹里重复出现的动作补目标约束或补一个能推进的工具反复调同一个工具工具返回信息不足模型以为没成功检查返回是否有明确成功标识返回里加status字段明确成败结果时好时坏上下文顺序或长度不稳定对比成功与失败样本的上下文长度固定拼装顺序设长度上限成本突然飙升出现循环或上下文膨胀看单任务 token 分布加双上限截断长返回写操作重复执行非幂等动作被自动重试核对工具幂等标记改为先查后写或强制确认长文档后半段被忽略关键信息位置太靠前或被截断检查是否触发截断用检索分段关键内容放末尾换模型后效果下降对结构化输出的遵循度不同跑一遍回归集加强输出格式约束或回滚这张表里我最想强调的是“反复调同一个工具”那一条。这个问题极其常见根源往往不在模型而在工具设计——工具返回了一个模糊的成功提示模型没法判断到底成没成只能再试一次。解决办法很土所有工具返回必须带一个明确的状态字段成功、失败、部分成功再带一句人话描述。改完之后这类循环基本消失。6.2 几个踩过的坑第一个坑是上下文越长越好。早期我总觉得多给信息没坏处实测下来完全不是。上下文超过一定长度后模型对中间部分的利用率明显下降还容易被无关信息带偏。后来我定了个规矩每一段上下文进来都要能回答“它支撑哪个判断”答不上来就删掉。这条规矩执行之后效果和成本同时改善。第二个坑是没有区分“模型说失败”和“工具真失败”。模型有时候会误判工具返回说“执行失败”然后重试实际工具已经成功了。解决办法是让工具返回结构化的状态码并且让模型在做判断前先读状态码而不是读自然语言描述。自然语言描述留给最终答复用判断逻辑一律走结构化字段。第三个坑是评测集和线上分布不一致。我做过一个抽取任务离线评测准确率九成多上线后掉到七成。查了两天才发现评测集是我自己挑的规范样本线上来的数据里有大量格式混乱的历史数据。后来我强制要求评测集从线上真实流量里抽而且必须包含至少两成的“脏数据”。这条现在写进了我们的上线检查清单。第四个坑是忽略了工具本身的延迟波动。有一次任务超时率突然上升模型侧毫无变化最后定位到某个依赖系统的响应时间在高峰期翻了三倍把整个链路拖垮了。处理方式是给每个工具单独设超时并且设一个熔断连续失败就快速跳过不要让一个慢工具拖死整个任务。第五个坑是人工确认做得太重。一开始我把确认点设得很密结果人比原来还累用户直接弃用。后来改成只在不可逆的写操作上确认中间过程全自动接受度立刻上来了。这里的原则是确认点要少而关键不要多而琐碎。7. 把趋势和分级落到你自己的项目上说了这么多最后还是回到怎么用。我自己的做法是每年年初做一次“能力盘点”把手上所有需求按 L1 到 L3 分一遍看看有多少其实停在 L1 就够了有多少必须上 L3。盘完通常会发现真正需要复杂智能体的需求少得可怜大部分需求是一个好的检索加一次结构化输出就能解决的。这个结论每年都成立说明趋势再热落到具体业务上还是那几件朴素的事把任务定义清楚、把上下文管好、把工具设计规范、把验收做扎实。另外分享一个我一直在用的小技巧任何新项目先花半天时间搭一个只有三个工具的 L2 最小闭环跑十个真实任务看轨迹。这半天的投入能帮你提前发现八成以上的架构问题比写二十页方案有用得多。轨迹里那些多余的步骤、误解的返回、绕远的路径都是最真实的设计反馈。至于那些趋势我的态度一直是关注但不追。技术侧的变化决定你能做什么工程侧的变化决定你能交付什么而绝大多数人的瓶颈在后半段。把循环控住、把成本算清、把轨迹留住、把验收做实这四件事做到位2025 年这些趋势不管往哪边走你都不会掉队。