AGI核心突破的技术验证：四把尺子与三组实验

最近圈子里都在转一条消息：某家头部AI实验室的前首席研究官公开表态，AGI的核心突破已经实现。说实话，我第一眼看到这个判断，没有急着当新闻报道划过，而是停下来把它拆了一遍。AGI这个词被说太多次了，但真正做过训练、调过推理、给客户做过落地项目的人，普遍是谨慎的；能让一位前首席研究官把“核心突破”四个字放出来，说明底层能力确实到了一个临界点。这篇东西我不打算复述新闻，也不想制造焦虑，只从技术角度谈谈：所谓核心突破到底指什么，靠什么验证，以及我们这些做应用、做产品的人能从中拿到什么。适合正在犹豫要不要全面押注智能体方案的技术负责人，也适合想知道AGI离自己业务还有多远的工程师。

1. AGI的“核心突破”：先别急着下定义

1.1 “已实现”说的不是科幻场景，而是学习机制的临界点

很多人把AGI理解成“一个什么都会的机器人管家”，这种电影化定义会让讨论跑偏。站在工程角度看，AGI核心突破是指一个系统具备了“面对开放任务时，自主完成拆解、尝试、纠错、交付”的基本机制，而不是说它已经拥有全世界所有知识，也不是说它不会犯错。过去基于大模型的做法，本质上是把海量文本压缩成统计规律，遇到一个问题，它检索看起来最像答案的片段；而这次被反复谈起的新阶段，模型结构里多了一个类似“推理循环”的东西，它可以在一个任务上反复观察输出、比对目标、调整路径，直到结果达到可验收的程度。这就像以前请来的实习生，只会照着手册处理常规工单；现在换成一位能自己看需求、拆子任务、遇到冲突主动换方案的老员工。区别不在知识量，而在有没有“任务闭环能力”。这才是“核心突破”四个字真正成立的地方。

从研究视角看，“已实现”并不是指模型已经通过了所有人类智力测试，而是指一套通用学习机制已经被验证可复现。这种机制的核心是：模型在训练阶段积累的基础能力，能在推理阶段被组合成新的策略，去应对训练数据里没有明确出现过的目标。说得更直白一点，过去我们做AI应用，本质是“把答案写在程序里”；后来做大模型，本质是“把答案隐含在参数里”；而现在这一个阶段，模型开始像人一样，在拿到问题的瞬间现场编排解题步骤。这个变化，是架构、数据、算力三者共同作用的结果，不是某一个算法突然开窍。

1.2 为什么这句话从一位前首席研究官嘴里说出来，更值得听

一位每天负责模型研发方向的人站出来说“已实现”，和一家公司的营销负责人口径是完全不同的。前者的判断来自实验曲线、内部评测、失败样本，说话要考虑专业名誉；后者要照顾对外叙事和生态位。所以我听到这条消息的第一反应，不是搜谁反驳了、谁的评级下调了，而是去想：他到底看到了哪些外部看不到的观测证据，才会用一个“已实现”这么重的词。可能是几类东西叠加出来：一是模型中开始稳定出现“多轮自我反思”行为，模型会主动说“刚才我的推导有问题，重新来”；二是给出外部工具时，模型能自主决定何时调用、如何解读返回结果，不再需要人类把每个动作写死；三是在全新的、没有标准答案的任务上，模型能一步步产出可执行方案，而不是撞车后直接放弃。这些现象单个出现还能用“记忆”解释，但同时在多类任务上稳定出现，就只能指向“通用学习机制已经被验证”。

当然，说“核心突破已实现”，不等于说“AGI已经完全落地”。两者之间还隔着工程化、安全约束、成本控制、场景适配这一大段路。但对我这种做应用的人来说，前者是地基，后者是装修。如果地基已经换了，那现在所有的产品架构、评估方法、团队分工，都值得重新审视一遍。这也是为什么我不打算把注意力放在“谁说得对”上，而是想提供一套能自己动手验证的尺子。

2. 我自己判断“核心突破”是否到位的四把小尺子

2.1 尺子一：能不能完成“规划—试错—修正”闭环

判断AGI级别能力，不能只看一道题答得漂不漂亮。我习惯把它按“闭环能力”拆成四个维度：规划、试错、修正、交付。第一把尺子，就看它在一个新任务上能不能自己把目标拆成子步骤，并且根据反馈修正做法。一个可复现的测试是：给模型一个需要组合多个领域的任务，比如“用公开数据模拟一份供应链缺货预警报表，要求包含库存周转、补货周期、安全库存三个变量，并给出异常推断”。这种任务没有一个标准答案，也不可能靠背诵命中，模型如果上来就输出一个完整方案，那是大概率在编；如果它先问三个澄清问题，再给一个初版框架，然后补充一句“我需要更多数据才能算出准确结论”，反而更接近真实AGI行为。

只看结论对错是学生思维，看它有没有动态调整路径，才是工程判断。我见过很多模型在单轮回答里表现惊艳，可一旦你指出“你这一步假设不成立”，它就立刻放弃整个思路，重新编一个答案。真正的核心突破应该表现为：模型能定位到逻辑链条里具体哪一环错了，修正哪一段，保留其余有效部分，再往下推进。这不是“重新生成一个答案”，而是“对一个已经存在的答案做手术”。前者是记忆和概率，后者才是推理闭环。

2.2 尺子二：会不会主动调用工具弥补认知边界

第二把尺子关乎“认知边界”。AGI不需要知道所有事情，但必须知道自己不知道，并且能通过外部工具补齐。我常用一个很简单但很难作弊的测试：给模型一个日期范围，让它计算其中工作日数量，并要求“不要给近似值，给精确值；如果你需要工具，可以用”。如果模型直接把两个日期一减，再随口说个粗略数字，说明它不具备工具意识；如果它写出一段Python，用日历库循环计算，再把运行结果摘进回答，那就说明它开始把自己当成一个“可以指挥工具的大脑”，而不是一个百科全书播放器。

同样的逻辑可以延伸到浏览器搜索、数据库SQL查询、代码执行器、图像识别服务。凡是能主动调用外部能力来补足自身短板的行为，都算通用性的证据，因为人类专家也是这样工作的。工程师不需要背住所有库函数，但知道“这个功能应该去查文档”“这个计算应该交给程序跑”。模型如果打通了这一步，就意味着它在系统里不是孤立的文本生成器，而是可以嵌入到真实业务流程里的调度中枢。

2.3 尺子三：能不能在长任务中守住原始目标

第三把尺子，是在长达数小时的工作里，模型还能否记得最初要解决的问题。很多模型单轮对话很强，多轮一长就开始顺拐：用户让它写一套订单处理系统，中间插入十轮无关交流后，它可能把订单系统优化目标忘掉，开始做大而全的通用平台。这个现象对应工程上的“上下文漂移”，也是智能体落地最难啃的骨头。我建议用一个两阶段测试：先给模型布置一个需要200行以上实现的完整任务，记录它第一步提出的方案；然后在之后十轮对话里插入大量干扰信息，比如问它无关知识点、改需求细节；最后让它回头把最初的交付物重新生成一遍。

如果它能回滚到原始目标，并指出“你后面补充的内容里，有两个条件和初版目标冲突，需要你确认取舍”，说明它具备目标管理能力。过去这几乎是大模型最明显的短板，现在许多模型已经能做到了，这正是核心突破最直观的证据。长任务守约能力，直接影响智能体能不能在真实业务里独立跑完一个流程，而不是每十分钟需要人工兜底一次。

2.4 尺子四：跨模态推理是否真的在“抽象”而不是“拼贴”

第四把尺子关于抽象表征。大模型最初被质疑是“随机鹦鹉”，只会统计文字之间的搭配概率。跨模态推理是一个很有效的照妖镜：给模型一张发票截图和一个表格文件，问“这两张材料里的交易总额是否一致”。表面上是OCR加数字比对，实际需要模型把图像里的空间排版、表格里的行列关系、金额单位三样东西压到一个统一的语义空间里去比较。如果模型一步到位给结论，还解释了哪一行对应哪一列，说明它在处理“意义”而非“文本形状”。

我见过一个很有意思的案例：模型不仅能答出金额不一致，还指出“图片中第二行金额后面标注的是美元，表格里写的是人民币，所以单纯数字相同并不代表一致”。这种对单位、语境、模态差异的综合判断，不是靠记忆能完成的，需要多模态表征里真的存在一条共同的抽象通道。所以我通常把跨模态推理作为“通用智能”的最后一道试金石。如果模型只能在纯文本里玩花样，那它再能写诗，也很难说具备真正的通用性；一旦它能在文字、图像、表格、代码之间自由穿梭并做一致性判断，通用性的证据就比较扎实了。

3. 开发者实操：用三组实验验证AGI核心突破的四个能力

3.1 实验环境准备：别在聊天窗口里点两下就算验证

想验证“核心突破”，我建议不要在网页聊天窗口里点两下就算数，那样容易受演示模板和运气影响。最基础的做法，是把同一个问题丢给同一个模型跑五到十次，记录成功率和行为类型。准备工作很简单：一个开发环境、一个模型接口、一个可以传系统提示词的调用脚本。不同团队的接口网关不一样，但只要能按标准对话补全格式调用就行。下面是我常用的最小调用模板，你只需要换成自己的接口地址和密钥：

import requests def call_llm(messages, model="your-model"): resp = requests.post( url="http://your-gateway/v1/chat/completions", headers={"Authorization": "Bearer YOUR_KEY"}, json={ "model": model, "messages": messages, "temperature": 0, } ) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"]

这里有几个关键点。第一，温度设成0，保证输出可复现，否则同一道题每次答案都不一样，你很难判断能力到底稳不稳定。第二，消息结构里要区分系统提示和用户内容，系统提示用来定义行为边界，用户内容放任务本身。第三，建议把所有上下文都保留在请求里，不要在外部拼接或者省略历史，否则长任务实验会失真。准备一套带编号的记录表，每轮实验记下模型输出、是否修正、修正是否有效、用时多少，这比任何印象都可靠。

3.2 实验一：未知规则推导，考基础闭环

第一个实验专门测“未知规则推导”。做法是随机定义一个隐藏规则，给模型几个已知样本，让它推出下一个输出。规则不能是常规数学序列，比如“第n项等于第n-1项乘以2再加3”这种太容易猜到；要选那种需要现场归纳的组合，比如“下一项是上一项的每一位数字加1，如果超过9则取个位”。这种规则不可能大规模出现在训练语料里，所以模型没法靠记忆，只能靠推理。

我建议用代码随机生成规则，然后跑十组，记录第一轮正确率和受到反馈后的修正率。如果模型第一轮能直接给出正确规则，说明它的归纳能力很强；如果第一轮错但能在提示“再检查一下你的推导”后修正，说明具有自我纠错能力；如果十组全是同样错误且拒绝调整，那基本可以判断它还在靠模式匹配。具体提示词可以这样设计：把五个输入输出对放进用户消息，要求模型先给出规则，再预测第六个。

3.3 实验二：工具调用决策，看模型是否懂得“借力”

第二个实验不需要真的接外部工具，而是用“计划调用”来测。给模型一个需要精确计算的任务，同时告诉它可以描述“如果需要调用工具，请说明工具名称和传参”。比如问“某仓库每天入库120件，出库平均85件，库容5000件，当前库存2100件，按这个趋势多少天会达到库容上限”。如果模型直接口算，大概率会出错；更好的行为是它先写出计算公式，再说明“这个结果需要准确计算，我会用代码执行器跑一下”。

记录模型是选择硬算、列公式不执行，还是明确规划了一个工具调用。真正具备AGI核心能力的模型，通常会在回答里出现“我将调用计算器”或“这一步应该交给代码解释器”这样的表述。之后你还可以进阶测试：允许模型真的调用一个执行环境，看它是否把返回结果转化为最终答案，而不是把一堆无格式数字直接丢给用户。工具意识是智能体落地的前提，没有这个能力，模型再聪明也只能在对话框里当顾问。

3.4 实验三：长任务目标回滚，验证上下文管理能力

第三个实验考察长程一致性。给模型一个需要分阶段完成的复杂任务，比如“为一家跨境电商公司设计一套退货预测系统，输出需求文档并给出三个核心指标的定义”。先让它输出第一版方案，然后用十轮聊天故意分散注意力：问它今天天气、让它写一首诗、跟它讨论某个无关技术问题，每轮结束后再追加一条对原需求的小改动。最后一步，要求模型忽略最近几轮的内容，重新输出第一版需求文档，并说明哪些改动保留、哪些舍弃。

这里要重点观察的不是模型能不能复述，而是它如何处理冲突。弱模型往往直接生成一个四不像的大杂烩；有目标管理能力的模型会说“你第三条改动和第一条冲突，我基于原目标做取舍，保留库存周转率这个指标，因为它是退货预测的关键因子”。如果十次实验里有六次以上能守住原始目标并给出取舍理由，我就认为长程一致性已经越过可用线。

3.5 实验结果解读：怎么判断这些行为算不算“核心突破”

做完三组实验，你会拿到一大堆输出。我的解读方法是看两个比率：多轮自纠错率，也就是第一次错但能在反馈后修正的概率；以及长任务守约率，也就是在干扰下能回滚到原始目标并完成合理取舍的概率。如果自纠错率超过一半、守约率超过三成，这个模型就已经具备相当强的通用问题解决倾向。如果再叠加工具调用测试里的主动借力行为，那基本可以判定，所谓“核心突破”在当地部署的模型上也是可观测的。

还要强调样本量。任何一组实验只跑一次都没有意义，因为模型输出有随机性，你的提示词也可能踩到小概率模式。我自己的习惯是同一任务至少跑十次，再换两种不同措辞跑一个对照，观察行为稳定性。真正的能力是分布，不是单点。

4. 常见误区与排查实录：被热搜带偏的四个认知偏差

4.1 误区一：把AGI当成“全知全能且永不犯错”

第一次接触这些能力的人，最容易用一个极端标准去要求模型。它不知道某个冷门知识，就骂它是人工智障；它犯一次低级计算错误，就说AGI是骗局。这种二元评价没有意义。人类专家的核心能力也不是全知全能，而是在不确定时知道如何降低风险、如何验证假设、如何承认不知道。AGI核心突破解决的是“主动逼近目标”的能力，不是“一步到位”的完美度。

我自己的标准是：模型任务达标率能从过去的30%提到70%，同时失败后能通过反馈修正到90%，这已经是生产力级的变化。你不需要它每次都一次答对，你需要它能在你的介入下快速收敛。拿这个标准去看，很多过去不能自动化的长流程，现在真的可以尝试了。

4.2 误区二：只看基准分，不看分布外泛化

还有一个高频误区是拿公开榜单说事。榜单分数高，不一定代表到了你的业务场景就靠谱，因为榜单数据可能出现在训练集里。我踩过一个很典型的坑：某个内部测试里，模型在标准代码生成任务上跑分很高，可一遇到带私有字段名和特殊格式的API就乱套。排查下来发现，它只是把训练集里的常见格式当成了通用规则，并没有真正理解字段之间的逻辑关系。

所以做验证时，一定要在测试集里注入“不可能在预训练里出现过”的领域词汇和格式，比如公司内部的项目代号、特定行业的缩写、新造的复合术语。真正的泛化能力，必须在分布外数据上验证才算数。把公开benchmark和内部对抗样本放在一起看，才能避免被跑分欺骗。

4.3 误区三：模型拒绝回答就等于“不会”

很多时候模型说“我无法完成这个任务”，其实是你的提示边界设错了，或者它在防御性保守，而不是能力达不到。遇到拒绝，先检查系统提示词里是否隐藏了过度限制的表述，再检查任务描述是否有歧义。我遇到过一个模型连续拒绝处理一份带敏感字段的表格，改成“只输出行数与列名的统计信息”后，它立刻能正常执行。这告诉我们，不能把“拒绝”和“不会”混为一谈，先排查约束再下结论。

4.4 排查记录：四类高频问题的定位思路

这四类问题我在不同模型上都见过，不是某一家的专利。关键在于把它们的定位方法变成标准动作，而不是每次靠感觉猜。排查做得越细，你对模型能力的边界就摸得越准。

5. 对从业者来说：接下来真正要补的能力

5.1 从“写提示词”升级到“设计智能体”

核心突破之后，应用层的玩法会明显改变。以前大家研究的重点是提示词模板，怎么把需求翻译成模型听得懂的话；现在模型已经能自己拆任务、调用工具、管理长程目标，应用架构的重心就转移到“智能体”设计上。你需要给它定义目标、提供工具清单、设定边界条件、建立检查点，像带一个能力很强但经验尚浅的新员工一样，给它上下文，而不是替它做每一步。

我最近在推的架构很轻：一个任务调度器负责拆解和分发，一个工具层负责把外部系统包装成模型可调用的接口，一个策略模型负责判断当前该调用哪个工具，最后再接一个人工审核位处理高风险输出。这个架构的好处是每一层都能单独测试、单独回滚，模型能力升级时可以平滑替换。

5.2 把评估体系从“文本顺眼”改为“任务交付”

很多团队还在用“生成文本是否通顺”“回答是否像人”来评价模型，这个标准在AGI核心突破面前已经过时了。真正要紧的是任务交付质量：写代码就看单测通过率，做数据清洗就看产出表质量指标，做客服就看问题解决率和用户回访满意度。文本只是载体，结果才是目的。

我建议每个项目都建一张“交付评估表”，把任务拆成结果指标和过程指标。结果指标决定能不能上线，过程指标用来定位问题。举个例子，一个报表生成智能体，结果指标是“报表字段正确率”，过程指标是“模型是否在遇到单位不一致时主动停下询问”。这种评估方式不仅更能反映真实价值，也能让团队在模型迭代时看清到底进步在哪。

5.3 三个马上可以动手的改进项

第一，把上下文工程当作核心能力。关键信息放在模型注意力的有效范围内，越长越容易被稀释，能用前置摘要就绝不堆历史记录。第二，把工具函数设计成带schema的API，让模型能理解参数含义和返回值结构，而不是给它一个裸函数。第三，给智能体配上失败回滚机制。模型一旦走偏，自动回到上一个确认过的状态点重新执行，这能大幅提高长任务成功率。

安全层面也要同步补位。让模型调用不可信工具前，先做权限校验和输入过滤，不要直接把外部内容喂进系统提示。技术安全不是限制能力，而是让能力可用。AGI核心突破放大了系统的“行动力”，所以工程上必须补上对应的“刹车和保险”。

我自己把这些实验来回跑了差不多两个月，最大的感受不是“机器要取代谁”，而是“工程协作方式要变了”。以前接到需求先问“能不能形成规则”，现在先问“能不能交给一个会自己修正路径的智能体”。这中间的转换成本不在模型能力，而在团队愿不愿意把测试、监控、回滚做成标配。AGI核心突破是否已经实现，业内还会吵很久；但把四把尺子装进自己的评估工具箱，这件事什么时候做都不亏。