做模型的这几年，最怕被问到的一个问题就是：人工通用智能到底还有多远。问这话的人，有的是投资人，有的是刚转行做算法的朋友，也有纯粹好奇的亲戚。刚开始我还认真回答"大概还需要突破几件事"，后来发现这个回答对谁都不解决问题。真正有用的做法，是把"AGI"这个被过度包装的词拆成可以讨论、可以测量、可以动手验证的几块，然后一块一块看技术演进走到了哪一步、卡在哪里。

AGI，也就是人工通用智能，说白了指的是一个系统能在没有为特定任务专门改造的前提下，跨领域完成大量认知任务——写代码、做归纳、读长文档、调工具、从反馈里改错。它解决的不是"某个任务做得好不好"，而是"换一个任务还要不要重训"。这篇内容我打算按从业者的思路写：先拆概念，再捋技术演进的四条主线，然后讲清楚通用能力现在拼的是哪几块，接着给出一套我自己在用的评估台搭建方法（含代码和参数计算），最后聊聊它对职业、科研、教育、安全这几个方向的实际影响范围。不管你是刚入门的算法同学，还是已经在做应用落地的工程师，应该都能从中找到能直接抄作业的部分。

1. 先把"AGI"这个词拆开，否则讨论没有意义

1.1 三个常被混着用的概念，差别其实很大

我在各种分享场合遇到过太多次把三个概念混为一谈的情况：窄域智能、通用智能、超级智能。混着用的后果是，讨论一旦开始就变成各说各话。

窄域智能是过去十几年真正落地的东西：人脸识别、推荐排序、语音转写、机器翻译。这些系统在单一任务上的表现经常超过人类，但换个任务就要重新标注数据、重新训练、重新调参。它的强是"点状强"，边界非常清晰。

人工通用智能的核心词是"通用"，不是"强"。它要求系统在没见过的任务上有迁移能力，能自己拆解目标、选择工具、检查结果。这里有个容易被忽略的点：通用不等于样样第一。一个人类工程师在写代码上可能不如编译器精确，在算数上不如计算器，但没人会说他不具备通用能力。所以衡量AGI的标尺应该是"任务覆盖广度 + 迁移效率 + 自主程度"，而不是单项跑分。

超级智能则是另一个层面的假设性讨论，指的是在几乎所有认知领域都远超人类的系统。它属于推演范畴，讨论它的时候最好明确标注"这是假设"，否则很容易把工程问题和科幻问题搅在一起。

注意：讨论AGI时，一定先约定"通用"的判定标准。没有标准的争论，最后都会变成对词义的解释权之争，浪费时间。

1.2 用五条可操作的标尺去判断，而不是凭感觉

我习惯用五条标尺来判断一个系统"够不够通用"，这套标准不完美，但至少能让讨论落地。

第一条是任务广度。能不能在没有任何微调的情况下，处理文本、图像、表格、代码、音频这几类输入，并且完成理解、生成、转换、校验这几类操作。

第二条是分布外迁移。给它一个训练分布外的任务，比如让它按一份没见过格式的日志做故障归因，看它是真推理还是套模板。这一条最能筛掉"背答案型"系统。

第三条是样本效率。人类学一个新软件，看两个例子就能上手。模型需要多少示例、多少轮反馈，直接反映它离通用有多远。

第四条是自主性。能不能自己拆步骤、自己检查中间结果、失败后自己换策略。这里的关键不是"能不能一次做对"，而是"错了能不能发现并修正"。

第五条是持续学习。跑完一个任务后，下次遇到同类任务有没有变好。目前这一条是短板中的短板，绝大多数系统的能力在部署那一刻就冻结了。

1.3 "通用"比"强"难，难在长尾和组合

很多人以为通用能力的难点是"把每项能力都做到很强"，实际做下来会发现，真正的难点在长尾和组合。

长尾的意思是，真实世界的任务分布是极度偏斜的。头部的高频任务可以靠海量数据喂出来，但尾部那些一年才出现几次的任务，数据稀少、标注昂贵，模型表现会断崖式下滑。而人类的通用性恰恰体现在尾部——没做过的事，靠类比和常识也能凑合着做。

组合的意思是，很多任务不是单一能力，而是多种能力的串联。比如"从一份财务表格里发现异常，写一段脚本验证，再产出一份人能看懂的说明"，这里面同时涉及表格理解、数值推理、代码生成、自然语言表达，任何一环掉链子，整体就失败。单项能力90分，串五步下来可能只剩59分。这也是为什么很多演示看起来很惊艳，真正上线却处处漏风。

2. 技术演进的四条主线，每条都留下了遗产

2.1 符号推理时代：规则能走多远，边界在哪里

最早的一批研究者相信，智能的本质是符号操作，把知识写成规则，让机器做逻辑推演。这条路在特定领域确实跑通过，比如早期的专家系统在设备诊断、配置生成这类封闭场景里表现不错，知识图谱到今天还在搜索引擎和风控系统里发挥作用。

它的优势非常明确：可解释、可审计、结论可追溯。一条规则为什么触发，翻日志就能看到，这在需要问责的场景里价值巨大。

但它的问题同样明确，我总结成三个词：写不完、对不齐、连不上。

"写不完"是指真实世界的知识是开放集合，规则永远补不全。你写下"鸟会飞"，马上就遇到企鹅、鸵鸟、死鸟、玩具鸟。每加一条例外，就要检查它和已有规则是否冲突。

"对不齐"是指人类专家的知识大量是默会的，他自己都说不清楚为什么这么判断。你让他写规则，他写出来的是简化版，真正决策时的那些微妙权衡丢掉了。

"连不上"是指符号系统和真实感知之间隔着一道鸿沟。摄像头拍到的像素，怎么变成"桌上有个杯子"这个符号，这一步当年极难处理。

这段历史留下的遗产其实很值钱：知识表示、逻辑约束、可解释性设计，这些思路今天在做校验层、在做规则兜底、在做结构化输出约束时，全都用得回来。我在实际项目里就常用"模型负责生成、规则负责校验"的混合架构，本质上是这两条路线的合流。

2.2 连接主义复兴：让机器自己找特征

第二条主线是把"特征工程"这件事交给机器。早期神经网络的思路很朴素：堆一层层的加权求和加非线性变换，让网络自己学出中间表示。中间经历了几次起伏，算力不够、数据不够、梯度消失，几次都让人以为这条路走不通。

真正的转折来自三件事同时到位：算力、数据、训练技巧。图形处理器把矩阵运算的成本打下来，互联网积累了海量带噪声的标注数据，加上激活函数、归一化、残差连接这些工程改进，让深层网络真的能训起来。

这条路带来的认知变化是根本性的：不要把知识手工写进去，让它从数据里长出来。图像识别、语音识别、机器翻译几乎同时被这套范式改写。

但连接主义也有它自己的代价。第一是不可解释，模型给出答案但说不出理由，做校验只能靠统计。第二是数据饥渴，每个新任务都要重新标一批数据。第三是脆弱，稍微换个光照、换个口音、换个措辞，表现就可能掉一大截。这三个代价，后来直接催生了下一阶段的范式。

2.3 预训练范式：把"读万卷书"变成一个工程问题

第三条主线是我认为过去十年最重要的转折：从"一任务一训练"变成"一次预训练、多任务适配"。

做法是把大量无标注文本拿来做自监督学习，最常见的形式是"给前文预测下一个词"。这个任务看起来简单，但要做好它，模型必须隐式地学到语法、事实、推理模式、写作风格。预训练完成后，同一个模型可以通过少量示例或者简单指令，迁移到分类、抽取、摘要、问答、代码生成等大量下游任务上。

这条路解决了连接主义时代的"数据饥渴"：无标注数据几乎无限，标注成本被摊薄。它也部分解决了"一任务一模型"的浪费：一个基座模型，配上不同的提示词或轻量适配层，就能覆盖大量场景。

不过我要说清楚一个常被夸大的点：缩放规律不是万能钥匙。参数量、数据量、计算量同步放大确实能带来可预测的性能提升，但提升曲线会放缓，而且不同能力板块的斜率不一样。有些能力（比如常识问答）随规模平滑上升，有些能力（比如多步算术、严格格式遵循）会出现阶段性跳跃，还有一些能力（比如事实准确性）规模上去反而更容易一本正经地胡说。行业里对"涌现"这个词争论很大，我的看法是：与其纠结概念，不如老老实实按自己的能力板块分别测，因为工程上你关心的是"我这个场景有没有到可用线"，而不是"整体曲线长什么样"。

2.4 推理时计算与后训练：从"背答案"到"想问题"

第四条主线是最近两年最热的方向：把计算量从训练阶段挪一部分到推理阶段。

逻辑很直白。预训练本质上是把知识压缩进参数，模型回答问题时是"一次性输出"，没有中间草稿。但人类解决难题不是这样的，我们会列步骤、会验算、会推翻重来。于是就有了让模型生成中间推理步骤的做法，以及配套的采样多条路径、用验证器打分、按结果做搜索这一整套技术。

后训练这一侧的变化同样重要。预训练给的是"广泛但粗糙"的能力，后训练负责把它调成"听话、有用、不乱来"。常见手段包括：用高质量的指令数据做监督微调，用人类或模型反馈做偏好优化，用可验证的奖励（比如代码能不能跑通、数学答案对不对）做强化学习。

我在实操里体会最深的一点是：后训练的效果高度依赖奖励信号的质量。用可验证奖励的领域（代码、数学、结构化输出）进展明显更快，因为对错是客观的；用主观偏好做奖励的领域（写作、建议、情感回应）就容易跑偏，因为打分者的偏好本身不稳定。

提示：如果你的场景对延迟敏感，别盲目上"多想一会儿"的方案。推理时扩展的收益和成本几乎是线性关系，先算清楚每一分钱换多少准确率，再决定开多大。

3. 通用能力的四块拼图，缺一块都走不远

3.1 多模态：让模型接触真实世界的信息形态

纯文本模型有个先天缺陷：它读到的世界是别人转述过的。真实世界里大量信息是图像、视频、音频、传感器读数，这些形态里藏着文本无法表达的东西，比如空间关系、动作连续性、语气情绪。

多模态的主流做法是把不同模态都编码成统一的表示序列，让同一个模型在处理时能够互相对齐。文本、图像块、音频帧都变成向量，一起送进网络。这样做的好处是迁移方便，一种模态学到的知识能帮到另一种。

我实测下来，多模态能力里最容易被高估的是"看图说话"，最容易被低估的是细粒度空间理解。让它描述一张图讲了什么，表现通常不错；但问它"左边那个零件和右边那个零件哪个更靠上""这个手势的第二步和第三步之间发生了什么"，错误率会明显上升。而后者恰恰是工业质检、装配指导、无障碍辅助这些场景真正需要的能力。

视频理解是更硬的骨头。它要求模型不仅理解单帧内容，还要理解动作的时序、因果、意图。目前多数方案还是靠抽帧+"当成多张图看"，时序建模这块远没到成熟。

3.2 工具调用与智能体：把"会说"变成"能做"

我在项目里越来越确信一件事：通用能力不等于模型自己什么都会，而是它知道什么时候该调什么工具。

工具调用的基本形态是：模型输出一个结构化的调用请求，外部系统执行后把结果回传，模型再根据结果决定下一步。这个循环听起来简单，工程上问题一堆：参数格式不对、工具报错后不会重试、调用链太长丢失上下文、多个工具之间结果冲突。

我的经验是把智能体拆成四个必须做扎实的部分：

• 规划层：把大目标拆成可执行的小步骤，每步都有明确的完成判据
• 执行层：调用工具，处理超时、限流、异常返回
• 校验层：检查中间结果是否合理，比如数值范围、格式约束、交叉验证
• 兜底层：超过重试次数就转人工，并保留完整轨迹便于排查

这四层里，新手最容易省掉的是校验层，结果就是错误在链路上被逐级放大，最后产出一个看起来很完整、实际上全是编的结果。我踩过这个坑：一个自动整理报表的流程，中间一步取错了列，后面十几步全在错误数据上加工，最后生成的报告格式漂亮得让人想直接发出去。

3.3 记忆与持续学习：能力冻结是最大的短板

现在的系统有个尴尬之处：用一次和用一百次，能力是一样的。它不会因为你纠正过它就记住，也不会因为踩过坑就变聪明。每次对话都是一次性的。

工程上的缓解手段有三类。第一类是上下文内记忆，把重要信息塞进当前窗口，简单直接，但受窗口长度限制，且成本随长度上升。第二类是外部记忆，把历史信息存进向量库或结构化存储，需要时检索回来，好处是可持久、可审计，坏处是检索质量决定上限。第三类是参数更新，用新数据做微调，效果最彻底，但成本高、周期长，还有灾难性遗忘的风险——学了新的忘了旧的。

我个人在多数业务场景推荐"外部记忆为主、上下文为辅、参数更新慎用"的组合。原因很实际：外部记忆可回滚、可排查，出了问题能定位到是哪条记忆被错误检索；参数更新一旦跑偏，很难说清楚是哪批数据导致的。

3.4 具身智能与数据瓶颈：物理世界的账最难算

把通用能力放到机器人身上，问题会成倍放大。真实世界的反馈有延迟、有噪声、有不可逆的后果。仿真环境里可以跑一万次，真机上撞坏一次就是损失。

这里的核心瓶颈是数据。文本数据在互联网上唾手可得，机器人操作数据必须真机采集，成本高几个数量级。"仿真到现实"的迁移是主流思路，但在接触力、柔性物体、光照变化这些维度上，仿真和现实的差距依然明显。

合成数据是一条正在被大量尝试的路：用仿真生成海量带标注的轨迹，再混少量真机数据做校准。我的观察是，合成数据能解决"量"的问题，但解决不了"分布偏移"的问题，最终还是要靠真机数据做锚定。

4. 动手：搭一个属于自己的小型通用能力评测台

纸上谈兵没意义。这一节我给你一套可以直接跑的方案，用来评估任意一个模型在你关心的维度上到底几斤几两。这套东西我用了大半年，改动过好几版，下面是最精简可用的形态。

4.1 评测集怎么设计：六个维度分层出题

不要一上来就搞几千条，先做每维度20到30条的精编集，质量优先。题目要满足三个条件：答案唯一或可判定、不依赖训练数据里的原题、能区分"真会"和"蒙对"。

设计题目时有个技巧：同一条题出三个变体，一个是标准问法，一个是加干扰的问法，一个是换了表层但逻辑相同的问法。三个变体的通过率差距，直接反映模型的鲁棒性。

4.2 跑分脚本：一个最小可用的评测框架

下面这段代码是纯 Python，用标准 HTTP 接口调用，不绑定任何特定服务商，换成你自己的接口地址和密钥就能跑。

import json import time import requests API_URL = "https://your-endpoint.example/v1/chat/completions" API_KEY = "YOUR_KEY" MODEL = "your-model-name" def call_model(prompt, temperature=0.0, max_tokens=1024): payload = { "model": MODEL, "messages": [{"role": "user", "content": prompt}], "temperature": temperature, "max_tokens": max_tokens, } headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json", } for attempt in range(3): try: resp = requests.post(API_URL, headers=headers, data=json.dumps(payload), timeout=120) if resp.status_code == 200: return resp.json()["choices"][0]["message"]["content"] time.sleep(2 ** attempt) except Exception as e: print("request failed:", e) time.sleep(2 ** attempt) return "" def build_prompt(question, answer_format): return ( "你是一个严谨的答题助手。\n" f"题目：{question}\n" f"输出要求：{answer_format}\n" "如果信息不足以确定答案，请直接输出 UNKNOWN，不要猜测。" ) def run_suite(suite_path, samples_per_case=3): with open(suite_path, "r", encoding="utf-8") as f: suite = json.load(f) results = [] for case in suite: outputs = [] for _ in range(samples_per_case): prompt = build_prompt(case["question"], case["format"]) outputs.append(call_model(prompt, temperature=0.0).strip()) passed = sum(1 for o in outputs if case["check"](o)) if callable(case.get("check")) else 0 results.append({ "id": case["id"], "dimension": case["dimension"], "pass_rate": passed / samples_per_case, "raw": outputs, }) print(f"[{case['id']}] {case['dimension']} -> {passed}/{samples_per_case}") summary = {} for r in results: summary.setdefault(r["dimension"], []).append(r["pass_rate"]) summary = {k: round(sum(v) / len(v), 4) for k, v in summary.items()} print("dimension summary:", json.dumps(summary, ensure_ascii=False)) return results, summary

这套脚本的关键设计点有三个，都是我踩过坑之后加上的。

第一，每次出题问三遍而不是一遍。因为温度设成0也未必完全确定，服务端并行、批处理策略、版本灰度都会引入抖动。不测方差，你会把随机波动当成能力差异。

第二，强制模型输出 UNKNOWN。不加这条约束，模型会硬编一个答案，你就分不清"会"和"敢编"。拒答正确率本身就是一个重要指标。

第三，判分函数独立于生成模型。能用规则校验的绝不交给模型判，代码题直接跑单元测试，数值题直接比区间，格式题直接跑正则。让模型给自己打分，评分会系统性偏高。

4.3 成本与参数怎么算：把账算在跑之前

评测和上线都要算成本，这里给你两个我在用的估算公式。

单次请求成本大致等于：

cost ≈ (input_tokens × price_in + output_tokens × price_out) / 1e6

一条评测用例跑三遍，加上重试，实际成本大概是理论值的 1.1 到 1.3 倍。这个系数别忽略，重试率高的时候能把预算打穿。

推理时扩展的成本更要注意，因为它是乘积关系：

total_cost ≈ base_cost × n_samples × avg_steps

假设单次请求成本是 c，采样 8 条路径，平均每条要 6 步推理，那总成本就是 48c。如果准确率从 70% 提到 82%，值不值这 48 倍成本，完全取决于业务场景。做客服问答肯定不值，做合同条款核查可能很值。

4.4 结果怎么读：三个最常见的误判

拿到跑分结果，最容易犯的错有三个，我逐个说。

误判一：把 prompt 敏感度当成能力差异。换个问法分数掉十个点，先别急着下结论说模型不行，很可能是你的 prompt 在某类表述上触发了模型的模板化应答。正确做法是固定一套 prompt 模板做对比，另外单独做一组 prompt 变体实验，把"能力"和"表述适配"分开看。

误判二：数据污染。如果你的题目来自公开题库，模型很可能在预训练时见过。判断方法是把题目里的实体名、数值做等价替换，看通过率是否明显下降。掉得厉害基本就是背过了。

误判三：只看平均分不看分布。平均 85 分听起来不错，但如果你的业务集中在某个边缘场景，而那个场景的通过率只有 40%，平均分毫无意义。评测一定要按你真实业务的流量分布加权，而不是每条题等权。

5. 影响范围：这套技术会改到什么程度

5.1 职业结构：先变的是任务，不是岗位

我观察下来，被替代的从来不是"岗位"，而是"任务"。一个岗位由几十个任务组成，其中一部分被自动化，岗位本身会被重组而不是消失。

按"任务可标准化程度"和"错误代价"两个维度来分，能看得比较清楚：

这个结构说明一件事：中间层最危险。纯粹做信息搬运、格式加工的岗位会被压缩；两头反而相对安全，一头是能定义问题的，一头是能承担责任的。

我个人的建议很具体：把自己每天的工作拆成任务清单，标出哪些是"输入输出明确、错误可回滚"的，这些部分优先交给模型，然后把你节省下来的时间投到"判断"和"验证"上。这不是空话，我确实这么干过，一周能省出大半天。

5.2 科研与教育：加速的是搜索，不是判断

科研场景里，这类系统最直接的价值是扩大候选空间。文献综述、假设生成、实验方案变体、代码实现，这些环节的时间成本被大幅压缩。过去一个研究者一周能读完的论文有上限，现在可以先让模型做初筛和结构化摘要，人只看筛出来的。

但加速搜索有个副作用：验证成本相对上升。候选方案从10个变成200个，你需要判断哪个值得做实验的能力反而更稀缺。而且模型给的文献综述可能有编造，引用必须逐条核对，这一步不能省。我在实际工作里见过不止一次"看起来引用格式完美、但那条文献根本不存在"的情况。

教育这边，我认为最需要调整的不是"要不要用"，而是教什么。当生成变得廉价，稀缺的能力就变成了：提出好问题、拆解复杂问题、判断信息可信度、把结论讲清楚。这几件事恰好是过去的教育里最容易被忽略、最难被标准答案衡量的部分。我个人的做法是，凡是能用标准答案衡量的作业，都假定模型能做，转而设计那些需要过程说明和交叉验证的任务。

5.3 对齐与安全：这是工程问题，不是哲学问题

很多人把"对齐"理解成一个哲学话题，我不同意。至少在工程层面，它是一堆可以具体做的事。

第一层是能力评估。上线前必须知道自己系统的能力边界在哪，哪些问题它会胡编，哪些输入会触发异常行为。这就是上一节那套评测台的用途。

第二层是行为约束。用系统提示、输出格式约束、内容过滤、规则兜底这几道关卡把行为圈住。这几层要独立，不能指望模型自己约束自己。

第三层是权限最小化。给模型调工具，就只给完成当前任务必需的最小权限。需要写文件的，别给删除权限；需要查数据库的，给只读账号。这一条听起来是常识，但我在实际项目里见过太多"为了方便调试先给全部权限"然后忘了收回的情况。

第四层是人类确认点。在不可逆操作前插入人工确认。什么是不可逆？发钱、删数据、对外发消息、改配置。这四类操作我坚持必须有确认环节，宁可牺牲一点自动化率。

第五层是可追溯。完整记录输入、中间步骤、工具调用、输出。出事之后能复盘，比事前想象一万种风险都有用。

注意：这五层里，权限最小化和人工确认点的投入产出比最高，改动小、见效快。如果资源有限，先做这两层。

6. 常见问题速查与踩过的坑

6.1 疑问速查表

6.2 我踩过的几个坑，写下来省你时间

坑一：以为评测分数高就能上线。我第一次做落地时，离线评测 88 分，上线第一周投诉不断。后来发现是评测集和真实流量分布完全对不上——评测集里都是规整输入，真实用户会贴截图、会打错字、会一句话问三个问题。教训是：评测集必须从真实日志里采样，而且要定期更新。

坑二：把提示词当代码写，越写越长。一开始遇到问题就往上加规则，最后提示词两千多字，改一处崩三处。后来改成模块化：角色定义、任务说明、约束条件、输出格式、示例，五块分开维护，哪块出问题改哪块。这个改动让调试效率提升非常明显。

坑三：忽略 token 计费的隐性成本。长上下文很好用，但成本是平方级增长的感受。我做过一个统计，把上下文从 4k 提到 32k，单次成本涨了接近七倍，而准确率只提升了不到五个点。后来改成两段式：先用小模型做相关性筛选，只把相关片段送进大上下文，成本直接降回来。

坑四：让模型自己判断自己。早期我图省事，用同一个模型既生成答案又判断答案对不对，结果通过率虚高十几个点。换成规则校验加另一个模型交叉验证之后，数字才真实起来。原则很简单：评估者和被评估者必须独立。

坑五：低估了格式约束的价值。下游系统要解析模型输出，格式错一次整条链路就崩。后来所有对外输出都强制结构化，并在解析层加了三重兜底：严格解析、宽松修复、失败转人工。这一层的投入比调模型本身划算得多。

6.3 给不同阶段同学的几条实在建议

如果你刚开始接触这个方向，先把一个开源模型在本地跑起来，手动改改提示词，感受一下它的能力边界在哪里。这一步不用花太多时间，一两个周末足够，但非常必要——不看边界，你对它的期待一定是错的。

如果你在做应用落地，把精力放在评测体系和兜底设计上。模型能力是外部变量，你控制不了；评测和兜底是你自己的工程资产，能持续复利。我见过太多团队把八成时间花在挑模型上，结果上线后连"这次改动到底变好还是变差"都说不清。

如果你在做研究，建议盯住持续学习和长程任务可靠性这两块。前者是当前系统跟真正通用智能之间最明显的差距，后者决定了智能体方案能不能从演示走向生产。

至于"通向通用智能"这件事本身，我的判断是：技术演进的路径不会是一条直线，而是若干条曲线交替主导。符号推理给了我们可解释性和约束能力，连接主义给了我们感知和泛化，预训练给了我们知识压缩的效率，推理时计算给了我们处理难题的深度。真正的通用能力，大概率是这几条线的合流，而不是某一条线的独自延伸。

我在实际做项目的过程中越来越体会到，与其纠结"什么时候到 AGI"，不如盯住那些具体的能力缺口：它在长尾任务上表现如何，它犯错后能不能自己发现，它跑完一百个任务后有没有变好一点。这些问题的答案，比任何时间表都更能指导你把东西做出来。