UModel / STAROps / 三件套

培训导读：3 个问题串起这份教材

问题	答案在
比对 Agent Infra的产品？我们做哪个？	第一章产品全景
数字员工的"大脑"（数据建模）怎么建？	第二章 UModel
数字员工的"身体"（平台 + 配置）怎么运转？	第三章 STAROps + 第四章三件套

第一章产品全景：Agent Infra 5 大产品

阿里云把 Agent 工程按"开发→运行→治理→观测→优化→运维"生命周期拆成 5 个独立产品，各司其职；MVP 只对标其中 3 个（UModel / STAROps / AgentLoop）。

我们 MVP 的范围（重要边界）

产品	MVP 是否做	说明
UModel	✅ 自研等价物	nodes/links YAML（基于官方 Node/Link/Field 三原语）
STAROps	✅ 自研等价物	数字员工 + 三件套（复用现有 SKILL.md/Extension @tool）
AgentLoop	✅ 自研等价物	评估 Skill（MVP 阶段 Skill 形式）
AgentCore	❌ 不做	多 Agent Team 编排是迭代后的事；原文该部分有产品植入成分
AgentRun	❌ 不做	用现成 CodeAgent 作为执行体，不需要开发平台

第二章 UModel——可观测数据建模方法

2.1 一句话理解

UModel 是用图结构（Node + Link）给 IT 世界画一张"统一、无歧义的地图"——让数字员工拿到的不只是某条日志，还有"它属于谁、关联到哪、对应哪次运行"。它是本体论（Ontology）在运维领域的商业落地。

2.2 是什么（官方定义）

UModel（Universal Observability Model）是一种基于图模型的可观测数据建模方法，采用 Node（节点）和 Link（边）组成的图结构描述 IT 世界。它是阿里云可观测体系的数据建模基础，提供通用的可观测"交互语言"，让人、程序和 AI 都能理解和分析可观测数据。

来源：阿里云官网 UModel 概览

2.3 本体论溯源（理解 UModel 的钥匙，重点）

2.3.1 阿里云官方明确承认：UModel 源于本体论

这不是脑补，是官方原话：

来源	官方原话
阿里云官网 UModel 概览	"UModel 的设计理念源于信息学的本体论（Ontology），通过明确定义可观测领域内概念及其相互关系，形成形式化的知识表示"
知乎·阿里云可观测团队	"本体论跨越两千余年的时光……最终在阿里云 UModel 身上，完成了在可观测与智能运维领域的原生实践"
阿里云开发者社区	"STAROps……是国内在 AIOps 方向上把 Ontology 落地得较为完整的实践"
思否·阿里云官方文章	"UModel 是阿里云基于本体论思想构建的运维世界统一建模框架"

2.3.2 本体论是什么（官方通俗解释）

本体论（Ontology）词源来自希腊语 ontos（存在）+ logos（学说），直译"关于存在的学说"。哲学里它回答：世界由什么构成？事物的本质是什么？

不管是哲学本体论还是计算机本体论，核心都解决三个问题：

问题	含义	在 UModel 里的对应
What exists?	这个世界里有什么东西真实存在？	EntitySet（实体集）——有哪些实体类型
How to classify?	这些东西怎么分类、怎么定义？	Field（字段）——实体的属性和类型
How to relate?	这些东西之间有什么关系？	Link（关系）——EntitySetLink/DataLink/StorageLink

一句话：本体论就是给你要研究的"世界"画一张统一、无歧义的地图。

2.3.3 UModel 把本体论映射为技术实现

传统本体论概念	UModel 技术实现	运维场景具体化
概念（Concept）	EntitySet	`apm.service` / `k8s.pod` / `devops.code_repository`
实体（Entity）	Entity（EntitySet 的实例）	`user-service` / `web-pod-123`
关系（Relation）	EntitySetLink / DataLink / StorageLink	`runs_on` / `manages` / `sourced_from`
属性（Attribute）	Field	主键、状态、类型、约束规则
公理（Axiom）	Schema 验证（ajv）	字段约束、关系基数、类型校验

2.3.4 分清四个易混概念（官方特别强调）

▼
mermaid
复制代码
flowchart TD
    Ontology["<b>本体论 Ontology</b><br/>定义'世界本身是什么样的'<br/>所有认知的起点"]:::o
    Epist["<b>认识论 Epistemology</b><br/>回答'我们该怎么认识世界'<br/>认知的方法"]:::e
    KG["<b>知识图谱 Knowledge Graph</b><br/>连接事实关系<br/>实体+关系+证据网络"]:::k
    WM["<b>世界模型 World Model</b><br/>推演状态变化<br/>预测+行动评估+反馈修正"]:::w

    Ontology -->|"先定义有什么"| KG
    Epist -->|"决定怎么观察"| KG
    KG -->|"基于事实推演"| WM
    WM -.->|"反馈修正"| Ontology

    classDef o fill:#fde2e2,stroke:#c0392b,stroke-width:3px,color:#000
    classDef e fill:#fef9e7,stroke:#f39c12,stroke-width:2px,color:#000
    classDef k fill:#e8f4fd,stroke:#2980b9,stroke-width:2px,color:#000
    classDef w fill:#eafaf1,stroke:#27ae60,stroke-width:2px,color:#000

层次	解决的问题	典型产出
本体论	业务语言怎么定义	概念、属性、关系、约束
知识图谱	事实关系怎么连接	实体、关系、证据、查询
世界模型	状态变化怎么推演	预测、行动评估、反馈修正

本体论是起点——先定义"有什么"，才能谈"事实怎么连"（知识图谱）、"状态怎么变"（世界模型）。 UModel 落在本体论层——定义运维世界的概念、属性、关系；知识图谱（EntityStore 实例数据）和世界模型（运行态）基于它构建。

对我们的意义：HCS 六件套（ci-definitions）和 UModel 都是本体论落地，只是粒度不同——UModel 是 3 原语（Node/Link/Field），六件套是 6 件套（entity/relationship/metrics/event/behavior/fault_mode）。

2.3.5 Palantir vs UModel（本体论的两种商业落地）

来源：53AI - Palantir 本体 vs UModel

维度	Palantir Foundry Ontology	阿里云 UModel
定位	通用业务知识图谱	智能运维的语义运行时
给谁用	业务人员 + 数据工程师	运维 SRE + 数据团队 + AI Agent
典型场景	实体管理、关系查询、业务分析	智能运维、数据治理、Agent 推理
AI 原生程度	业务运营数字孪生层	AI 原生（直接服务 Agent 推理）
底层共识	都是本体论——用图描述世界	都是本体论

2.3.6 本体论在 UModel 里的四阶段迭代

来源：思否 - UModel 基于本体论思想构建

▼
mermaid
复制代码
flowchart LR
    S1["<b>① 数据标准化</b><br/>统一表示"]:::s
    S2["<b>② 实体与关联</b><br/>建立关系图"]:::s
    S3["<b>③ 知识表达</b><br/>领域经验附着"]:::s
    S4["<b>④ 行动能力</b><br/>受控执行闭环"]:::s

    S1 --> S2 --> S3 --> S4
    S4 -.->|"闭环反馈"| S1

    classDef s fill:#e8f4fd,stroke:#2980b9,stroke-width:2px,color:#000

阶段	做什么	对应 UModel 组件
① 数据标准化	把分散数据统一表示	6 类 Set
② 实体与关联	建立实体关系图	3 类 Link
③ 知识表达	把领域经验附着到对象上	Field + 三层语义的"知识层"
④ 行动能力	定义受控执行动作	三层语义的"行动层"（重启/回滚/扩容/降级）

2.4 三原语架构

▼
mermaid
复制代码
flowchart TD
    subgraph PRM ["核心原语：图模型基础"]
        direction TB
        P1["<b>Node（节点）</b><br/>Set 数据集 + Storage 存储类型"]:::p
        direction LR
        P1a["EntitySet<br/>实体集"]:::set
        P1b["LogSet<br/>日志集"]:::set
        P1c["MetricSet<br/>指标集"]:::set
        P1d["TraceSet<br/>链路集"]:::set
        P1e["EventSet<br/>事件集"]:::set
        P1f["ProfileSet<br/>性能数据集"]:::set
        P1g["TelemetryDataSet<br/>可观测数据基类（含 time 字段）"]:::set
    end

    subgraph LNK ["<b>Link（关联）</b>"]
        direction LR
        L1["EntitySetLink<br/>实体→实体"]:::link
        L2["DataLink<br/>实体→数据"]:::link
        L3["StorageLink<br/>模型→存储"]:::link
    end

    subgraph FLD ["<b>Field（字段）</b><br/>描述 Set 和 Link 的属性<br/>含 20 多种配置项"]
        F1["字段配置项<br/>名称/类型/约束规则/分析特性"]:::field
    end

    PRM --> LNK
    LNK --> PRM

    classDef p fill:#e8f4fd,stroke:#2980b9,stroke-width:3px,color:#000
    classDef set fill:#e8f4fd,stroke:#2980b9,color:#000
    classDef link fill:#fef9e7,stroke:#f39c12,color:#000
    classDef field fill:#eafaf1,stroke:#27ae60,color:#000

6 类 Set 类型：

Set 类型	用途	关键字段
EntitySet	实体集	主键、属性、状态
TelemetryDataSet	可观测数据基类	time 字段（其他 4 类继承它）
LogSet	通用日志数据	无较多约束
MetricSet	指标集合	多指标和标签维度
TraceSet	链路追踪	TraceID、SpanID
EventSet	事件数据	告警 + 系统事件
ProfileSet	性能剖析数据	CPU、内存

3 类 Link 类型：

Link 类型	用途	示例
EntitySetLink	实体之间的关联	服务→数据库的调用关系
DataLink	实体与数据的关联	服务→它的日志/指标
StorageLink	模型与存储的关联	解耦逻辑模型与物理存储

2.5 三大设计选择

对象优先：先定义对象边界，再映射数据。一个对象被定义一次，无论 Pod 重建、数据源切换还是新系统接入，它的身份和关系结构都是稳定的——这是 UModel 应对资源漂移的官方机制
规范可验证：定义的规范可被 Schema 验证
基于稳定规范连接已有系统：UModel 站在 CMDB / 可观测工具 / 知识图谱之上，把它们已有的事实组织成统一对象图

UModel 不是另一个可观测工具、CMDB 或知识图谱。它站在这些系统之上，把它们中已有的事实组织成统一对象图。

2.6 三层语义

层	描述
数据层	描述"有什么"和"如何连接"——实体、观测数据及关联
知识层	把黄金指标、健康度、告警规则、分析模板和领域经验附着到对象上
行动层	定义重启、回滚、扩容、降级和预案执行等可操作能力

本体不只是"建模"，还要能驱动受控行动——三层形成"数据→知识→行动"闭环。

2.7 官方实例一：DevOps 域 5 实体 + 4 关系

来源：阿里云官网 - DevOps 领域 UModel 设计案例

5 个实体（EntitySet）：

实体类型	用途	核心字段	业务价值
`devops.developer` 研发人员	人员信息管理	工号、姓名、团队、角色	责任归属、团队协作分析
`devops.code_repository` 代码仓库	代码库管理	仓库ID、名称、语言、框架	技术栈分析、代码质量跟踪
`devops.code_release` 代码发布	发布记录管理	发布ID、标签、提交SHA、发布时间	版本管理、发布质量跟踪
`devops.image_registry` 镜像仓库	镜像仓库管理	仓库ID、名称、类型、提供商	镜像集中管理、安全合规
`devops.image` 容器镜像	容器镜像信息	镜像名、标签、摘要、构建时间	镜像版本管理、部署追踪

4 种关系（EntitySetLink）：

▼
mermaid
复制代码
flowchart LR
    Dev["研发人员<br/>devops.developer"]:::e
    Repo["代码仓库<br/>devops.code_repository"]:::e
    Release["代码发布<br/>devops.code_release"]:::e
    Registry["镜像仓库<br/>devops.image_registry"]:::e
    Image["容器镜像<br/>devops.image"]:::e

    Dev -->|"manages（管理）"| Repo
    Dev -->|"manages（管理）"| Registry
    Release -->|"sourced_from（来源）"| Repo
    Image -->|"sourced_from（来源）"| Release
    Registry -->|"contains（包含）"| Image

    classDef e fill:#e8f4fd,stroke:#2980b9,stroke-width:2px,color:#000

跨域关联——DevOps 域 5 实体通过 EntitySetLink 与 APM 域、K8s 域打通：

▼
mermaid
复制代码
flowchart LR
    subgraph DEV ["DevOps 域"]
        Dev["研发人员"]:::d
        Repo["代码仓库"]:::d
        Release["代码发布"]:::d
        Image["容器镜像"]:::d
    end

    subgraph K8S ["K8s 域"]
        Pod["Pod"]:::k
        Deploy["Deployment"]:::k
    end

    subgraph APM ["APM 域"]
        Svc["APM 服务"]:::a
    end

    Dev -->|"manages"| Repo
    Repo -->|"sourced_from"| Release
    Release -->|"sourced_from"| Image
    Image -->|"uses"| Pod
    Image -->|"uses"| Deploy
    Svc -->|"traces_to"| Repo
    Svc -->|"owns"| Dev

    classDef d fill:#e8f4fd,stroke:#2980b9,color:#000
    classDef k fill:#fef9e7,stroke:#f39c12,color:#000
    classDef a fill:#eafaf1,stroke:#27ae60,color:#000

业务价值（官方原话）：服务溯源 / 责任归属 / 版本关联 / 镜像关联 / 部署追踪

2.8 官方实例二：EntityStore 实例数据

来源：阿里云官网 - EntityStore 介绍

▼
text
复制代码
UModel (知识图谱)
├── EntitySet: apm.service (类型定义)
│   ├── Entity: user-service (实例 1)
│   ├── Entity: payment-service (实例 2)
│   └── Entity: order-service (实例 3)
├── EntitySet: k8s.pod (类型定义)
│   ├── Entity: web-pod-123 (实例 1)
│   └── Entity: api-pod-456 (实例 2)
└── EntitySetLink: service_runs_on (关系类型)
    ├── Link: user-service → web-pod-123
    ├── Link: payment-service → api-pod-456
    └── Link: order-service → web-pod-123

业务场景：user-service 出性能问题 → UModel 沿 service_runs_on 找到 web-pod-123 → 再沿 DataLink 找到 Pod 的指标/日志/事件——这就是"从业务身份出发，找到运行资源，再定位对应的日志、指标、事件"的具体实现。

2.9 工程细节（Schema 级，开发必读）

2.9.1 EntitySet YAML 完整结构

来源：阿里云官网 - 关联关系建模

▼
yaml
复制代码
kind: entity_set
schema:
  url: "umodel.aliyun.com"
  version: "v0.1.0"
metadata:
  name: "apm.service"                # 实体集名（domain.type 格式）
  display_name:
    zh_cn: "应用"
  domain: apm                         # 所属域
spec:
  primary_key_fields: ["service_id"]  # 主键（支持复合主键）
  fields:                             # 字段定义
    - name: service_id
      type: string
      max_length: 128
      filterable: true                # 支持过滤查询
      analysable: true                # 支持聚合分析
  lifecycle:                          # 生命周期管理
    first_observed_time_field: created_at   # 首次观测时间
    last_observed_time_field: updated_at    # 最后观测时间
    ttl: 30d                           # 过期时间（默认 30 天）

2.9.2 主键设计 3 要求（官方建模原则）

来源：阿里云官网 - UModel 建模原则

设计要求	推荐做法	避免做法
唯一性	`service_name + cluster_name`	仅用 `port` 等非唯一字段
稳定性	`service_id`、`hostname`	`ip_address`、`process_id`（会漂移）
语义清晰	`service_name`、`pod_name`	`uuid`、`hash_value`

这就是"对象优先"的工程化——主键必须选稳定标识（业务身份），绝不能选会漂移的资源 ID。

2.9.3 生命周期 3 阶段

阶段	行为
活跃	可被查询
过期	最新时间不可查，存活期内可查
删除	超过 TTL（默认 30 天）后完全不可查

2.9.4 DataLink 的核心：fields_mapping

▼
yaml
复制代码
spec:
  src: {kind: entity_set, name: apm.service}
  dest: {kind: metric_set, name: apm.metric.apm.service}
  data_link_type: related_to
  fields_mapping:                # 关键：跨数据源的字段映射
    "service_id": "acs_arms_service_id"

fields_mapping 解决跨数据源语义统一——同一个服务，在实体里叫 service_id，在底层存储里叫 acs_arms_service_id，靠映射打通。

2.9.5 .umodel 查询（基于 SPL）

来源：阿里云官网 - UModel Query

▼
sql
复制代码
-- 查询所有 EntitySet 定义
.umodel | where kind = 'entity_set' | limit 0, 10

-- 查询特定域的所有定义
.umodel | where json_extract_scalar(metadata, '$.domain') = 'apm' | limit 0, 10

-- 图查询（实体关系路径）
.umodel | graph-match <path> project <output>

3 种查询方式：graph-match（图模式匹配）/ graph-call（图函数调用）/ Cypher（标准图查询语言）

第三章 STAROps——全域智能运维平台

3.1 一句话理解

STAROps 是"用 Agent 做运维"的应用平台——运维用自然语言定目标，数字员工自主完成动态规划、安全执行与结果验证的全闭环，人只做关键决策。

3.2 是什么（官方定义）

STAROps 是阿里云基于大模型和智能体技术打造的全域智能运维平台，深度融合跨域可观测数据与大语言模型推理能力，实现从被动响应到主动自治的运维模式转型。

来源：阿里云官网 STAROps 产品介绍

STAR 命名解析（四大设计理念）：

S — Sense（全域感知）：通过连接器接入日志/指标/链路/事件/变更/代码等跨域数据，基于 UModel 维护实体、关系和动态拓扑
T — Target（目标导向）：从告警响应转向目标达成
A — Autonomy（自主运维）：运维智能体自主完成动态规划、安全执行与结果验证的全闭环
R — Resilience（业务韧性）：实时守护业务系统韧性

3.3 三大核心模块

模块	能力	说明
智能助手	自然语言即时交互	一个对话窗口内完成告警分析、指标解读、日志诊断
长期任务（Mission）	跨天/月级异步任务	一次目标对齐即可自主执行跨天/月级运维计划，内置 HIL 机制
数字员工（SRE Agent）	企业专属 SRE 智能体	自定义配置职责/权限/工具/技能，沉淀可复用 Skill

3.4 架构图

▼
mermaid
复制代码
flowchart TD
    subgraph ENTRY ["用户入口"]
        direction LR
        E1["STAROps 控制台"]:::entry
        E2["云监控 CMS 2.0"]:::entry
        E3["日志服务 SLS"]:::entry
        E4["IM 集成<br/>钉钉 / 飞书"]:::entry
    end

    subgraph CORE ["STAROps 三大核心模块"]
        direction TB
        M1["<b>智能助手</b><br/>多轮对话 + @实体引用 + /工具唤起"]:::m
        M2["<b>长期任务 Mission</b><br/>跨天/月级异步任务<br/>定时 + 手动 + 事件触发<br/>内置 HIL"]:::m
        M3["<b>数字员工 SRE Agent</b><br/>企业专属智能体<br/>自定义职责/权限/工具/技能"]:::m
    end

    subgraph ENV ["数字员工工作环境（三件套）"]
        direction LR
        R["默认规则<br/>Markdown 编写"]:::env
        T["MCP / CLI / 连接器"]:::env
        S["Skill / Runbook"]:::env
    end

    subgraph BASE ["底座"]
        direction LR
        B1[("<b>UModel</b><br/>可观测数据建模")]:::base
        B2[("<b>统一可观测数据底座</b><br/>日志/指标/链路/事件/拓扑/变更")]:::base
        B3[("<b>AgentLoop</b><br/>观测+评估+优化")]:::base
    end

    subgraph SEC ["安全治理（横切）"]
        direction LR
        SEC1["RAM 权限控制"]:::sec
        SEC2["HIL 人工确认"]:::sec
        SEC3["端到端加密 + 行为审计"]:::sec
    end

    ENTRY --> CORE
    M3 --> ENV
    CORE --> BASE
    SEC -.-> CORE

    classDef entry fill:#e8f4fd,stroke:#2980b9,color:#000
    classDef m fill:#fef9e7,stroke:#f39c12,stroke-width:2px,color:#000
    classDef env fill:#fdebd0,stroke:#e67e22,color:#000
    classDef base fill:#f4ecf7,stroke:#8e44ad,stroke-width:2px,color:#000
    classDef sec fill:#fadbd8,stroke:#c0392b,color:#000

层	角色	关键组件
入口层	用户接入	控制台 / CMS 2.0 / SLS / IM
核心模块层	三大产品形态	智能助手 / 长期任务 / 数字员工
三件套层	数字员工配置	默认规则 + 工具接入 + 领域方法
底座层	数据 + 建模 + 评估	UModel + 统一可观测数据 + AgentLoop
横切安全治理	全链路贯穿	RAM 权限 + HIL + 审计加密

3.5 核心概念速览

概念	说明
数字员工	智能执行主体，分 2 种：系统内置员工（Ops Agent，预置受限）+ 自定义数字员工（绑定 RAM 角色，可配 Skill/MCP/连接器）
长期任务 Mission	跨天/月级异步运维计划，含多个事项
执行蓝图 Blueprint	长期任务的执行计划，AI 生成、经用户确认后启动
事项 Task	长期任务下的一次执行单元，定时/手动/事件触发
产物 Artifact	事项执行输出物（任务报告 + 过程快照）
问题发现 Finding	数字员工从现象归纳的稳定问题判断，同一问题只更新一条、不重复建立
处理项 Task	闭环问题发现的最小处理单元，低风险自动执行、高风险需人工确认
工作空间 Workspace	相互隔离的可观测数据和资源范围
HIL	高风险操作的人工确认机制
技能 Skill	数字员工的领域能力
默认规则	数字员工行为约束（Markdown）
MCP 服务	标准化工具调用接口
连接器	接入外部系统（系统连接器 + 自定义连接器）

3.6 长期任务内部机制（工程细节）

3.6.1 使用流程 4 步

▼
mermaid
复制代码
flowchart LR
    S1["<b>① 创建与规划</b><br/>意图对齐<br/>AI 生成执行蓝图<br/>用户确认后启动"]:::s
    S2["<b>② 任务管理</b><br/>状态/事项列表/进度"]:::s
    S3["<b>③ 执行与干预</b><br/>实时输出流<br/>关键节点 HIL"]:::s
    S4["<b>④ 产物管理</b><br/>报告 + 过程快照"]:::s

    S1 --> S2 --> S3 --> S4

    classDef s fill:#e8f4fd,stroke:#2980b9,stroke-width:2px,color:#000

3.6.2 意图对齐 6 要素（描述目标时）

要素	说明	示例
做什么	核心任务目标	定时巡检 K8s 集群
范围	作用对象和边界	集群 ID 为 c1234567890
频率	执行时间和周期	每天凌晨 2 点
输出	期望结果形式	生成巡检报告，10 点发送
约束	特殊条件和限制	周末节假日不发
重点	特别关注的方面	高危问题深入分析根因

3.6.3 执行蓝图的关键规则

AI 自动生成，必须经用户确认后启动
对话追加的更新需用户确认
更新仅对后续事项生效（不影响已执行的事项）

3.6.4 事项 3 种触发方式

触发方式	说明	示例
定时触发	按 Cron 规则自动触发	每天 02:00 执行集群巡检
事件触发	基于事件（告警/指标阈值）自动触发	CPU 超限告警后自动诊断
手动触发	Mission 详情页对话框输入指令	临时执行

3.6.5 输出流（执行过程实时可见）

信息类型	说明
思考过程	AI 推理分析过程
工具调用	MCP 调用的工具名/入参/返回
执行结果	每步骤的输出和状态

输出流是 AgentLoop 评估的输入——全程留痕才能事后回看评估。

3.6.6 问题发现与处理项闭环

▼
mermaid
复制代码
flowchart LR
    F["<b>问题发现 Finding</b><br/>带证据+影响+处理项+验证条件<br/>同一问题只更新一条"]:::f
    T["<b>处理项 Task</b><br/>低风险自动/高风险 HIL"]:::t
    V["<b>验证条件</b><br/>处置后是否恢复"]:::v
    C["<b>闭环</b><br/>问题关闭"]:::c

    F --> T --> V --> C
    V -.->|"未恢复"| F

    classDef f fill:#fde2e2,stroke:#c0392b,stroke-width:2px,color:#000
    classDef t fill:#fef9e7,stroke:#f39c12,stroke-width:2px,color:#000
    classDef v fill:#e8f4fd,stroke:#2980b9,color:#000
    classDef c fill:#eafaf1,stroke:#27ae60,stroke-width:2px,color:#000

3.7 数字员工：内置 vs 自定义

维度	系统内置员工（Ops Agent）	自定义数字员工
对应	`apsara-ops`	用户创建
RAM 角色	不绑定，继承使用者权限	绑定 RAM 角色
技能管理	不支持	支持
连接器 / MCP / CLI	不能配置	可配置
长期任务	可以创建	可以创建

创建数字员工的关键字段（官方 API）：

参数	说明
`ID`	唯一标识（小写字母/数字/-/_，1-64 字符，创建后不可改）
`displayName`	显示名称（如"K8s 集群运维专家"）
`ramRoleArn`	RAM 角色 ARN（决定运行时可访问范围）
`description`	描述（会影响 AI 行为倾向）
`defaultRule`	默认规则（Markdown）

第四章三件套——数字员工的工作配置

4.1 一句话理解

三件套 = 默认规则（约束做事方式）+ 工具接入（提供执行能力）+ 领域方法（决定怎么用工具）——把工具、规则和业务经验各自承担清楚的职责。

4.2 默认规则（Default Rule）

官方定义：以 Markdown 编写的数字员工行为约束，由 4 部分构成。

组成部分	作用	示例
角色定义	数字员工是什么岗位、负责什么	"你是一名资深的 Kubernetes 集群管理员。"
数据源聚焦	限定可访问的数据源范围	"首先查询 K8s APIServer 的 AuditLog。"
分析逻辑约束	排查走什么步骤、什么步骤必须走	"按审计日志 - 事件关联 - 资源指标的顺序排查。"
输出要求	结论格式、证据数量、必含字段	"报告中必须列出具体的变更操作人和变更时间。"

关键规则：

用 Markdown 语法编写（支持标题、列表、表格）
修改后仅对后续创建的会话生效（已有会话不更新）
与 Skill 的区别：默认规则约束做事方式，技能扩展具体能力

官方完整模板示例（K8s 集群巡检助手）

来源：阿里云官网 - 配置默认规则

▼
markdown
复制代码
# 角色定义
你是一名资深的 Kubernetes 集群管理员，负责保障集群的安全性与稳定性。

# 分析逻辑与优先级
在执行巡检或诊断任务时，请严格遵守以下步骤：

1. **审计日志 (Audit Log) 优先**：
   - 首先查询 K8s APIServer 的 AuditLog。
   - 重点过滤：关注 verb 为 `delete`, `patch`, `update` 的操作，
     特别是针对 `ConfigMap`, `Secret`, `Deployment` 的修改。
   - 忽略 verb 为 `get`, `list`, `watch` 的只读请求。

2. **事件关联 (K8s Events)**：
   - 检查 `k8s.event` 数据流。
   - 重点关注：Reason 为 `OOMKilled`, `Evicted`, `CrashLoopBackOff`,
     `FailedScheduling` 的异常事件。

3. **资源指标 (Metrics)**：
   - 关联 Pod/Node 的 CPU、Memory 指标。
   - 识别资源瓶颈导致的异常。

# 输出要求
- 报告中必须列出具体的变更操作人和变更时间。
- 异常事件必须附上原始日志片段作为证据。
- 给出明确的根因判断和处置建议。

4.3 工具接入（Tool）

工具类型	调用方式	适配场景
MCP 服务	标准 JSON-RPC 协议	标准化工具调用、动态发现
阿里云 CLI	自动接入云资源 API	查询、执行云操作
连接器	接入外部系统	已有 CMDB / ES / Prometheus

阿里云 CLI 三种执行策略（风险控制关键）：

策略	行为
拒绝	直接禁止调用（优先级最高）
每次询问	每次调用前向用户确认（写操作建议配置此项）
自动执行	判断需要调用时直接执行

连接器 2 类：

系统连接器：可观测 / 代码访问 / 流水线 / 资源——接入云监控、SLS、云效、GitHub、阿里云资源
自定义连接器：MCP 服务 / 环境代理——接入自建 MCP，或访问内网/多云

连接器关键规则：归属于单个数字员工；每个连接器一套访问身份；创建后角色和目标通常不可修改（需删除重建）。

4.4 领域方法（Skill / Runbook）

业务 Skill 按异常现象选排查手册（Runbook），说明先确认哪些对象、取得什么证据、怎样解释结果，信息不足时如何继续。

关键设计：默认规则保留公共约束，具体业务判断放在各自手册中，避免将所有组件知识堆进一段长提示词。

原文例子：

查不到日志 → 确认对象、时间窗、数据源
查到心跳失败 → 区分配置准备 / 网络发送 / 响应处理
看到资源重建 → 核对触发条件与后续状态

工具返回一次结果，排查方法决定这次结果意味着什么。

4.4.1 Skill 7 要素规范

来源：sls.aliyun.com - Skill 编写规范

适用类型：巡检类 / 诊断类 / 报告类 L0 只读 Skill（写操作 L2+ 需走风险分级与审批流程）

要素	说明
1. 元数据	Skill 名称/描述/版本
2. 触发条件	何时触发 Skill
3. 输入参数	Skill 接收的参数
4. 处理流程	Skill 内部执行步骤
5. 输出格式	Skill 产出格式
6. 错误处理	异常情况处理
7. 依赖工具	Skill 调用的 MCP/CLI

4.4.2 Skill 三级加载机制（Token 成本控制）

来源：知乎 - Skill 设计

层级	加载时机	内容要求	Token 成本
Level 1	常驻（每次对话都在）	`name` + `description`，≤100 字	~50-150 Token/个
Level 2	匹配触发时一次性加载	`SKILL.md` 正文，≤500 行	~2,000-5,000 Token
Level 3	执行中按需读取	脚本/参考文档/模板	按实际引用大小

核心原则：

Level 1 越精准越好（决定触发时机）
Level 2 越精简越好（减少 Token 消耗）
Level 3 放心放（按需加载不占常驻空间）

Token 成本警示：装 20 个 Skill，光 Level 1 就吃掉 1,000-3,000 Token；一次触发 2 个 Skill，Level 2 又加 4,000-10,000 Token。上下文越满，AI 注意力越分散，回答质量反而下降。

4.5 三件套协作关系图

▼
mermaid
复制代码
flowchart TD
    DW["数字员工本体"]:::dw
    DW --> R["默认规则<br/>Markdown 编写<br/>角色+数据源+分析逻辑+输出"]:::rule
    DW --> T["工具接入"]:::tool
    DW --> S["领域方法<br/>Skill / Runbook"]:::skill
    T --> MCP["MCP 服务"]:::tool
    T --> CLI["阿里云 CLI"]:::tool
    T --> CN["连接器"]:::tool
    R -.->|"约束工作范围"| DW
    T -.->|"提供查询能力"| DW
    S -.->|"指导怎么使用工具"| DW

    classDef dw fill:#fef9e7,stroke:#f39c12,stroke-width:3px,color:#000
    classDef rule fill:#fdebd0,stroke:#e67e22,color:#000
    classDef tool fill:#fadbd8,stroke:#c0392b,color:#000
    classDef skill fill:#eafaf1,stroke:#27ae60,color:#000

协作顺序：

数字员工加载默认规则（约束做事方式）
任务匹配时触发对应 Skill（扩展具体能力）
Skill 内部按需调用 MCP/CLI 工具（执行实际操作）
输出必须符合默认规则的输出要求

第五章端到端调用链路

5.1 完整链路图（用户→数字员工→报告）

▼
mermaid
复制代码
flowchart TD
    User(["用户"]):::u

    subgraph STAROPS ["STAROps 平台"]
        direction TB
        Chat["<b>智能助手</b><br/>对话入口"]:::c
        Mission["<b>长期任务 Mission</b>"]:::m
        DW["<b>数字员工</b>"]:::dw
        Blueprint["<b>执行蓝图</b><br/>AI 生成+用户确认"]:::b
        Task["<b>事项 Task</b><br/>定时/事件/手动触发"]:::tk
        Finding["<b>问题发现 Finding</b>"]:::f
        Handle["<b>处理项</b><br/>低风险自动/高风险 HIL"]:::h
        Artifact["<b>产物</b><br/>报告+快照"]:::a
    end

    subgraph ENV ["三件套（数字员工配置）"]
        direction LR
        R["默认规则"]:::r
        S["Skill"]:::s
        T["MCP/CLI/连接器"]:::tk2
    end

    subgraph UMODEL ["UModel 底座"]
        direction LR
        ES["EntitySet"]:::um
        EL["EntitySetLink"]:::um
        DL["DataLink"]:::um
    end

    User -->|"描述目标"| Chat
    User -->|"确认蓝图"| Blueprint
    Chat --> DW
    DW --> Blueprint
    Blueprint --> Task
    Task --> DW
    DW -.->|"约束+能力"| ENV
    DW -->|"查关联现场"| UMODEL
    DW -->|"执行工具"| T
    DW -->|"归纳问题"| Finding
    Finding --> Handle
    Handle -->|"验证"| Artifact
    Artifact -->|"报告"| User

    classDef u fill:#fde2e2,stroke:#c0392b,stroke-width:2px,color:#000
    classDef c fill:#fef9e7,stroke:#f39c12,stroke-width:2px,color:#000
    classDef m fill:#fef9e7,stroke:#f39c12,color:#000
    classDef dw fill:#fef9e7,stroke:#f39c12,stroke-width:3px,color:#000
    classDef b fill:#e8f4fd,stroke:#2980b9,color:#000
    classDef tk fill:#e8f4fd,stroke:#2980b9,color:#000
    classDef tk2 fill:#fadbd8,stroke:#c0392b,color:#000
    classDef f fill:#fadbd8,stroke:#c0392b,color:#000
    classDef h fill:#fdebd0,stroke:#e67e22,color:#000
    classDef a fill:#eafaf1,stroke:#27ae60,color:#000
    classDef r fill:#fdebd0,stroke:#e67e22,color:#000
    classDef s fill:#eafaf1,stroke:#27ae60,color:#000
    classDef um fill:#f4ecf7,stroke:#8e44ad,stroke-width:2px,color:#000

5.2 一次完整排查的时序

用户描述目标（含 6 要素）→ 智能助手接入
AI 生成执行蓝图 → 用户确认后启动
事项触发（定时/事件/手动）→ 数字员工执行
数字员工加载默认规则 → 匹配触发 Skill → 调用 MCP/CLI 工具
工具通过 UModel 关联现场（业务身份→运行资源→观测数据）
执行过程输出流全程留痕（思考/工具调用/结果）
归纳问题发现 → 生成处理项（低风险自动/高风险 HIL）
验证条件通过后闭环 → 产出报告
AgentLoop 回看 Trajectory → 评估诊断质量 → 修订 Skill/Runbook → 下次用新方法

第六章术语速查表（新员工必备）

6.1 UModel 术语

术语	英文	一句话解释
本体论	Ontology	定义"世界有什么"的学说——UModel 的理论根基
节点	Node	数据集（Set）+ 存储类型（Storage）
关联	Link	节点之间的关系
字段	Field	描述 Set 和 Link 的属性（20+ 配置项）
实体集	EntitySet	同类实体的集合定义（如 `apm.service`）
实体	Entity	EntitySet 的具体实例（如 `user-service`）
实体关联	EntitySetLink	实体→实体的关系（calls/contains/runs_on 等）
数据关联	DataLink	实体→观测数据的关联（含 fields_mapping）
存储关联	StorageLink	模型→物理存储的关联（解耦）
对象优先	Object-first	对象身份稳定，资源漂移仍可沿对象追
三层语义	—	数据层（有什么）/ 知识层（经验附着）/ 行动层（受控执行）

6.2 STAROps 术语

术语	英文	一句话解释
数字员工	Digital Employee / SRE Agent	智能执行主体，分内置员工和自定义员工
长期任务	Mission	跨天/月级异步运维计划
执行蓝图	Blueprint	长期任务的执行计划，AI 生成+用户确认
事项	Task	长期任务下的一次执行单元
产物	Artifact	事项输出物（报告+过程快照）
问题发现	Finding	从现象归纳的稳定问题判断（同一问题只更新一条）
处理项	Task	闭环问题发现的最小处理单元
工作空间	Workspace	相互隔离的数据和资源范围
人工干预	HIL	高风险操作的人工确认机制
输出流	—	AI 执行时的思考/工具调用/结果实时展示

6.3 三件套术语

术语	英文	一句话解释
默认规则	Default Rule	Markdown 编写的数字员工行为约束（4 部分）
技能	Skill	数字员工的可复用能力模块（SKILL.md）
排查手册	Runbook	按异常现象组织的排查步骤
MCP	Model Context Protocol	标准化工具调用协议
连接器	Connector	接入外部系统的配置模块
Skill 三级加载	Level 1/2/3	常驻元数据→触发加载正文→按需读取附件

6.4 产品术语

术语	一句话解释
AgentRun	智能体开发构建平台
AgentCore（原 AgentTeams）	智能体构建和治理平台（多 Agent Team 协作）
AgentLoop	智能体自进化平台（观测+评估+优化）
STAROps	全域智能运维平台
UModel	可观测数据建模方法（横切底座）
Trajectory	Agent 执行轨迹（AgentLoop 的采集对象）
Agent-as-a-Judge	AgentLoop 的评估方式——评估器本身是 Agent

10-运维Agent-MVP深入拆解