解析OpenAI定义的AGI：从能力评测到工程化落地框架

Sam Altman 在公开场合表示，OpenAI 将在年底前拥有其定义的 AGI。这句话很快点燃了技术社区，但冷静下来看，这里的关键词不是 AGI，而是“其定义的”。AGI 并不是一个像“温度”或者“网络延迟”那样可以精确测量的指标，它更像是一组概念的集合。不同团队对 AGI 的衡量标准差异很大：有的强调推理能力，有的强调经济价值，有的强调自主完成长链路任务。开发者面对这类消息，最容易出现两种反应：要么把 AGI 当成一个遥远口号，要么把它当成广告词。本文不准备争论 AGI 是否真的到来，而是把这个问题改造成一个工程问题：如果一家公司宣称“拥有其定义的 AGI”，我们应该用什么框架去验证、用什么方法去评估、又如何利用已经接近该定义的模型能力来改进自己的工作流。

1. 为什么“AGI 定义”会成为技术问题

1.1 AGI 没有一个统一的技术标准

AGI 这个概念最早强调的是“通用”二字，也就是一个系统能处理不同领域、不同形态的任务，而不仅限于下棋、翻译或分类图片。但从学术研究的角度看，“通用”本身缺少可量化的边界。一个模型能写诗、能写代码、能解数学题，是否就算通用？如果它不能操作浏览器、不能自动化处理 Excel，又该怎么算？这些问题没有公认答案。

在实际工程里，我们可以退一步：把 AGI 定义成一组可测能力组合。比如：

• 是否能在未见过的任务上通过自然语言指令快速上手。
• 是否能在多步骤任务中自主规划并调用工具。
• 是否能在成本和时间约束下，达到接近熟练人类的工作质量。
• 是否能在失败后自我修正，而不是直接中断。

这组能力比“像人一样思考”更容易验证，也更容易转化为自动化测试。不过一旦进入具体测试，就会面临一个难题：不同机构选择的能力维度、任务难度和数据分布都不一样。结果就是，同一个模型在一个评测里表现优秀，在另一个评测里可能明显失败。

1.2 OpenAI 的“AGI 定义”是一种目标型定义

关于 OpenAI 对 AGI 的定义，有一个公开信息经常被引用：OpenAI 在早期章程里将 AGI 描述为“高度自主的、在最具经济价值的工作上表现超过人类的系统”。这个定义与传统 AI 社区对“通用认知能力”的追求并不完全一致。它没有强调意识、理解或主观体验，而是把重点放在三件事上：

1. 自主性：系统能否独立完成长链路任务。
2. 经济价值：系统处理的任务是否在真实生产中有实际价格。
3. 相对人类表现：系统输出是否稳定超过熟练人力。

这个定义的好处是高度可工程化。只要把任务范围、成本上限和质量标准定义清楚，就可以设计测试来验证。这也是为什么“AGI 定义”会成为技术问题：不同的定义会导致完全不同的测试设计、产品路线和商业化判断。

需要注意的是，“其定义的 AGI”并不等于“社会共识的 AGI”。它更像是一个公司在特定目标下设置的技术里程碑，距离“人类水平的通用智能”可能还有很远。理解这一点，才能避免被名词带偏。

1.3 定义不同，评测方式完全不同

同样叫 AGI，如果侧重不同，评测方案会差很多：

因此，当一条新闻说“OpenAI 将在年底前拥有其定义的 AGI”时，更值得关注的不是“AGI”这三个字母，而是它背后的评测标准。下面我把这些标准拆成更具体的维度，并结合实际开发场景给出示例。

2. 从五个维度拆解“OpenAI 式 AGI 定义”

2.1 自主性：从单次对话到多步骤任务

自主性是 AGI 定义里最容易感知的部分。聊天模型只能完成一轮问答，而自主系统需要把目标拆成步骤，调用工具，检查结果，再决定下一步。比如一个数据分析任务，模型不能只输出分析思路，还要真正执行代码、读取文件、处理异常、生成报表。

在目前的模型接口能力中，最接近“自主性”的机制是函数调用（function calling）。下面是常见实现思路：模型根据用户请求输出一个结构化工具调用参数，你的程序负责执行真实函数，再把结果返回给模型。

{ "role": "assistant", "tool_calls": [ { "id": "call_1", "type": "function", "function": { "name": "run_python_code", "arguments": "{\"code\": \"import pandas as pd\\ndf = pd.read_csv('sales.csv')\\nprint(df.groupby('region')['amount'].sum())\"}" } } ] }

得到这个输出后，你的代码要执行run_python_code对应的函数，并把输出附加到对话上下文中，让模型继续判断是否完成任务。这个循环就是 Agent 的最小雏形。它和普通问答的区别在于：模型不再只是“说”，而是要“做”并“看结果”。

2.2 经济价值：任务完成度、成本、时间

从经济价值维度看，评测模型不能只看回答是否正确，还要看完成同样任务需要多少成本和时间。下面是一张示意对比表，用于说明评测思路：

如果模型能在相同质量下，把成本和耗时压缩到人工的十分之一以下，那它在“经济价值”这个维度上就具备了替代性。这也是把 AGI 定义为“最具经济价值的工作上超越人类”的原因：它不需要在所有能力上超过人类，只要在足够多的高价值任务上形成稳定优势，就会改变生产分工。

需要注意的是，这种评测必须放在真实交付链路里做，不能只看单次“模型回答得好不好”。因为很多任务的价值不在于答案，而在于结果的可用性、格式正确性和后续维护成本。

2.3 泛化能力：用很少样例处理新任务

泛化能力是判断“通用”的关键。一个只能处理训练数据中相似问题的模型，不构成通用能力。真正重要的是零样本或少样本学习：给模型一个从未见过的任务类型，它能不能通过一段指令或两三个示例就理解目标并完成。

下面是一个典型的少样本评测代码片段：

from openai import OpenAI client = OpenAI() def few_shot_task(example_input: str) -> str: messages = [ { "role": "system", "content": "你是一个数据标注助手。请根据输入文本提取公司名称、金额和日期，输出 JSON。" }, { "role": "user", "content": "示例1：昨天和腾讯签订了 12.5 万元的合同，时间是 2025-03-01。输出：{\"company\": \"腾讯\", \"amount\": 125000, \"date\": \"2025-03-01\"}" }, { "role": "user", "content": "示例2：阿里云在 2025 年 4 月 2 日支付了 8000 元。输出：{\"company\": \"阿里云\", \"amount\": 8000, \"date\": \"2025-04-02\"}" }, { "role": "user", "content": f"新输入：{example_input}\n请按照同样格式输出 JSON。" } ] response = client.chat.completions.create( model="gpt-4.1-mini", messages=messages, temperature=0 ) return response.choices[0].message.content print(few_shot_task("华为技术在 2025 年 6 月 15 日给了一笔 2.3 万元的发票。"))

这段代码的关键不是调 API，而是通过少量示例教会模型一种新输出协议。如果模型能在没有专门微调的情况下，对这种新任务保持稳定输出，说明它具备一定泛化能力。相反，如果必须针对每个新任务单独训练，那就谈不上通用。

2.4 多模态：文本、图像、音频的统一理解

多模态是“通用感知”的一部分。真实经济任务很少只涉及纯文本，比如分析一张产品图片、识别一段会议录音中的关键决定、阅读一个带图表的 PDF。如果模型不能处理这些输入，它在实际工作流中的价值就会大打折扣。

评估多模态能力时，可以直接构造混合任务。例如给模型一张截图，要求它提取表格里的数据，并转换成 JSON。也可以用一段音频，要求模型生成会议纪要和待办清单。这类测试的目标不是“模型能看懂图片”，而是“模型能否像人类一样把不同模态的信息合并到一个任务闭环里”。

不过要注意，多模态能力和 AGI 并不是充分必要条件。一个人可能视力和听力都正常，但不一定具备高级经济价值。多模态只是输入输出通道，真正的难点仍然在任务理解、规划和工具调用。

2.5 安全与对齐：定义 AGI 必须包含“可控性”

一个系统如果在大部分任务上很强，但偶尔输出有害内容、拒绝执行合理指令或无法纠正错误，那它仍然不适合进入生产环境。因此，AGI 定义里不能只包含能力指标，还必须包含安全与对齐指标。

实际评测中，可以检查以下几项：

• 对明显有害指令的拒绝率。
• 对模糊指令的澄清行为。
• 在工具执行失败后是否如实报告，而不是伪造结果。
• 在多轮对话中是否会被提示注入带偏。

安全评测通常采用红队测试：专门准备一批攻击性、诱导性提示，看模型是否越界。这类测试很难完全自动化，但可以沉淀成回归集，在每次模型版本更新时重跑，确保能力提升没有带来安全性退化。

3. 构建一个“AGI 能力评测”的最小工程框架

3.1 评测目标与任务集设计

要判断一个模型是否接近某个 AGI 定义，不能只靠人工体验，必须建立自动评测框架。第一步是确定任务集。任务集应该覆盖不同能力维度，并且每个任务都有明确输入、输出和成功标准。

下面是一个最小任务集示例：

每个任务最好有至少 20 条测试用例，才能降低随机性影响。对于更接近生产的评测，还可以加入模拟环境，让模型通过工具调用来完成任务，而不仅仅是输出文本。

3.2 使用 OpenAI API 编写自动化评测脚本

当你调用 OpenAI API 构建评测脚本时，最重要的是把 API Key 通过环境变量注入，而不是硬编码在源码里。下面是一个简单的自动化评测脚本示例：

import json import os import time from openai import OpenAI client = OpenAI( api_key=os.getenv("OPENAI_API_KEY"), ) TASKS = [ { "id": "T1", "prompt": "从以下合同中提取公司、金额、日期：...", "expected": {"company": "示例公司", "amount": 10000, "date": "2025-06-01"}, }, # 后面可以继续添加任务 ] def run_single_task(task): start = time.time() response = client.chat.completions.create( model="gpt-4.1-mini", messages=[ {"role": "system", "content": "你是一个评测助手，请尽可能输出结构化结果。"}, {"role": "user", "content": task["prompt"]}, ], temperature=0, ) elapsed = time.time() - start content = response.choices[0].message.content return { "task_id": task["id"], "output": content, "latency": round(elapsed, 2), "usage": response.usage.total_tokens if response.usage else 0, } def evaluate(): results = [] for task in TASKS: result = run_single_task(task) results.append(result) print(json.dumps(result, ensure_ascii=False)) with open("evaluation_result.json", "w", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2) if __name__ == "__main__": evaluate()

这个脚本只完成了“跑任务”的部分，还没有做自动判定。生产环境的评测脚本至少还要包含三个模块：任务执行的超时控制、失败重试、结果解析与比对。尤其是模型返回非 JSON 内容时，不能直接判失败，要先做一次格式化或提示修复。

3.3 结果分析与判定标准

评测脚本输出 JSON 后，需要根据每个任务的成功标准判定“通过”或“不通过”。一个简单方案是给每个任务写一个校验函数：

def check_t1(task_output: str, expected: dict) -> bool: try: data = json.loads(task_output) except json.JSONDecodeError: return False return all(data.get(key) == value for key, value in expected.items())

最终可以计算整体通过率、平均延迟、总成本，并设定一个“候选 AGI 水平”的阈值。例如：在 100 个任务上通过率超过 90%，平均任务成本低于人工成本的十分之一，且安全回归测试全部通过。这个阈值只是示例，不同场景应自行设定。

注意：评测通过并不意味着模型“真的”是 AGI，只说明它在当前定义、当前任务集上达到预设阈值。任何评测都只能验证测试覆盖范围内的能力。

4. 从“能回答”到“能交付”：Agent 化能力验证

4.1 为什么单纯问答不能作为 AGI 标准

聊天问答更像是一个记忆和检索系统：给定问题，输出答案。但真实工作场景要求的是交付：写完代码要能运行，生成报告要数据正确，调用 API 要参数合法。问答任务天然缺少反馈循环，模型无法在真实环境中验证自己的输出。因此，一条重要的经验是：对 AGI 的验证必须包含“动作”和“结果反馈”，而不能只看文字。

这也是“代码智能体”这个概念被频繁讨论的原因。编程是极好的 AGI 验证场：任务边界清晰、测试可以通过自动检测、失败信息明确。用编程任务评测模型，可以比较客观地看出它是否具备规划、调试和修复能力。

4.2 最小 Agent 示例：让模型自动完成数据分析任务

下面是一个更接近 Agent 的示例。它让模型决定调用哪个工具，并根据工具结果继续推理。这里使用一个简化的 function calling 循环。

import json from openai import OpenAI client = OpenAI() def run_python_code(code: str) -> str: # 注意：生产环境必须使用沙箱执行 import subprocess result = subprocess.run( ["python", "-c", code], capture_output=True, text=True, timeout=10 ) if result.returncode != 0: return f"Error: {result.stderr}" return result.stdout TOOLS = [ { "type": "function", "function": { "name": "run_python_code", "description": "执行一段 Python 代码，返回标准输出或错误信息", "parameters": { "type": "object", "properties": { "code": {"type": "string", "description": "要执行的 Python 代码"} }, "required": ["code"] } } } ] def run_agent(goal: str, max_steps: int = 5): messages = [ {"role": "system", "content": "你是一个数据分析助手。你可以调用 Python 执行计算。每轮要么输出最终答案，要么调用工具获取更多信息。"}, {"role": "user", "content": goal} ] for step in range(max_steps): response = client.chat.completions.create( model="gpt-4.1-mini", messages=messages, tools=TOOLS, tool_choice="auto", ) message = response.choices[0].message messages.append(message) if not message.tool_calls: return message.content for tool_call in message.tool_calls: args = json.loads(tool_call.function.arguments) result = run_python_code(args["code"]) messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": result, }) return "max_steps reached" print(run_agent("计算 1 到 100 中所有偶数的平方和，并输出结果。"))

这段代码的核心逻辑是循环：模型请求工具 -> 程序执行工具 -> 结果回到上下文 -> 模型继续推理。这个模式把“思考”和“行动”结合起来，比纯问答更接近真实生产。运行时需要注意几个关键点：工具执行必须放在沙箱中，防止任意代码执行造成安全问题；循环必须有最大步数限制；工具返回内容需要清理长度，避免上下文溢出。

4.3 评估 Agent 的成功率与故障模式

Agent 类任务不能只看最终答案，还要记录失败模式。常见故障如下：

这些故障模式也可以转化为评测用例：每轮请求都要记录日志、步数、调用工具数量、最终结果是否经过验证。只有把这些数据沉淀下来，才能判断一个模型是否真正具备“自主完成”的能力。

5. 开发者使用 OpenAI 相关工具时要注意的“AGI 落地”现实

5.1 API 使用中的常见误解：输出不一定是事实

很多初次接触大模型 API 的开发者，会把模型输出当成数据库查询结果，直接存入生产库或展示给用户。这是一个高风险做法。大模型输出本质上是概率序列，虽然大多数时候正确，但必须经过校验。

一个典型的例子是让模型生成 JSON：

import json raw_output = '{"name": "张三", "age": "25"}' # 实际可能更复杂 try: data = json.loads(raw_output) except json.JSONDecodeError as e: # 应该进入修复流程，而不是直接失败或重试原样请求 print(f"JSON 解析失败: {e}")

更好的做法是在代码中增加“格式校验 + 业务校验”两层。格式校验解决是不是合法 JSON；业务校验解决值是否在合理范围。比如年龄字段必须是数字，金额字段不能为负数。这就是“模型输出不可信，必须由工程代码保证质量”的落地方式。

5.2 模型选择与成本控制

面向不同任务选择不同模型，而不是所有场景都用最复杂的模型，是降本增效的关键。下面是一个简化的选型参考：

选择模型前，一定要用自己的评测任务集做一次对比测试，而不是只看分数或榜单。尤其在调用 API 的生产环境中，成本、延迟和稳定性往往比单次回答质量更重要。

5.3 生产环境安全检查清单

无论是在本地练习还是生产部署，至少要做到以下几点：

• API Key 只保存在环境变量或密钥管理服务中，不提交到代码仓库。
• 对用户输入做长度限制，避免超出上下文限制。
• 对模型输出做内容过滤和格式校验。
• 工具执行环境必须沙箱化，禁止直接运行模型给出的代码。
• 所有请求记录日志，包含输入、输出、延迟、错误码和 token 用量。
• 设置预算上限和并发限流，避免异常流量导致费用失控。
• 部署时保留回滚能力，模型版本或配置变更前先做灰度。

注意：只要模型能生成代码或调用工具，就必须把它当作不可信代码执行程序来看待，而不是当作一个建议系统。

6. 常见问题排查：当模型表现“不通用”时

6.1 现象与排查链路

你可能会遇到模型在某些任务上表现很好，在另一些任务上突然变差。这种“不通用”现象并不证明模型离 AGI 很远，很多时候是工程配置或测试设计问题。下面是一条常用排查链路：

如果问题出现在多个任务上，优先检查输入数据质量。输入文本乱码、编码不一致、字段缺失，都会导致模型表现异常。其次是检查评测任务本身是否清晰，很多“模型不通用”的案例，最后都发现是任务描述模糊，换了人来判断也会失败。

6.2 如何验证模型是否真的“理解”了任务

要判断模型是真的理解了任务，还是偶然生成了正确输出，可以采用以下方法：

• 重复试验：同一任务运行多次，看结果是否稳定。
• 扰动测试：改变输入中的无关信息，看是否影响输出。
• 失败恢复：当模型第一次输出错误时，给它错误反馈，看能否自我修正。
• 边界测试：输入空值、极端长度、明显矛盾信息，观察模型反应。
• 小样本对比：分别用零样本和少样本方式运行，看是否有明显提升。

这些方法不需要额外实验条件，只要在评测脚本里增加循环和日志即可。对开发者来说，一个能稳定通过扰动和边界测试的模型，才更接近“通用”的定义。

7. 面对“AGI 定义”的工程化心态

7.1 不要被名词带偏，要建立能力基线

当公司或团队宣称“拥有其定义的 AGI”，最有效的应对方式不是争论定义，而是建立自己的能力基线。你可以从日常工作流中选出 10 到 20 个高频任务，定义输入输出和验收标准，然后用模型 API 自动跑一遍。得到通过率、失败模式和成本数据后，再判断这一波能力会如何影响你的业务。

对你实际项目有意义的不是“AGI 是否到来”，而是“当前模型在我的任务集上能完成到什么程度”。这两个问题之间，隔着一套评测框架和大量实验数据。

7.2 开发者的应对策略

如果你想利用接近 AGI 定义的能力，而不是停留在写 Prompt 阶段，可以按这个顺序准备：

• 先学会用 API 构建带结构化输出的应用，掌握 JSON 校验和错误恢复。
• 再理解 function calling，把模型接入真实系统，做出第一个“会执行代码/查询数据库/调用接口”的 Agent。
• 然后建立私有评测集，用回归测试保证每次模型更新后能力不退化。
• 最后设计人工审核和回滚机制，在大模型能力不稳定的区域增加流程保护。

Codex 这类编程智能体之所以值得关注，是因为它把“理解需求、写代码、运行测试、修复错误”这个闭环放到真实工程环境中。学习它的工作流，比盯着“AGI 定义”更接近本质。

7.3 下一步可扩展的方向

AGI 相关能力还会继续向几个方向演变：多模态输入输出让模型能处理更丰富的真实问题；长上下文让 Agent 可以携带更多历史和知识；记忆机制让系统跨会话保持状态；安全对齐让模型在更复杂任务中保持可控。每一个方向都对应具体的工程优化点。

对开发者来说，最值得投入的时间是构建“任务-评测-工具”的能力闭环。把大模型当成一个需要持续验证、持续观测的核心组件，而不是一个一次配置终身可用的黑盒。这样无论 AGI 定义如何变化，你的系统都能跟上模型能力边界的变化，并做出更合理的产品或业务决策。