站在2026年4月底这一个时间点上，谈论这个问题似乎是恰逢其会。
随着今年早期Openclaw热潮的逐渐平息(事实上，这个博客服务器就是当时阿里云搞得openclaw优惠套餐留下的基础设施遗产)，回顾一下agents的发展与局限性是很有趣的一件事。作为一名非典型技术爱好者，我也较为长期的使用了claude code, codex和Ppenclaw以及一些不太知名的，乱七八糟的agents。
当前的基础模型与agent设计的确让自然语言->可用程序这一流程简化到了两年前无法想象的程度，agent也从24年的概念阶段逐渐走向工程可用，但在对Agents能力惊叹的同时，也存在一些隐藏的焦虑：
AI在多少程度上会取代程序员？
又会在多大程度上取代泛计算机学科的科研工作？
定量结论很难详细给出，不过我们可以讨论一个更有趣的话题角度，如果AI要在某个方面高度取代人类，其至少要做到任务闭环。
从控制论的角度讲，闭环控制是非常经典与核心的概念，从目标到反馈，再到比较与最终的控制，一个设计合理的闭环系统只需要通过一个目标设定就可以在工作范围内达成目的。其中，对于agents来讲最核心的部分我认为就是反馈，这也恰好对应上了llm令人印象深刻代码和数学能力:至少在某些子问题上，有相对明确的对错标准。
因此，我们这里想引入一个“飞轮效应”来讨论这一想法。
“飞轮效应”最初指为了让静止的飞轮开始旋转，需要持续的初始力，但当其动能累计后，只需要少量外力即可持续运转。后续被贝索斯等人引入到管理和商业领域，用于阐述系统/公司突破临界点后，可以高效自主运转与扩展的机制。
对于agent飞轮来讲，其能够调用工具，能够连续执行多个步骤，但飞轮并没有完全转起来，核心缺失就是任务闭环。如果该系统能够持续完成任务并得到可评价的结果，自动积累数据资产，为下一轮生产与基模迭代提供更多燃料，我们就能够认为飞轮已经转起来了。
可以简单定义为以下流程：
智能体执行任务 → 与环境交互，产生行动-观察-结果轨迹 → 从成功/失败中自动学习 → 能力提升 → 解锁更复杂场景 → 产生更多高质量交互数据 → 循环加速
能否利用任务结束后的反馈，是开环的”强大自动化工具“和闭环的”飞轮系统“间的主要区别。
特别的，这里的”飞轮“似乎与经济学中的”马太效应“本质类似：
凡有的，还要加给他，叫他有余；凡没有的，连他所有的也要夺去。 ----《马太福音》
但为了形象化说明“飞轮”开始旋转后越来越强的后续动能，我认为这里使用飞轮效应这个词更有趣。这一部分在4.4节我们还会有详细论述。
编程是飞轮最容易转起来的领域，原因也很简单，该领域拥有非常及时的正确/错误反馈。尽管代码的错误逻辑对于人类稍显复杂，多种错误类型之间也呈现出复杂的耦合态势，但能够作为一个典型“难实现，易验证”的问题构造领域，除了人类价值判断等必须人工参与的环节之外，LLM Agent可以接管程序设计中的闭环流程，如果通过最简单的测试通过/不通过来作为核心指标，已经可以给出不太谦虚的断言：
以代码通过为唯一指标的Coding Agent 在局部意义上已经实现了自动飞轮
但显然代码的作用不仅仅是为了正确。
数学领域的情况与代码类似，但更为微妙。
数学有明确的正确性标准，一个命题的成立与否，一个证明的有效与否，原则上不依赖人的主观判断。在标准数学题，形式化证明等领域，模型的输出是可以被检查，验证或反驳的。
但数学领域的自然语言证明相比于代码，其运行性依然有一定差距。LLM很容易生成一些流畅完整且自信的证明文本，但其中可能隐藏着非常细微的错误，如归纳假设，边界条件或不等价变形等。对于人类和语言模型，验证这些并不是非常容易且直接。
形式化证明则是弥合这一差距的核心手段。在Lean，Coq等形式化证明系统中，证明对象和可执行的代码具有类似的可检查性，可以通过逻辑与规则进行验证（参见1），其闭环流程可以一定程度上优化掉人类审查环节。
text自然语言数学： 提出解法 → 人类或模型检查 → 发现潜在错误(困难) → 修改推理 形式化证明： 生成 Lean/Coq 证明 → proof checker 检查（自动化） → 返回错误 → 修改证明 → 再检查
不过，这并不意味着数学飞轮相比代码飞轮情况更好。 主要阻碍点包括自然语言命题和形式化语言的翻译，大量数学背景知识的形式化，以及很多困难问题依然面临反馈稀缺问题。总的来说，形式化证明让数学获得了强验证器作为反馈，但在完全闭环上还有一些路需要走。
熟悉数理逻辑的读者可能会自然产生一个疑问：“哥德尔不完备性定理在哪”？这一节简单谈论一下为什么哥德尔不完备性并不妨碍形式系统的工程价值。
对于足够强且一致的形式系统，总会存在一些命题，它们在该系统内部既不能被证明，也不能被否证。--哥德尔不完备性定理
有限与无限：哥德尔不完备性定理讨论的是足够强，能够表达初等算术的形式系统，但对于真实人类世界而言，我们讨论的绝大多数命题都建立在有限的边界上。平行的例子比如，我们构建了一个真实的代码系统，其测试通过并不意味着该程序能够在所有可能输入，所有运行环境与所有扩展需求中都一定是正确的，反而只需要在极其有限的人工定义验证条件下，一定程度满足使用需求即可。
换句话说，不完备性限制的是理论上的形式系统能力上限，而非其在局部问题中的工程价值。
这也是代码和形式化数学相对特殊的地方。这一领域的agent并不完美，也不解决所有开放问题，但它们为大量实际任务提供了足够明确的反馈机制。正是这种局部可验证性，使得 LLM agent 可以在其中不断生成、执行、检查、修正，并形成局部自动飞轮。
正如我们之前所提到的，代码与数学推理是非常独特的领域，客观且廉价的自动验证器与幻觉多发的昂贵模型api形成了对偶与互补，为正确性做出了更强的约束，然而，代码的目标不仅仅是正确，在更广泛的现实工程中，正确的验证是非常欠定义的一个问题，这也是引入人类作为“起搏器”的核心出发点。
与RLHF，DPO等偏好优化方法的理念完全类似的，agent飞轮的终端还是落在了人类喜好（preference）这一低效但微妙的方向，与静态的训练任务不同，人类在对agent的使用过程中，不仅仅承担对模型输出好坏的评价任务，还包括持续的任务推理轨迹监控与修正，风险评估与审批等角色。
可以简单地认为，对于缺少明确评价系统的开环任务，人类喜好是一个闭环的路径，这与心脏起搏器的角色设定较为类似。
从当前的角度看，人机协同的方式与边界在被逐渐重新定义。 LM/Agent的可用性逐渐由原本的搜索/文本生成器，向更复杂的拟人工程任务发展，在多轮可测反馈中，由A->B的任务执行甚至可以由语言模型自主规划与最终完成。
然而，当前的基础模型在数据语料，探索性成本，真实世界交互等领域上的局限，限制了其脱离网络与信息空间的能力，这也是当前最为根本的边界之一。
即使从语言哲学的角度看，语言确实深刻塑造了我们理解世界的方式；但无论是否认同维特根斯坦式的观点，也很难说语言本身就是人类行动的全部。真实世界不只是语言对象的集合。它还包括身体经验、物理约束、长期互动等复杂内容。因此，当前agent最强的地方，仍然是信息空间中的行动能力。
系统的能力取决于其最薄弱的一环，对于Agent这样一个半闭环系统，最尴尬的境地在于，为了让飞轮转起来，我们引入了人类，但这一困难环节也恰恰限制了飞轮转速的上限。
对于长任务来说，不断的审查-反馈-迭代流程成为了人类更主要的劳动，而这一部分的精确性又成为了半闭环系统稳定运行的保障：如果没有人类，飞轮就可能跑偏，如果过度依赖人类，飞轮又无法真正转起来。
外溢效应主要体现在正反两方面。
正面上，代码/数学飞轮的高准确性会向其他领域扩散，即使一个任务没有那么容易闭环，但其中的代码实现，数据处理等部分可以间接利用这些局部飞轮，从而极大地缩短流程，提高工作效率。
以科研为例，科研工作中的许多环节并不是严格的编程问题，包括文献整理，实验设计，项目管理等等，但其中许多步骤可以转化为可执行任务，进而加快任务闭环。 例如，数据清洗->数据分析->绘图这一任务链，基本可以由代码agent完成90%以上的工作，人类只需要在最后对数据进行解释，对图表进行审美上的优化即可，相比于极有可能引入误差/噪声的人工手动处理，具有更强的可溯源性与可信度。
之前，许多领域的门槛在于，使用者需要掌握编程，数据和工具链等细节，才能把自己的问题与任务转换为可执行流程，在我最早接触科研的时候，还有许多关于R语言编程等等的实现教程，而现在，研究人员只需要知道有这件事，就可以在LLMs和Agent的辅助下复现这一流程。
在此基础上，许多垂域相关人士会将Agents和领域内的工作流结合起来，将领域内可复现的知识与流程内化到Agent工作流中，逐渐成为领域工作流的一部分，也为Agents和未来的基础模型发展提供了新燃料。
反面上，Agents当前正确率与“道德水平”并没有达到一个非常稳定的阶段，当代码中隐藏的错误或危险行为被扩散到更广泛的领域后，想判断其的错误要付出非常巨大的成本，例如一个能运行但有有错误设计的脚本如果被内化到领域工作流中，可能带来巨大的损失，这也与近年来的软件供应链中的几起包投毒事件具有非常类似的结构。
更强的Agent生成更多看起来正确的内容，这些生成内容具有更大的校验难度，虽然的确降低了生产成本与行动门槛，但人类的判断能力并没有同步提高，因此飞轮能力提高，反而外溢到了风险和责任层面。
对于一个完整的闭环系统而言，可以非常粗糙地简化出一个这样的模型：
假设一个任务由多个关键环节组成，每个环节的成功率为 ，且这些环节都必须成功，最终任务才算成功，那么整体成功率可以近似写成：
即：最终任务的成功，依赖于每个环节的成功。
对于长任务来说，其自然由多个环节组成，但即使每一个环节的成功率都很高，总体成功率也未必高，例如，对于5个90%成功率的多环任务，其最终成功率 。
当然，实际工作中并不总是严格的串联系统，某些错误也可以被后续的流程发现并回滚修正，充分的测试与多agent交叉检查也能提高系统鲁棒性。但这一简化模型依然说明了核心问题：
长任务中，agent的可靠性不能由单步能力直接外推。
更麻烦的是，agent的错误往往不是静态错误，而是动态的轨迹漂移。一个轻微的任务误解，可能导致计划的偏移，进而调用错误的工具，产生误导或无关的反馈，模型对错误的反馈进行解释，最终整个系统在一个可能自洽的错误方向上狂奔。
对于多环节正确衰减，一个自然的反驳是：如果单个agent/LLM不可靠，那使用多个agent或planner-executor-verifier这样的分工结构来提高整体可靠性？
直觉上，这是一个非常有吸引力的想法。一个agent进行规划，一个负责执行，一个负责审查，等等，这样的分工似乎与多人团队协作很类似，也能缓解单点错误。
但是我们会发现，当前社区中的多agent协作有非常有趣的能力分层设定：多agent的分工通常交给多个不同模型配合不同提示词和设定来实现，这一方面有成本上的考虑，另一方面也体现出一个可能问题：
多agent并不等于多样化认知
我们当前正在进行的一份工作也是基于平行的假说：
模型同质性假说:多个agent共享相似的基础模型，对齐机制与训练数据时，它们的错误分布与能力边界也会高度相似，从而限制多agent系统在开放任务中的自我纠错能力和飞轮增益
换句话说，多agent系统协同的能力提升取决于其能力边界的互补。 如果不同agent的错误近似独立，那么交叉验证会显著提高可靠性，否则很有可能只是类似cot的质量提升，更有可能是错误判断的”傻瓜共振“。
一个简单的类比：
text低相关错误： Agent A 犯错 → Agent B 可能发现 → 系统有机会纠偏 高相关错误： Agent A 犯错 → Agent B 也倾向于接受 → 错误被二次确认
我们认为Moe架构模型的训练也能在这个框架下解释，其由路由机制在不同token/样本/任务上激活不同专家参数，从而实现模型容量扩大与部分计算成本降低。但正如我们所说的，不同专家虽然可能在训练中形成一定分工，但它们通常仍共享训练目标、数据来源和模型框架。其间的差异能否形成真正的错误互补，并不能由专家数量本身保证。
同时，Moe的router本身也有可能成为新的薄弱环节：如果 router 把任务分配给了不合适的专家，或者多个专家共享同一类偏差，那么系统可能仍在错误方向上保持高度自信。
对应我们的公式，如果把多个 agent 看成多个错误检测器，那么系统收益取决于错误相关性。理想情况下，不同 agent的错误分布相互独立；现实中，如果它们来自同类基础模型，错误往往不是独立采样，而是高度相关的系统性偏差。更值得担心的是，模型厂商之间的相互蒸馏可能会增强这种相关性。
当然，以上的论断很大一部分仍处于假说阶段，如果有后续工作更新我会在本篇博客中继续完善。
正如我们前面外溢效应一节所说，agent可能将错误或噪声组织成可复用的流程/经验，这时的飞轮就是更危险的噪声放大器。
在普通工具链中，错误通常是局部的。一个脚本写错了，最多导致这一次任务失败。但在 agent 系统中，错误可能进入循环：
text错误目标理解 → 错误计划 → 错误工具调用 → 错误结果 → 错误总结 → 错误经验沉淀 → 下一轮更快更稳定地犯同类错误
在当前LLM的包装下，错误越发隐蔽，更难被审查者认知。 从代码角度，一个提示词可能在一次迭代中生成成千行代码，人类很难对此做出高质量的code review；更进一步，开环任务中LLM非常擅长自洽解释，一个错误轨迹可能非常有条理，清晰的步骤，完整的理由与证据链，经过多轮包装后，一个错误甚至比正确结果更显得可信。
更进一步，在技术错误之外，agent 飞轮中的“噪声”也包括了偏见、安全风险和伦理风险。
传统LLM使用中的错误与偏见输出通常停留在一次性回答中，用户看到后可能发现，也可能忽略，但在飞轮中，LLM的偏见可能逐渐变成流程化的偏见。 在招聘，教育，医疗，法律与科研等场景中，都有可能有这样的情况，隐藏在看似公正的流程下的可能是非常深层次的系统性偏见。
安全领域的风险也是类似的，从Openclaw在今年2月前后的安全风险就可以看出；伦理方面的问题则更加混乱：如果使用agent造成了风险或损失，这里的责任边界会更加模糊且难以确认。
某种意义上，agent飞轮失控的核心不仅是模型本身是否存在“偏见”，而是在近乎完全放权的情况下偏见的隐藏。一个聊天模型的偏见更容易停留在文档解释层，而一个agent的偏见风险可能会进入操作层。
将视角从agent系统放大到整个AI生态，我们更需要担心的是，强大基础模型为数据飞轮引入的偏差。
以Anthropic在claude code的开发为例，我们可以看到一种非常有辨识度的数据飞轮方案:
text更强的基础模型 → 更多用户与开发者接入 → 更多真实任务、交互轨迹与偏好反馈 → 更好的模型、工具接口与 agent 工作流 → 更强的平台吸引力 → 进一步集中用户、数据和能力
有理由推测2，opus/sonnet模型在训练过程中对agent使用能力有专门的语料数据。
这种非常典型的数据飞轮在基础模型能力提升的同时，也带来了三类可能的结构性风险：我们上一节中提过的偏见放大，与这里要提的能力垄断和数据垄断。
对于能力垄断，尽管大量上层应用看起来非常多样化：代码，文档，科研，法律...各种领域都有自己的agent，也有自动化工具支持，但如果底层能力主要来自于少数几个基础模型，那么生态的繁荣并不能带来能力来源的多样化。最终，大部分应用之间的差异更多实际只是不同的提示词工程与UI差异。
对于数据垄断，越强的模型越能吸引用户使用，带来越多的高价值任务，进而产生更多高质量的交互与任务数据，这些数据反过来用于改进模型，优化工具。数据优势与能力优势在此又形成了闭环的飞轮。
相比于聊天时代的语言模型，agent时代的高价值数据更多，完整的任务工作轨迹比单次问答更具有数据商业价值。但在这个过程中，偏见可能不只是被表达出来，更有可能被模型训练内化，更进一步，成为新时代ai的基础设施的一部分，
当然，强平台也更有资源和意愿投入安全评测，伦理对齐等等，但如果异质性生态被破坏，飞轮成为护城河，这些对齐的成本投入与价值产出可能逐渐不再对等。
这与电力，铁路等天然垄断行业非常类似，但问题更新颖也更有挑战。从这个角度讲，或许我们需要考虑，人工智能的下一次飞跃可能要超越企业界限，提升到国家/地球层面？当然，目前看来可行性不高。
即使存在局部小飞轮和外溢效应，将其迁移到困难任务依然有非常多阻碍。
迁移困难至少由以下四个因素影响；
这些困难的共同点在于：它们缺少像编译器、单元测试那样廉价、明确、可重复的反馈机制。代码任务中的错误往往可以在几秒或几分钟内暴露，而机器人、科研实验、组织决策和现实部署中的错误，可能需要更长时间、更高成本，甚至造成不可逆后果。
当前的飞轮能够解决的是闭环系统问题，但困难任务要解决的是开环系统，这也是为什么许多研究者认为VLA/世界模型等技术会是下一代人工智能核心，因为其目标是在更复杂环境中构建反馈结构。
下一代人工智能理解世界的基础，可能是视觉-语言-动作模型和世界模型。
视觉-语言-动作模型，即 Vision-Language-Action model (VLA)，试图把视觉观察、语言指令和动作控制统一起来。核心哲学是将模型在文本空间中的能力扩展到视觉环境理解与动作执行上。平行的对应类似下表：
| Coding Agent | VLA Agent |
|---|---|
| 代码库 | 视觉环境 |
| 终端命令 | 动作控制 |
| 编译器 / 测试 | 物理反馈 |
| diff / commit | 状态变化 |
| git 回滚 | 真实环境恢复 |
| 错误多为符号错误 | 错误可能具有物理成本 |
错误的本质差异是引入世界模型（World-Model,WM）的核心动机。 WM可以被理解为 agent对环境动态的内部模型。其在识别当前状态的基础上尝试预测：如果采取某个动作，环境接下来会如何变化。
此时的反馈流程由：
行动 → 真实反馈 → 修正
变为
候选行动 → 内部模拟 → 筛选行动 → 真实执行 → 外部反馈 → 校准世界模型
从而减少昂贵的外部试错环节。
从飞轮角度看，VLA更接近于行动的接口，而WM更接近反馈的预测。这样就形成了老生常谈的"数字孪生"闭环：外部闭环系统负责接触真实世界，而内部闭环系统负责降低成本。
不过，当前VLA与WM也远远没有达到飞轮闭环的程度，还有新的困难：
当前的VLA与WM更接近于下一代飞轮的必要但不充分组件。
可以想象的是，困难任务中的下一代飞轮，大概率不会来自于一个更大的LLM，而是与真实世界交互的多组件系统：
正如我们这篇博客反复强调的，飞轮转起来的核心是反馈，丰富闭环反馈是构建下一代agent和基础模型的核心。按成本/真实性由低到高，主要约束包括；
这三类约束相互校准，最终形成多层闭环，带来新反馈结构的重构。
回到最初的问题：LLM 与 agents 的飞轮效应，距离我们还有多远？
我的回答是；飞轮效应部分成立，但距离完全的飞轮依然还有很长的距离。
当前的飞轮已经能完成大量任务，飞轮效应也已经在部分领域形成，但向下一步扩张和完善，还有很长的一段路要走。agent与LLMs已经能够改变我们的许多工作与生活方式，但其自主递归与改进还需要更多人类的参与。
Lean Community, “What is a proof assistant?” The page describes a proof assistant as software that provides a language for defining objects, specifying properties, and proving that these specifications hold; the system checks that proofs are correct down to their logical foundation. See: https://leanprover-community.github.io/ ↩
Anthropic, “Claude Code Docs: Data usage.” The documentation states that for consumer users on Free, Pro, and Max plans, Anthropic may train new models using data from these accounts when the data-improvement setting is on, including Claude Code usage; for commercial users such as Team, Enterprise, API, third-party platforms, and Claude Gov, Anthropic says it does not train generative models using code or prompts sent to Claude Code under commercial terms unless the customer has chosen to provide data for model improvement. See: https://code.claude.com/docs/en/data-usage#data-usage ↩
本文作者:ziqing luo
本文链接:
版权声明:本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！