AI 近期思考：从 Codex 到 Agent 自我进化

最近几个月，AI 的变化速度明显加快了。不是那种「又出了一个新模型」的加快，而是我们对「AI 能做什么」的认知边界在被不断推开。

我想把最近的观察整理成五个判断，每个都对应一个正在发生的趋势。

一、「把同一件事做快一点」 VS 「我们做了以前根本不可能去碰的事情」

OpenAI Codex 的产品负责人 Rohan Varma 在今年 2 月的 20VC 播客中提出了一个很锐利的框架：

「把同一件事做快一点」（doing the same thing faster） VS 「我们做了以前根本不可能去碰的事情」（doing things that were previously impossible）

这个区分之所以重要，是因为它揭示了当前 AI 产品的两个阵营：

效率派：用 AI 让已有的工作流更快。Copilot 补全代码、AI 润色文档、自动生成周报——这些都在这个象限。价值是线性的，省时间就是省成本。
可能派：用 AI 去碰以前根本不敢想的事。让 Agent 自主完成一个完整的功能开发、让模型通过纯强化学习涌现出推理能力、让非程序员能从零搭建硬件产品——这些是以前「不可能」的。

我自己的体感

这个框架放在我身上特别有说服力。

以前我做的事情：写代码时等 Copilot 补全下一行、用 ChatGPT 润色一段文字、让 AI 帮我总结一篇论文。这些是「做快一点」。

现在我开始做的事情：

自己动手做硬件——我用 ESP32 + 称重传感器做了一个智能水杯秤，用 Orange Pi + ESP32 做了一个跑 Agent 的桌面宠物。以前这些需要嵌入式工程师的背景，现在 AI 帮我查引脚定义、写驱动代码、调试通信协议。我不是「更快地完成了硬件开发」，我是一个软件工程师开始做硬件了——这件事以前不在我的可能性集合里。
自己动手训练/微调模型——以前训练模型是算力大厂的事。现在有了 DeepSeek-R1 这样的开源推理模型，加上各种开源工具链，个人开发者可以基于开源模型做领域适配、做蒸馏、做自己的 Agent 系统。这件事的成本门槛在指数级下降。

Rohan Varma 在那期播客里说的核心观点就是：Codex 不是让你写代码更快，而是改变你对「什么可以被自动化」的认知。当智能的成本趋近于零，限制你的不再是「这要花多少时间」，而是「你敢不敢想象这件事可以被完成」。

二、Agent 应该走向自我进化

如果把 Agent 比作我们派出去的员工，那现在的管理方式是很原始的。

你给 Agent 一个任务，它去执行，成功了或失败了，然后呢？没有然后。下一个任务来，它可能犯一模一样的错误。

但真正的员工不是这样工作的。好的团队每天有站会、每周有复盘，看看哪里出了问题、哪些能力需要补强、哪些流程需要优化。Agent 也应该这样。

和梁文锋的思路不谋而合

DeepSeek 创始人梁文锋在近期的内部沟通中提到了类似的思路：大模型未来是要自我迭代的。

这不是空谈。DeepSeek-R1 已经在技术上验证了这个方向。根据 DeepSeek-R1 技术报告（arXiv:2501.12948），他们做的最关键的一件事是：

直接对基础模型应用大规模强化学习（RL），无需依赖监督微调（SFT）作为前置步骤。

这意味着什么？意味着模型不是在「模仿人类写的正确答案」，而是在自己探索解题路径。在这个过程中，DeepSeek-R1-Zero 自然涌现出了自验证（self-verification）、反思（reflection）、生成长链思维（long CoT）等能力。

这是第一次有研究证明：LLM 的推理能力可以纯粹通过 RL 来激励，不需要 SFT。

把这个思路迁移到 Agent 层面：

传统 Agent	自我进化 Agent
任务失败就结束了	失败后自动分析原因
每次从零开始	积累经验，越用越强
能力由开发者预设	通过反馈循环发现新能力
错误重复出现	错误被记录并避免

每天给 Agent 开日会

我在实际使用 pi（我的 AI 编程助手）的过程中，越来越强烈地感受到这个需求。理想的状态应该是：

晨间同步：Agent 汇报昨天完成了什么、遇到了什么阻塞、发现了什么可优化的模式
错误复盘：系统性地归类失败案例——是上下文理解错了？是工具调用参数错了？还是目标本身就不明确？
能力规划：根据错误模式，主动建议需要新增的工具/Skill/知识源

这不仅仅是工程问题，更是一个产品设计问题：如何让 Agent 的使用者感知到 Agent 在变聪明？

三、所以目前很多模型厂商，其实都在追求模型的编码能力

如果你仔细观察过去半年各大模型厂商的发布会，会发现一个明显的趋势：所有人都在卷编码能力。

为什么？因为编码能力是 AGI 的「必修课」，也是最容易量化的竞技场。

SWE-bench 成为新战场

SWE-bench（Software Engineering Benchmark）已经成为衡量 AI 编码能力的标准答案。这个 benchmark 让 AI 去 GitHub 的真实 issue 里修 bug，而不是做简单的代码补全。最新的排行榜上：

OpenAI Codex 专门为自主编程设计
Claude 3.5/4 系列在编码任务上持续领先
DeepSeek-R1 及其蒸馏系列在开源模型中表现突出
国内各家（通义、智谱、月之暗面 Kimi-Dev）都在发力编码

编码能力 = 通用问题解决能力的代理指标

模型厂商疯狂追求编码能力，背后有一个隐含逻辑：编码能力是通用智能的最佳代理指标。

原因很简单：

编码需要理解复杂的需求（语言理解）
需要规划实现步骤（推理和规划）
需要调试和纠错（自我修正）
需要调用 API 和工具（工具使用）
需要处理多文件依赖（长上下文管理）

如果一个模型能把代码写好，它大概率也能做好其他需要结构化思维的任务。 这就是为什么编码能力成为兵家必争之地。

更深一层的原因是：代码是可以自动验证的。写出来的代码能不能跑、测试过不过、bug 修没修好——这些都是客观标准，不像聊天对话那样主观。这让编码能力成为一个「无法造假」的竞争维度。

四、大模型的变化：升级带来的降维打击

这是我最想提醒大家注意的一点：模型升级带来的不是线性提升，而是降维打击。

越聪明的模型，越少的约束

我观察到的一个规律是：

模型时代	Prompt 工程的复杂度	约束数量
GPT-3.5 时代	极高，需要精心设计 few-shot、CoT 提示	大量
GPT-4 时代	中等，基本指令+少量示例即可	中等
o1 / Claude 3.5+ 时代	低，简单描述需求就能理解	较少
当前前沿模型	极低，甚至「说人话」就行	最少

越强大的模型，越不需要你教它怎么做事。 你只需要说清楚「做什么」，它会自己搞定「怎么做」。

但这带来一个问题：你为旧模型精心设计的 prompt 和 workflow，在新模型面前可能不仅多余，甚至有害。

需要经常更新能力和 Prompt

我自己的体会是：每当有重大模型更新，都需要重新审视之前沉淀下来的东西：

Prompt 模板：以前需要详细的角色设定和输出格式约束，现在可能只需要一句话
Workflow 设计：以前需要把任务拆得很细才能保证质量，现在可以给更大的自主权
Skill / Tool 的设计粒度：以前需要把工具做得很小很专，现在可以给更通用的工具让模型自己组合
评估标准：以前模型能达到 60 分就算不错，现在 90 分才是及格线

这就是「降维打击」的意思：不是你的 Agent 变强了，是你对 Agent 的预期基准被整体抬高了。 以前觉得惊艳的能力变成了 baseline，以前觉得不可能的事情变成了理所当然。

一个具体的例子

以我博客的构建系统为例。早期我用 AI 帮忙写文章时，需要给它非常详细的 outline、每段的要点、甚至示例句式。现在？我只需要丢给它五个 bullet point，它就能生成一篇结构完整的初稿。不是我变懒了，是模型的理解能力跨过了某个阈值。

但反过来，如果我还在用早期的「详细 outline + 要点约束」方式去使用新模型，反而会限制它的发挥——相当于拿开 F1 赛车的限速器当卡丁车开。

五、不断扩展自己的能力：从回答问题到作用于真实世界

最后这一点是我最兴奋的：AI 的能力边界正在从一个「问答机器」变成一个「能作用于真实世界的系统」。

这条进化路径非常清晰：

Stage 1：Function Call —— 「帮我查一下天气」

最早的扩展是 Function Calling（函数调用）。模型不再只能生成文字，还能调用你预先定义好的函数。

OpenAI 在 2023 年 6 月推出 Function Calling 功能，让模型可以结构化地调用外部工具。但它的局限很明显：所有能力都要提前定义，每次新增能力都要改代码。

Stage 2：MCP —— 「连接一切」

2024 年 11 月，Anthropic 开源了 Model Context Protocol (MCP)。

MCP 的核心理念是：不要为每个数据源写定制集成，用一个统一协议连接所有东西。就像 USB-C 取代了各种专用接口一样，MCP 想取代各种自定义的 AI 工具集成。

"Even the most sophisticated models are constrained by their isolation from data—trapped behind information silos and legacy systems." —— Anthropic MCP Announcement

现在已经有大量 MCP Server 实现：Google Drive、Slack、GitHub、Postgres、Puppeteer……以及各种社区贡献的工具。

Stage 3：Skills —— 「专业能力包」

Skills 是在 MCP 之上的进一步抽象。如果说 MCP 解决的是「连接」问题，Skills 解决的是**「专业能力」的封装和复用**。

一个 Skill 不只是一个 API 调用，它包含：

领域知识：特定领域的专业信息和最佳实践
工具链：该领域常用的工具和操作流程
交互模式：针对这类任务的典型对话模式和决策逻辑
质量标准：什么样的输出算是「做好了」

比如我现在使用的 pi 编程助手就有 Skills 体系：business-consult（读代码翻译业务逻辑）、oct（数仓查询）、fengniao（企业数据查询）等等。每个 Skill 都是把一个专业领域的能力打包成了 Agent 可以调用的模块。

Stage 4：CLI / Shell —— 「控制系统」

当 Agent 不仅能调用 API，还能直接操作 shell 命令，它就获得了对操作系统的完整控制权。

这意味着它可以：

安装软件包、配置环境
git 操作、CI/CD 流程
运行测试、查看日志
管理服务器、部署应用

这是从「虚拟世界」到「真实计算环境」的关键一步。 很多编程 Agent（如 OpenAI Codex、Devin、Cursor 等）的核心能力就建立在 shell 操作之上。

Stage 5：Real World —— 「物理世界」

这是我正在探索的方向，也是前面提到的桌面宠物项目的意义所在。

当 Agent 有了 CLI 能力之后，下一步自然就是控制物理设备：

通过 GPIO 控制传感器和执行器
通过串口/I2C/SPI 与硬件通信
通过网络控制 IoT 设备
最终形成一个「数字-物理」闭环

我的 Orange Pi 桌面宠物就是一个实验：Agent 不再只活在终端里，它有一块屏幕可以显示表情、有一个麦克风可以听见声音、将来还可以有电机做出动作。它在物理世界里占据了一个位置。

从回答问题到改变现实

回顾这条路径：

阶段	能力范围	交互对象
纯文本生成	回答问题	用户
Function Call	调用预定义功能	开发者预设的系统
MCP	连接任意数据源	企业系统和互联网
Skills	专业领域自治	特定领域的知识和工具
CLI / Shell	完整计算控制	操作系统和服务器
物理世界	改变现实状态	传感器、执行器、IoT 设备

AI 正在从一个「聊天机器人」变成一个「能干活的存在」。 这个转变比大多数人意识到的要深远得多。

总结

把这五个判断放在一起看，我会说：我们正处在一个拐点。

不是技术拐点——那些 GPT-4、Claude、DeepSeek 的发布已经是历史了。而是认知拐点：越来越多的人开始意识到，AI 的价值不在于「替代人力」，而在于扩大人类「可能」的边界。

从「做快一点」到「做不可能的事」——价值判断的坐标轴变了
从「一次性任务」到「自我进化的员工」——对 Agent 的期待变了
从「通用聊天」到「编码为王」——模型竞争的焦点变了
从「精心调教」到「越聪明越简单」——使用方式变了
from answering questions to acting on the real world — capability boundary changed

最后，我想引用 Rohan Varma 在那期播客里反复强调的一个观点作为结尾：

The cost of intelligence is declining exponentially. （智能的成本正在指数级下降。）

当智能变得几乎免费，真正稀缺的不是算力、不是数据、不是算法，而是想象力——你敢不敢想象，接下来哪件「不可能的事」会变成你的日常？

参考资料

Rohan Varma (OpenAI Codex PM), 20VC Podcast: Why the Cost of Intelligence is Declining Exponentially, Feb 2025
DeepSeek-AI, DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning (arXiv:2501.12948), Jan 2025
梁文锋 / DeepSeek 团队，内部沟通与融资相关会议（来源：小红书），2025
Anthropic, Introducing the Model Context Protocol, Nov 2024
SWE-bench Official Leaderboard
OpenAI, Function Calling and Other API Updates, Jun 2023