金磊发自凹非寺
量子位 | 公众号 QbitAI
龙虾(OpenClaw)的火,是真的火,整个行业都在为这个能真正干活的 Agent 疯狂。
但真用起来的尴尬,也是真的尴尬。
因为好多企业跟风 All in Agent,砸钱接入了顶尖大模型,搭好了看似炫酷的 Demo,可一到规模化落地就频频翻车——要么卡在系统对接上,要么困在权限安全里,最后变成只有少数工程师会用的内部玩具,根本跑不进真实的业务流程。
这就不免让人发出疑问了:人人都能用的龙虾,怎么到了企业这里就水土不服了呢?

针对这个问题,来自 MiniMax 的 Agent 首席架构师阿岛和腾讯云 Agent Runtime 产品副总经理、专家工程师 Gary,在近期一场 Agent Infra 热点圆桌中一针见血地戳破了真相:
企业落不好 Agent,是人的思维从根上就出错了。
用“人在中心”的旧体系,套“Agent 为中心”的新时代
在直播中,阿岛和 Gary 达成了一个最核心的共识,这也正是绝大多数企业 Agent 落地失败的首要原因:
试图在不改变原有工作流、不调整系统架构的前提下,把 Agent 当成一个“插件”强行嵌入现有的企业体系中。
现有的企业 IT 系统是怎么来的?是为了让人更好地分工协作而设计的。
无论是 OA 审批、财务报销,还是研发管理系统,其底层逻辑都是“以人为中心”。系统里塞满了为了防范人类错误而设置的审批节点、繁琐的表单规范和层层递进的权限控制。Gary 坦言:
绝大多数企业的常规操作,是让 AI 去适配这些以人为中心设计的流程。
阿岛在直播中用了一个非常生动的比喻——Harness:
Agent 就像一辆马力全开的 F1 赛车。你想让它跑出极限速度,就必须为它打造适配的车身与专业的赛道。但现在很多企业的做法,是强行把这辆 F1 赛车开到了普通的乡镇公路上,还要求它必须遵守家用轿车的限速和红绿灯规则。这怎么可能跑得快?

想要真正释放 Agent 的能力,企业必须完成一次思维的跃迁:从过去的“人在中心操控 AI”,转变为“Agent 在中心干活,人是驾驭者(Harness)”。
这意味着企业的工作流、代码项目、文档规范,甚至文件命名,都必须转变为“面向 Agent 友好”的结构化模式。Agent 需要能拿到人能拿到的所有信息,而人,退居为它的输入和输出节点之一。
Gary 用腾讯内部的亲身实践佐证了这一点。
在腾讯内部,研发团队最初尝试将 Agent 接入需求管理系统 TAPD。TAPD 的设计源自传统的软件工程,强调角色分工(产品提需求、研发写代码、测试抓 Bug),系统中布满了复杂的富文本交互和审批节点。
“一开始我们尝试在不改变既有工作流的情况下,把 Agent 对接进去,结果发现这条路完全走不通。”Gary 回忆道。
真正的破局点发生在思维转变之后。当研发人员开始思考“我一个人如何在 AI 的辅助下最高效地完成工作”时,奇迹发生了:
我们发现突然不需要那么多流程了。我们以 Git 仓库为唯一真源,消除了冗余的审批节点,赋予了 Agent 能够自闭环的权限。那一刻,所有的落地门槛都消失了,Agent 自然而然地就落地成功了。
真正的 Agent Native 企业,一定是围绕 Agent 重新组织工作流的。
技术惯性认知误区,正在让 Agent 落地走偏
如果说“旧瓶装新酒”是思维上的宏观阻碍,那么在具体的执行层面,业界普遍存在的技术惯性认知误区,如同隐形的枷锁,直接决定了 Agent 落地的成败。
这是目前云厂商和 IT 基础设施团队最容易犯的错误。很多人仅仅把 Agent 看作是下一个微服务或者大数据升级。正如 Gary 所说:
我看到同行中有很多误区,最典型的就是拿过去做微服务的那套 K8s 技术方案,去硬承接 AI Agent。

这种生搬硬套是致命的,因为两者的底层假设完全相悖。
传统的 Docker 和 K8s,假设的是应用是无状态的、同质化的,并且是随时可以销毁和快速伸缩的。
但 Agent 的本质是什么?
它是有状态的,它的记忆和当前执行的上下文至关重要;它是异质的,每一个 Agent 基于不同的设定和进度,都是独一无二的;它还是长时运行的,可能需要 7x24 小时不间断地为你盯着数据或执行任务。
拿着解决静态、无状态问题的旧锤子,去敲击自主、不确定性的 Agent 钉子,显然只会把钉子敲弯。
云不仅是给人用的,更是给 Agent 用的
思维的转变,最终必须落地到坚实的基础设施上。
过去几十年的 IT 信息化进程,无论是单体应用、微服务还是大数据,其核心服务的对象始终是“人”。但正如 Gary 所言,AI Agent 带来的是一次真正的范式转移——它改变了用云的主体:
过去的云都是人使用的,现在的云,是 Agent 去使用的。
这意味着,传统的基础设施已经无法承载 Agent 的需求。为了解决这个问题,腾讯云推出了 Agent Runtime。
它的核心设计逻辑非常清晰:消灭偶然复杂度(Accidental Complexity)。
对于大模型公司,他们只需要专注把模型能力做强;对于企业客户,他们只需要专注自己的业务 know-how。至于 Agent 怎么在一个安全的环境里运行、状态如何保存、权限如何管控、怎么跟第三方系统打通通信,这些庞大且繁杂的脏活累活,全部交由腾讯云 Agent Runtime 这样的原生基础设施来解决。
在这个体系下,腾讯云打造了专门的 Agent 网关来解决连接问题,并计划开源Cube 安全沙箱技术,从计算、网络、存储底座重新设计,为 Agent 提供一个既能保留工作状态,又能安全隔离的专属运行环境。
但在这个环节也存在着一个安全认知误区。
因为一提到 Agent 拥有自主操作权限,很多企业的安全部门就如临大敌:数据泄露怎么办?它乱操作删库了怎么办?
这种担忧很正常,但如果因为这种担忧就拒绝 Agent,那就大错特错了。阿岛认为,这就像 15 年前电商刚兴起时,大家都在质疑“邮购靠谱吗”、“支付安全吗”一样。
新技术的出现,必然会冲击原有的基础设施,但同时也一定会催生出适应新时代的基础设施。阿岛指出:
在移动互联网时代,我们孕育出了手机一键登录、微信支付、支付宝这样的基础设施,才有了后来的外卖、打车和电商生态。
Agent 时代也一样。今天大家觉得安全是阻碍,但未来一年,我们一定会看到专属于 Agent 身份认证、权限委托的“时代支付宝”出现。

Gary 对此也补充道:
未来智能体甚至可能会在法律或者事实上拥有某种类似于企业法人的地位和权限。我们要做的是构建 Agent 时代的安全沙箱和授权体系,而不是因为害怕就停滞不前。
腾讯云 Agent Runtime 的核心设计,正是从底层基础设施层面,为 Agent 构建了这套原生的安全体系,通过 Cube 安全沙箱的全隔离运行环境、精细化的权限管控机制、全链路的操作轨迹可追溯能力,从根源上解决企业对 Agent 安全的核心顾虑,让企业无需再因安全担忧而限制 Agent 能力的释放。
而腾讯云这种原生基础设施的能力,在与 MiniMax 的深度标杆合作中,展现得淋漓尽致。
熟悉大模型发展的人都知道,决定 Agent 能力天花板的关键技术之一,是Agentic RL。这与过去简单的一问一答式训练不同,Agentic RL 需要让模型在一个真实的沙盒环境中(比如 Mac 系统写 iOS 代码,或者 Windows 系统操作桌面)去自主探索、试错并获得奖励。
这对底层 Infra 提出了极其苛刻的要求。
阿岛透露,为了覆盖足够多的场景,MiniMax 可能需要同时拉起十万甚至几十万级别的沙盒。这些沙盒里跑着不同的操作系统镜像,它们必须在秒级启动,而且环境必须高度稳定、支持随时快照保存:
一开始我们用传统的 K8s 去跑,发现根本不行,几万个并发瞬间就把 K8s 的 Master 节点拉垮了。
传统的 Infra 工程师面对这种需求,第一反应往往是“你能不能少拉一点?”
但在 AI 的进化速度面前,妥协意味着落后。
在这个关键节点,腾讯云展现了强大的定制化加速与底层重构能力。
为了支撑 MiniMax 庞大的并发需求,腾讯云抛弃了修修补补的思路,针对 Agentic RL 场景将计算和存储进行了全面重塑:
- 在计算调度上: 深入内核级进行锁优化和快照技术攻关,确保海量异构沙盒的秒级并发启动。
- 在存储加速上: 针对 MiniMax Agentic RL 训练面临的数十万异构镜像分发、带宽瓶颈的核心痛点,摒弃了传统繁琐的拷贝和复制流程,基于 Cube 平台自研了块级去重、多级缓存、按需加载的专属加速存储方案,利用内存映射等底层技术实现了磁盘直接作为镜像盘或沙盒盘的瞬间挂载,可支撑分钟级数十万沙箱的快速拉起,并发能力可随集群规模平行扩展;同时针对训练中高频的 CheckPoint 断点回放、分叉实验需求,打造了自研的 CoW 快照存储设施,支撑 Agent 秒级的暂停恢复与快照回滚能力,彻底解决了传统存储方案在大规模 Agent 训练场景下的性能瓶颈。
正是在这种真正 Agent-centric 的极速算力基础设施支撑下,MiniMax 得以实现模型能力的月级别快速迭代,并在复杂人设保持、长程任务执行上达到了比肩甚至超越国际顶尖模型的水平。
Gary 这样总结与 MiniMax 的合作:
我们不是比别人更聪明,而是我们真正认识到了这是时代的范式转移,并且认真地去重构它。
给从业者的建议
从会聊天的工具,到能干活的生产力;从个人桌面的 Demo,到千行百业的大规模落地。Agent 正在以不可逆的姿态重塑这个世界。
阿岛预测,在未来一年,Token 的成本将呈指数级下降,我们将看到全模态的 Agent 在便携设备中实时互动,并且具备自主进化、自己编写 Skill 的能力。
在这样一个近乎科幻的现实面前,企业和普通开发者该如何自处?
两位行业前沿的探索者给出了最朴素也最核心的建议:
第一,破除 Agent 与我无关的偏见。
无论你是做前端、后端、产品还是行政,只要你的工作中有重复性的内容,Agent 就一定能为你提效。不要因为一开始用不好,就觉得是岗位不匹配或者 AI 太笨。坚定地相信它,是落地的第一步。
第二,建立 AI Native 的工作模式,把 Agent 的价值用透。
Gary 分享了他自己的一种新型焦虑症:
我发现我的 Token 根本用不完。我的 Agent 不需要吃饭,只需要一台电脑和 Token 就能干活,但我居然没有让它时刻运行起来替我打工,这说明我自己的工作模式还不是 AI Native 的。

企业落地的第一步,不是立刻重构大系统,而是先让每个员工在自己的具体岗位上把 Agent 用起来。
当大家都习惯了 Agent,内部自然会形成分享插件和 know-how 的“大集市”,沉淀出企业的 AI 资产。只有底层的基建和员工习惯都 Agent-friendly 了,组织形态的重塑才会水到渠成。
第三,也是最重要的一点——Build is everything!
不要等系统完美了再上场,不要等公司下达指令再行动。就从今天开始,从解决工作中的某一个小 Bug、回复某一类邮件开始,用 WorkBuddy、用 MiniMax 去搭建属于你自己的 Harness。
在这个日新月异的时代,衡量一个工程师或企业效率的标准,或许很快就会变成:你每天能同时让多少个 Agent 为你打工?你每个月能烧掉多少有价值的 Token?
Agent 时代的入场券,不属于那些在岸上观望的人,只属于那些敢于跳下水,一边呛水一边学习游泳的构建者。
