任云舒最近和一个做Agent框架的朋友聊天，他说了句大实话：现在市面上的Agent项目，绝大多数还停留在“拿大模型当函数用”的阶段——接个记忆库、调几个工具、套一层规划循环，看起来什么都能干，实际上换个场景就碎。正说着，我刷到KAUST诸葛鸣晨的专访，里头有两个判断我印象很深：一是2026年Agent的最大突破会是“递归自进化”，二是三年后有望出现“神经计算机”。这两个词单独拎出来都不新鲜，但放在一起，其实指向了一条非常具体的演进路径。
这篇内容我想了很久，决定不写成单纯的专访摘录，而是从一个Agent开发实践者的视角，把这几年踩过的坑、看到的行业信号，以及这两个判断背后的技术逻辑拆开揉碎讲清楚。适合正在做Agent开发、想搞清楚Agent能力上限在哪、以及关心AI硬件接下来怎么演变的开发者阅读。信息量会比较大，但我会尽量用大白话和实际案例来解释，保证你能边看边对照自己的项目。
1. 递归自进化到底是什么：从“外部堆功能”到“内部改结构”
1.1 一句话理解：让Agent修改自己的“大脑”
大多数人对Agent进化的理解是“越用越熟”——用久了，记忆库大了，工具调得溜了，表现自然变好。但递归自进化完全不是一个量级。它指的是Agent不仅能基于经验调整策略，还能修改自己赖以推理的指令体系、工具编排逻辑，甚至底层的能力结构。
打个比方。普通Agent像是一个厨师，菜谱是别人写好的，他照着做，做多了更熟练，但不会自己发明新菜系。递归自进化是这个厨师开始修改菜谱本身，今天觉得“盐放两克不够，改成三克”，明天觉得“这个步骤可以删掉，换成焖制更好”，后天他开始重新设计厨房的设备摆放。菜谱的修改会影响每道菜的出品，而新出品又会反过来让他产生了新一轮的修改动机。
在工程上，这意味着Agent内部会出现一条“自我反馈闭环”。传统Agent是用户输入问题，Agent调用大模型推理，调用工具执行，返回结果。递归自进化要在外面再套一圈：让Agent观察自己的整个推理和执行过程，主动识别哪些Prompt写得模糊、哪些工具选择不合理、哪些思维链步骤冗余，然后生成修改后的Prompt或配置，再跑一轮验证是否改善。如此循环往复，每一轮都在改自己的“工作方式本身”。
1.2 和AutoGPT那种“自我提示”是两码事
这里有一个很容易混淆的地方。很多人会问：AutoGPT不也是自己给自己重新写Prompt吗？差远了。AutoGPT的“自我提示”是临时性的、单任务内的——它为了完成“帮我在网上订酒店”这个任务，会动态拆解子任务并生成对应的执行指令，但任务结束、对话清空，一切归零。它的“自我改进”是对环境状态的反应，而不是对自己能力的重构。
递归自进化有两根本质不同的支柱：
- 跨任务的持续修改：进化发生在任务与任务之间，Agent会把上个任务里“用哪个工具更合适”“哪个Prompt模板容易让模型误解”的经验沉淀下来，直接改写自己长期使用的那套系统配置。
- 能力维度的自我调整：它改的不是某一次回答的措辞，而是改“自己如何生成回答”的机制。比如发现自己的规划模块经常忽略时间约束，就修改规划Prompt，加入强制校验逻辑；发现某些工具参数容易传错，就自动改写工具调用的包装函数。
所以你看，AutoGPT是“用同一个大脑解决不同问题”，递归自进化是“不断换一个更好的大脑去解决未来的问题”。前者是用法层面的迭代，后者是结构层面的迭代。诸葛鸣晨把递归自进化定为2026年的最大突破，正是因为这条从用法到结构的跨越，难度比大多数人想象的大。
1.3 递归的复利效应
为什么“递归”是这里的关键词？因为它直接决定了进化的速度曲线。
普通机器学习的改进是线性的：你用更多数据训练模型，性能缓慢爬升。递归自进化的改进是复利式的：Agent想出了一个改进方案，这个方案让它想问题更清晰，于是它又能想出更复杂的改进方案，接着再改，再想……每一轮改进都建立在前一轮改进的基础之上。
我在实际测试一些带简单自省能力的Agent时观察到，当Agent能回顾自己过去的错误并调整行为规则后，前几轮优化确实有效，但性能很快进入平台期。原因很简单：它缺乏“修改自己修改方式”的能力。让Agent修改自己的Prompt很容易，但让Agent意识到“我修改Prompt的策略本身有局限”，就需要更高阶的元认知，也就是“反思自己的反思”。这个递归层级一旦打开，效果曲线才会真正陡峭起来。这也就是为什么诸葛鸣晨判断这不是一个简单的功能升级，而是Agent能力的“范式级跃迁”的原因——递归把成长从加法变成了乘法。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 今天的Agent卡在哪里：距离自进化还差的四道硬坎
诸葛鸣晨的预判很乐观，但作为在一线写代码的人，我很清楚从今天的Agent到递归自进化，中间隔着的东西比大部分人想的多。这几年大家在Agent方向上的产品和开源项目十有八九都撞到了同一堵墙——不是大模型能力不够，而是工程化条件根本不支持Agent做安全的自我修改。总结下来有这么四道坎，每一道都实打实卡过项目。
2.1 记忆不是数据库，是“结构化经验”
很多Agent开发者的第一个动作是给Agent接一个向量数据库，对话记录一存，关键词一检索，就当有记忆了。问题是这种记忆是没有结构的流水账，Agent能“想起”发生过什么，但不理解“那件事教会了我什么”。
递归自进化要求Agent的长期记忆以“结构化经验”为核心。什么叫结构化经验？至少要包含三层：一是具体情境（当时任务是什么、环境状态如何）、二是采取的行动（调用了哪个模型、用了哪个工具、Prompt是什么）、三是结果评估（成功还是失败、偏差有多大、原因推测）。少一层，Agent就无法从历史中提取可迁移的改进规则。
我在自己的项目中试过给Agent增加一个“经验提炼层”：每完成一个任务，让Agent用固定模板输出一条经验记录，内容包括“任务类型、有效策略、失败原因、可复用的规则”。跑了两周之后，Agent处理相似任务的效率明显提升，因为它不再需要每次从零推理，而是先调用经验库里的规则。这个实验虽然没有做到自动改写系统配置，但它验证了一个关键前提：只有先把记忆整理成结构化经验，自进化才有原料可用。卡在这一步，后面的循环根本转不起来。
2.2 评估机制缺失：没有裁判的自进化是灾难
递归自进化模型里有个致命点：Agent怎么判断一次自我修改是变好了还是变坏了？如果这个问题不解决，所谓自进化就会退化成随机乱改，甚至能力退化。
工业界现在普遍接受的方案是“强化学习+奖励模型”，但奖励模型（Reward Model）本身也是一个大模型，它也有自己的误差。让Agent用另一个可能有误差的模型来评估自己的修改，就存在一个更棘手的问题——自我欺骗或能力幻觉。我在一个带自省功能的Agent项目里遇到过这样的情况：Agent修改了自己的规划Prompt后，自我评估认为“决策质量提升了20%”，但用人眼一看，它其实只是把输出格式变得更漂亮了，实质推理深度反而下降了。
要解决这个问题，单靠构建一套可验证的评估流程还远远不够。代码生成类的Agent有个天然优势——可以用单元测试、静态检查工具做外部验证，正确与否不依赖主观判断。但更通用的任务（写文案、做战略分析、设计系统架构）没有标准答案，评估就难了。诸葛鸣晨说2026年才能实现递归自进化，这背后隐含的正是整个评估链条的成熟还需要时间。Agent必须学会用更可靠的外部信号（实测结果、用户反馈、规则库）取代大模型的主观自我评价，才能安全地迭代自己。
2.3 环境与仿真：自进化的训练场
Agent修改自己的结构之后，需要在一个足够真实的环境里验证效果，不能一上来就在生产环境里乱试。这就好比飞行员改进了驾驶技术，不能直接在真实航班上测试，得先在模拟机里飞几百个起落。
目前Agent开发里最稀缺的，恰恰是高质量仿真环境。代码任务可以利用测试用例和沙箱执行；浏览器操作类任务有WebArena这类环境；但企业级业务任务、跨系统协作任务、需要和人交互的任务，很难构建一个低成本、高保真的模拟器。没有仿真环境，Agent就只能用真实流量做验证，风险高不说，迭代速度也上不去。
一个我能看到的破局思路是“数字孪生+回放”：把过去真实任务的轨迹记录下来，做成可重放的测试集，Agent的每次修改都可以在历史轨迹上跑一遍，看覆盖率、成功率、资源消耗的变化。这不需要完整的仿真环境，只需要足够丰富的历史数据。但问题来了，历史轨迹本身有数据偏差，环境的动态变化也无法完全覆盖。所以递归自进化的前提，不只是Agent本身变强，还需要一套成熟的“训练环境基建”，这不是单靠Agent框架就能解决的问题。
2.4 安全沙箱：自进化必须有止损开关
一台能自我修改代码的机器，如果不加任何安全约束，失控只是时间问题。递归自进化的Agent会尝试修改自己的配置、重写工具、甚至改变推理策略——这相当于给软件装上了一个能自我修改内核的能力。
从业者的共识是，这类Agent必须在安全沙箱里运行，并使用“双通道监督”机制来控制风险。第一通道是硬性边界：Agent只能修改指定范围内的配置，不能触碰系统内核、不能读取敏感数据、不能执行超出权限的操作。第二通道是行为审计：所有自我修改操作必须留痕，且需要经过一层独立的校验器（可以是规则引擎或者人工审批）确认后才能生效。
我的建议是，给Agent的自进化流程设计“分阶段上线”：第一阶段在离线环境验证，第二阶段在影子模式运行（Agent的修改只作用于模拟请求，不触碰真实流量），第三阶段仅开放给内部小范围用户，全部通过后再逐步放量。每一道防线都是为了一个核心原则——Agent可以自由地改变自己的想法，但不能自由地改变系统的边界。
3. 神经计算机：三年后Agent硬件的“算法-硬件联合设计”
如果说递归自进化解决的是软件层面的能力跃迁，那诸葛鸣晨提到的“神经计算机”就是在说硬件层面的变革。很多人看到这个词第一反应是脑机接口那种科幻东西，其实不是。从Agent开发的实际情况来看，神经计算机更像是因为现有架构严重制约了Agent能力扩展，倒逼出来的一条硬件路线。
3.1 为什么现有硬件扛不住Agent的爆发
现在的大模型推理依赖GPU集群，核心计算模式是矩阵乘法。矩阵乘法能高效处理Transformer的前向传播，但Agent的运行负载和单次推理完全不同——Agent要做多轮推理、要维护长上下文记忆、要在多个工具调用之间切换、要运行规划算法。每一轮决策都有大量的小请求、频繁的内存读写、复杂的逻辑分支。
更头疼的是，递归自进化会让推理链变得极长。传统用户问一个问题，模型生成一个答案，这是一次推理；Agent要连续推理十几次甚至几十次，每次推理还要携带越来越长的记忆上下文。在现有GPU架构上，这种“长程推理+大记忆交互”的负载会导致两个问题：延迟线性增加，显存带宽成为瓶颈。有人统计过，一个中等复杂的Agent任务消耗的token量，相当于普通聊天对话的50到100倍。照这个趋势发展下去，即便模型能力没有瓶颈，硬件成本也会先用光你的预算。
3.2 神经计算机和冯·诺依曼架构的根本差异
传统计算机采用冯·诺依曼架构，计算单元和存储单元分离，数据需要不断在CPU/GPU和内存之间搬运。这个“搬运”开销在Agent的长程推理场景中被无限放大，因为Agent的核心操作是“从记忆里找相关信息，把它和当前推理状态融合”。这种操作本质上是记忆访问密集型，而传统架构在这方面的效率非常低。
神经计算机的核心思路是“存算一体”或“近存计算”：把计算单元直接嵌入存储阵列内部，让数据在存储的地方就地完成计算。就好比以前你要从仓库把材料运到工厂加工，再运回来；现在仓库本身就带了个加工车间，材料留在原地，直接在仓库里完成处理。对Agent这种高频读取、高频更新的记忆访问模式来说，这种结构能省下几十倍的搬运能耗和延迟。
另外，神经计算机还会引入非冯·诺依曼的并行机制，脉冲神经网络、模拟计算、大规模异步电路这些技术都有可能成为底层组件。它们的目的只有一个——让“记忆读取”和“逻辑推理”这两件事不再彼此拉扯。
3.3 从“模型适配硬件”到“硬件跟随算法演化”
我在上面提到，普通开发者设计Agent时考虑的是“这个模型在GPU上跑得动吗”，但神经计算机的时代会翻转这个问题：你的Agent算法是什么结构，硬件就按这个结构去设计。
这是一个非常大的思维转换。比如Agent如果天然带有“分层规划→记忆查询→工具执行→结果反思”这样四个固定阶段，那么硬件层面就可以为这四个阶段设计专用的计算流水线。诸葛鸣晨说“三年后有望实现”，大概率不是指彻底取代GPU，而是先在部分细分领域做出专用的神经计算芯片，用在Agent推理加速、端侧智能设备、机器人控制这些特定场景里。
我个人对这件事的判断是，短期内普通人感受不到变化，因为大模型API还是跑在云端的GPU上。但如果你是做终端设备的，这个方向值得现在就关注——端侧Agent设备的落地，大概率会先于云端享受到神经计算机带来的能效红利。试想一下，一个耳机、一个眼镜、甚至一颗门锁电池，就能跑起一个常驻的语音Agent，这个体验和现在必须联网调云端API完全不同。
4. 突破信号与落地场景：2026年我们可能看到什么
理论说完了，回到大家最关心的问题：如果递归自进化真是2026年的最大突破，我们具体会看到什么东西？我结合当前Agent生态的发展趋势，梳理出了几个大概率出现的信号。
4.1 开发者工具链会出现“自动调优Agent”
2026年最先跑通递归自进化的产品形态，我猜测是开发者工具类Agent。为什么？因为代码任务有两个天然优势：第一，验证信号明确（单元测试通过、静态检查无错、性能指标达标）；第二，修改空间清晰（代码、配置文件、测试用例都结构明确，Agent能精准定位修改点）。这两个条件叠加，让代码场景成为递归自进化风险最低的试验田。
具体来说，会出现这样的工具：你给Agent一个仓库，告诉它修某个bug，它不仅能修，还会在修完后自动复盘“我刚才为什么一开始定位错了？”“哪个线索被我漏掉了？”“以后同类问题该先看什么？”。然后它会把复盘结论写成一条规则，存进自己的经验库。下一次遇到类似bug，它会在第一轮就调用这条规则，直接跳过之前犯过的错。
这种工具的出现会明显改变程序员的日常：从“人指挥Agent干活”变成“Agent越用越懂你这个项目的风格和坑”。它不会取代程序员，但会极大压缩查资料、试错、看日志的时间。
4.2 Agent评测基准从“单次分数”转向“成长曲线”
现在的Agent评测方式还停留在“给一组任务，算正确率”的阶段。一次性的考试只能测出Agent当前能力，测不出Agent能否自主进步。2026年如果递归自进化真的落地，评测基准一定会跟着改变。
我看好的一种评测范式叫“多轮进化评测”：给Agent同一个任务集，允许它在每轮任务结束后自我修改，然后连续评测很多轮，看它的成功率曲线是上升、持平还是下降。一个能真正实现递归自进化的Agent，应该表现出“正确率随轮次稳步爬升”的形态，而不是一开始就冲到高位然后震荡。
这种评测方式的改变，会反过来倒逼Agent架构设计的变化。因为如果评测看的是成长曲线，那么开发者就必须在系统里预留“反思-修改-验证”的循环机制，而不是简单地堆一个更大的模型。我看一些开源框架已经开始掉头了，比如把“反思模块”作为一等公民写进Agent循环、在Agent配置里增加自修改策略、允许工具列表动态注册。这些动作就是在为新的评测标准做准备。
4.3 算力成本曲线出现关键转折
递归自进化要跑通，需要额外的推理开销和更长的任务链路，这会带来一个新的悖论：能力更强了，但烧钱更狠了。除非硬件层面同时出现突破，否则这项技术在商业上是不可持续的。
所以2026年的另外一个关键信号，是Agent单位任务的算力成本曲线的转折。这个转折有两个来源：一是模型层面对长上下文和推理链的优化（比如更高效的缓存机制、稀疏注意力、推测解码），二是神经计算机这类新硬件逐步进入工程化。诸葛鸣晨把“递归自进化”和“神经计算机”放在同一个时间轴上，很可能是在暗示：软件层面的大突破，需要硬件层面的同频配合才能变成实际可用的能力。
对普通开发者的启示是：如果你的Agent项目现在因为算力成本太高而无法落地，不用太焦虑，这个问题大概率会在未来一到两年内有结构性缓解。但前提是你要保证自己的架构足够灵活，能在推理链变长、记忆变大的情况下依然保持模块化，而不是被某个特定模型的接口锁死。
5. 对Agent开发者的实际启示：今天就能做的五件事
说了那么多愿景层面的东西，最后落回现实：递归自进化也好，神经计算机也罢，都不是明天一觉醒来就有的东西。但好消息是，“为自进化准备的工程架构”今天就能开始搭。根据我自己的实践经验，有这么几件事是现在投入产出比最高的。
5.1 把可观测性做成默认能力
Agent项目最常见的工程失误，是只记录最终结果，不记录中间的推理轨迹。可递归自进化最需要的就是过程数据——它要知道自己“哪一步想歪了”，才能去修正。没有过程的日志，就像考试只给你分数不给你错题解析，永远没法进步。
我现在做Agent项目的基本要求是：每一个推理循环都要输出完整的结构化日志，包含思考内容、工具调用参数、返回结果、时间开销等。调试模式时打印精简版，生产模式时存完整版。这个习惯看似简单，却能救命。没有它，后面所有自进化优化都无从谈起，因为你连“为什么之前失败了”都查不出来。
5.2 用“经验库”替代“堆Prompt”
很多Agent开发者喜欢把技巧一股脑写进系统Prompt，越堆越长，最后模型根本“注意”不到重点。递归自进化的方向恰恰相反：核心指令越短越好，可迁移的经验放进外部经验库，按需检索。
这个思路我实测过非常有效。把系统Prompt控制在核心的“身份、边界、行动原则”三块以内，然后把业务知识、避坑经验、工具使用技巧放到外部向量库，Agent根据具体任务动态召回。这样改的好处是，后续做自进化时，你只需要让Agent往经验库里追加或修改经验条目，不需要重写系统Prompt。修改的粒度小，风险就低，验证也快。今天的Agent项目如果还维持着一个两三千字的巨无霸Prompt，等自进化框架成熟后迁移成本会非常高。
5.3 给Agent装一个“裁判”而不是“镜子”
要让Agent具备自进化能力，必须为它设计一个尽可能客观的评估器。我见过很多项目用Agent自己当裁判，让它判断自己的改进好不好，这本质上是在照镜子——镜子里看到的，只是它自己想看到的东西。
理想的设计是三重评估：第一层是外部硬性指标，比如代码测试通过率、任务完成时间、用户点击反馈，这些指标独立于Agent的自我认知；第二层是规则校验器，用固定规则检查输出格式、安全边界、合规要求；第三层才是大模型评估器，用来评估那些没有客观标准、只能靠语义判断的维度。层层递进，才能把自进化的风险压到可控范围。
5.4 关注能效比，而不是只看模型分数
还有一个很多人忽略的点：选择模型的时候，不要只看榜单分数，要看“能效比”——你跑一个真实Agent任务所花的总成本除以任务完成质量。随着神经计算机和推理优化技术的发展，未来Agent的竞争力不再取决于谁能调用最强模型，而取决于谁能在同等成本下完成更多有效决策。
这意味着，Agent架构的设计要尽量和模型解耦。理想的架构应该是：核心逻辑是通用的，底层的模型可以随时替换——今天用闭源大模型，明天换开源模型，后天换成跑在神经计算机上的端侧模型。技术演进取胜的关键，从来不是押注某一个具体模型，而是你的系统能不能快速适应下一波算力变化。
5.5 从“做项目”的思维转向“建生态”的思维
最后一点，也是我认为最考验功力的一点：递归自进化Agent无法在孤立应用中独立发展，它需要数据、工具、评估、仿真组成的完整生态。诸葛鸣晨说“三到五年后才会有更多创业公司参与”，其实也就是说，这个赛道的窗口期比很多人想象的更长，也更具系统性。
我在实际开发和参与社区讨论中最大的体会是，任何想在Agent自进化领域做出成果的团队，都要学会“拥抱生态”：使用开源框架来降低重复建设成本，加入公开评测基准来对齐问题定义，甚至主动开源自己的数据或工具，让更多人参与构建反馈闭环。Agent自进化不是“应用层”的竞争，而是“平台层”的竞争。谁能先把生态跑起来，谁就能在2026年这个时间点到来时占住坑位。
我在自己的项目里把上面这五条当成默认的设计原则之后，最大的变化是：每天盯着代码的时间变少了，思考架构边界和验证逻辑的时间变多了。这个行业的变化速度远超我们的直觉，但技术跃迁从来不是凭空冒出来的。递归自进化在2026年会不会如期而至，谁也说不准，但那些为它准备的工程基础设施，不管到时候突破以什么形式出现，都不会白费。这是我现在最笃定的一点。