做模型的这几年最怕被问到的一个问题就是人工通用智能到底还有多远。问这话的人有的是投资人有的是刚转行做算法的朋友也有纯粹好奇的亲戚。刚开始我还认真回答大概还需要突破几件事后来发现这个回答对谁都不解决问题。真正有用的做法是把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条的精编集质量优先。题目要满足三个条件答案唯一或可判定、不依赖训练数据里的原题、能区分真会和蒙对。维度考察点出题要点判分方式知识准确性事实召回与边界意识混合常见与冷门事实含不知道选项精确匹配 拒答正确率多步推理中间步骤可靠性需要3步以上、含干扰条件答案 关键中间值代码能力可运行与鲁棒性含边界条件的函数题单元测试通过率长上下文定位与抗干扰关键信息埋在长文档中段抽取准确率工具使用参数正确与错误恢复故意设计一次工具报错最终成功率指令遵循格式与约束遵守要求特定输出格式与字数规则校验通过率设计题目时有个技巧同一条题出三个变体一个是标准问法一个是加干扰的问法一个是换了表层但逻辑相同的问法。三个变体的通过率差距直接反映模型的鲁棒性。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, temperature0.0, max_tokens1024): payload { model: MODEL, messages: [{role: user, content: prompt}], temperature: temperature, max_tokens: max_tokens, } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } for attempt in range(3): try: resp requests.post(API_URL, headersheaders, datajson.dumps(payload), timeout120) 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_case3): with open(suite_path, r, encodingutf-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, temperature0.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_asciiFalse)) 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 倍成本完全取决于业务场景。做客服问答肯定不值做合同条款核查可能很值。场景类型延迟容忍建议采样数建议验证强度实时对话3 秒内1格式校验文档处理分钟级1 到 3规则加抽检代码生成分钟级3 到 8单元测试必跑关键决策辅助可接受小时级8 以上多路交叉验证4.4 结果怎么读三个最常见的误判拿到跑分结果最容易犯的错有三个我逐个说。误判一把 prompt 敏感度当成能力差异。换个问法分数掉十个点先别急着下结论说模型不行很可能是你的 prompt 在某类表述上触发了模型的模板化应答。正确做法是固定一套 prompt 模板做对比另外单独做一组 prompt 变体实验把能力和表述适配分开看。误判二数据污染。如果你的题目来自公开题库模型很可能在预训练时见过。判断方法是把题目里的实体名、数值做等价替换看通过率是否明显下降。掉得厉害基本就是背过了。误判三只看平均分不看分布。平均 85 分听起来不错但如果你的业务集中在某个边缘场景而那个场景的通过率只有 40%平均分毫无意义。评测一定要按你真实业务的流量分布加权而不是每条题等权。5. 影响范围这套技术会改到什么程度5.1 职业结构先变的是任务不是岗位我观察下来被替代的从来不是岗位而是任务。一个岗位由几十个任务组成其中一部分被自动化岗位本身会被重组而不是消失。按任务可标准化程度和错误代价两个维度来分能看得比较清楚类型特征受影响程度典型应对高标准化、低错误代价格式转换、初稿生成、信息汇总高转向审核与把关高标准化、高错误代价财务核算、医疗记录、合规检查中高人机双签模型做初筛低标准化、低错误代价创意发散、头脑风暴、素材探索中用模型扩选项人来收敛低标准化、高错误代价复杂谈判、危机处置、跨部门决策低模型做信息整合辅助这个结构说明一件事中间层最危险。纯粹做信息搬运、格式加工的岗位会被压缩两头反而相对安全一头是能定义问题的一头是能承担责任的。我个人的建议很具体把自己每天的工作拆成任务清单标出哪些是输入输出明确、错误可回滚的这些部分优先交给模型然后把你节省下来的时间投到判断和验证上。这不是空话我确实这么干过一周能省出大半天。5.2 科研与教育加速的是搜索不是判断科研场景里这类系统最直接的价值是扩大候选空间。文献综述、假设生成、实验方案变体、代码实现这些环节的时间成本被大幅压缩。过去一个研究者一周能读完的论文有上限现在可以先让模型做初筛和结构化摘要人只看筛出来的。但加速搜索有个副作用验证成本相对上升。候选方案从10个变成200个你需要判断哪个值得做实验的能力反而更稀缺。而且模型给的文献综述可能有编造引用必须逐条核对这一步不能省。我在实际工作里见过不止一次看起来引用格式完美、但那条文献根本不存在的情况。教育这边我认为最需要调整的不是要不要用而是教什么。当生成变得廉价稀缺的能力就变成了提出好问题、拆解复杂问题、判断信息可信度、把结论讲清楚。这几件事恰好是过去的教育里最容易被忽略、最难被标准答案衡量的部分。我个人的做法是凡是能用标准答案衡量的作业都假定模型能做转而设计那些需要过程说明和交叉验证的任务。5.3 对齐与安全这是工程问题不是哲学问题很多人把对齐理解成一个哲学话题我不同意。至少在工程层面它是一堆可以具体做的事。第一层是能力评估。上线前必须知道自己系统的能力边界在哪哪些问题它会胡编哪些输入会触发异常行为。这就是上一节那套评测台的用途。第二层是行为约束。用系统提示、输出格式约束、内容过滤、规则兜底这几道关卡把行为圈住。这几层要独立不能指望模型自己约束自己。第三层是权限最小化。给模型调工具就只给完成当前任务必需的最小权限。需要写文件的别给删除权限需要查数据库的给只读账号。这一条听起来是常识但我在实际项目里见过太多为了方便调试先给全部权限然后忘了收回的情况。第四层是人类确认点。在不可逆操作前插入人工确认。什么是不可逆发钱、删数据、对外发消息、改配置。这四类操作我坚持必须有确认环节宁可牺牲一点自动化率。第五层是可追溯。完整记录输入、中间步骤、工具调用、输出。出事之后能复盘比事前想象一万种风险都有用。层级目标具体做法常见疏漏能力评估知道边界分维度评测集、红队测试只测正常输入行为约束圈住输出系统提示、格式校验、规则兜底全部依赖模型自律权限控制限制影响面最小权限、只读优先、沙箱执行调试权限未回收人工确认拦截不可逆四类高危操作强制确认确认流于形式可追溯事后可复盘全链路日志、版本快照只存最终输出注意这五层里权限最小化和人工确认点的投入产出比最高改动小、见效快。如果资源有限先做这两层。6. 常见问题速查与踩过的坑6.1 疑问速查表问题现象可能原因排查动作处理建议同一问题两次答案不同采样随机性、服务端批处理固定温度跑十次统计分布评测取多次平均别用单次结果下结论换了问法准确率骤降对表述模板过拟合做 prompt 变体对照实验固化模板重要场景做多模板投票长文档里关键信息漏读注意力分散、位置偏差把关键段落挪到不同位置重测关键信息前置或分段处理后汇总多步任务中途跑偏缺中间校验打印每步输出人工看一遍加校验层每步产出结构化结果工具调用参数格式错结构约束不足检查返回的 JSON 是否合法用结构化输出约束加解析失败重试答案看起来很对但引用是假的生成时补全了不存在的细节逐条核对引用来源强制要求给出可验证出处不能给就标未知模型过度迎合用户偏好优化副作用用相反立场提问做对照提示词中明确要求指出错误前提推理成本超预算采样数过多、上下文过长统计 token 分布与重试率分级路由简单问题走轻量路径6.2 我踩过的几个坑写下来省你时间坑一以为评测分数高就能上线。我第一次做落地时离线评测 88 分上线第一周投诉不断。后来发现是评测集和真实流量分布完全对不上——评测集里都是规整输入真实用户会贴截图、会打错字、会一句话问三个问题。教训是评测集必须从真实日志里采样而且要定期更新。坑二把提示词当代码写越写越长。一开始遇到问题就往上加规则最后提示词两千多字改一处崩三处。后来改成模块化角色定义、任务说明、约束条件、输出格式、示例五块分开维护哪块出问题改哪块。这个改动让调试效率提升非常明显。坑三忽略 token 计费的隐性成本。长上下文很好用但成本是平方级增长的感受。我做过一个统计把上下文从 4k 提到 32k单次成本涨了接近七倍而准确率只提升了不到五个点。后来改成两段式先用小模型做相关性筛选只把相关片段送进大上下文成本直接降回来。坑四让模型自己判断自己。早期我图省事用同一个模型既生成答案又判断答案对不对结果通过率虚高十几个点。换成规则校验加另一个模型交叉验证之后数字才真实起来。原则很简单评估者和被评估者必须独立。坑五低估了格式约束的价值。下游系统要解析模型输出格式错一次整条链路就崩。后来所有对外输出都强制结构化并在解析层加了三重兜底严格解析、宽松修复、失败转人工。这一层的投入比调模型本身划算得多。6.3 给不同阶段同学的几条实在建议如果你刚开始接触这个方向先把一个开源模型在本地跑起来手动改改提示词感受一下它的能力边界在哪里。这一步不用花太多时间一两个周末足够但非常必要——不看边界你对它的期待一定是错的。如果你在做应用落地把精力放在评测体系和兜底设计上。模型能力是外部变量你控制不了评测和兜底是你自己的工程资产能持续复利。我见过太多团队把八成时间花在挑模型上结果上线后连这次改动到底变好还是变差都说不清。如果你在做研究建议盯住持续学习和长程任务可靠性这两块。前者是当前系统跟真正通用智能之间最明显的差距后者决定了智能体方案能不能从演示走向生产。至于通向通用智能这件事本身我的判断是技术演进的路径不会是一条直线而是若干条曲线交替主导。符号推理给了我们可解释性和约束能力连接主义给了我们感知和泛化预训练给了我们知识压缩的效率推理时计算给了我们处理难题的深度。真正的通用能力大概率是这几条线的合流而不是某一条线的独自延伸。我在实际做项目的过程中越来越体会到与其纠结什么时候到 AGI不如盯住那些具体的能力缺口它在长尾任务上表现如何它犯错后能不能自己发现它跑完一百个任务后有没有变好一点。这些问题的答案比任何时间表都更能指导你把东西做出来。