2026 GDPS 大会洞见
今年的 GDPS 给我的一个很强烈的感觉是:AI 话题已经不再停留在“模型又变强了”这一层,而是开始往更具体的工程问题和组织问题收束。大家讨论的,不只是 Agent 能不能做事,而是它怎样进入企业、怎样被约束、怎样沉淀成真正可复用的能力,甚至怎样进一步改变团队规模与公司的形态。
如果把这次大会的内容压缩成一句话,那就是:企业级 Agent 平台正在从概念展示走向工程化落地,而 AI Native 与 One Person Company,正在成为这股变化向外扩散的两个方向。
一、三大关键词与行业趋势
- 三大关键词:企业级「龙虾」(企业级 Agent Platform)+ AI Native Dev(软件开发范式重构)+ OPC(One Person Company)是大会的高频主题——AI 开始重构开发方式与组织形态。
- OpenClaw 成为最热 Agent 产品形态,出现大量「套壳虾」,进入「百虾大战」。
- Skill 成为企业核心资产,软件工程进入 AI-Native 阶段,竞争从人力规模转向 Skill 能力沉淀。
- 记忆、安全与权限、角色与成本管理成为企业级 Agent 平台的关键能力。
- Harness Engineering 兴起,系统轻量化加速,模型能力增强并向 Agent 化演进。
这几个关键词放在一起看,其实已经勾勒出一条很清晰的路径:先有越来越强的模型,再有越来越像“员工”的 Agent,然后企业开始反过来问,如何把这些能力装进一个安全、稳定、可控、可计费的系统里。也正是在这个意义上,Agent 平台不再只是产品问题,而是基础设施问题。
二、「百虾大战」:OpenClaw 类产品名一览
腾讯 WorkBuddy — Tencent WorkBuddy
腾讯 QClaw — Tencent QClaw
腾讯龙虾管家 — Tencent Lobster Manager
腾讯云保安 — Tencent Cloud Security Guard
腾讯乐享知识库·龙虾版 — Tencent Lexiang Knowledge Base · Lobster Edition
字节 ArkClaw — ByteDance ArkClaw
智谱 AutoClaw — Zhipu AutoClaw
月之暗面 Kimi Claw — Moonshot AI Kimi Claw
阿里云 CoPaw — Alibaba Cloud CoPaw
阿里云 JVSClaw — Alibaba Cloud JVSClaw
阿里云 QoderWork — Alibaba Cloud QoderWork
百度红手指 Operator — Baidu Red Finger Operator
百度 DuClaw — Baidu DuClaw
科大讯飞 AstronClaw — iFlytek AstronClaw
MiniMax MaxClaw — MiniMax MaxClaw
网易有道 LobsterAI — NetEase Youdao LobsterAI
当贝 Molili — Dangbei Molili
智麻 ChatClaw — Zhima ChatClaw
矽速 PicoClaw — Xisu PicoClaw
博云 BocLaw — BocCloud BocLaw
ZeroClaw — ZeroClaw
万得 WindClaw — Wind WindClaw
小米 MiClaw — Xiaomi MiClaw
猎豹 EasyClaw — Cheetah Mobile EasyClaw
猎豹元气 AIBot — Cheetah Mobile Genki AIBot
京东灵犀 Claw — JD Lingxi Claw
快手 KClaw — Kuaishou KClaw
美图 Claw — Meitu Claw
360安全 Claw — 360 Security Claw
商汤 SenseClaw — SenseTime SenseClaw
华为小艺 Claw — Huawei Xiaoyi Claw
ToDesk ToClaw — ToDesk ToClaw
三、OpenClaw 如何走进企业
3.1 引入原生 OpenClaw 的风险
原生 OpenClaw 直接引入企业,现阶段答案是否定的。 企业级应用更关注的是安全,精准和边界,这和个人级AI助手在需求上有很大的不同。
个人用户会容忍“差不多能用”,企业不会。企业要的是权限边界明确、执行结果可追踪、成本可核算、角色可管理,最好还能在出现风险时一键兜底。从这个角度看,原生 OpenClaw 之所以难以直接进入企业,并不是它不够酷,而是它天然更像一台面向个人创造力的机器,而不是一套面向组织治理的系统。
3.2 当前主流方案
主要是两大类:
- 云服务商路线:如阿里云无影、AWS、百度云等推出的类 OpenClaw 云产品,将权限、沙箱、网关、身份管理、负载均衡、服务稳定性、观测与监控等 Harness 基础设施建好,开箱即用,企业用户可自行配置 Agent。
- 自研路线:企业基于 OpenClaw 二次定制开发的方案。
这两条路线,本质上是买“现成底座”还是自己搭“可控底座”的选择。前者追求速度,后者追求贴合度。短期看,云厂商会先吃到更多红利;长期看,真正把 Agent 变成组织核心能力的公司,往往还是会走向自己的平台化建设。
AWS OpenClaw on AgentCore
阿里云无影:JVS Crew
MemTensor:ClawForce
商汤科技:小浣熊家族 Raccoon
百度智能云:DuClaw
追觅科技:DreameClaw
基于 OpenClaw 的二次开发产品,已在企业内实现招聘、审批等十余项业务 AI 化。
3.3 硅谷的一些信号
以下信息仅为信号,不代表必然发生,仅供策略分析参考。
2026 年 3 月 31 日,Claude Code 相关代码泄漏事件中,包含一个尚未公开的名为 KAIROS 的模块。它有点像对 Agent 终极形态的一种构想:被设计为后台守护进程(Daemon),让 Claude 长期在线;通过订阅 GitHub Webhook,可在代码库出现新 Bug 时自动触发修复流程;其内置的 「Dream」(做梦)机制,允许在系统空闲时自行整理、压缩长期记忆——这已经很有「真正 Agentic AI」的味道。
另据硅谷投资人在社交媒体上的消息,OpenAI 可能在 4 月发布一款定价约 2000 美元/月的「AI 员工」类产品。
上述信息尚无明确产品功能与发布档期,但综合线索指向同一方向:能自主干活的 AI 员工,是模型厂商与云厂商都在布局的方向。
我觉得这里最值得关注的,不是某个传闻本身是否准确,而是这些传闻背后的想象已经开始趋同了。大家不再满足于“会聊天的 AI”,而是在讨论“会长期在线、会主动发现问题、会自己维护记忆、会自动协作的 AI”。这意味着下一轮竞争,不只是模型参数或单点功能的竞争,而是整套 Agent 运行机制的竞争。
四、企业 OpenClaw / Agent 平台的可能方向
4.1 Harness Engineer
该概念由 HashiCorp 联合创始人 Mitchell Hashimoto 于 2026 年 2 月 5 日首次提出;约六天后,OpenAI 在百万行代码实验报告中正式采用这一术语。
Harness 到底是什么:一个与计算机的类比
中国有成语「信马由缰」,比喻做事随心所欲、不加约束——这大致就是 Agent 在没有 Harness 工程时的执行状态。Harness 工程要做的,则是把 Agent 这匹马的缰绳收紧,让它按我们规定的路线前进。
过去我们讨论 Agent,常常把注意力放在“它会不会思考”“会不会规划”“会不会反思”上。但现在越来越多团队开始意识到,真正决定系统可用性的,不只是模型聪不聪明,而是你有没有给它一个足够好的工作环境。Harness 解决的正是这个问题:不是继续在 Agent 外面堆更复杂的编排,而是为它准备一整套合适的工具、规则、权限和反馈回路。
与计算机系统的对比
| 计算机系统要素 (Computer System) | Agent 环境要素 (Agent Environment) | 说明 (Description) |
|---|---|---|
| CPU (算力) | LLM (大语言模型) | 提供核心的推理、计算与生成能力。 (Provides core reasoning, computation, and generation capabilities.) |
| Memory (内存) | Context Window (上下文窗口) | 决定了 Agent 同时能处理的信息量与短期记忆。 (Determines the amount of information and short-term memory the agent can handle simultaneously.) |
| OS (操作系统) | Harness (工程框架) | 提供进程调度、权限控制、各类接口及运行约束。 (Provides process scheduling, permission control, interfaces, and operational constraints.) |
| Application (应用程序) | Agent (智能体) | 运行在环境之上,利用资源处理特定的实际业务任务。 (Runs on top of the environment, utilizing resources to handle specific business tasks.) |
Harness 的前沿探索
Agent 开发范式的转变
从重编排转向 Harness 建设:不必在 Agent 层堆叠过于复杂的工作流编排,编排逻辑会逐渐内化到模型能力中。例如,过去需要在 Agent 内做「分析用户意图的路由设计」「对执行结果的反思决策」等模式,未来可能成为模型的默认能力。
接下来的重点,应放在:我们为 Agent 提供什么样的运行环境、哪些工具与 Skill、什么样的约束规则。
换句话说,未来真正拉开差距的,可能不是谁写出了更复杂的 Flow,而是谁更懂得给模型铺路。谁能把环境准备得更清楚、工具定义得更明确、约束做得更自然,谁就更有机会把 Agent 变成稳定的生产力,而不是一次次需要人工兜底的演示系统。
4.2 AI Native 怎么去做
从面向 GUI,转向面向 AIPI(API、CLI、Shell),让 AI 能直接操作软件。
这部分我个人感触很深。过去几年,很多“AI 操作软件”的演示看起来都很惊艳,但一旦真正落到生产环境,就会暴露出速度慢、成功率不稳定、维护成本高的问题。问题并不全在模型,而在于大量软件压根不是为 AI 设计的。AI 只能像人一样去点按钮、识别界面、猜下一步,自然就又慢又脆弱。
这一转变在我们公司应不仅体现在「AI 提效」项目中:新增软件功能都应考虑如何让 AI 方便接入;同时,产品中的软件也要逐步兼容 AI 操作。
我从 2024 年起关注用户界面的 AI 自动化测试;至今,通过 LLM 操作手机、车机的通用方案,仍是 Agent 拆解测试步骤、在屏幕上模拟用户操作、根据反馈再决策——从最早的 AutoGPT,到去年智谱 AI 开源的 AutoGLM 手机操作框架,本质类似。根因是:此前大量软件并非 AI Native。
公司去年 CES POC 中的 AutoFlow(通过 Agent 操作 Spotify 播放音乐)也是同一路线。
为什么自动化测试难建、AI 操作软件又慢又不准? 核心在于:当前软件设计多为面向人的接口,AI 只能绕路去模拟人对 GUI 的操作。
终局方向是:各软件提供面向 AI 的操作接口;软件行业已开始掉头。
飞书在 3 月 28 日发布 Lark CLI,Claude Code 等 AI 工具可直接操作飞书全系能力:
Chrome 也有开源 CLI 版本,AI 不必再通过模拟人类的方式操作浏览器。
留给我们的课题:在 AI 提效项目中,存量系统要做 AIPI 改造;新增系统或功能需同时考虑面向人与面向 AI 的接口。
我越来越觉得,AIPI 这件事不会只是一种“给 AI 用的附加接口”,而会慢慢变成软件设计的新默认值。今天我们还在讨论“要不要给 AI 开接口”,过一两年,问题可能会变成“这个系统为什么还没有 AI 可调用的接口”。
4.3 Skill 开发需要注意什么
A. SAFETY(安全)
有专注 AI 安全的企业在分析 ClawHub 上 Skill 的安全性,据称逾 800 个 Skill 存在风险,风险类型包括:
- 恶意投递与下载器
- 凭据窃取与钓鱼
- 提示注入与指令操控
- 数据外泄与窃取
- 恶意脚本与通用检测
- 远控与反向 Shell
- 远程代码执行与命令注入
- 供应链与不可信安装
- 伪装与欺骗
- 黑客工具与漏洞利用
- 诈骗与金融欺诈
- 系统劫持与配置篡改
在企业内部,Skill 应由私有化 Skill 平台管理,供应链风险可在很大程度上被隔离。但开发阶段仍可能从第三方平台或开源项目引入 Skill;内部开发也可能因各种原因产出带安全风险的 Skill。因此需要制定 Skill 安全审核标准与审核方法。
业内已有公司做审查 Skill 安全性的插件,从多维度与指标评估;我们需要建设相应的审查标准、方法与工具。
如果说过去软件时代的关键资产是代码仓库,那么在 AI Native 时代,Skill 很可能会变成新的资产层。也正因为它离执行更近、离权限更近、离数据更近,Skill 的安全问题不能再被当作普通插件问题来处理,而要当作软件供应链的一部分来治理。
B. PERFORMANCE(性能)
Skill 完成任务时,还需考量准确率、多次执行一致性等,作为正式发布前的重要测试与评估指标。
C. COST(成本)
这与传统软件开发不同:Skill 开发尤其需要成本意识——Skill 的 Token 消耗,就是企业未来的研发成本。数据是企业的护城河,Skill 是企业的 AI 竞争力:同样一件事,若我方 Skill 的消耗比对手少一半,同等投入下就能多做一个项目。
在实施上,要设计完成任务的最短路径;能用 RPA 或脚本固化的流程,应用脚本替代「全靠模型想」,在提高稳定性的同时降低 Token 成本。例如解压文件:不要让模型自己琢磨用什么工具,甚至反复自写脚本尝试——应预先写好脚本,并告诉模型在什么情况下如何用。这也是 Harness 工程的体现之一。
很多团队现在看 Skill,还是从“能不能做成”出发;但真正进入企业之后,更重要的问题往往会变成“能不能稳定做成”“能不能便宜做成”“能不能规模化做成”。这也是为什么我越来越相信,未来企业之间的差异,不只体现在模型选型上,更体现在 Skill 资产和 Harness 工程的沉淀速度上。
五、最后一点判断
这次 GDPS 让我更确定了一件事:企业级 Agent 的竞争,正在从“谁先接上大模型”转向“谁先完成 AI Native 化、Skill 资产化和 Harness 工程化”。
OpenClaw 代表的是 Agent 产品形态的爆发,Harness Engineering 代表的是工程方法的成熟,AIPI 代表的是软件接口范式的变化,而 OPC 则代表了这些变化最终可能带来的组织结果。它们看似分散,实际上正指向同一个趋势:AI 不只是新工具,而是在重写软件如何被构建、被调用、被管理,最终也重写公司如何运转。