GDPS 2026 大会洞见:企业级 Agent、AI Native 与一人公司

0 阅读13分钟

2026 GDPS 大会洞见

gdps2026-01.jpg

今年的 GDPS 给我的一个很强烈的感觉是:AI 话题已经不再停留在“模型又变强了”这一层,而是开始往更具体的工程问题和组织问题收束。大家讨论的,不只是 Agent 能不能做事,而是它怎样进入企业、怎样被约束、怎样沉淀成真正可复用的能力,甚至怎样进一步改变团队规模与公司的形态。

如果把这次大会的内容压缩成一句话,那就是:企业级 Agent 平台正在从概念展示走向工程化落地,而 AI Native 与 One Person Company,正在成为这股变化向外扩散的两个方向。

一、三大关键词与行业趋势

  1. 三大关键词:企业级「龙虾」(企业级 Agent Platform)+ AI Native Dev(软件开发范式重构)+ OPC(One Person Company)是大会的高频主题——AI 开始重构开发方式与组织形态
  2. OpenClaw 成为最热 Agent 产品形态,出现大量「套壳虾」,进入「百虾大战」。
  3. Skill 成为企业核心资产,软件工程进入 AI-Native 阶段,竞争从人力规模转向 Skill 能力沉淀
  4. 记忆、安全与权限、角色与成本管理成为企业级 Agent 平台的关键能力。
  5. 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 之所以难以直接进入企业,并不是它不够酷,而是它天然更像一台面向个人创造力的机器,而不是一套面向组织治理的系统。

gdps2026-02.png

gdps2026-03.jpeg

3.2 当前主流方案

主要是两大类:

  1. 云服务商路线:如阿里云无影、AWS、百度云等推出的类 OpenClaw 云产品,将权限、沙箱、网关、身份管理、负载均衡、服务稳定性、观测与监控等 Harness 基础设施建好,开箱即用,企业用户可自行配置 Agent。
  2. 自研路线:企业基于 OpenClaw 二次定制开发的方案。

这两条路线,本质上是买“现成底座”还是自己搭“可控底座”的选择。前者追求速度,后者追求贴合度。短期看,云厂商会先吃到更多红利;长期看,真正把 Agent 变成组织核心能力的公司,往往还是会走向自己的平台化建设。

AWS OpenClaw on AgentCore

gdps2026-04.png

阿里云无影:JVS Crew

gdps2026-05.jpg

MemTensor:ClawForce

gdps2026-06.jpg

gdps2026-07.jpg

商汤科技:小浣熊家族 Raccoon

gdps2026-08.jpg

百度智能云:DuClaw

gdps2026-09.jpeg

追觅科技:DreameClaw

基于 OpenClaw 的二次开发产品,已在企业内实现招聘、审批等十余项业务 AI 化

截图 2026-04-04 13-52-32.png

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 在百万行代码实验报告中正式采用这一术语。

gdps2026-11.jpeg

Harness 到底是什么:一个与计算机的类比

中国有成语「信马由缰」,比喻做事随心所欲、不加约束——这大致就是 Agent 在没有 Harness 工程时的执行状态。Harness 工程要做的,则是把 Agent 这匹马的缰绳收紧,让它按我们规定的路线前进。

过去我们讨论 Agent,常常把注意力放在“它会不会思考”“会不会规划”“会不会反思”上。但现在越来越多团队开始意识到,真正决定系统可用性的,不只是模型聪不聪明,而是你有没有给它一个足够好的工作环境。Harness 解决的正是这个问题:不是继续在 Agent 外面堆更复杂的编排,而是为它准备一整套合适的工具、规则、权限和反馈回路。

gdps2026-12.jpeg

与计算机系统的对比

计算机系统要素 (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 的前沿探索

gdps2026-13.png

gdps2026-14.png

Agent 开发范式的转变

重编排转向 Harness 建设:不必在 Agent 层堆叠过于复杂的工作流编排,编排逻辑会逐渐内化到模型能力中。例如,过去需要在 Agent 内做「分析用户意图的路由设计」「对执行结果的反思决策」等模式,未来可能成为模型的默认能力。

接下来的重点,应放在:我们为 Agent 提供什么样的运行环境、哪些工具与 Skill、什么样的约束规则

换句话说,未来真正拉开差距的,可能不是谁写出了更复杂的 Flow,而是谁更懂得给模型铺路。谁能把环境准备得更清楚、工具定义得更明确、约束做得更自然,谁就更有机会把 Agent 变成稳定的生产力,而不是一次次需要人工兜底的演示系统。

截图 2026-04-04 14-02-40.png

4.2 AI Native 怎么去做

从面向 GUI,转向面向 AIPI(API、CLI、Shell),让 AI 能直接操作软件。

截图 2026-04-04 14-03-40.png

这部分我个人感触很深。过去几年,很多“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 工具可直接操作飞书全系能力:

gdps2026-17.png

Chrome 也有开源 CLI 版本,AI 不必再通过模拟人类的方式操作浏览器。

gdps2026-18.png

留给我们的课题:在 AI 提效项目中,存量系统要做 AIPI 改造;新增系统或功能需同时考虑面向人与面向 AI 的接口。

我越来越觉得,AIPI 这件事不会只是一种“给 AI 用的附加接口”,而会慢慢变成软件设计的新默认值。今天我们还在讨论“要不要给 AI 开接口”,过一两年,问题可能会变成“这个系统为什么还没有 AI 可调用的接口”。

4.3 Skill 开发需要注意什么

gdps2026-19.jpg

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 不只是新工具,而是在重写软件如何被构建、被调用、被管理,最终也重写公司如何运转。