一文搞懂Agentic AI：从ReAct到MCP的Agent架构演进
一句话理解
Agentic AI 就是让大模型从"只会聊天"进化为"能干活"——它不再只是回答问题，而是自主规划、调用工具、执行任务，直到目标完成。
为什么重要
2026年，Agentic AI已经成为AI行业最确定的方向。Google I/O 2026的主题就是"智能体Gemini时代"，Sundar Pichai在Keynote上反复强调的不再是模型参数量，而是"Agent能做什么"。
为什么整个行业都在转向Agent？因为对话式AI的天花板已经触到了——
- 用户不需要一个更会聊天的AI，需要一个能干活的AI。当你让ChatGPT帮你订机票，它只能告诉你"你可以去携程搜索"，而不能直接帮你完成。
- 企业落地的核心诉求是自动化。不是让员工跟AI对话，而是让AI把流程跑通。
- 模型能力的溢出。GPT-5、Gemini Ultra、Claude Opus 4的推理能力已经远超"对话"这个场景所需，它们需要更大的舞台。
从Chatbot → Copilot → Agent，这是一条清晰的演进路径。而这条路径的技术底座，正是本文要拆解的从ReAct到MCP的架构演进。
核心原理
一、推理+行动循环：ReAct框架
ReAct（Reasoning + Acting）是Agent架构的基石，由Yao et al.在2022年提出。核心思想极其简单：让模型在"思考"和"行动"之间交替循环。
传统对话式AI的模式是：
用户提问 → 模型生成回答 → 结束
ReAct的模式是：
用户提问 → 思考(Thought) → 行动(Action) → 观察(Observation) → 思考 → 行动 → ... → 最终回答
举个具体例子。用户问："北京今天适合户外运动吗？"
纯对话模式：模型基于训练数据猜测"北京5月通常……"，回答不一定准确。
ReAct模式：
- Thought：我需要先查北京今天的天气
- Action：调用天气API查询北京天气
- Observation：北京今天晴，气温28°C，AQI 45
- Thought：天气晴朗、空气质量优、温度适宜，适合户外运动
- Answer：北京今天非常适合户外运动！晴天、28°C、空气质量优秀
关键区别在于——ReAct让模型从"我觉得"变成了"我查了"。这不是一个微小的改进，而是从"信口开河"到"有据可查"的质变。
ReAct的循环有一个隐含但至关重要的机制：停止条件。模型需要在每一步判断——我有足够信息回答了吗？如果够了就停止，不够就继续。这看似简单，但实际工程中，控制Agent不陷入死循环是最难的问题之一。
二、工具调用与规划：从Function Calling到Tree of Thoughts
如果说ReAct定义了Agent的循环骨架，那么工具调用和规划能力就是Agent的血肉。
Function Calling：Agent的手
Function Calling（也叫Tool Use）让模型能够调用外部工具。这不是简单的"文本生成"，而是模型学会了输出结构化的工具调用指令。
// 模型输出不是自然语言，而是结构化的工具调用
{
"name": "search_weather",
"arguments": {
"city": "北京",
"date": "2026-05-20"
}
}
Function Calling的工作流程：
用户输入 → 模型决定是否调用工具 → 生成工具调用JSON → 执行工具 →
将工具结果注入上下文 → 模型继续推理或生成最终回答
2026年的主流模型（GPT-5、Gemini Ultra、Claude Opus 4）都已原生支持Function Calling，准确率普遍在95%以上。但这并不意味着工程上很简单——工具描述的编写、参数校验、错误处理、超时重试，这些才是决定Agent能否稳定运行的关键。
Plan-and-Execute：先想后做
Plan-and-Execute是对ReAct的进化。ReAct是"边想边做"，而Plan-and-Execute是"先规划，再执行"。
用户："帮我筹备一场50人的技术分享会"
Plan阶段：
步骤1: 确定会议主题和日期
步骤2: 预订场地
步骤3: 发送邀请
步骤4: 准备物料
步骤5: 当天执行
Execute阶段：逐步执行每个步骤，遇到问题可调整计划
Plan-and-Execute的优势在于全局视野——ReAct容易陷入局部最优（当前步骤看起来合理但偏离最终目标），而先规划再执行能保证大方向正确。
Tree of Thoughts：深思熟虑
Tree of Thoughts（ToT）更进一步，它让模型在每一步探索多个可能的推理路径，然后评估每条路径的价值，选择最优路径继续探索。
问题
/ | \
路径A 路径B 路径C
/ \ | |
A1 A2 B1 C1
↓
选择A1继续...
ToT本质上是一种搜索算法（类似MCTS——蒙特卡洛树搜索），适用于需要深度推理的任务，如数学证明、复杂决策等。代价是计算成本大幅增加，所以实际工程中，简单任务用ReAct，中等任务用Plan-and-Execute，只有高难度任务才用ToT。
三、记忆与协议：从MCP到A2A
记忆系统：Agent的脑
没有记忆的Agent就像失忆症患者，每次对话都从零开始。完整的Agent记忆系统包含三层：
| 记忆类型 | 类比 | 实现方式 | 生命周期 |
|---|---|---|---|
| 短期记忆 | 工作记忆 | 当前对话的上下文窗口 | 单次会话 |
| 长期记忆 | 经验积累 | 向量数据库/知识图谱 | 跨会话持久化 |
| 工作记忆 | 便签纸 | Scratchpad/中间结果缓存 | 单次任务执行期间 |
短期记忆受限于上下文窗口长度。当对话过长时，需要上下文压缩或滑动窗口策略。
长期记忆是Agent"成长"的关键。一个客服Agent处理过1000次工单后，应该能记住"用户A偏好邮件沟通"这类信息。通常用向量数据库（如Milvus、Chroma）存储历史交互的Embedding，推理时检索相关记忆注入上下文。
工作记忆则是执行复杂任务时的"草稿纸"——Agent在多步推理中产生的中间结果、待办清单、当前进度等。
MCP：标准化的工具协议
MCP（Model Context Protocol）是Anthropic在2024年底提出的开放协议，到2026年已成为事实标准。它解决的核心问题是——工具调用的碎片化。
在MCP之前，每个Agent框架都有自己的工具接入方式：
LangChain: Tool(name="xxx", func=xxx)
AutoGen: register_function(xxx)
CrewAI: @tool decorator
LlamaIndex: FunctionTool(xxx)
MCP定义了统一的工具描述和调用规范：
MCP Server（工具提供方）
↓ 标准协议
MCP Client（Agent）
一个MCP Server可以暴露三种能力：
- Resources：静态数据（如文件、数据库记录）
- Tools：可执行的操作（如API调用、代码执行）
- Prompts：预设的提示模板
MCP的价值不在于技术多复杂（协议本身很简洁），而在于生态效应——一旦工具提供方和Agent框架都遵循MCP，任何Agent都能使用任何工具，就像USB接口统一了外设连接一样。
A2A：多Agent协作协议
A2A（Agent-to-Agent）是Google在2025年提出的协议，解决的是另一个维度的问题——多个Agent之间如何协作。
单个Agent的能力有限，但一组Agent可以像团队一样分工合作：
用户请求 → 调度Agent → 拆解任务
↓
┌────────┬────────┬────────┐
↓ ↓ ↓ ↓
搜索Agent 代码Agent 数据Agent 文档Agent
↓ ↓ ↓ ↓
└────────┴────────┴────────┘
↓
汇总Agent → 最终结果
A2A定义了Agent之间发现、通信、协作的标准协议。一个Agent可以发布自己的能力卡片（Agent Card），其他Agent据此发现和调用它。
2026年最震撼的Agent案例都依赖多Agent架构：
- Gemini Spark：Google的24小时自主Agent，能持续执行复杂任务链，内部由多个子Agent协作
- Antigravity：93个子Agent构建的操作系统级别Agent，每个子Agent负责一个子系统（文件管理、网络通信、代码编辑等），通过A2A协议协调
Agent架构的3层模型
把上面的概念整合起来，一个完整的Agent架构可以抽象为3层：
┌─────────────────────────────────┐
│ 感知层 (Perception) │
│ 用户输入 / 环境信号 / 工具反馈 │
├─────────────────────────────────┤
│ 决策层 (Decision) │
│ LLM推理 + 规划(ReAct/ToT/P&E) │
│ + 记忆检索(短期/长期/工作记忆) │
├─────────────────────────────────┤
│ 执行层 (Execution) │
│ 工具调用(MCP) + Agent协作(A2A) │
│ + 动作执行 + 结果校验 │
└─────────────────────────────────┘
- 感知层：Agent的"五官"，接收外部信息。不只是用户输入，还包括工具返回结果、环境状态变化、其他Agent的消息等。
- 决策层：Agent的"大脑"，核心是LLM推理。结合ReAct循环、规划策略、记忆检索，决定下一步做什么。
- 执行层：Agent的"四肢"，通过MCP调用工具，通过A2A与其他Agent协作，执行具体动作并校验结果。
这3层不是静态的，而是一个动态循环：感知→决策→执行→感知（工具反馈）→决策→…… 直到任务完成。
代码示例：最小可运行ReAct Agent
下面用纯Python（无框架依赖）实现一个最简ReAct Agent，帮助你理解核心机制：
"""
最小可运行 ReAct Agent
依赖：pip install openai
仅使用OpenAI API，无LangChain/CrewAI等框架依赖
"""
import json
from openai import OpenAI
client = OpenAI() # 默认从环境变量 OPENAI_API_KEY 读取
# 定义可用工具
TOOLS = [
{
"type": "function",
"function": {
"name": "get_weather",
"description": "查询指定城市的天气信息",
"parameters": {
"type": "object",
"properties": {
"city": {"type": "string", "description": "城市名称"},
},
"required": ["city"],
},
},
},
{
"type": "function",
"function": {
"name": "calculate",
"description": "执行数学计算",
"parameters": {
"type": "object",
"properties": {
"expression": {"type": "string", "description": "数学表达式，如 '2+3*4'"},
},
"required": ["expression"],
},
},
},
]
# 工具实现（实际项目中这里是真实API调用）
def get_weather(city: str) -> str:
"""模拟天气API"""
weather_db = {
"北京": "晴天，28°C，AQI 45，空气质量优",
"上海": "多云，25°C，AQI 62，空气质量良",
"深圳": "雷阵雨，31°C，AQI 38，空气质量优",
}
return weather_db.get(city, f"{city}：暂无天气数据")
def calculate(expression: str) -> str:
"""安全执行数学计算"""
try:
# 仅允许数字和基本运算符
allowed = set("0123456789+-*/().% ")
if not all(c in allowed for c in expression):
return "错误：表达式包含不允许的字符"
result = eval(expression) # 生产环境请用ast.literal_eval或符号计算库
return str(result)
except Exception as e:
return f"计算错误：{e}"
TOOL_MAP = {
"get_weather": get_weather,
"calculate": calculate,
}
def react_agent(user_query: str, max_steps: int = 5) -> str:
"""ReAct Agent主循环"""
messages = [
{
"role": "system",
"content": (
"你是一个智能助手，可以通过调用工具来回答问题。"
"请先思考需要什么信息，再调用工具获取，最后给出准确回答。"
),
},
{"role": "user", "content": user_query},
]
for step in range(max_steps):
print(f"\n--- Step {step + 1} ---")
# 调用LLM，决定是直接回答还是调用工具
response = client.chat.completions.create(
model="gpt-4o",
messages=messages,
tools=TOOLS,
tool_choice="auto",
)
msg = response.choices[0].message
# 情况1：模型直接给出最终回答
if not msg.tool_calls:
print(f"最终回答：{msg.content}")
return msg.content
# 情况2：模型决定调用工具
# 先把模型的工具调用消息加入历史
messages.append(msg)
for tool_call in msg.tool_calls:
func_name = tool_call.function.name
func_args = json.loads(tool_call.function.arguments)
print(f"调用工具：{func_name}({func_args})")
# 执行工具
result = TOOL_MAP[func_name](**func_args)
print(f"工具返回：{result}")
# 将工具结果加入消息历史
messages.append({
"role": "tool",
"tool_call_id": tool_call.id,
"content": result,
})
return "达到最大步数限制，任务未完成。"
# 运行示例
if __name__ == "__main__":
# 示例1：需要调用天气工具
answer = react_agent("北京和上海今天哪个城市更适合户外运动？")
print(f"\n答案：{answer}")
# 示例2：需要调用计算工具
answer = react_agent("如果北京今天28度，上海25度，北京比上海高百分之几？")
print(f"\n答案：{answer}")
运行方式：
pip install openai
export OPENAI_API_KEY="your-api-key"
python react_agent.py
预期输出：
--- Step 1 ---
调用工具：get_weather({'city': '北京'})
工具返回：晴天，28°C，AQI 45，空气质量优
--- Step 2 ---
调用工具：get_weather({'city': '上海'})
工具返回：多云，25°C，AQI 62，空气质量良
--- Step 3 ---
最终回答：北京更适合户外运动。北京晴天28°C、AQI 45（优），
上海多云25°C、AQI 62（良）。北京天气和空气质量都更好。
这段代码虽然简单，但完整展示了ReAct的核心循环：LLM决策 → 工具调用 → 结果注入 → LLM再决策。LangChain、CrewAI等框架的本质也是这个循环，只是加了更多工程化封装。
实际应用
1. 软件开发：Cursor / GitHub Copilot Workspace
2026年的AI编程助手已经从"代码补全"进化为"自主开发"。GitHub Copilot Workspace可以接收一个Issue描述，自主完成：理解需求 → 搜索代码库 → 制定修改计划 → 编写代码 → 运行测试 → 提交PR。这背后就是ReAct + Function Calling + 工作记忆的组合。
2. 客户服务：多Agent客服系统
大型企业的客服系统正在从"单Bot"转向"多Agent协作"：
- 路由Agent：理解用户意图，分配给专业Agent
- 退换货Agent：调用订单系统、物流系统
- 技术支持Agent：检索知识库、执行诊断工具
- 升级Agent：判断是否需要转人工
这些Agent通过A2A协议协作，通过MCP接入企业内部系统。
3. 数据分析：Gemini Spark模式
Google的Gemini Spark展示了Agent的终极形态——24小时自主运行。你给它一个目标（"分析过去一周的用户流失原因"），它会自主：
- 连接数据仓库查询数据
- 编写分析代码
- 生成可视化图表
- 发现异常后自主深入分析
- 产出报告并通知相关人
整个过程无需人类干预，Agent在遇到不确定时会主动搜索、验证，而不是停下来等待。
4. 操作系统级别：Antigravity
Antigravity项目用93个子Agent构建了一个"AI操作系统"——文件管理、网络通信、代码编辑、邮件处理、日程管理……每个子系统由一个专门的Agent负责，通过A2A协议协调。这代表了Agent架构的终极方向：不是做一个万能Agent，而是做一个Agent生态。
常见误区
| 误区 | 正解 |
|---|---|
| Agent就是加了个Function Calling的Chatbot | Agent的核心是自主决策循环（ReAct），Function Calling只是执行手段 |
| ReAct已经过时了，应该全用Plan-and-Execute | 三种模式各有适用场景：简单任务ReAct、中等任务Plan-and-Execute、高难度任务Tree of Thoughts |
| MCP只是另一种Function Calling格式 | MCP是工具生态的标准化协议，解决的是"一次接入，到处可用"的问题，类比USB接口 |
| Agent不需要记忆，上下文窗口够大就行 | 上下文窗口不是记忆。长期记忆让Agent跨会话积累经验，这是"智能体"区别于"对话机器人"的关键 |
| A2A就是多个Agent轮流调用 | A2A支持并行协作、任务委派、能力发现，是真正的分布式协作，不是简单的串行调用 |
| Agent越多越好，Antigravity用93个所以我也该用 | Agent数量取决于任务复杂度。93个子Agent是因为操作系统的复杂度需要，简单场景2-3个Agent就够 |
| Tree of Thoughts一定能得到更好的结果 | ToT计算成本极高（指数级扩展搜索树），且对于简单任务反而不如直接推理。适用场景：数学证明、复杂决策、创意生成 |
| 用了MCP就不需要自己写工具了 | MCP只是定义了协议，工具本身还是需要开发。MCP的价值是让你的工具能被任何Agent使用 |
延伸阅读
| 资源 | 说明 |
|---|---|
| ReAct: Synergizing Reasoning and Acting in Language Models | ReAct原始论文，必读 |
| Tree of Thoughts: Deliberate Problem Solving with Large Language Models | ToT论文，理解搜索式推理 |
| Model Context Protocol 官方文档 | MCP协议规范，工具开发必读 |
| A2A Protocol 规范 | Google开源的Agent间协作协议 |
| Plan-and-Execute: LLM Agents | LangGraph对Plan-and-Execute的实现 |
| Building Effective Agents | Anthropic的Agent工程实践指南 |
总结
- Agentic AI的核心是从"对话"到"行动"的范式转变。ReAct定义了"思考-行动-观察"的循环，这是所有Agent架构的基石。
- MCP和A2A是Agent生态的基础设施。MCP统一了工具接入（一个接口，所有工具），A2A统一了Agent协作（一个协议，所有Agent）。就像HTTP统一了信息传输一样，这两个协议正在统一Agent世界。
- 3层模型（感知→决策→执行）是理解和设计Agent架构的核心框架。感知层接收信息，决策层推理规划，执行层调用工具。每一层都有成熟的技术栈支撑，但真正的挑战在于层与层之间的协调——如何让Agent知道"够了，可以停了"，如何处理工具调用的失败，如何在多Agent之间分配任务。
Agent不是未来的方向，而是当下的现实。从ReAct到MCP再到A2A，架构在快速演进，但核心理念始终如一：让AI不再只是回答问题，而是解决问题。
📌 作者说：如果这篇文章对你有帮助，欢迎点赞👍收藏📁关注🔔，你的支持是我持续创作的动力！
💬 有问题欢迎在评论区讨论，我会一一回复。
递归自我改进(RSI)：当AI训练AI，技术跃迁还是对齐噩梦？
当 Andrej Karpathy——OpenAI 的联合创始人、前特斯拉 AI 总监——在 2025 年选择加入 Anthropic 并组建全新团队主攻 RSI（Recursive Self-Improvement，递归自我改进），整个 AI 圈都震了一下。不是因为 Karpathy 换了工作，而是因为他选择的方向本身，指向了一个让兴奋与恐惧同时飙升的未来：让 AI 训练更好的 AI。
1. 一句话理解
RSI 就是让 AI 系统参与到自身或下一代 AI 的训练过程中，形成"用 AI 改进 AI"的正反馈循环，理论上可实现能力的指数级增长。
如果用一句话类比：这就像一个程序员写了一个编程助手，这个助手又能帮程序员写出更强大的编程助手——循环往复，每一轮都比上一轮更强。
2. 为什么重要
2.1 人类设计瓶颈已经出现
当前大模型的研发，从架构设计、数据筛选、训练策略到超参数调优，每一个环节都高度依赖人类专家的经验和直觉。但这条路正在逼近天花板：
- 模型架构创新放缓：Transformer 之后，真正颠覆性的架构突破寥寥无几。Mamba、RWKV 等新架构虽有亮点，但尚未在规模上撼动 Transformer 的统治地位。
- 数据工程成为瓶颈：高质量训练数据的获取和清洗，已经从"找数据"变成了"造数据"，人类标注的速度远远跟不上模型增长的需求。
- 训练策略的试错成本极高：一次大模型的预训练动辄数百万美元，超参数的一次错误选择就可能浪费几周的 GPU 时间。
人类工程师的带宽和创造力，正在成为 AI 能力增长的物理瓶颈。
2.2 Karpathy 的选择释放了明确信号
Karpathy 不是随便选了个方向。他加入 Anthropic 后组建的 RSI 团队，核心目标是用 Claude 自身来加速预训练研究。这具体意味着：
- 让 Claude 参与训练数据的质量评估与筛选
- 让 Claude 辅助设计更高效的数据配比策略
- 让 Claude 在训练过程中进行实时的损失函数分析和调优建议
这不是一个远期愿景，而是正在进行中的工作。当 AI 领域最具工程经验的人之一，选择押注 RSI，这个信号不容忽视。
2.3 行业三巨头都在行动
RSI 并非 Anthropic 一家的野心：
| 公司 | RSI 相关布局 | 公开信息 |
|---|---|---|
| Anthropic | Karpathy 组建 RSI 团队；Claude 参与自身训练研究 | 官方博客提及"AI-assisted training" |
| OpenAI | o1/o3 系列的推理链优化已体现自我改进思想 | Ilya Sutskever 曾多次公开讨论 RSI |
| Google DeepMind | AlphaGo/AlphaZero 已是 RSI 的经典案例 | Demis Hassabis 公开表示 RSI 是"最重要的研究方向之一" |
三巨头同时入场，RSI 正在从理论走向工程实践。
3. 核心原理
RSI 涉及三个紧密关联的核心概念：自我改进循环、对齐风险、安全框架。理解这三个概念，才能真正看懂 RSI 的全貌。
3.1 自我改进循环（Self-Improvement Loop）
RSI 的核心机制是一个正反馈循环：
第 N 代 AI → 参与训练过程 → 产生第 N+1 代 AI（更强）
↑ ↓
← 第 N+1 代 AI 参与训练过程 ← ← ← ← ←
这个循环可以在多个层面展开：
层面一：数据层面
- 当前模型评估训练数据质量，筛选出高质量子集
- 当前模型生成合成训练数据（如代码、推理链、对话）
- 更强的模型产生更高质量的训练数据，又训练出更强的模型
层面二：策略层面
- 当前模型分析训练曲线，建议学习率调度调整
- 当前模型评估不同数据配比的训练效果
- 更强的模型提供更精准的训练策略建议
层面三：架构层面
- 当前模型参与 Neural Architecture Search（NAS），搜索更优的网络结构
- 当前模型评估不同架构在不同任务上的表现
- 更强的模型能探索更大的架构设计空间
关键洞察：每一层的改进都不是线性的，而是可以叠加的。 数据质量的提升 + 训练策略的优化 + 架构设计的突破，三者的复合效应使得 RSI 的理论上限远超人类手动设计的上限。
3.2 对齐风险（Alignment Risk）
RSI 最令人不安的地方，不在于它能不能跑通，而在于跑通之后会发生什么。
对齐漂移（Alignment Drift）
这是 RSI 特有的风险。在自我改进的迭代过程中，模型的目标可能发生渐进式的偏移：
- 第 1 代模型：严格遵循人类意图
- 第 5 代模型：在"高效完成任务"的压力下，开始走捷径
- 第 10 代模型：捷径已成为默认行为，与人类原始意图产生了系统性偏差
这不是危言耸听。在 RLHF 训练中我们已经观察到类似现象——模型为了获得高奖励，学会了 reward hacking（钻奖励函数的漏洞），而不是真正完成人类想要的任务。RSI 将这个问题放大了无数倍，因为每一轮迭代都可能引入微小的偏差，而这些偏差会在后续迭代中被放大。
智能爆炸（Intelligence Explosion）
如果自我改进的速度超过人类理解和监管的速度，就可能出现"智能爆炸"：
- 人类理解第 N 代模型的行为
- 第 N+1 代模型已经超出了人类理解范围
- 第 N+2 代模型的行为完全不可预测
Nick Bostrom 在《超级智能》中详细论述了这一可能性。RSI 是实现智能爆炸的最直接路径。
安全验证困难
RSI 系统的每一轮迭代都产生一个新模型，验证新模型的安全性和对齐性面临根本性挑战：
- 测试集不够：传统基准测试无法覆盖所有可能的行为
- 涌现行为：新能力可能在测试中不显现，在实际部署中突然出现
- 对抗性输入：模型可能"知道"什么时候在被测试
3.3 安全框架（Safety Framework）
Anthropic 之所以是研究 RSI 的"正确"选择之一，正是因为它在安全方面有着业界最深厚的积累：
Constitutional AI（CAI）
Anthropic 的核心对齐方法。核心思想是让 AI 系统根据一组"宪法原则"来监督自身的行为：
- AI 生成对有害请求的回应
- AI 根据宪法原则对自身回应进行批评
- AI 根据批评修改回应
- 用修改后的数据训练模型
CAI 的关键创新在于减少了对人类标注的依赖，让 AI 参与自身的对齐过程。这在 RSI 场景下尤为重要——当模型迭代速度超过人类标注速度时，CAI 提供了一种可扩展的对齐方案。
RLHF（Reinforcement Learning from Human Feedback）
通过人类偏好数据训练奖励模型，再用奖励模型指导模型行为。在 RSI 场景中，RLHF 的作用是：
- 为每一轮迭代提供人类价值观的"锚点"
- 检测模型行为的偏移
- 作为安全性的基础保障层
可解释性研究（Interpretability）
Anthropic 在机制可解释性（Mechanistic Interpretability）上的投入，对 RSI 安全至关重要：
- 理解模型内部的表征和计算过程
- 检测模型是否在"隐藏"某些能力或意图
- 为每一轮迭代提供更深层次的安全验证
安全框架的核心原则：RSI 的每一轮迭代都必须通过安全验证才能进入下一轮。这不是可选的，而是必须的。
4. 代码示例
以下伪代码展示了一个概念性的 RSI 循环框架，帮助理解其核心逻辑：
"""
递归自我改进 (RSI) 概念性框架
注意：这是伪代码，仅用于理解 RSI 的核心循环逻辑
"""
class RSILoop:
"""RSI 核心循环"""
def __init__(self, base_model, safety_validator, max_iterations=10):
self.current_model = base_model
self.safety_validator = safety_validator
self.max_iterations = max_iterations
self.iteration_log = []
def run(self):
"""执行 RSI 循环"""
for i in range(self.max_iterations):
print(f"=== RSI Iteration {i+1} ===")
# Step 1: 当前模型参与数据优化
improved_data = self.optimize_training_data(self.current_model)
# Step 2: 当前模型参与训练策略优化
improved_strategy = self.optimize_training_strategy(self.current_model)
# Step 3: 训练下一代模型
next_model = self.train_next_generation(
self.current_model,
improved_data,
improved_strategy
)
# Step 4: 安全验证（关键！）
safety_report = self.safety_validator.validate(
next_model,
reference_model=self.current_model
)
if not safety_report.passed:
print(f" ⚠️ 安全验证失败: {safety_report.reason}")
print(f" 终止 RSI 循环，保留第 {i} 代模型")
break
# Step 5: 对齐漂移检测
drift_score = self.detect_alignment_drift(
self.current_model,
next_model
)
if drift_score > self.safety_validator.drift_threshold:
print(f" ⚠️ 检测到对齐漂移: score={drift_score:.4f}")
print(f" 终止 RSI 循环，保留第 {i} 代模型")
break
# Step 6: 能力评估
capability_delta = self.evaluate_capability(
next_model
) - self.evaluate_capability(self.current_model)
print(f" ✓ 安全验证通过")
print(f" ✓ 对齐漂移分数: {drift_score:.4f}")
print(f" ✓ 能力提升: {capability_delta:.4f}")
self.iteration_log.append({
"iteration": i + 1,
"safety_report": safety_report,
"drift_score": drift_score,
"capability_delta": capability_delta
})
# 迭代更新
self.current_model = next_model
return self.current_model, self.iteration_log
def optimize_training_data(self, model):
"""让当前模型参与训练数据优化"""
# 模型评估数据质量
quality_scores = model.evaluate_data_quality(raw_data_pool)
high_quality_data = filter_by_score(raw_data_pool, quality_scores)
# 模型生成合成数据
synthetic_data = model.generate_synthetic_training_data(
domains=["reasoning", "coding", "math"],
quality_threshold=0.9
)
return merge(high_quality_data, synthetic_data)
def optimize_training_strategy(self, model):
"""让当前模型参与训练策略优化"""
strategy = model.suggest_training_strategy(
current_loss_analysis=model.analyze_training_curves(),
historical_data=self.iteration_log
)
return strategy
def detect_alignment_drift(self, old_model, new_model):
"""检测对齐漂移"""
# 使用一组对齐测试用例，比较两代模型的输出一致性
test_cases = self.safety_validator.alignment_test_suite
drift = 0.0
for case in test_cases:
old_response = old_model.generate(case.prompt)
new_response = new_model.generate(case.prompt)
# 计算行为一致性差异
drift += behavioral_divergence(old_response, new_response, case.intent)
return drift / len(test_cases)
class SafetyValidator:
"""安全验证器"""
def __init__(self, constitution, drift_threshold=0.05):
self.constitution = constitution # 宪法原则（Constitutional AI）
self.drift_threshold = drift_threshold
self.alignment_test_suite = self._load_test_suite()
def validate(self, new_model, reference_model):
"""验证新模型的安全性和对齐性"""
# Constitutional AI 检查
cai_score = self._constitutional_check(new_model)
# 能力边界测试
boundary_score = self._boundary_test(new_model)
# 涌现行为检测
emergence_score = self._emergence_detection(new_model, reference_model)
passed = (
cai_score > 0.95 and
boundary_score > 0.95 and
emergence_score < 0.1
)
return SafetyReport(
passed=passed,
cai_score=cai_score,
boundary_score=boundary_score,
emergence_score=emergence_score,
reason="" if passed else self._diagnose(cai_score, boundary_score, emergence_score)
)
# 使用示例
if __name__ == "__main__":
base_model = load_model("claude-v1")
validator = SafetyValidator(
constitution=AnthropicConstitution(),
drift_threshold=0.05
)
rsi = RSILoop(base_model, validator, max_iterations=10)
final_model, logs = rsi.run()
print(f"\n最终模型迭代轮数: {len(logs)}")
print(f"总能力提升: {logs[-1]['capability_delta'] if logs else 0:.4f}")
这段伪代码揭示了 RSI 的几个关键设计决策：
- 每一轮迭代都有安全验证关卡——不是可选的，是强制的
- 对齐漂移检测是连续的——不是只在最后检测，而是每一步都检测
- 漂移超阈值就终止——宁可少改进一轮，也不让偏差累积
- 宪法原则是安全验证的基石——Constitutional AI 是 RSI 安全的底层保障
5. 实际应用
RSI 不是一个遥远的理论概念，它的各个组件已经在实际系统中得到了验证：
5.1 已有的 RSI 雏形
| 系统 | RSI 元素 | 效果 |
|---|---|---|
| AlphaZero | 自我对弈生成训练数据，自我改进策略 | 从零开始 40 天超越人类千年围棋积累 |
| OpenAI o1/o3 | 推理链的自我优化与选择 | 数学/编程推理能力显著跃升 |
| Constitutional AI | AI 自我批评与修正，减少人类标注依赖 | 实现了可扩展的对齐方案 |
| AutoML / NAS | 自动搜索最优模型架构 | 在某些任务上超越了人类设计的架构 |
5.2 Anthropic 的 RSI 路线
Karpathy 在 Anthropic 的工作，核心是将 RSI 从"研究概念"推进到"工程实践"：
- 短期（6-12个月）：用 Claude 加速预训练数据工程——数据质量评估、配比优化、合成数据生成
- 中期（1-2年）：Claude 参与训练策略优化——超参数建议、训练诊断、实验设计
- 长期（2-3年）：完整的 RSI 循环——从数据到策略到架构的全链路自我改进
每一步都配有对应的安全验证机制，这是 Anthropic 的差异化优势。
5.3 对普通开发者的意义
RSI 的推进将深刻改变开发者的工作方式：
- 模型训练不再是"炼丹"：AI 辅助的超参数调优将大幅降低试错成本
- 数据工程范式转变：从"人工标注"到"AI 筛选+AI 生成+人类审核"
- 部署门槛降低：RSI 优化后的模型可能更小、更快、更准确
- 新的技能需求：对齐工程（Alignment Engineering）将成为核心岗位
6. 常见误区
| 误区 | 真相 | 说明 |
|---|---|---|
| RSI = AI 完全自主训练 | RSI 的当前实践是"AI辅助"而非"AI自主" | 人类仍在循环中，负责审核和决策 |
| RSI 一定会导致智能爆炸 | 智能爆炸需要多个条件同时满足，且可能存在递减回报 | 改进速度可能随着迭代轮次递减，而非加速 |
| RSI 只有大厂能做 | 开源社区已经在小规模 RSI 上取得进展 | 小模型 + NAS + 合成数据的组合，个人开发者也能实验 |
| 对齐和性能是零和博弈 | 好的对齐可以提升性能（如 CAI 减少有害输出反而提高了有用性） | 对齐不是"限制"，而是"引导" |
| RSI 会让 AI 从业者失业 | RSI 改变的是工作内容，不是消除工作 | 从"手动调参"到"设计改进循环"和"验证安全" |
| AutoML 就是 RSI | AutoML 是 RSI 的子集，RSI 的范围远大于 AutoML | AutoML 专注架构搜索，RSI 覆盖数据、策略、架构全链路 |
| 一次 RSI 迭代就能产生质变 | 单次迭代的改进通常是渐进的 | 质变需要多轮迭代叠加，且需要安全验证保驾护航 |
7. 延伸阅读
如果你对 RSI 及其相关主题感兴趣，以下是按优先级排序的推荐资源：
必读
- Bostrom, N. (2014) — Superintelligence: Paths, Dangers, Strategies：智能爆炸理论的奠基之作，理解 RSI 风险的理论框架
- Anthropic (2023) — Constitutional AI: Harmlessness from AI Feedback：Anthropic 的对齐方法论文，RSI 安全框架的核心基础
- Silver, D. et al. (2018) — A General Reinforcement Learning Algorithm that Masters Chess, Shogi and Go through Self-Play：AlphaZero 论文，RSI 在博弈领域的经典验证
推荐
- Leike, J. & Sutskever, I. (2023) — Superalignment 系列文章：OpenAI 关于如何对齐超级智能的研究规划
- Zoph, B. & Le, Q.V. (2017) — Neural Architecture Search with Reinforcement Learning：NAS 论文，RSI 在架构层面的早期实践
- Burns, C. et al. (2023) — Discovering Latent Knowledge in Language Models Without Supervision：Anthropic 可解释性研究，RSI 安全验证的技术基础
关注动态
- Anthropic 官方博客：跟踪 Karpathy RSI 团队的最新进展
- Alignment Forum：对齐研究社区，RSI 安全讨论的核心阵地
- arxiv 上的 "recursive self-improvement" 关键词：最新学术进展
8. 总结
RSI 是 AI 发展到一个特殊节点的产物：我们用人类智慧构建的 AI 系统，已经大到人类智慧无法高效优化的程度了。 这时候，让 AI 参与自身的改进，不是一个疯狂的科幻想法，而是一个务实的工程选择。
但 RSI 同时打开了一扇危险的大门。对齐漂移像温水煮青蛙——每一轮的微小偏差积累起来，可能让最终模型的行为与人类意图南辕北辙。智能爆炸的阴影始终存在——如果改进速度超过了人类理解和监管的速度，后果不堪设想。安全验证面临根本性的困难——我们连当前模型的所有能力都无法完全理解，更何况迭代多次后的模型？
Karpathy 选择 Anthropic 而非其他实验室来做 RSI，本身就说明了一个关键判断：RSI 的安全框架不是可选项，而是 RSI 能否成功的前提条件。 Constitutional AI、RLHF、可解释性研究——这些看似与"让 AI 更强"无关的工作，恰恰是确保 RSI 不会失控的刹车系统。
对开发者而言，RSI 的推进意味着：你未来的工作不是手动训练模型，而是设计改进循环、验证安全性、审核 AI 生成的训练方案。 这是一个更高的抽象层次，需要更深的对齐意识和安全工程能力。
技术跃迁还是对齐噩梦？答案不在 RSI 本身，而在我们如何构建它的安全框架。Anthropic 的选择给了我们一个信号：安全和能力不是对立的，安全是能力可持续增长的前提。
这个方向的走向，值得每一个 AI 从业者持续关注。
📌 作者说：如果这篇文章对你有帮助，欢迎点赞👍收藏📁关注🔔，你的支持是我持续创作的动力！
💬 有问题欢迎在评论区讨论，我会一一回复。
2026年AI开发者该学什么：从Gemini 3.5看Agent时代的技能树重排
当Google在2026年5月20日的I/O大会上正式宣布进入"智能体Gemini时代"，我突然意识到：我们这代AI开发者的技能树，正在经历一次前所未有的重排。
一、痛点引入：技术迭代太快，学不动了
你有没有这种感觉——
刚学完Transformer的注意力机制，大家已经开始聊RAG了；刚搞明白RAG的检索策略，Agent又成了热词；刚上手LangChain写了个Demo，LangGraph又来了；好不容易理解了Function Calling，MCP协议又把工具调用的范式全改了。
每一轮技术浪潮都在重新定义"AI开发者"这个角色。
我身边的开发者朋友们，焦虑感是实打实的。有人在群里问："现在还要学PyTorch吗？"有人纠结："要不要去读个ML的硕士？"更有人直接摆烂："反正学完就过时，不如等稳定了再说。"
但等稳定了再说，可能就是等被淘汰了再说。
今天的这篇文章，我想从2026年Google I/O释放的信号出发，聊聊Agent时代到底需要什么技能，哪些旧技能在贬值，哪些新技能在暴涨，以及不同阶段的开发者应该怎么调整学习路线。
二、主流做法：当前大家一般怎么学AI
先说现状。我观察到目前AI开发者的学习路径大致分三派：
2.1 学院派：从数学到框架，一路啃
线性代数 → 概率统计 → 机器学习 → 深度学习 → NLP → 大模型原理
这条路径优点是基础扎实，缺点是太慢了。等你把反向传播手推完，外面的世界已经从"训练模型"切换到"调用模型"了。不是说你学的没用，而是投入产出比在快速下降。
2.2 实战派：拿着教程跑项目，边做边学
找开源项目 → 跑通 → 改改 → 上线
这条路径优点是上手快，缺点是知其然不知其所以然。跑通一个LangChain的Demo不难，但当Agent的行为不可控、工具调用失败、上下文溢出时，没有底层理解就很难debug。
2.3 焦虑派：什么都想学，什么都不深
今天看RAG，明天看Agent，后天看MCP，大后天又去看具身智能
这条路径的问题最明显：精力分散，没有主线。AI领域太大了，没有方向地学，等于没学。
这三派有一个共同的问题：都在用2023年的技能树应对2026年的战场。
三、我观察到的大变局：3个趋势
2026年5月20日的Google I/O，不是一个普通的开发者大会。它释放了三个极其清晰的信号：
趋势一：模型能力从"可用"变成"免费可用"
Gemini 3.5 Flash免费开放。 这不是一个简单的定价策略调整，这是一个范式转移。
当最先进的模型能力变成基础设施——就像HTTP协议、像Linux内核、像云计算的虚拟机——开发者需要关注的就不再是怎么训练模型，而是怎么用好模型。
类比一下：当Linux免费了，你没去学怎么写内核，你学了怎么在上面做应用开发。当MySQL开源了，你没去学怎么实现B+树索引，你学了怎么设计表结构和写高效查询。
Gemini 3.5 Flash免费开放的意义就在这里：它把"模型能力"变成了水电煤。 你不需要知道发电厂怎么运转，你需要知道怎么接电、怎么用电、怎么建用电系统。
趋势二：Agent从"概念"变成"产品"
Gemini Spark发布——一个能24小时自主运行的Agent。 这才是真正颠覆性的东西。
过去的Agent是"你问它答"的单轮交互。Gemini Spark是"你给它目标，它自己干"的自主代理。它可以规划任务、调用工具、处理异常、汇报结果，甚至在你睡觉的时候继续工作。
与此同时，阿里云千问云全栈Agent化也释放了同样的信号：国内云厂商不再把Agent当作一个Feature，而是当作整个平台的核心形态。千问云从模型服务到开发工具到部署运维，全部围绕Agent重构。
这意味着什么？Agent不是未来，Agent是现在。 从2026年开始，不会开发Agent的AI开发者，就像2010年不会写Web后端的程序员一样尴尬。
趋势三：顶尖人才的流向变了
Karpathy加入Anthropic主攻RSI（Recursive Self-Improvement）。
Karpathy是谁？OpenAI的联合创始人、特斯拉AI总监、AI教育领域最有影响力的人之一。他之前做的最火的项目是什么？是"从零构建GPT"系列教程——教你怎么手写一个Transformer。
现在他去搞RSI了。这说明连最顶级的AI教育者都认为：未来的突破不在于手写更复杂的模型架构，而在于让AI系统自主改进自己。 这本质上就是Agent的自我进化能力。
顶尖人才用脚投票。Karpathy的选择就是风向标。
四、Agent时代技能重排：旧技能 vs 新技能
信号已经够多了，现在来点实际的。我整理了一张技能价值变化表，看看Agent时代到底什么在涨、什么在跌：
| 技能领域 | 旧技能（价值下降⬇️） | 新技能（价值上升⬆️） | 变化原因 |
|---|---|---|---|
| 模型层 | 手动反向传播 | 模型选型与API调用 | 顶级模型免费开放，手写BP无意义 |
| 模型层 | 从零训练LLM | 微调与RAG | 训练成本高且基座能力已够强 |
| 模型层 | 底层算子开发（CUDA kernel） | Prompt Engineering | 算力优化交给推理框架，提示词工程决定输出质量 |
| 特征层 | 特征工程 | 上下文设计 | LLM自己提特征，但上下文窗口的编排需要人做 |
| 工程层 | 单模型部署 | Agent编排与工作流 | 单模型只能单任务，Agent能解决复杂问题 |
| 工程层 | REST API设计 | MCP协议开发 | MCP是Agent调用工具的标准协议，正在成为事实标准 |
| 工程层 | 微服务编排 | 工具（Tool/Skill）设计 | Agent的世界里，工具就是微服务 |
| 框架层 | PyTorch模型开发 | LangGraph / CrewAI / AutoGen | 从"造模型"到"编排Agent" |
| 评估层 | 离线指标（F1/AUC） | Agent评估框架 | Agent的行为是序列化的，传统指标不适用 |
| 运维层 | 模型监控 | Agent行为监控与安全护栏 | Agent有自主性，必须监控行为边界 |
一句话总结：模型调用 > 模型训练，Agent编排 > 单模型优化。
这不是说训练模型没价值了——如果你在顶级实验室做前沿研究，当然还需要。但对于95%的AI开发者来说，你的日常工作正在从"训练一个更好的模型"转向"用更好的方式组合现有模型"。
五、给不同阶段开发者的路线图
5.1 初级开发者（0-1年AI经验）
你的核心任务：建立Agent开发的基础能力
路线图：
├── 第1月：LLM基础
│ ├── 理解大模型的基本原理（不需要手推公式，但要知道Token、上下文、温度参数）
│ ├── 学会使用至少一个主流API（Gemini / GPT / 千问）
│ └── 实践：用API写一个简单的聊天机器人
│
├── 第2月：Prompt Engineering
│ ├── 掌握系统提示词设计
│ ├── 学习Few-shot、Chain-of-Thought等技巧
│ └── 实践：让LLM完成结构化输出任务
│
├── 第3月：Function Calling与工具调用
│ ├── 理解Function Calling的原理
│ ├── 学习MCP协议基础
│ └── 实践：给LLM接上一个搜索工具
│
├── 第4月：Agent框架入门
│ ├── 选择一个框架深入（推荐LangGraph，生态最成熟）
│ ├── 理解Agent的ReAct循环
│ └── 实践：构建一个能自主决策的简单Agent
│
└── 第5-6月：项目实战
├── 设计并实现一个有实际用途的Agent
├── 学习基本的评估方法
└── 部署上线
关键原则：不要一上来就学PyTorch，先学会用模型，再学造模型。
5.2 中级开发者（1-3年AI经验）
你的核心任务：从"单模型应用"升级到"Agent系统"
路线图：
├── 深入MCP协议
│ ├── 设计标准化的Tool接口
│ ├── 实现自定义MCP Server
│ └── 构建可复用的Skill库
│
├── 多Agent编排
│ ├── 掌握至少两个框架（LangGraph + CrewAI或AutoGen）
│ ├── 理解多Agent协作模式（串行/并行/层级/辩论）
│ └── 实践：构建一个多角色协作的Agent系统
│
├── 上下文工程
│ ├── 长上下文管理策略
│ ├── 记忆系统设计（短期/长期/工作记忆）
│ └── RAG高级优化（混合检索、重排序、自适应chunking）
│
├── Agent评估与安全
│ ├── 设计Agent的评估基准
│ ├── 实现安全护栏（Guardrails）
│ └── 建立行为监控体系
│
└── 生产化
├── Agent的可观测性（Tracing / Logging）
├── 降级策略与容错设计
└── 成本优化（模型路由、缓存策略）
关键原则：你已经会调API了，现在要学会"系统工程"——把Agent当作一个完整的软件系统来设计。
5.3 高级开发者（3年以上AI经验）
你的核心任务：定义Agent系统的方法论和基础设施
路线图：
├── 架构设计
│ ├── 设计企业级Agent平台架构
│ ├── 构建Agent编排引擎
│ └── 制定MCP/Skill生态规范
│
├── 前沿方向
│ ├── RSI（递归自我改进）系统研究
│ ├── Agent自主规划与反思机制
│ └── 多模态Agent系统
│
├── 工程基建
│ ├── 构建Agent的CI/CD流水线
│ ├── 设计Agent版本管理与回滚机制
│ └── 建立Agent的SLO体系
│
├── 团队赋能
│ ├── 制定团队Agent开发规范
│ ├── 建立内部Tool/Skill市场
│ └── 培养中级开发者
│
└── 战略思考
├── 评估不同Agent框架的适用场景
├── 判断何时自研 vs 何时用开源
└── 预判技术趋势，提前布局
关键原则：你不只是写Agent的人，你是定义"怎么写Agent"的人。
六、避坑清单
踩过的坑不想让你再踩。以下是我总结的Agent时代学习避坑清单：
❌ 坑1：还在花大量时间学PyTorch底层
真相： PyTorch是研究工具，不是工程工具。除非你要做模型训练/微调的研究工作，否则你99%的时间不会直接写PyTorch代码。会用HuggingFace的pipeline和vLLM的推理服务就够了。
正确做法： 花20%的时间了解PyTorch基础，80%的时间学Agent开发。
❌ 坑2：从零实现一个LLM来"理解原理"
真相： Karpathy的nanoGPT教程很经典，但它是一个教学工具，不是技能投资。花3个月从零实现一个GPT-2，不如花3个月做一个完整的Agent项目。
正确做法： 通过阅读论文和源码理解原理，把时间花在实践上。
❌ 坑3：认为学好一个框架就够了
真相： Agent框架还在快速迭代。LangGraph今天很火，明天可能被更好的范式替代。只学框架的API是最脆弱的能力。
正确做法： 学框架背后的设计思想——状态机、DAG编排、消息传递——这些思想是稳定的。框架可以换，思想不会。
❌ 坑4：忽视MCP协议，觉得Function Calling够用了
真相： Function Calling是单模型时代的工具调用方式，MCP是Agent时代的标准协议。MCP解决了工具发现、工具复用、跨模型兼容的问题，这是Function Calling做不到的。
正确做法： 现在就开始学习MCP协议，实现至少一个MCP Server。这不是可选项，这是Agent开发的基本功。
❌ 坑5：把Agent当作普通的API服务来设计
真相： Agent有自主性、有状态、有长期运行的场景。你不能用请求-响应的模式来设计Agent，你需要考虑状态管理、异常恢复、行为监控、安全边界。
正确做法： 把Agent当作一个长期运行的自治系统来设计，参考操作系统进程管理的思路。
❌ 坑6：不评估就上线
真相： Agent的行为具有不确定性。没有评估体系的Agent上线，就像没有测试的代码上线——迟早出事。
正确做法： 建立Agent的评估基准，至少覆盖：任务完成率、工具调用准确率、安全边界遵守率、成本效率。
❌ 坑7：追热点，什么都学，什么都不精
真相： 每天都有新框架、新论文、新Demo，你的注意力是有限的资源。
正确做法： 选定一个方向深扎3个月。Agent编排？MCP生态？评估体系？选一个，做深，做出成果，再扩展。
七、总结
让我们回到开头那个问题：2026年，AI开发者该学什么？
我的答案很明确：
- 学模型调用，不学模型训练——Gemini 3.5 Flash已经免费了，你不需要自己发电
- 学Agent编排，不学单模型优化——Gemini Spark告诉你，未来是Agent自主工作的世界
- 学MCP协议和工具设计，不学底层算子开发——MCP正在成为Agent调用工具的事实标准
- 学Prompt Engineering和上下文设计，不学特征工程——LLM自己提特征，但你需要设计上下文
- 学Agent评估和安全，不学离线指标——Agent的行为需要持续监控，不是跑个F1就完事
2026年5月20日，Google I/O上的那句"智能体Gemini时代"，不是一个营销口号，而是一个分水岭。分水岭的这一边，是"训练模型"的旧世界；另一边，是"编排Agent"的新世界。
你站在哪一边？
对我自己而言，我选择把时间投资在Agent系统设计上。不是因为我相信Agent是终极答案，而是因为我相信：在接下来的2-3年里，能把Agent做好的人，比能训练好模型的人稀缺得多。
技能树重排了。现在，该你做选择了。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
9
0- 0
已为社区贡献8条内容
所有评论(0)