经常访问的一个金融投资专家在展望2026年时提到： 2026年目前在预期的元年，

• 自动驾驶元年
• 液冷元年
• 国产HBM元年
• 端侧AI元年
• 固态电池元年
• AI应用元年
• 量子计算元年
• 存算一体芯片商用元年
• 类脑计算元年
• 低空经济元年
• 商业航天元年
• 人型机器人元年
• 硅光元年
• 可控核聚变元年

总之就是各种元年，让人眼花缭乱，股民又有很多知识要恶补了。当然了，我肯定不是来科普上述概念的，作为我最关注的人工智能领域，在过去的2025年其实也有不少新的元年，我借此也尝试总结几个本人感兴趣的点。

一、推理（Reasoning）元年

2024年9月，OpenAI凭借o1与o1-mini模型，正式开启了一场以“推理”为核心的革命——这场革命也被称为推理规模扩展（inference-scaling），或**基于可验证奖励的强化学习（RLVR）**革命。2025年初，该公司又推出o3、o3-mini及o4-mini模型，进一步加码这一技术方向。自此，推理能力几乎成为所有主流AI实验室模型的标志性特征。对这一技术突破重要性的理解，我们来看看安德烈·卡帕西（Andrej Karpathy）的解释：

通过在多个环境中（例如数学题/代码谜题），利用自动可验证的奖励对大语言模型（LLM）进行训练，模型会自发形成人类眼中类似“推理”的策略——它们学会将问题拆解为中间计算步骤，还掌握了多种反复推敲以解决问题的策略（相关案例可参考 DeepSeek R1 论文）。

实践证明，RLVR 训练具备极高的性价比（能力/成本比），这也消耗了原本计划用于预训练的大量计算资源。因此，2025年大语言模型的能力进步，很大程度上取决于各实验室对这一新阶段技术红利的挖掘。总体来看，2025年的模型规模与此前相近，但 RL（强化学习）的训练时长大幅增加。

2025年，所有知名 AI 实验室至少都发布了一款推理模型。部分实验室推出了支持推理/非推理双模式的混合模型。如今，许多API模型都配备了调节旋钮，可针对特定提示词调整推理的深度。而推理能力真正的突破，在于工具调用。具备工具调用能力的推理模型，能够规划多步骤任务、执行任务，并基于结果持续推理，从而更新计划以更好地达成目标。一个显著成果是，AI辅助搜索如今真正可用。此前，将搜索引擎与大语言模型对接的效果一直不尽如人意，但现在，即便是更复杂的研究问题，我也常常能通过ChatGPT中的“GPT-5思考模式”得到解答。推理模型在代码生成与调试方面也表现卓越。推理机制让模型能够从一个错误出发，逐步排查代码库的多个层级，定位问题根源。我发现，只要推理模型具备读取和执行代码的能力，即便是面对庞大复杂的代码库，最棘手的漏洞也能被优秀的推理模型诊断出来。

二、智能体（AI agents）元年

当推理能力与工具调用能力相结合，你将得到智能体（AI agents）。这一点尤其让我兴奋。过去AI更像是写手或顾问，现在它正成为能动手的“行动者”。智能体AI不仅能告诉你该怎么做，还能自己执行——触发工作流、调用API、操作软件。

整个2025年，所有人都在谈论智能体，每个使用“智能体”这个术语的人，给出的定义似乎都略有不同。在我看来，智能体就是一种通过循环调用工具来达成目标的大语言模型（LLM）系统。智能体的两大突破性应用领域是编码和搜索。深度研究模式，即让大语言模型负责收集信息，耗时15分钟以上为你生成一份详细报告，在今年也风靡一时。我就曾尝试用豆包研究过一个学术课题，确实可以写出一份有模有样的研究报告，但是很多细节需要优化，比如引用地址的时效性等问题。GPT-5的思考模式也是一种智能体模式，而且运作效果也很不错。

三、编码智能体（coding agents）元年

2025年最具影响力的事件发生在2月 ——Anthropic 低调发布了 Claude Code。说它低调，是因为它甚至没有单独的博客文章！Anthropic将Claude Code的发布，作为其宣布Claude 3.7 Sonnet的博客文章中的第二项内容。Claude Code是我所说的编码智能体最典型的例子，这类大语言模型系统能够编写代码、执行代码、检查结果，然后进一步迭代优化。2025年，各大实验室都推出了自己的命令行界面（CLI）编码智能体：Claude Code、Codex CLI、Gemini CLI、通义千问代码（Qwen Code）、Mistral Vibe，独立于厂商的选项包括GitHub Copilot CLI、Amp、OpenCode、OpenHands CLI 和 Pi。Zed、VS Code 和 Cursor 等集成开发环境（IDE）也在编码智能体的集成方面投入了大量精力。

我第一次接触编码智能体模式，还是下半年自己写的一个小项目：不用任何复杂的前端框架（如react），用纯html+css+js的模式，去定制一个企业网站。最大的难点就是设计稿要求精准还原，并且需要有各种动效。当然了，我肯定不是精通前端的人，顶多算个了解前端，css更只是略知一二。我Cursor和Trae都用了，最终因为费用等问题，还是选择了Trae。用过后只想说：以前做不了的项目，现在确实轻松，除了要珍惜自己的使用额度外，其他没毛病。最大的难点反而是一开始的官网设计图怎么转成html代码，figma make用了下，效果也不是很好。

四、氛围编程（vibe coding）元年

今年2月，安德烈・卡帕西（Andrej Karpathy）在一条推文中创造了 “氛围编程”（vibe coding）这个术语：

我发现了一种全新的编程方式，称之为 “氛围编程”。在这种模式下，你完全沉浸于氛围之中，拥抱指数级提升的效率，甚至可以忘掉代码本身的存在。这种方式之所以可行，是因为大语言模型（比如搭载Sonnet模型的 Cursor Composer）已经变得过于强大。我现在还会用SuperWhisper和Composer语音交互，几乎不用碰键盘。我会提一些极其琐碎的需求，比如 “把侧边栏的内边距减少一半”，因为我懒得自己去找对应的代码。我总是直接 “全部接受” 模型生成的内容，再也不看代码差异对比了。遇到错误提示时，我直接复制粘贴过去，不加任何说明，通常这样就能解决问题。代码的复杂程度已经超出了我平时的理解范围，要搞懂它得花不少时间仔细研读。有时候模型修不好bug，我就换种方式绕开，或者让它随机修改，直到问题消失。这种方式用来做周末随手的一次性项目还不错，而且过程特别有意思。我确实在做一个项目或网页应用，但这已经算不上真正的编程了。我只是看看效果、说说话、运行一下程序，再复制粘贴点东西，大部分时候都能正常工作。

vibe coding的一个本质，就是让人去做最擅长的事：创造和判断。让AI去做最擅长的事：执行和实现。但我们需要具备的关键能力就是有清晰的产品思维，有要会判断代码质量，要善于表达需求，要懂得去快速迭代。

我个人实践的感受是，AI IDE确实好用，但是我预感方案比较麻烦时，会先让AI提出编程方案，而不是让AI立刻修改编辑文件。等我审核通过后，再让AI修改，或者自己修改细节敲上去。因为不止一次AI把我的代码完全搞砸了，也许当下要求AI的这个功能有完成，但是他可能会为了完成当下的功能而破坏到现有的其他代码。特别是那些堆栈调用较深的，排查修复起来真是要老命，一旦你全权交给AI，奔溃的时候就是你说东他说西连环bug套。同时，大型工程的话，对上下文的理解还是不够。十几年的屎山项目动不动就是几百万行代码…AI不太能搞定，写个轻应用或者小模块倒是问题不大。

五、MCP元年

2024年11月，Anthropic推出了 模型上下文协议（Model Context Protocol，MCP） 规范，将其作为一种用于在不同大语言模型（LLM）中集成工具调用的开放标准。2025年初，该协议的受欢迎程度呈爆发式增长。5月曾出现这样一个节点：OpenAI、Anthropic和Mistral三家公司在短短八天内，相继推出了对MCP的API级支持！MCP不仅仅是AI的“USB-C接口”，而是一个从根本上重构AI应用架构，具有良好的可插拔性、可发现性和可组合性，推动AI从Chatbot迈向智能体时代的范式转变协议。但其极高的采用率却让我颇感意外。我认为这归根结底是时机问题：MCP 的发布恰逢模型终于在工具调用方面变得成熟可靠，以至于许多人似乎将对MCP的支持误认为是模型使用工具的先决条件。

自从我深度使用Trae及同类工具后，就没怎么使用MCP了。Anthropic自身似乎也在今年晚些时候意识到了这一点，推出了出色的Skills（技能）机制。MCP涉及Web服务器和复杂的JSON负载，而一个Skill只是文件夹中的一个Markdown文件，还可选择性地附带一些可执行脚本。随后在11月，Anthropic发布了《通过 MCP 执行代码：构建更高效的智能体》。文中描述了一种让编码智能体生成代码来调用MCP的方式，这种方式规避了原始规范带来的大量上下文开销。

12月初，MCP被捐赠给了新成立的智能体人工智能基金会（Agentic AI Foundation）。

六、上下文工程元年

上下文工程（context engineering）这一术语近来开始受到关注，被视为提示工程（prompt engineering）更优的替代概念。

以下是Shopify首席执行官托比・吕特克（Tobi Lutke）发布的一条相关推文示例：

相比 “提示工程”，我更喜欢 “上下文工程” 这个说法。它更准确地描述了这项核心技能：为任务提供所有必要语境，使大语言模型（LLM）具备合理解决该任务的能力，这是一门艺术。

近期，安德烈・卡帕西（Andrej Karpathy）也进一步强调了这一观点：

强烈支持用 “上下文工程” 取代 “提示工程”。人们通常将 “提示” 与日常使用大语言模型时给出的简短任务描述联系在一起。但在所有工业级大语言模型应用中，上下文工程是一门精妙的艺术与科学，它需要在语境窗口中，为下一步操作填充恰到好处的信息。说它是科学，是因为做好这件事需要涵盖任务描述与说明、少样本示例、检索增强生成（RAG）、相关（可能是多模态的）数据、工具、状态与历史记录、信息压缩…… 要做好这些工作难度极大。说它是艺术，则是因为这需要凭借对大语言模型 “心智模式” 的直觉判断来指导实践……

常见的上下文工程的方法有：offload（转移策略）、reduce（压缩策略）、retrieve（检索策略）、isolate（隔离策略）、cache（缓存的机制）等。

七、合成数据元年

AI再聪明也得“吃饭”，但2025年高质量互联网数据已接近见底，清理成本也越来越高。于是，合成数据成了战略武器——用模型自己生成的数据，再去训练模型。

微软的SYNTHLLM框架等项目已证明，只要设计得当，合成数据完全能支持大规模训练。更大的模型不一定需要更多数据，数据集可以按需调优，不再盲目追求“多多益善”。数据从此进入“定制养殖”时代。

八、量化幻觉元年

还记得2024年纽约律师用ChatGPT编案例结果翻车的事吗？过去大家把AI幻觉看作一种“小脾气”，不行就重试。但现在，厂商把它当作可测量、可优化的工程指标。

RAG（检索增强生成）几乎成了标配，让AI“先查证，再说话”。还出现了专门测试集，比如RGB与RAGTruth，用于量化幻觉率。虽然无法100%消除，但治理思路已从“凭经验调”转向“用数据治”，方向对了。