企业官网建设流程全解析

2025 年人工智能十大趋势和 AI 智能体级别这两个词，最近在各种场合被反复提起。上周还有个做企业内训的朋友问我，能不能用一页纸讲明白今年到底该往哪儿投人、投钱、投时间。我当时的回答是：趋势清单本身不值钱，值钱的是你拿什么判据去判断哪一条跟你有关；同样，智能体分级也不是拿来贴标签的，而是拿来定验收标准的。这篇就按这个思路，把 2025 年人工智能十大趋势拆开来讲，同时把我自己在项目里一直在用的 AI 智能体级别划分方法、每一级的判定标准、最小可运行代码、参数预算公式和踩过的坑，一次性摊开说清楚。不管你是刚接触大模型的业务同学，还是已经在写推理服务链路的工程同学，看完之后至少能做到两件事：知道今年哪些方向是真变化、哪些是旧瓶装新酒；知道手里的项目该做成第几级智能体，以及第几级到底怎么验收。

1. 先把趋势清单和智能体分级这两件事说清楚

很多人对趋势类内容有天然的反感，觉得是玄学。我部分同意，但有一个前提得先讲清楚：趋势的价值不在于预测未来，而在于帮你做减法。一年下来新技术名词几百个，你真正能落地的可能就两三个，趋势清单的作用是把噪音过滤掉，让你把注意力压在少数几个会持续投入的方向上。所以我讲趋势，不会讲“某技术将改变世界”，而是讲“这条趋势落地之后，工程上的做法会发生什么变化，你要补什么能力”。

1.1 为什么今年要换个读法

过去两年看趋势，大家习惯盯模型榜单。榜单第一换人了，就代表方向变了。2025 年这个逻辑基本失效了，原因很直接：头部模型之间的差距在日常任务上已经被压缩得很小，你再花大力气去追那零点几个百分点的差距，投入产出比非常差。真正拉开差距的地方挪到了模型之外——上下文怎么组织、工具怎么接、失败怎么恢复、成本怎么控、结果怎么验。

我自己内部做技术选型时有一个很土的办法，叫“三层过滤”。第一层问：这条趋势是不是改变了我的输入输出形态，比如从纯文本变成多模态输入输出，这属于形态变化，必须跟。第二层问：是不是改变了我的系统结构，比如从单次调用变成一个带循环的执行体，这属于架构变化，得评估。第三层问：是不是只改变了参数和配置，比如换个量化精度、调个温度值，这种就归到日常优化，不值得单独开会讨论。用这个过滤器过一遍，十条趋势里真正需要动手的通常不超过四条，剩下的都是背景信息。这个习惯我建议你也养成，能省掉大量无效的技术焦虑。

1.2 智能体级别的划分逻辑与判据

说完趋势怎么读，再说分级。市面上讲智能体分级的内容不少，多数是从“自主性”这一个维度去分，我觉得不够用。自主性高不等于好用，一个完全放飞、什么都能自己决定但结果不可复现的智能体，在企业里基本没人敢用。所以我习惯用六个维度一起判：单次任务的最大自主步数、可调用工具的数量与危险等级、失败后的自恢复能力、记忆的跨会话跨度、人工介入的频率与位置、结果的验收方式。这六个维度组合起来，才能描述一个智能体到底成熟到什么程度。

我用的一张分级表大致是这样，需要说明的是，这套划分是我在多个项目里迭代出来的内部工具，不是任何官方标准，你完全可以按自己的业务改权重：

这张表最有用的一列其实是最后一列“验收方式”。级别越高，你越不可能靠人肉读结果来判断对错，必须提前把断言、回归集、看板、审计做出来。换句话说，级别不是能力标签，是验收成本标签。你想升到 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 再加记忆层和子任务调度。

关键参数我列几个常用的经验值，供你起步时参考，具体要按业务调：

这些数字不是拍脑袋来的，都是我在项目里被事故教育之后定下来的保守值。起步阶段宁可设紧一点，跑顺了再逐步放宽，反过来会很痛苦，因为你不知道放宽之后哪一步会失控。

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_factory=dict) 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_hook=None): 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_ascii=False)[: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 典型问题速查表

这张表里我最想强调的是“反复调同一个工具”那一条。这个问题极其常见，根源往往不在模型，而在工具设计——工具返回了一个模糊的成功提示，模型没法判断到底成没成，只能再试一次。解决办法很土：所有工具返回必须带一个明确的状态字段，成功、失败、部分成功，再带一句人话描述。改完之后这类循环基本消失。

6.2 几个踩过的坑

第一个坑是上下文越长越好。早期我总觉得多给信息没坏处，实测下来完全不是。上下文超过一定长度后，模型对中间部分的利用率明显下降，还容易被无关信息带偏。后来我定了个规矩：每一段上下文进来都要能回答“它支撑哪个判断”，答不上来就删掉。这条规矩执行之后，效果和成本同时改善。

第二个坑是没有区分“模型说失败”和“工具真失败”。模型有时候会误判工具返回，说“执行失败”然后重试，实际工具已经成功了。解决办法是让工具返回结构化的状态码，并且让模型在做判断前先读状态码，而不是读自然语言描述。自然语言描述留给最终答复用，判断逻辑一律走结构化字段。

第三个坑是评测集和线上分布不一致。我做过一个抽取任务，离线评测准确率九成多，上线后掉到七成。查了两天才发现，评测集是我自己挑的规范样本，线上来的数据里有大量格式混乱的历史数据。后来我强制要求评测集从线上真实流量里抽，而且必须包含至少两成的“脏数据”。这条现在写进了我们的上线检查清单。

第四个坑是忽略了工具本身的延迟波动。有一次任务超时率突然上升，模型侧毫无变化，最后定位到某个依赖系统的响应时间在高峰期翻了三倍，把整个链路拖垮了。处理方式是给每个工具单独设超时，并且设一个熔断，连续失败就快速跳过，不要让一个慢工具拖死整个任务。

第五个坑是人工确认做得太重。一开始我把确认点设得很密，结果人比原来还累，用户直接弃用。后来改成只在不可逆的写操作上确认，中间过程全自动，接受度立刻上来了。这里的原则是：确认点要少而关键，不要多而琐碎。

7. 把趋势和分级落到你自己的项目上

说了这么多，最后还是回到怎么用。我自己的做法是每年年初做一次“能力盘点”：把手上所有需求按 L1 到 L3 分一遍，看看有多少其实停在 L1 就够了，有多少必须上 L3。盘完通常会发现，真正需要复杂智能体的需求少得可怜，大部分需求是一个好的检索加一次结构化输出就能解决的。这个结论每年都成立，说明趋势再热，落到具体业务上还是那几件朴素的事：把任务定义清楚、把上下文管好、把工具设计规范、把验收做扎实。

另外分享一个我一直在用的小技巧：任何新项目，先花半天时间搭一个只有三个工具的 L2 最小闭环，跑十个真实任务，看轨迹。这半天的投入能帮你提前发现八成以上的架构问题，比写二十页方案有用得多。轨迹里那些多余的步骤、误解的返回、绕远的路径，都是最真实的设计反馈。

至于那些趋势，我的态度一直是：关注，但不追。技术侧的变化决定你能做什么，工程侧的变化决定你能交付什么，而绝大多数人的瓶颈在后半段。把循环控住、把成本算清、把轨迹留住、把验收做实，这四件事做到位，2025 年这些趋势不管往哪边走，你都不会掉队。