最近几个月，AI界有一个项目让人无法忽视，那就是OpenClaw。这个项目在短短时间内引起了广泛的关注，获得了数十万的星标，Token消耗也令人咋舌，几乎所有的大公司都迅速跟进。乍一看，它似乎又是一个火爆的AI产品，但深入思考后，不禁让人好奇——OpenClaw的出现究竟传递了什么信号？它真的是技术上的一次飞跃，还是暗示着某种更深层次的变化呢？
最近，在清华科技园，端侧智能北京市重点实验室举办了一场关于智能体的创新研讨会，8位来自不同领域的嘉宾分享了他们的见解，讨论了OpenClaw背后的技术逻辑、发展趋势以及安全性等多个维度。
中国人民大学的副教授林衍凯在会上做了题为《从OpenClaw看智能体技术发展趋势》的报告，探讨了三个关键问题：第一，现在的智能体技术发展到什么阶段？第二，当前的核心瓶颈是什么？第三，未来一到三年，这项技术将如何演进？
他从系统架构、执行交互方式到基础模型和多智能体的协作，逐层剖析技术的真实状态，提出一个看似“反常”的观点——OpenClaw并非在底层算法上取得了突破，而是通过工程整合使得大模型的能力达到了“可用”的标准，让智能体真正走入了实用阶段。它更像是一个智能体操作系统的早期雏形，在统一模型、工具及交互方式上重新定义了AI的使用方式。它的迅猛发展本质上是模型能力与工程体系在同一时间点共振的结果。
此外，林衍凯还对核心瓶颈进行了系统性的理解，指出OpenClaw暴露了智能体在可靠性、长任务执行、Token成本、记忆体系及自主进化等方面的主要问题。
最后，他强调，智能体未来的发展重心不再仅仅是提升模型的实力，而是通过端云协同、协议标准化和多智能体系统，实现从单一能力向系统能力的转变。
接下来是演讲的完整内容：
今天，我想借OpenClaw这个最近炙手可热的智能体项目，和大家聊聊目前智能体技术的发展现状、核心瓶颈以及未来的方向。我会尽量减少产品讨论，更多地关注技术层面的思考。
首先让我们看看一些数据，自OpenClaw推出后，24小时内便获得了9000个星标，两个月内星标数超过27万，甚至超过了Linux，成为历史上星标最多的项目之一。根据我获取的数据，OpenClaw在OpenRouter上的Token消耗量在一周内就达到4.73TB，远超其他项目。同时，国内几乎所有的大厂也开始跟进，今天微信也接入了龙虾，热度极高，许多城市也为OpenClaw制定了相关政策。
我今天并不是想讨论它火不火，而是想探讨三个技术性的问题：它为何在这个时刻引爆？它技术上是否真的有创新？以及目前亟需解决的问题有哪些？
OpenClaw爆火的根本原因是“可用性革命”
OpenClaw自项目启动到突破20万星标，创始人加入OpenAI，实际上也不过三四个月，而它的火爆至今也仅一个月。为什么它会如此火呢？在我看来，核心原因是它大幅降低了用户的使用门槛。不同于传统聊天机器人，它是一个可以自主执行任务的AI智能体。尽管在大模型出现后，像AutoGPT和XAgent等项目也有类似的能力，但OpenClaw真正实现了让普通用户轻松上手使用。
在这里，我有个大胆的看法：从AI和大模型技术创新的角度来看，OpenClaw其实并没有太多创新，它只是在利用已有的技术。它没有训练模型、没有改进推理算法，也没有进行底层工具学习。它所做的，主要是接入IM通讯平台、本地部署架构、分层记忆和Gateway标准化。这些都是优秀的软件工程设计，但在核心算法上并未有实质性突破。
我们可以看到，系统中真正发挥作用、为用户带来良好体验的，实际上是接入的Claude Opus 4.6或GPT-5.4等基础模型。我认为，OpenClaw对大模型的影响，类似于浏览器对互联网的作用——它本身并不创造内容，但重新定义了用户的交互方式，让非技术背景的人也能顺畅地将大模型应用到日常工作中。
正因为OpenClaw在底层算法上没有过多改变，它反而成为了一个非常好的技术分析样本。它的成功向我们展示了哪些技术已相对成熟（例如基础模型的工具调用和执行能力），同时也揭示了当前还缺失的技术（例如系统的可靠性、记忆模型的迁移能力，以及端云协同的不足）。
我想通过OpenClaw这个切入点，系统性地审视智能体技术的现状、核心瓶颈，以及未来的研究方向。
让我们来看一组统计数据，自大模型问世以来，在50%成功率的情况下，智能体可以自主完成的任务长度在大模型推出后，倍增时间从过去的一两年缩短到约4个月。右边的图是我提到的Claude Opus 4.6和GPT-5.4，它们在代码能力和工具调用能力方面相较于前一版本有了质的飞跃。
OpenClaw是智能体操作系统的雏形
OpenClaw的整体技术架构简洁明了，从底层的系统控制到智能体循环系统，再到上层的标准化封装和信息流管理，最终接入各种用户可见的渠道。大家使用起来之所以顺畅，源于它的六大关键技术特性——这是我在另一场报告中听到的总结，非常到位：社交接入、本地部署、设备接入、模型生态、技能生态，这些特征让它在底层模型、各类用户、不同设备和复杂任务中展现出强大的兼容性。
从软件工程的角度来看，OpenClaw有三个非常核心的设计。
首先是它的Gateway系统，采用三层架构，通过分层的方式实现无论外部接入设备还是IM软件，都能通过Gateway统一路由和调度到智能体层。这样一来，智能体便不必担心用户通过什么平台交流，或外部硬件是什么，只需专注于底层API和顶层接口的对接。
其次是它的分层记忆机制。
OpenClaw设计了一个简单而实用的记忆机制。虽然它的记忆机制看似简单，但在实际应用中非常有效。早在AutoGPT或其他智能体模拟系统中，我们也见过类似的设计。
最底层（L1）是当前会话的上下文，属于短期记忆，当上下文窗口快满时会自动压缩消息，其生命周期随会话结束而终止。
第二层（L2）其实就像我们的日常笔记或流水账，能够自动收集最近两天的记录，并且有一个为期30天的衰减机制。
再往上是长期记忆层（L3），它负责把底层的信息进行整合，提炼出有关人物的资料、喜好以及一些经验教训。
最顶层（L4）则是围绕文件的语义智能召回，目的就是让系统更个性化。通过这样一套建立在大模型之上的智能体记忆架构，系统会“越用越懂你”，而且使用效果会越来越好。
接下来，第三部分兼容了Claude的技能生态。你可能已经注意到，它有三层结构。第一层通过名称和描述来帮助模型迅速明白技能的功能，从而实现快速检索；第二层则是详细的工作流程，这让模型在处理不同任务时能更清楚该怎么做，比如制作PPT或者其他工作的大致步骤。这种技能方法能让智能体执行特别复杂的任务。最后一层是一些相关的资源。
以上三点是我对OpenClaw进行拆解后认为最有价值的部分。
谈到OpenClaw的整体架构，我有个个人看法，我真心觉得OpenClaw不该仅仅被视为一个软件或应用，而更像是未来智能体操作系统的雏形。
我看到一篇有趣的文章，提到正如Linux让所有的硬件和软件在统一标准下运行，OpenClaw也在尝试让所有AI模型、消息平台和工具在同样的标准下协作，这正是操作系统的核心使命。
它在上面提供了统一的抽象，屏蔽了不同大模型API的差异；下面则管理资源，比如技能插件和消息通道；而中间则通过网关进行调度。它的四层架构——LLM抽象层、Agent循环、运行时、网关——与经典操作系统的分层结构高度一致。
最近我也常跟朋友讨论，OpenClaw的代码其实缺乏一个强大的团队来维护。随着大家用AI生成代码来修改它，现在的状态就像早期的Linux，显得有点粗糙，代码臃肿，甚至已经超出一个人能审查的范围，整体架构也不够成熟。我觉得这也是创始人加入OpenAI的原因之一，希望借助大公司的力量推动目前原型和产品级操作系统的重构。
现在OpenClaw仅仅解决了一个人在一台设备上操作一个Agent的问题，但未来所有的终端设备都将成为Agents，未来的需求是数百个Agents在分布式环境下协同工作，这需要线程管理、服务发现和行为审计，而这些正是OpenClaw目前所欠缺的。所以我们看到，目前整个生态的竞争正在框架层、协议层以及未来可能出现的编排层展开。可以说，未来的模型工具和应用必须适应这样的框架和协议，才能有效使用。
去年我发布了一些智能体模型，但反响并不如预期。是什么原因呢？其实我自己都不太想用它，首先它的能力还不如Claude，我写代码时还是会选择Claude。其次，发布时即使是一些极客用户，能够给我们的模型配API，还是更倾向于使用ollama进行推理，毕竟ollama已经是一个相当不错的框架了。
不过，智能体有自己的一套运行框架，我们的模型必须在我们设计的框架下才能更好地运行。这意味着一旦有了OpenClaw，用户就会直接使用OpenClaw来运行你的模型。如果效果不好，用户就会觉得你的智能体模型不行。这点非常重要，未来一旦有了这样的东西，可能是OpenClaw，或者基于OpenClaw的其他东西，我们的模型就得主动适应它，正如在移动时代，应用程序必须兼容IOS和安卓一样，这也是我们要努力的方向。
生态竞争焦点：框架、协议与Agent-Native软件
因此，从操作系统的角度来看，生态竞争已经开始。目前有三条发展路线。
在协议层面，大家也在争夺，包括MCP、A2A、IOA协议。协议决定了谁在这个生态中的话语权，未来大家都得跟着它走。对于我们这些研究人员来说，正如我刚才提到的，未来模型的竞争维度必须从跑分高转向使用体验好。这使得工具的使用、结构化输出、长上下文和推理能力，从原来的加分项变成了硬性要求。如果达不到这些标准，就无法在OpenClaw这样的框架下运行，大家也不会选择使用你。
接下来是交互执行层面，大家正在探索智能体如何操作软件。目前有两条路线：
第一条是通过调用结构化API、MCP协议直接介入外部工具，这种方式可靠、执行迅速，而且相对容易验证。但问题是，它面向的现有软件生态并没有提供完善的API接口，覆盖率不足也是个难题。
另一条路线是GUI Agent，像人一样去看屏幕、点击鼠标，豆包AI手机或Claude Computer Use都在尝试这种方式。它的优势在于通用性强，任何APP都能操作，但缺点是需要不断截屏识别，速度较慢、资源消耗大，且点击的准确率不如直接调用API来得稳定。
从我的视角来看，大模型智能体的出现，特别是OpenClaw这种现象级产品，正在促使传统软件向“AI原生（Agent-Native）”设计方向发展。当用户发现API调用效果更好时，他们会逐渐要求软件提供API接口。如果OpenClaw、Claude Code等主流框架无法调用你的软件，大家就会慢慢舍弃它。
最近也有一些研究尝试通过大模型将现有的GUI软件自动转化为Agent-Native的CLI接口，比如港大的CLI-Anything项目。它通过7个步骤的自动化流程，分析软件代码库，自动生成CLI接口，在Blender、LibreOffice等9款软件上验证，所有一千多项测试均已通过。
因此，我认为短期内这两条路线还是会共存，GUI处理长尾的应用，而技能调用则处理核心工作流。长期来看，随着越来越多软件逐步转化为Agent-Native接口，工具调用的覆盖率将持续上升。
核心瓶颈与关键技术路径：长程性、端云协同、任务拆解与记忆系统
从基模层面看，Agent要真正落地使用，必须能够可靠地完成多步长任务，这是用户愿意使用你的前提。看看这两张图：
图上纵坐标表示模型可以完成的任务时长。在只要求50%成功率的情况下，像Claude Opus 4.6甚至能执行长达10小时的任务；但如果将可靠性提高到80%、90%甚至95%（这可算是日常商用的底线），即使是Opus 4.6的任务时长也会从10小时降到1小时。就像QA时提到的，普通人并没有那么多钱，或者算力有限，能够接触到的模型可能只能完成几分钟的任务，这使得我们现在的智能体模型在纯端侧的道路上短期内不太容易实现。
从工具型智能体到自主进化的新纪元
从短期来看，端云结合似乎是个不错的办法。要是完全依赖云端的话，算力就显得捉襟见肘，费用也相当高。而如果只考虑端侧的话，眼下的模型效果难以满足需求。那么，有什么解决方案呢？其实可以通过云端来拆解任务，把长时间的工作细分为几分钟的小任务，然后让端侧来执行，最后再由云端进行验证。
这种方法目前看来是可行的。我们在 AgentCPM 系列的研究中发现，在特定的应用场景下，端侧的小模型完全可以达到与云端大模型相近的效果。刘知远老师提到的密度法则（Densing Law）也指出，我们的模型能力每 3.5 个月就会翻一番。也就是说，今天需要云端处理的子任务，明年端侧就可能能够完成，随着时间推移，端云结合的应用前景会越来越广。
我们的智能体能力如今已经达到了人类专家的水平。正如之前提到的，Agent 在特定领域的突破相当显著，尤其是在代码领域，比如 Claude Code，它在 GitHub 上的提交占比已经达到了 4%，预计到年底会贡献 20% 的提交量；而国内的日行迹公司通过 FARS 项目，也证明了大模型可以批量生成研究论文。
这些案例让我们得出了一个共同的公式：专业智能体 = 通用大模型 + 领域知识库 + MCP 工具 + 专业工作流程 + 领域后训练。只要我们走通这条路，就能在端侧搭建一个专注于特定任务的智能体，既节省算力，又能高效运作。
不过，单纯依靠云端的方式也有一个致命的问题，那就是 Token 消耗非常高。目前真正使用 OpenClaw 的人并不多，结果一周就消耗了 4.7T Token。假设未来有两千万人使用，现有基础设施肯定承受不住。大家可以看看成本对比图，使用 Opus 4.6 每天大概需要 10 美元，即使是 GPT5.4 也得花 5.5 美元。
最近有人说，未来的竞争可能就是谁掌握了更多高质量的 Token，掌握这些 Token 的人将在产业或技术竞争中占据优势。
现在这么贵的 Token 实在是难以负担，假如未来用户增加十倍、百倍，现有算力根本无法支撑。因此，我们必须充分利用手机、PC 等设备的闲置算力，推行端云结合。云端负责任务的规划和拆解，而端侧的小模型则负责执行这些子任务。一旦把长任务分解成十个以内的小任务，端侧模型就能胜任。解决长程任务的方式不一定是让单一模型变得更强，拆分任务，让合适的模型做合适的事情，更能有效解决问题。
为了处理长任务，记忆系统也是个关键点。目前市面上有很多不同设计的记忆系统，包括人工设计的和基于学习的，有明文记忆、隐状态记忆和参数化记忆，各有优劣。人工设计的记忆结构安全可控，但策略固定，无法应对新场景；基于学习的记忆可能会发现更优策略，但需要梯度信号和模型权重都是可访问的。
在记忆形式上，隐状态记忆与特定模型绑定，换模型就不行，而参数化记忆则无法在其他模型中应用。从记忆架构的可用性角度来看，对于端侧模型，我们可以使用隐状态和参数记忆。而在未来的端云记忆大规模复用中，我认为“可迁移的明文记忆 + 可优化/学习机制”将是一个非常有潜力的方向。
从工具型智能体到自主进化系统
最后谈谈自主进化的问题。如今的智能体自主性还不够强。当我们把任务应用到多种场景后，真实环境的动态和多变性往往要求模型能像人一样主动适应和探索，同时不断学习。目前的智能体还是依赖已有模式，部署后无法主动进化。学术界也在逐渐从早期的模仿学习转向人类反馈的探索学习，朝着具备主动环境交互能力的自主学习方向发展。
那么，结合端云协同和现有的 OpenClaw 框架，我们是否能实现端侧的自主进化呢？
目前的自主进化有很多分类，比如基于经验学习和参数学习的自主进化，以及有明确监督、弱监督和无监督信号的模式。最近有一个尝试是在 OpenClaw 上进行端侧自主进化，项目名为 OpenClaw-RL，来自 Princeton 团队。他们发现智能体与环境交互时会生成下一个状态信号，比如用户的回复、工具输出和终端状态变化，这些信号中既有评价信息，也有行动指导信息。
OpenClaw RL 的设计是一个全异步的四组件架构，在前端服务用户的同时，后台同步进行轨迹收集、质量评估和权重更新。在个性化评测场景中，他们发现仅需 8 步训练，就能将个性化得分从 0.17 提升到 0.76。当然，这个项目还处于初步阶段，局限性也很明显：需要 8 块 GPU，仅支持自托管开源模型，无法改进闭源模型，缺乏跨用户的联邦学习。当前的端侧自主演化机制仍然非常初级，面临诸多限制，比如参数学习存在崩溃风险；闭源模型无法获取权重学习；每个部署端也都是数据孤岛。真正的 AI 自主进化离实际应用还有很长的路要走。
未来如果实现了端云结合，可以想象会有更多设备参与进来。再看看多智能体（Multi-Agent）系统的发展，过去几年中，整个多智能体系统取得了令人瞩目的进展。从 2020 年 OpenAI Five 的个位数智能体，到 2026 年 Moltbook 上的 150 万智能体进行自主社交，规模提升了六个数量级。
清华团队提出的 MacNet 证明了增加智能体数量确实能持续提高任务解决质量，首次发现了智能体协作的 Scaling Law。大企业和研究机构也在尝试将多智能体引入，比如 Opus 4.6 就引入了所谓的 Agent team 功能，一个主 Claude 实例可以生成多个独立的子 Agent 并行工作，通过共享任务列表和消息系统进行协调。这是工业界在多 Agent 架构上探索的一个相对成熟的实现。
不过，从多智能体的角度看，我还是想泼点冷水。Moltbook 确实引发了轰动 —— 150 万 AI Agent 在多个论坛讨论技术和存在主义，甚至创建了“龙虾教”。但从技术角度看，这更多是大量 Agent 的单向广播，而非真正的互动交流。
真正的群体智能涌现，需要像曼哈顿工程和载人航天那样，一群 Agent 去完成单个 Agent 无法完成的高阶任务。这种群体智能的涌现，需要智能体之间产生有意义的分工、冲突和适应性协调，而不仅仅是各说各话。离真正的“智能体互联网”还有很长的路。
最后我个人的判断，第一阶段是工具化 Agent 阶段，智能体作为增强版工具，人类负责设定目标和审查结果，关键突破在于推理能力的提升，并逐渐在端侧落地。当我们拥有 10B 规模的端侧模型，具备 R1 或 V3.2 推理能力时，端云协同架构就能大规模部署。MCP、A2A 等协议会在这一阶段逐渐成熟，若加速发展，到 2027 年，智能体或许能处理数天甚至数周的长任务。
第二阶段则是半自主智能体或协作 Agent 阶段，多个智能体开始能够进行自主分工、协调和纠错，这种协作 Scaling 可以被有效预测和利用。智能体在线学习将成为标配，就像 iPhone 刚推出后，三年内 APP 商店的生态迅速爆发，所谓的智能体操作系统也需要经历这样的生态建设期。
关于智能体自主学习的未来展望
到了第三个阶段，我们的智能体终于能够独立学习了，想象一下，整个世界里有数以万亿计的智能体，它们在被启用后会不断进化。说实话，要实现这个阶段，我们面临着不少根本性的问题，比如：自主性的界限在哪里？怎样才能实现一种不依赖于模型的记忆结构？群体智能涌现的条件又是什么？而当智能体取代了传统的知识工作者，谁又会为这些 Token 买单呢？这些都是挑战，但同时也是我们研究者的机会。
最后，来个总结吧。OpenClaw 并不算是技术的革命，但它确实标志着技术发展的一个关键时刻。从端到云的协同、记忆结构的构建，到智能体在端侧的演化以及群体智能的涌现，这些都揭示了当前智能体面临的一些问题。每一个层面都蕴藏着深刻的研究潜力。现在正是智能体技术从“可行演示”到“大规模应用”的重要转折点，这一时刻非常关键。
