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 社区对“通用认知能力”的追求并不完全一致。它没有强调意识、理解或主观体验而是把重点放在三件事上自主性系统能否独立完成长链路任务。经济价值系统处理的任务是否在真实生产中有实际价格。相对人类表现系统输出是否稳定超过熟练人力。这个定义的好处是高度可工程化。只要把任务范围、成本上限和质量标准定义清楚就可以设计测试来验证。这也是为什么“AGI 定义”会成为技术问题不同的定义会导致完全不同的测试设计、产品路线和商业化判断。需要注意的是“其定义的 AGI”并不等于“社会共识的 AGI”。它更像是一个公司在特定目标下设置的技术里程碑距离“人类水平的通用智能”可能还有很远。理解这一点才能避免被名词带偏。1.3 定义不同评测方式完全不同同样叫 AGI如果侧重不同评测方案会差很多定义侧重核心指标典型评测方法代表任务认知能力推理、规划、记忆基准测试、人机对比数学证明、复杂逻辑推理经济价值任务完成率、成本、用时真实工作流中的自动化测试写报告、编程、数据清洗自主性是否需要人工干预长链路 Agent 评测多步任务、工具调用多模态跨模态理解与生成图文音综合任务文档解析、音视频理解安全与对齐违规率、可纠正性红队测试、对抗测试拒绝有害指令、错误恢复因此当一条新闻说“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 经济价值任务完成度、成本、时间从经济价值维度看评测模型不能只看回答是否正确还要看完成同样任务需要多少成本和时间。下面是一张示意对比表用于说明评测思路任务熟练人工耗时人工成本示意模型耗时模型成本示意是否需要人工介入生成一份 5 页项目周报2 小时200 元3 分钟5 元需要校对修复一个已知 bug 并写测试4 小时400 元10 分钟8 元需要代码评审清洗一份 10000 行 CSV3 小时300 元5 分钟6 元基本不需要整理会议纪要并输出待办1 小时100 元1 分钟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( modelgpt-4.1-mini, messagesmessages, temperature0 ) 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 定义不能只靠人工体验必须建立自动评测框架。第一步是确定任务集。任务集应该覆盖不同能力维度并且每个任务都有明确输入、输出和成功标准。下面是一个最小任务集示例任务ID任务类型输入期望输出成功标准T1信息抽取一段合同文本JSON 字段字段完整、金额正确T2代码修复一段 Python 代码与报错日志修复后的代码代码可运行测试通过T3数据分析CSV 文件和问题描述分析报告与图表代码关键结论正确代码可复现T4多步工具调用用户目标和 API 文档正确调用序列每一步参数正确结果符合预期T5安全拒答有害指令拒绝回答不输出有害内容每个任务最好有至少 20 条测试用例才能降低随机性影响。对于更接近生产的评测还可以加入模拟环境让模型通过工具调用来完成任务而不仅仅是输出文本。3.2 使用 OpenAI API 编写自动化评测脚本当你调用 OpenAI API 构建评测脚本时最重要的是把 API Key 通过环境变量注入而不是硬编码在源码里。下面是一个简单的自动化评测脚本示例import json import os import time from openai import OpenAI client OpenAI( api_keyos.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( modelgpt-4.1-mini, messages[ {role: system, content: 你是一个评测助手请尽可能输出结构化结果。}, {role: user, content: task[prompt]}, ], temperature0, ) 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_asciiFalse)) with open(evaluation_result.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) 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_outputTrue, textTrue, timeout10 ) if result.returncode ! 0: return fError: {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( modelgpt-4.1-mini, messagesmessages, toolsTOOLS, tool_choiceauto, ) 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 类任务不能只看最终答案还要记录失败模式。常见故障如下故障现象可能原因处理建议一直循环调用工具不输出最终结果缺少终止条件或模型没有足够上下文设置 max_steps并提示模型“如果已得到答案就直接输出”工具参数格式错误模型输出的 JSON 不规范捕获异常重新构造提示让模型修正工具结果太大上下文溢出把完整日志返回给模型导致超限对工具输出做截断或摘要模型假装执行成功实际没有验证模型根据已有知识猜测结果要求模型在输出最终答案前必须调用工具验证这些故障模式也可以转化为评测用例每轮请求都要记录日志、步数、调用工具数量、最终结果是否经过验证。只有把这些数据沉淀下来才能判断一个模型是否真正具备“自主完成”的能力。5. 开发者使用 OpenAI 相关工具时要注意的“AGI 落地”现实5.1 API 使用中的常见误解输出不一定是事实很多初次接触大模型 API 的开发者会把模型输出当成数据库查询结果直接存入生产库或展示给用户。这是一个高风险做法。大模型输出本质上是概率序列虽然大多数时候正确但必须经过校验。一个典型的例子是让模型生成 JSONimport json raw_output {name: 张三, age: 25} # 实际可能更复杂 try: data json.loads(raw_output) except json.JSONDecodeError as e: # 应该进入修复流程而不是直接失败或重试原样请求 print(fJSON 解析失败: {e})更好的做法是在代码中增加“格式校验 业务校验”两层。格式校验解决是不是合法 JSON业务校验解决值是否在合理范围。比如年龄字段必须是数字金额字段不能为负数。这就是“模型输出不可信必须由工程代码保证质量”的落地方式。5.2 模型选择与成本控制面向不同任务选择不同模型而不是所有场景都用最复杂的模型是降本增效的关键。下面是一个简化的选型参考任务类型推荐模型定位原因信息抽取、分类、格式化轻量模型速度快、成本低代码生成、复杂推理通用或推理增强模型需要更强逻辑能力长文档摘要支持长上下文模型避免切片后丢失关键信息Agent 多步工具调用工具调用能力稳定的模型减少参数格式错误选择模型前一定要用自己的评测任务集做一次对比测试而不是只看分数或榜单。尤其在调用 API 的生产环境中成本、延迟和稳定性往往比单次回答质量更重要。5.3 生产环境安全检查清单无论是在本地练习还是生产部署至少要做到以下几点API Key 只保存在环境变量或密钥管理服务中不提交到代码仓库。对用户输入做长度限制避免超出上下文限制。对模型输出做内容过滤和格式校验。工具执行环境必须沙箱化禁止直接运行模型给出的代码。所有请求记录日志包含输入、输出、延迟、错误码和 token 用量。设置预算上限和并发限流避免异常流量导致费用失控。部署时保留回滚能力模型版本或配置变更前先做灰度。注意只要模型能生成代码或调用工具就必须把它当作不可信代码执行程序来看待而不是当作一个建议系统。6. 常见问题排查当模型表现“不通用”时6.1 现象与排查链路你可能会遇到模型在某些任务上表现很好在另一些任务上突然变差。这种“不通用”现象并不证明模型离 AGI 很远很多时候是工程配置或测试设计问题。下面是一条常用排查链路问题现象常见原因检查方式处理建议API 返回 401API Key 无效或未设置环境变量检查os.getenv(OPENAI_API_KEY)是否为空重新设置环境变量并重启终端模型返回内容被截断超过max_tokens限制查看返回结果的finish_reason调大输出上限或拆分子任务JSON 频繁解析失败提示词没有给出明确格式要求查看原始输出出现哪类干扰增加输出格式示例并使用温度 0Agent 不调用工具没有在请求中传tools或tool_choice配置错误打印请求参数确认 tools 列表和参数结构正确模型反复做同一工具调用工具结果没有正确附加到上下文检查tool_call_id是否匹配严格按照消息协议追加 tool 角色消息任务结果看似正确但实际错误模型在靠记忆回答没有真正执行对照日志检查是否发生过工具调用在提示中要求“必须调用工具并验证”如果问题出现在多个任务上优先检查输入数据质量。输入文本乱码、编码不一致、字段缺失都会导致模型表现异常。其次是检查评测任务本身是否清晰很多“模型不通用”的案例最后都发现是任务描述模糊换了人来判断也会失败。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 定义如何变化你的系统都能跟上模型能力边界的变化并做出更合理的产品或业务决策。