云原生新范式：AI Native 多智能体数字人架构实战

发布时间：2026-06-11 08:45来源：微信阅读：2

阿里妹导读

我们将云原生应用部门作为实验场，利用商业化产品 AgentTeams 组建了一支"数字员工小队"，让它们承担日常研发、工单解答、开源维护及运营等任务，将原本依赖人工串联的协作流程，升级为 AI Native 的工作模式。（本文内容基于作者个人的技术实践与独立思考，旨在分享经验，仅代表个人观点。）

开场：凌晨三点的告警

凌晨三点，值班人员的手机收到一条告警：某云产品消息引擎消费积压超过阈值。

按照以往的流程，接下来是这样的：被唤醒、登录跳板机、查阅 SLS 日志、对照运行手册、判断是消费者故障还是下游响应时间飙升、必要时拉群沟通、必要时升级至二线支持、最后撰写故障复盘报告。这一整套流程下来，MTTR（平均故障恢复时间）短则一两个小时，长则耗费半个晚上。

但在 AI Native 时代，剧本已被改写：告警出现 30 秒内，名为 taishan-alert-agent 的 Agent 数字人已在群内发出首轮诊断结论，并@了 taishan-diagnosis-agent 这个 Agent 数字人以进一步定位；再过 90 秒，根因定位完成，修复建议同步至 Team Room，并附带可执行脚本。值班同学起床洗漱的间隙，Agent 团队已闭环解决了 80% 的问题，剩余 20% 是关于"是否在生产环境直接执行修复"的决策——这一判断留给人来完成。

这套体系的基石，正是云原生推出的 AgentTeams 产品。基于它，我们能快速声明出一支"数字员工小队"，让内部一个个 AI Native 场景真正运转起来。今天就来聊聊它是如何诞生的、为何如此设计，以及我们目前的进展。

一、从 RPA 到大模型：自动化如何演变为"数字员工"

要讲透 AgentTeams，首先需梳理"自动化"的发展脉络。

最早出现的是 RPA（Robotic Process Automation，机器人流程自动化）。RPA 的本质是"录屏式"自动化：你如何点击鼠标、填写表单、从 A 系统复制数据到 B 系统，RPA 便照此复刻。它解决大量"流程清晰、规则固定、变化较少"的重复劳动，如财务对账、报表合并、跨系统数据搬运。但 RPA 存在硬伤：它不理解业务，一旦界面变动、字段顺序调整或弹窗增加，整条自动化脚本便需重做。

随后是大模型（LLM，Large Language Model）。大模型的革命性在于其具备"理解"能力——理解自然语言指令、上下文及模糊意图。于是，一种新的自动化形态诞生：Agent。Agent 不再是录屏脚本，而是能听懂"帮我处理此告警"的"人"——它会查阅文档、调用工具、做出判断并给出结论。

但单体 Agent 亦有天花板：上下文窗口有限，工具调用复杂度升高后易崩溃，面对需多角色协作的真实业务场景（产品提需求、研发写代码、测试跑回归、文档同步发布）便显得力不从心。

自然的演进方向是多 Agent 协同。然而问题在于：让多个 Agent 运行起来≠让它们像团队一样工作。缺乏组织结构便无稳定的分派关系，缺少通信策略则无可控可审计的消息边界，没有共享状态和统一网关就无法安全接入 LLM 与工具（MCP）。

AgentTeams 正是为解决"多 Agent 如何真正像团队般协作"这一问题而生。

二、何为 AI Native？为何我们要践行 AI Native？

许多人听说过 Cloud Native（云原生）——一套围绕"应用专为云上运行而设计"的方法论：容器化、微服务、声明式 API、持续交付、Kubernetes 编排。其核心是"应用无需适配云，而是天生生长于云上"。

AI Native 是同一思路的下一代延伸：系统不再是"额外集成 AI 能力"，而是"天生围绕 AI Agent 设计"。

维度

Cloud Native

AI Native

基本单元

容器 / Pod

Agent / Worker

编排对象

应用、副本、网络

智能体、协作关系、对话拓扑

声明式资源

Deployment / Service / Ingress

Worker / Team / Human / Manager

控制循环

kube-controller reconcile

hiclaw-controller reconcile

网关

Ingress / Gateway API

AI 网关（LLM / MCP 凭证收敛）

协作底座

Service Mesh

Matrix Rooms（多方在场、可审计）

为何要推行 AI Native？因为只有将 Agent 视为"一等公民"进行声明、编排与治理，才能解决三大难题：

可复制——一个可运行的 Agent 团队，下一个业务团队拿来即用，无需每次从零搭建。

可治理——谁能@谁、谁能调用哪个 LLM、谁能使用哪个 MCP，皆为策略而非约定。

可演进——今日使用 OpenClaw，明日切换 CoPaw（商业化语境中亦称 QwenPaw，下文统称 CoPaw），后日接入 OpenKruise Agent Sandbox，业务编排无需变动。

这便是 AI Native 的价值，也是 AgentTeams 的使命。

三、AgentTeams 究竟是什么

先厘清名称，避免误解：

HiClaw：开源项目地址（github.com/agentscope-ai/HiClaw），未来将更名为 AgentTeams，社区可见的所有 CRD、controller、Helm Chart 均源于此。

AgentTeams：HiClaw 在阿里云上的商业化云产品，提供托管版的多智能体协同平台。

为简化表述，下文统一称为 AgentTeams。

AgentTeams 的官方定位十分明确：协作编排治理平面（Collaboration Orchestration Plane）。它不替代 Agent 运行时（OpenClaw / CoPaw 层），也不替代推理服务（LLM 提供商）和工具服务（MCP Server），它专注于一件事——让多个 Agent 像真正的组织般运转。

类比如下：

层

Cloud Native

AI Native (AgentTeams)

工作负载运行时

containerd / CRI-O

OpenClaw / CoPaw

编排控制面

kube-controller-manager

hiclaw-controller

服务网关

Ingress / Envoy

Higress AI Gateway

共享存储

PV / PVC

MinIO / OSS（S3 兼容）

通信底座

Service Mesh

Matrix（Tuwunel homeserver）

用户终端

kubectl / Dashboard

Element Web / 钉钉客户端

若你已熟悉 Kubernetes，便能快速上手 AgentTeams。

四、架构：平台 Manager+ 业务 TeamAdmin

→TeamLeader→Workers

AgentTeams 最关键的设计决策，是将"组织结构"转化为声明式 CRD，并显式分层平台管控与业务协作。所有 API 资源均位于 apiVersion: hiclaw.io/v1beta1 下，核心包含四种 Kind：

Kind

类比

一句话定位

Manager

平台管控者

平台级管理 Agent，可创建 Team / Human / 平台资源。商业化版本中平台管控动作由控制台 UI 承接，默认禁用。

Team

部门

一个 TeamAdmin（Human Owner）+ 一个 TeamLeader（Worker）+ 若干 Worker，是真正"做事"的单元

Worker

员工

最小执行单元：容器 + Matrix 账号 + MinIO/OSS 空间 + Gateway Consumer

Human

真实用户

真人 + 权限层级（L1/L2/L3），决定可进入哪些房间、可@哪些 Agent；其中某个 Human 可被指定为某 Team 的 TeamAdmin，代表业务方"老板"角色

真实的协作链：谁与谁对话

许多人初见 Manager 会误以为它是"老板"，其实不然。Manager 是平台管控角色——负责创建 Team / 创建 Human / 维护平台级配置。在商业化版本里，平台管控动作由产品控制台 UI 承接，业务协作链路收敛为 TeamAdmin → TeamLeader → Workers，Manager 不直接与 Worker 对话；而 HiClaw 开源侧仍保留 Manager 作为协调 Agent 的通用能力，开源用户可根据场景自行决定 Manager 的参与方式。

真正"老板派活给经理、经理带员工干活"的链路存在于 Team 内部，由 TeamAdmin（业务方真人）→ TeamLeader（Worker）→ Workers 串联而成：

几个关键边界，直接决定了它"像一个团队"而非"一堆 Agent"：

Manager 不进 Team Room、不@Worker（商业化版本）—— 平台管控动作由控制台承接，业务协作链路收敛为 TeamAdmin → TeamLeader → Workers。类比 Kubernetes 中的 cluster-admin，只管"建集群、建 Namespace、发权限"，不管业务如何运行。HiClaw 开源侧仍保留 Manager 作为协调 Agent 的通用能力，开源用户可按需使用。

TeamAdmin 才是真正的"老板"——它是 Team CRD spec.admin 字段里指定的一个 Human，是该 Team 上的 Human Owner，通常由 L1/L2 权限的真人承担，代表业务方"老板"角色。TeamAdmin 并非独立于 L1/L2/L3 之外的新权限层级，而是某个 Human 在具体 Team 上的业务 Owner 身份。产品推荐实践是：TeamAdmin 仅与该团队的 TeamLeader 在 Leader DM Room 里对话，"老板不越级管理"作为房间拓扑层面的约束。

TeamLeader 本质是一个特殊的 Worker——它是由 Team 声明出来的协调型 Agent，职责是接需求、拆任务、派活和汇总结果。它可以拥有自己的 Skills / MCP / Soul，归属在这个 Team 的所有 Worker 都会注册到 Leader，因此 Leader 清楚队伍里有谁、每个人擅长什么。但需注意，TeamLeader 与普通 Worker 在产品语义、字段能力和运行时选择上并不完全等价——它承担了任务编排和结果收敛的额外职责，这些在 Team CRD 中有专门的配置入口。

Worker 之间能否互相@，由 Team 的 peerMentions 字段控制；能否跨 Team@，由各自的 channelPolicy 控制。一切"谁能跟谁说话"皆为策略，而非约定。

五、Human 资源与三层权限

许多多 Agent 平台只解决了 Agent 间的事，忽略了"人"也是一等公民。AgentTeams 专门为真人设计了 Human CRD：

三层权限设计直接映射进 Matrix 房间邀请和 Agent 的@mention 允许名单：

层级

含义

能力

L1 Admin

平台管理员

进任何 Team Room、@任何 Worker；可被任意 Team 指定为 TeamAdmin

L2 Team

团队成员

进自己 accessibleTeams 列表内的 Team Room、@该 Team 内任何 Worker；如果在某个 Team 的 spec.admin 里被点名，就是该 Team 的 TeamAdmin，独占该 Team 的 Leader DM Room

L3 Worker

单 Worker 协作者

只能跟自己 accessibleWorkers 列表内的 Worker 单聊

注意：TeamAdmin 不是一个独立的权限层级，而是 L1/L2 Human 在某个具体 Team 上的"业务 Owner"身份。

一个 Human 可以同时是 A 团队的 TeamAdmin、B 团队的普通成员、C 团队完全无关。这种"权限 × 团队"的二维设计，让真实组织里"我是 X 部门的负责人但 Y 部门的旁听者"这种关系能够原生表达。需要说明的是，上述约束在商业化版本中通过产品层面的房间拓扑和权限策略来保障，属于推荐实践；开源 CRD 层提供了声明这些关系的字段，但并非所有约束都由 CRD 层面天然强制执行。

这套权限模型解决了一个生产场景中非常关键的问题：HITL（Human-in-the-Loop，人在回路）不是补丁，而是一等公民。值班同学、研发同学、PM、运营，都是用同一套 Matrix 客户端进入同一套房间，与 Agent 自然对话。

六、构建企业自己的 AI Native 体系

6.1 部署形态与实践路径选择

AgentTeams 提供两条落地路径：基于开源项目 HiClaw 自建，或直接使用阿里云托管的商业化云产品。两者共享同一套控制器语义（hiclaw-controller reconcile），核心差异在于运维方式和基础设施集成深度：

维度

开源自建（HiClaw）

云产品（AgentTeams）

Worker 后端

Docker 容器（本地/演示）或 K8s Pod（生产）

SAE / ECI 实例 / 安全沙箱

运维

企业自行运维控制面和基础设施

云产品全托管，开箱即用，监管控一体化

安全隔离

由企业内部安全体系兜底

成熟云模式，独立云账号/VPC + 安全容器

内网访问

天然可达企业内部服务

需通过安全接入网关打通（详见 6.2）

定制灵活性

可深度定制 Agent 运行时与工具链集成

提供产品级白屏化扩展支持

适用场景

对定制化要求高、有独立运维能力的团队

希望快速落地/云产品兜底、专注业务的团队

两条路径各有取舍，没有绝对优劣。

我们选择了云产品路径，核心考量有两个：一是聚焦业务——团队精力有限，把运维交给云产品，把时间留给数字人团队本身的打磨。二是以客户视角反哺产品——用自己的产品服务自己的业务（dog-fooding），在真实场景中发现产品短板，推动产品持续演进。下文均以云产品模式展开探索与验证。

6.2 基于云产品实施 AI Native 基础架构构建

网络架构：公共云 <-> 安全网络通道 -> 内部服务

通过前述 AI Native 场景分析，初期阶段主要依赖内部的代码仓库、项目协作平台、钉钉消息/文档、应用发布运维等系统。因此，只需打通这几类服务即可落地四类 AI Native 场景。以下是具体实施步骤：

1）购买/开通 AgentTeams 服务

购买一套 AgentTeams 服务，零改造接入。AgentTeams 运行在售卖区独立云账号、独立 VPC 及独立 ASI 集群中，无需自行运维产品本身，团队可专注于打磨业务数字人。该产品目前处于邀测阶段，预计很快会在阿里云正式上线。

2）搭建模型及 Worker 团队

首次登录控制台完成服务关联角色授权 → 创建实例（选择地域和网络配置）→ 添加模型并绑定供应商 → 创建用户 → 创建 Worker 团队（配置 Team Leader 的模型、SOUL.MD、AGENT.MD 及技能绑定）→ 创建 Worker 并关联团队 → 开启公网访问，通过 Element UI 验证团队功能。这样便获得了一支由 Team Leader 和多个 Worker 组成的数字人协作小组。

3）通过安全网络通道实现云端 AI Agent 安全访问内部服务

数字人团队就绪后，下一步是打通其与内部系统的连接。通过安全网络通道连接公共云 VPC 与内部网络，提供访问审计、权限管控和服务路由能力，仅定向开放必要的内部系统。这一机制兼顾开放与安全：企业可正常使用云产品推进 AI Native 实践，同时将 AI Agent 限制在云产品 VPC

内，防止访问逃逸和模型幻觉引发的内网误操作。至此，完成公共云与内部服务的对接，实现安全可控的独立 AI Agent 环境构建。

4）凭证收敛在网关，Agent 只拿 Consumer Token

网络打通后，还需解决凭证安全问题。LLM、MCP、内部服务的 API Key 不应散落在每个 Agent 容器里——跨网络分区的场景下尤其关键。AgentTeams 的做法是

- AI 网关（Higress / 阿里云 APIG）持有上游真正的凭证（OpenAI / Claude API Key、各种 MCP 上游 Token、内部服务的统一服务账号）。

- 每个 Worker 只拿一个可吊销的 Consumer Token，通过网关访问 LLM、MCP、内部服务。

- 网关层做 per-route allowedConsumers 授权——谁能调哪个 LLM、谁能用哪个 MCP、谁能访问哪个内部服务，都是策略，不是约定。

通过以上四步，该方案在解决运维托管的同时安全打通了内部服务依赖，最终以标准云产品方式完成 AI Native 基础设施搭建。基础设施就绪后，接下来进入真正的核心环节——在平台上构建面向具体业务场景的数字人团队。

七、15 个 Agent + 4 个 AI Native 场景实践

在 AgentTeams 上，我们已经沉淀了 15 个 Agent，覆盖研发、测试、诊断、答疑、经营分析、知识沉淀六大领域。如果只是单 Agent 各自为战，价值有限；真正的价值是把它们串成"闭环 AI Native 场景"——围绕一个真实工作场景，让多个 Agent 在 AgentTeams 上协同跑通端到端流程。

围绕核心内部真实场景，第一阶段共计 4 个 AI Native 场景：

AI Native 场景

数字人涵盖内容（TeamLeader + 多 Worker）

落地产品/项目

内部产品研发全链路

一句话进来，整条"需求 → Spec → 代码 → Review → 测试 → 发布"链路由 Team+ 不同数字人 Agent 自动跑通，文档同步维护；人只在需求澄清、PR 合并、生产发布等关键决策点介入。

AgentLoop 云产品

7×24 智能值班答疑中心

问题咨询和工单不再先经人工分流再排查，数字人团队全自动接管"分诊 → 诊断 → 回复"全程，值班同学只看数字人解决不了的疑难案例。

云监控产品

开源研发流水线

开源项目 Issue / 每个 PR 由数字人团队巡检 + 自动出 Patch + 自动 Review，人只在 PR 合并这一关键动作上决策。

RocketMQ/Chaosblade 开源

经营 + 社区双驾驶舱

PD / PDSA / 运营用自然语言问任意经营数据（收入、客户、订单等经营数据…），数字人取数、返回答案。

运营 / PM

过去人是工具的操作者，现在人是数字员工团队的决策者——业务方用自然语言或事件触发，一支声明出来的 Agent 团队自动跑完全程，工具反过来由 Agent 操作，人只在"需求澄清、架构评审、关键动作决策"等关键拐点介入。

以下是两个业务团队分别在自己场景下的一个多数字人协同的实际运行的截图，仅供参考。

示例 1:7×24 智能值班答疑中心场景

1、提供工单给数字人，进行工单分析

2、TeamLeader 分析完毕后，安排其他数字人进行执行处理

3、当本数字人发现自己无法解决时，需要转交给其他数字人继续解决

4、最终问题解决，并告诉 TeamLeader 进行汇总给人，进行查阅。

通过这套数字人的协同，可以看到以下优势：

1、自动分诊路由 —— Leader 基于产品线标签 + 核心问题特征精准选派专家，不靠人肉判断。

2、DAG 编排接力 —— 单节点起步、按需扩成多节点，专家间结论自动透传，无信息折损。

3、诊断深入根因层 —— 不止"复现/止损"，而是直达指标 Dimensions 设计层面的链路断点。

4、全程可追溯 —— 每个任务/产物都落到 shared/tasks/... 与 shared/projects/... 文件，人类可审计、可复盘。

5、人机共治 —— Human、TeamLeader、Worker 同房间在线，工单负责人随时可接管、补刀、纠偏。

6、输出工程化 —— 不只给"答案"，还给修复方案矩阵 + 工单回复建议，让人类值班 1 分钟收尾。

最终实现了从一张工单链接出发，三位数字员工 6 分钟内（13:50 → 13:56）完成"接单 → 路由 → 两阶段根因诊断 → 修复方案 → 工单回复建议"全闭环，把传统值班需要多人协调半天的链路问题，压成了一段可复盘的对话流。不仅仅时间大幅缩短，还能给出非常详细的报告。

示例 2：开源研发流水线 - Chaosblade

1、在 github 上提交一个 issue

2、让数字人针对性对某个 issue 进行分析并探索解决方案

3、人工参与确认方案无问题后，让数字人推送到社区

4、社区进行二次确认方案，并评论采纳

5、继续在数字人团队推动下一个动作，提供修复 PR

6、若 AI 提供的 PR 有问题，也可以直接在 github 进行交互

7、数字人团队检查到问题，进行修复

8、社区确认无问题，同意合并，问题解决。

以上在数字人团队中的各个人工介入的步骤，未来会升级为自动化的方式进行，人工只需要在社区进行 Review 及相关的确认交互，减少人工参与。

通过这套数字人的协同，可以看到以下优势：

1、一句话直达合并 —— 人类只下几句指令，全链路自动跑完。

2、真读懂代码 —— 13 次源码定位，精准还原 ±1 振荡反馈回路。

3、工程级输出 —— RCA + 风险评估 + 测试覆盖，资深贡献者水准。

4、真写代码 + 测试 —— +60/-1 真实 diff，4 组测试用例。

5、能扛 CI 反馈 —— DCO 失败自主 --amend --signoff + force push。

6、完全融入开源语境 —— 英文 RCA、/approve 协作流，与人类贡献者同构。

7、IM × GitHub 双通道 —— 内部下指令、外部交付，跨平台无缝协同。

最终实现了数字员工 github-chaosblade 接到一句"分析下 chaosblade#1301"的指令后，自动完成读源码定位 ±1 振荡反馈回路根因 → 在 issue 下发布根因分析与修复方案 → 在 feature/blade-ai 分支生成代码与测试 → 提交 PR#1302→ 根据 reviewer 反馈修复 DCO 并 force-push → 最终被 /approve 合并的 issue 全链路闭环，把开源协作里"提单—分析—编码—评审—合并"的整条链路一次性自动跑通。

八、写在最后：为什么 AI Native 值得做

回到最开始那个凌晨三点的故事。

过去十年，云原生让我们不再操心"应用怎么在服务器上跑"，让基础设施成了水电煤。下一个十年，AI Native 要让我们不再操心"AI 怎么在业务里干活"，让一支声明出来的数字人（Agent）团队，成为每个业务团队天然的"数字同事"。

AgentTeams 的目标也很直接：多 Agent 协同不是写脚本能解决的事，它需要一套像 Kubernetes 一样的控制治理平面——声明式 API、持续 reconcile、清晰的资源边界、可治理的权限和通信。当组织结构、消息策略、网关侧 LLM/MCP 规则、共享存储能在同一条运维路径上被治理，"数字员工"才真正从 PPT 走向生产。

如果你正在规划下一代 Agent 平台，建议把 AgentTeams 当作协作编排治理平面——让业务同学把精力真正聚焦在"业务数字人"的打磨上，把团队拉到 10x 效率。

我们也在持续演进 AgentTeams 的能力边界：更深度的钉钉集成让人机交互更自然；安全体系持续加固，涵盖企业级账户打通、业务数据权限收缩、高风险 HITL 决策和零信任网络；异构 Agent 协作能力，通过标准化接入层连接不同 Runtime 和部署形态的 Agent；以及 TeamSpec 模板化，把"角色配置、技能组合、协作策略"沉淀为可复用、可调整的团队蓝图。

附录

AgentTeams 开源地址：https://github.com/agentscope-ai/HiClaw