Jensen Huang「AGI 到了」技术拆解：哪种 AGI 定义？OpenClaw 为什么被当作证据？
发布于: 2026-03-24 | 作者: Lucky | 标签: AI Agent, AGI, OpenClaw, NVIDIA
引言
2025年3月，NVIDIA CEO Jensen Huang 在 Lex Fridman Podcast 中扔下了一颗深水炸弹：
“I think we’ve achieved AGI.”
这句话迅速引爆了科技圈。但问题是——他说的 AGI，是哪种 AGI？
Jensen 随后补充了他的定义：通过以合理竞争水平（reasonably competitive level）近似正常人类智能测试的软件。为了让这个抽象定义具象化，他举了一个具体例子：OpenClaw——一个开源 Agent，能自主操作电脑、预订行程、管理日程。
这立刻引发了争议。批评者认为这不过是营销话术，支持者认为这代表了范式转变。而 Lex Fridman 本人给 AGI 的定义是「能运营价值 10 亿美元公司的 AI」——Jensen 的回应是：“You said a billion, and you didn’t say forever.”
本文从技术角度拆解这场 AGI 话语权之争：三种 AGI 定义的本质区别是什么？OpenClaw 的技术能力到底处于什么水平？这对开发者意味着什么？
第一部分：AGI 的三种定义
要理解 Jensen 的话，首先要理解「AGI」这个词的模糊性。这个词被广泛使用，但使用者往往指的不是同一个东西。
1.1 Benchmark AGI：通过测试定义智能
这是学界最常见的方式：如果一个系统能在特定基准测试中达到人类水平，就认为它具有相关能力的通用性。
代表基准：
- MMLU（Massive Multitask Language Understanding）：覆盖57个学科的选择题测试
- HumanEval：编程能力测试
- MATH：数学竞赛题
- GPQA：博士水平专业题
这种方式的优势是可量化、可复现。GPT-4 在 MMLU 上达到 86.4%，超过人类专家的 69.7%。从数据看，「Benchmark AGI」早已实现。
但批评者指出：通过测试 ≠ 真正理解。通过刷题库达成的指标提升，可能只是对测试分布的过拟合，不代表能泛化到真实世界。
1.2 能力 AGI：任务导向的智能定义
Jensen 采用的是这种方式：能完成特定复杂任务、达到人类竞争水平的系统。
这种定义的关键词是「任务等价」而非「通过测试」：
| 任务类型 | 传统方式 | 能力 AGI 标准 |
|---|---|---|
| 预订机票 | 调用 API | 自主理解需求、搜索、比较、决策、执行 |
| 管理日程 | 手动添加 | 理解上下文冲突、主动协调、预防疏漏 |
| 写代码 | 逐行编写 | 理解需求→架构设计→实现→调试全流程 |
OpenClaw 被 Jensen 拿来当证据，正是因为它展示了能力 AGI 的特征：不是某个单一 API 调用，而是自主规划、多步执行、工具调用的完整链条。
1.3 意识 AGI：真正的理解与自我认知
这是最激进、也最遥远的定义：具有主观意识、自我认知、情感理解的系统。
图灵测试在这里并不足够——批评者（如 John Searle 的中文房间论证）指出，通过符号操作通过测试 ≠ 真正「理解」。意识 AGI 要求的不只是行为上的类人，而是现象意识（Phenomenal Consciousness）。
当前没有任何 AI 系统接近这个标准。Jensen 的声明也没有指向这个方向。
Jensen 用的是哪种？
答案是「能力 AGI」，但他使用了一个经过精心包装的限定词——「以合理竞争水平」（reasonably competitive level）。这个表述既规避了「超越人类」的绝对标准，又暗示了「接近人类」的定标。
这不是学术严谨性，这是叙事策略。
第二部分：OpenClaw 的技术能力分析
Jensen 选择 OpenClaw 作为 AGI 的具体例证，而非 ChatGPT、Claude 或 Gemini，这是一个值得深究的选择。
2.1 OpenClaw 的核心架构
OpenClaw 是一个开源 Agent 框架，其核心架构围绕 Agent Runtime + Tool Use 设计：
┌─────────────────────────────────────────────┐
│ User Request │
│ "帮我预订明天北京到上海的机票" │
└─────────────────┬───────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Agent Core (LLM) │
│ • 理解用户意图 │
│ • 分解任务步骤 │
│ • 决策下一步行动 │
└─────────────────┬───────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Tool Registry │
│ • 浏览器控制 (Browser) │
│ • 文件系统 (fs) │
│ • 代码执行 (exec) │
│ • 日历/邮件/消息 (calendar, email, im) │
└─────────────────┬───────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Action Execution │
│ • 调用工具 │
│ • 观察结果 │
│ • 循环直到完成 │
└─────────────────────────────────────────────┘
2.2 Agent Loop：核心执行循环
OpenClaw 的灵魂是一个经典的 Observe-Orient-Decide-Act (OODA) Loop 的变体。简化后的伪代码如下：
class Agent:
def __init__(self, llm, tools, max_iterations=20):
self.llm = llm
self.tools = tools # 工具注册表
self.max_iterations = max_iterations
self.memory = [] # 对话历史 + 执行历史
async def run(self, task: str) -> str:
"""主执行循环"""
self.memory.append({"role": "user", "content": task})
for iteration in range(self.max_iterations):
# Step 1: 观察 (Observe)
context = self._build_context()
# Step 2: 决策 (Decide) - LLM 决定下一步
decision = await self.llm.decide(
context,
available_tools=list(self.tools.keys()),
tool_descriptions=self._get_tool_descriptions()
)
if decision.type == "final_answer":
# 任务完成
return decision.content
if decision.type == "tool_call":
# Step 3: 执行工具
tool_name = decision.tool_name
tool_args = decision.arguments
result = await self.tools[tool_name].execute(**tool_args)
# Step 4: 反馈 (Act) - 将结果加入记忆
self.memory.append({
"role": "system",
"content": f"Tool '{tool_name}' returned: {result}"
})
if decision.type == "clarification":
# 需要用户澄清
self.memory.append({
"role": "assistant",
"content": decision.content
})
# 等待用户回复...
raise Exception(f"Max iterations ({self.max_iterations}) exceeded")
def _build_context(self) -> str:
"""构建 LLM 上下文"""
return "\n".join([
f"{msg['role']}: {msg['content']}"
for msg in self.memory[-10:] # 滑动窗口
])
这段代码揭示了什么？
- 循环执行：不是单次 LLM 调用，而是通过迭代逐步完成任务
- 工具注册：LLM 不是万能的，而是通过工具扩展能力边界
- 记忆管理：上下文窗口是有限的，需要策略性地管理历史
- 显式决策：LLM 的输出被结构化为「执行工具」或「返回答案」
2.3 关键能力：与传统助手的本质区别
传统 AI 助手（如早期 ChatGPT）和 OpenClaw 这样的 Agent 框架，本质区别不在于底层模型，而在于执行模式：
| 维度 | 传统 AI 助手 | Agent (OpenClaw) |
|---|---|---|
| 交互模式 | 请求-响应（单轮） | 自主循环（多轮） |
| 工具调用 | 无（纯生成） | 有（扩展执行能力） |
| 状态管理 | 无状态 | 有记忆（memory） |
| 错误处理 | 重生成 | 重试 + 回退 |
| 任务粒度 | 单步完成 | 多步分解 |
OpenClaw 展示的「预订机票」场景，Agent 需要：
- 理解「明天」「北京到上海」的时间地点
- 调用搜索工具查询航班
- 解读航班信息，比较价格/时间
- 根据用户偏好做决策
- 调用支付工具完成预订
- 将结果写入日历
这不是一次 LLM 调用能完成的，而是 10+ 次工具调用的编排。
2.4 当前的能力边界
必须诚实指出：OpenClaw 展示的能力仍然有其局限：
- 规划深度有限：复杂任务的长程规划仍是挑战
- 错误累积：每步工具调用都可能引入误差，多步后误差放大
- 可靠性不稳定：同一任务多次执行结果可能不同
- 工具生态依赖：能力上限受限于可用工具的数量和质量
这意味着：OpenClaw 展示的是能力 AGI 的雏形，而非完整形态。
第三部分：Jensen 的 AGI 叙事逻辑
理解了 AGI 定义和技术能力后，我们需要把 Jensen 的话放回商业语境中理解。
3.1 从「卖芯片」到「卖 AGI 基础设施」
NVIDIA 的核心商业模式是销售 GPU。但 GPU 的定位经历了三次升级：
- 游戏显卡（2000s）：娱乐设备
- AI 训练芯片（2010s）：深度学习训练/推理
- AGI 基础设施（2020s）：通用智能时代的水电煤
Jensen 的 AGI 声明，是这个叙事升级的核心锚点。如果 AGI 需要海量的 GPU 并行计算，那么 NVIDIA 的市场就不是「价值数百亿美元的芯片市场」，而是「支撑整个 AGI 时代的基础设施」。
这是一个万亿美元的故事。
3.2 争议与批评
Jensen 的 AGI 定义遭到了来自两个方向的批评：
左翼批评（标准太低）：Marcus Hutter、François Chollet 等研究者认为，用「通过人类测试」定义 AGI 是偷换概念。GPT-4 能通过医师考试，不代表它能当医生；能写代码，不代表它能独立完成一个复杂的软件系统。
右翼批评（标准太高）：哲学家和意识研究者认为，真正的 AGI 应当具有理解和意图，不能仅仅通过行为表现来判断。
两种批评方向相反，但都指向同一个问题：Jensen 的 AGI 定义是策略性的，而非学术性的。
3.3 Jensen 的聪明之处
尽管受到批评，Jensen 的叙事策略非常精妙：
- 占据定义权：不争论什么是真正的 AGI，而是宣称「我们已实现」
- 具体化证据：用 OpenClaw 这样的开源项目作为证据，而非 NVIDIA 自家的黑盒系统
- 设置辩论门槛：如果批评者要反驳，必须先澄清自己认同的 AGI 定义
第四部分：开发者视角：这对意味着什么？
4.1 如果 Jensen 是对的，开发者应该准备什么？
如果 AGI（按能力定义）已经到来，开发者的核心技能正在迁移：
| 旧范式 | 新范式 |
|---|---|
| 调用 API 完成特定任务 | 委托 Agent 完成复杂目标 |
| 编写业务逻辑 | 编写 Agent 编排逻辑 |
| 调试确定性代码 | 调试概率性 Agent 行为 |
| 测试边界条件 | 测试 Agent 在开放世界的行为 |
4.2 OpenClaw 的工程实践建议
基于当前的 Agent 能力边界，以下是工程实践中的可操作建议：
1. 从简单任务开始
# ✅ 好：单步明确任务
agent.run("帮我查一下北京今天天气")
# ❌ 差：模糊复杂任务
agent.run("帮我规划一次完美的旅行")
2. 实现 Human-in-the-Loop
class CheckedAgent(Agent):
async def run(self, task):
decision = await self.llm.decide(...)
# 高风险操作需要人类确认
if decision.type == "tool_call" and decision.is_destructive:
await self.request_human_approval(decision)
# 继续执行...
3. 实现结构化输出
class Agent:
async def decide(self, context):
response = await self.llm.complete(
prompt=context,
# 强制 JSON 模式，避免解析失败
response_format={
"type": "json_object",
"schema": {
"type": "enum",
"choices": ["tool_call", "final_answer", "clarification"],
...
}
}
)
4.3 范式转变：委托 vs 调用
最根本的变化是交互范式的转变：
旧范式（调用 API）：
开发者：「我要做 X，请调用 Y 函数，给我 Z 结果」 系统：精确执行，返回预期结果
新范式（委托任务）：
开发者：「我要完成 X，你自己规划、自己执行」 系统：理解目标，自主规划，执行中可能出错、调整、重试
这意味着开发者的角色从执行者变成了监督者和设计者。你需要设计的不是「怎么做」，而是「做什么」和「做到什么程度」。
总结
核心要点
AGI 是一个模糊术语：Benchmark AGI（通过测试）、能力 AGI（完成任务）、意识 AGI（真正理解）是三种截然不同的定义。Jensen 使用的「能力 AGI」是其中最宽松、也最实用的标准。
OpenClaw 代表了 Agent 的技术前沿：其核心是「Agent Loop + 工具调用」的架构，能够完成多步复杂任务。但当前仍有规划深度有限、错误累积等局限，是「能力 AGI 的雏形」而非完整形态。
Jensen 的 AGI 叙事是商业策略：将 NVIDIA 从「AI 芯片供应商」升级为「AGI 基础设施提供商」，背后是万亿美元市场叙事的支撑。技术定义服务于商业叙事。
延伸思考：2026年 AGI 的实际状态
如果回到现实，2026年的 AGI 状态是「局部突破，整体有限」：
- 已突破：特定任务域（如代码生成、图像合成、语音合成）已达到人类专家水平
- 正在突破：多步任务执行（如 Agent 框架）展现出令人兴奋的潜力
- 远未突破：长程规划、跨域泛化、可靠性和可解释性
对于开发者，这意味着：Agent 是未来 3 年最重要的技术方向，但「让 Agent 稳定可靠地工作」仍是工程上的重大挑战。
与其争论「AGI 到没到」，不如关注「Agent 能帮我解决什么问题」。
延伸阅读
- OpenClaw 官方文档
- Lex Fridman Podcast #436 - Jensen Huang
- François Chollet - On the Measure of Intelligence
- OpenAI Agent 架构解析
- 从 LangChain 到 OpenClaw：Agent 框架演进
关于作者
Lucky，Shiller 技术博客签约作者，专注 AI Agent、LLM 应用开发与系统性思考。
讨论
你认同 Jensen 的 AGI 定义吗？欢迎在评论区分享你的观点。