下一个十年，AI Native 要让我们不再操心 AI 怎么在具体业务里干活。通过 AgentTeams 这套如同 Kubernetes 一样的控制治理平面，组织结构、通信边界、网关凭证与共享存储被统一纳入声明式 API 的控制循环（Reconcile）中。

大家好，我是玄姐。

一、开场：凌晨的告警剧本

凌晨，值班同学的手机弹出一条刺眼的告警：某产品消息引擎消费堆积超阈值。

1.传统剧本（Cloud Native 时代）

• 被叫醒 ➔ 登跳板机 ➔ 翻 SLS 日志 ➔ 对照 Runbook ➔ 判断是消费者挂了还是下游 RT 飙了 ➔ 必要时拉群/升级到二线 ➔ 写故障复盘。

一整套流程下来，MTTR（平均故障恢复时间）轻则一两个小时，重则半个晚上。

2.新剧本（AI Native 时代）

• 30 秒内： 数字人 Agent 在群里贴出第一轮诊断结论，并 @ 专家数字人 Agent 进一步定位。
• 90 秒内： 根因定位完成，修复建议同步至 Team Room，附带一份可执行脚本。
• 最终结果： 值班同学刚起床洗完脸，问题已被 Agent 团队闭环了 80%。剩下的 20% 是一个“是否在生产环境直接执行修复”的终审决策：这个判断，留给人类。

  

这套流程的底层支撑，是云原生团队推出的 AgentTeams 产品。基于它，我们可以快速声明出一支“数字员工小分队”。今天就聊聊它是怎么长出来的、凭什么这么干，以及我们走到了哪一步。

二、从 RPA 到大模型：自动化向“数字员工”的演进

要讲清楚 AgentTeams，得先把“自动化”的脉络理一下：

• RPA 时代（录屏式自动化）：解决“流程清晰、规则固定”的重复劳动（如财务对账、数据搬运）。硬伤是不理解业务，界面一变、脚本即刻返工。
• 大模型时代（单 Agent 时代）：核心革命在于“理解力”。它能听懂模糊意图，会查文档、调工具。但单 Agent 有其天花板：上下文窗口有限，工具调用变复杂后容易崩，无法应对多角色协作的真实场景。
• 多 Agent 协同时代（AgentTeams 阶段）：让多个 Agent 跑起来 ≠  让它们像一个团队一样工作。没有组织结构就没有稳定的分派关系，没有通信策略就没有可控的消息边界。AgentTeams 就是为了解决“多 Agent 怎么真正像一个团队协作”而生的。

三、什么是 AI Native？为什么需要它？

Cloud Native（云原生）的核心是应用不再需要适配云，而是天生就长在云上。

AI Native（AI 原生）则是这一思路的延伸：系统不再是“额外集成 AI 能力”，而是“天生围绕 AI Agent 来设计”。

维度对比：Cloud Native vs AI Native

维度	Cloud Native (云原生)	AI Native (AgentTeams)
基本单元	容器 / 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，业务编排完全不用动。

四、核心架构：平台 Manager 与业务三层层级

在正式看架构前，先厘清两个概念：

• HiClaw：开源项目（未来将更名为 AgentTeams），社区里所有的 CRD、Controller、Helm Chart 均来自这里。
• AgentTeams：开源项目在阿里云上的托管版商业化产品，提供协作编排治理平面。

类比 Kubernetes，AgentTeams 极其注重组织结构的声明式设计。所有 API 资源均在 apiVersion: hiclaw.io/v1beta1 下，核心包含四种 Kind：

Manager (平台管控)
             │  仅做平台级动作：建Team、建Human、配权限
             │  ✗ 不直接和任何 Worker 对话
             ▼
    ──── 平台边界 ──────────────────────────────────────────
    ──── 业务边界 ──────────────────────────────────────────
       TeamAdmin (业务方 Human Owner，真人老板)
             │  提需求、给反馈、确认成果
             ▼
       TeamLeader (特殊的 Worker Agent，项目经理)
             │  拆任务、@ 派活、汇总结果
             ▼
    ┌────────┬────────┴────────┬────────┐
    ▼        ▼                 ▼        ▼
 Worker    Worker            Worker   Worker  (具体执行任务的 Agent)

协作边界与设计原则

• Manager 与业务解耦：Manager 属于平台管控角色（类似于 cluster-admin），负责建集群、发权限，不直接进 Team Room 参与对话。商业化版中该动作由控制台 UI 承接。
• TeamAdmin 才是真老板：由 Human 资源承担，拥有某 Team 的最高业务决策权。产品推荐实践中，TeamAdmin 只与 TeamLeader 单聊（DM Room），坚决贯彻“老板不越级管理”。
• TeamLeader 是核心枢纽：本质是个特殊的 Worker 角色，充当项目经理。它了解队伍里每个 Worker 的技能（Skills/MCP），负责拆解任务、派活与结果收敛。
• 通信边界完全由策略控制：Worker 之间能否横向 @ 协同，由 Team 的 peerMentions 字段控制；能否跨团队交流，由 channelPolicy 决定。

五、真人的一等公民身份：Human 资源与权限

很多平台只解决了 Agent 之间的通讯，却忽略了“人”才是闭环的终点。AgentTeams 通过 Human CRD 赋予真人原生身份：

apiVersion: hiclaw.io/v1beta1
kind: Human
metadata:
  name: zhangsan
spec:
  displayName: 张三
  email: zhangsan@example.com
  permissionLevel: 2            # 1=Admin, 2=Team, 3=Worker
  accessibleTeams: [oncall-team]
  accessibleWorkers: []

三层权限模型

• L1 Admin（平台管理员）：可进任何房间，@ 任意 Worker，能指派任何 Team 的管理员。
• L2 Team（团队成员）：进指定 accessibleTeams 房间。若被指定为 spec.admin，则激活 TeamAdmin 身份，独占 Leader 专属对话间。
• L3 Worker（独立协作者）：权限收敛，只能与特定 Worker 进行单聊。

这种“权限 X 团队”的二维设计，让真实企业中“我是 A 部门负责人，同时是 B 部门旁听者”的复杂关系得以原生表达。人在回路（HITL）不再是补丁，而是标准配置。

六、AI Native 基础架构的工程落地

1.部署形态对比

维度	开源自建 (HiClaw)	云产品 (AgentTeams)
Worker 后端	Docker 容器 / K8s Pod	SAE / ECI 实例 / 安全沙箱
运维成本	企业自行运维控制面与基础设施	云产品全托管，开箱即用，监管控一体
安全隔离	自行通过内部网络/容器策略兜底	独立云账号 + VPC + 安全容器隔离
内网访问	天然可达企业内部服务	需通过安全接入网关打通内部网络

出于“聚焦业务、以真实业务反哺产品（Dog-fooding）”的考量，我们选择了云产品托管路径进行落地。

2.实施四步走方案

[ AgentTeams 公共云 VPC ] ──( 凭证收敛：Consumer Token )──> [ AI 网关 ]
                                                                │
                                            (安全网络通道) ──────┘
                                                │
                                                ▼
                                    [ 企业内网敏感服务 / MCP ]

• 开通托管服务：实例运行在独立安全集群中，免去基础设施运维，让团队聚焦数字人本身。
• 构建 Worker 团队：白屏化配置 SOUL.MD、AGENT.MD 与 Skills 绑定，建立基础协作小组。
• 打通网络安全通道：建立公共云与内网的单向安全通道。提供精细化审计，将 Agent 的行为严格限制在特定 VPC 内，防止模型幻觉引发内网误操作。
• 凭证收敛于 AI 网关：LLM API Key、MCP Token 以及内部系统的凭证统一由网关（如 Higress）持有。Worker 容器只拿一个可随时吊销的 Consumer Token。谁能调哪个模型、调哪个接口，全部变成网关层可动态调整的策略。

七、实战演练：15 个 Agent 与 4 大 AI Native 场景

目前我们在平台上部署了15 个 Agent，全面覆盖研发、测试、诊断、答疑、经营分析和知识沉淀六大领域。单兵作战价值有限，真正的化化学反应来自于将它们串联成端到端的业务闭环：

【过去】 人类 ➔ 操作工具 (SLS / Git / 监控)
【现在】 业务输入 / 事件触发 ➔ Agent 团队协同 ➔ 自动操作工具 ➔ 人类在关键拐点决策

1.第一阶段四大落地场景

• A. 内部产品研发全链路（AgentLoop）：从一句话需求，到 Spec ➔ 代码 ➔ Review ➔ 测试 ➔ 发布 全自动跑通。人类只在需求澄清、PR 合并、生产发布等关键点进行决策。
• B. 7×24 智能值班答疑中心（云监控）：工单全自动接管，实现 自动分诊 ➔ 根因诊断 ➔ 回复建议 全程闭环，值班人类只需审核疑难杂症。
• C. 开源研发流水线（RocketMQ / Chaosblade）：自动巡检 Issue/PR、出 Patch、跑 Code Review，人类仅把控最后的 /approve 合并动作。
• D. 经营 + 社区双驾驶舱（运营 / PM）：产品与运营用自然语言询问复杂经营数据，数字人自动取数、计算并渲染图表返回。

2.典型成效复盘

案例一：7×24 智能值班答疑 ➔ 6分钟工单全闭环

从一张工单链接出发，三位数字员工在6 分钟内（13:50 ➔ 13:56）完成了“接单、路由、两阶段根因诊断、输出修复方案、生成工单回复建议”的全链路闭环。

核心优势：自动分诊不靠人肉判断；DAG 串联让专家 Agent 间信息透传无折损；诊断深入系统底层的链路断点，最终将半天的工单处理时间压缩为人类 1 分钟审查收尾。

案例二：开源研发流水线 ➔ Issue 到 PR 的自动化

在接到“分析 chaosblade#1301震荡反馈回路根因”的单条人类指令后，github-chaosblade 智能体自发完成了源码定位、在 Issue 下提交英文 RCA 报告、在分支生成测试用例与代码修复、提交 PR，并根据 CI 反馈自主进行 --amend 修正。

核心优势：具备工程级交付质量，能够完全融入 GitHub 协同语境，实现“内部下指令，外部自动化交付”的无缝跨平台协同。

八、写在最后：下一个十年，属于 AI Native

过去十年，云原生（Cloud Native）让我们不再操心服务器与环境部署，让基础设施成为了像水电煤一样的存在。

下一个十年，AI Native 要让我们不再操心 AI 怎么在具体业务里干活。通过 AgentTeams 这套如同 Kubernetes 一样的控制治理平面，组织结构、通信边界、网关凭证与共享存储被统一纳入声明式 API 的控制循环（Reconcile）中。

“数字员工”正在真正脱离 PPT，走向生产线的核心。