⁴

08-数字员工（MVP）

王保保

2026-11-09 17:50

阅读218

王保保

2026-11-09 17:50

阅读 218

需求分析

决策	依据
选中等 MVP	"这才是价值点"——4 模块完整对齐文章，但 MVP 阶段不做 Agent Team
③ 执行体用 CodeAgent	关键省力点——不维护 agentserver 那套 E2A 协议/Session/Plan Agent，直接用现成 CodeAgent
①②④ 全部自研	这才是数字员工核心价值，省不得
Agent Team 砍掉	单 Agent 已能跑通"自家排查自家"试点；多 Agent 协作引入复杂状态管理，MVP 不上
试点场景：自家排查自家	对标文章 "AgentCore for AgentCore"——用 MODoerRouterService 排查 MODoerRouterService 自己

不做的事（明确边界）

❌ 不做 Agent Team 多 Agent 协作（迭代后再上）
❌ 不做事件驱动告警自动响应（MVP 只做人工触发）
❌ 不做定时巡检（MVP 只做被动排查）
❌ 不做 LLM 自动评估修订 Runbook（MVP 评估产出建议，人工修订）
❌ 不做自进化（对齐文章"尚未实现自进化"的诚实声明）

模块

模块定义

① 业务关系图（UModel 等价物）

把业务身份 → 运行资源 → 观测数据三层关联起来，让数字员工拿到的不只是某一条日志，还包括"它属于谁、关联到哪里、对应哪一次运行"。

关联由实际运行状态驱动，不是静态配置。即使底层实例更换（资源漂移），排查仍能沿着同一个业务身份继续追。

② 三件套（规则 + 工具 + Skill）

把数字员工的工作配置分成三个部分：

默认规则：工作范围约束（只读权限、证据要求、输出方式、环境隔离）
工具接入：查询能力（MCP / CLI / API 五类工具）
领域方法：Skill / Runbook，按异常现象选排查手册，避免长提示词堆知识

③ 执行 Agent（数字员工本体）

真正的执行体——从 ① 拿到关联好的"现场"，从 ② 拿到规则、工具和排查手册，按手册一步步推进诊断。

MVP 实现载体：CodeAgent（关键省力点，不维护 agentserver）。

④ 评估体系（AgentLoop 等价物）

每次诊断后，自动评估"找对对象/取得证据/结论可支持/无遗漏"，发现问题产出修订建议，人工 review 后修订 Skill/手册。

MVP 实现方式：写成 Skill（不另起独立评估服务）。

模型关系

▼
text
复制代码
┌────────────────────────────────────────────────┐
│ 构建层（资产，建好备用）                          │
│  ① 业务关系图（UModel）                        │
│  ② 三件套（规则+工具+Skill）                    │
└────────────────────────────────────────────────┘
                       ↓ 实线（现场）+ 虚线（约束/工具/方法）
┌────────────────────────────────────────────────┐
│ 执行层（每次排查触发）                          │
│  ③ 执行 Agent（CodeAgent）                    │
└────────────────────────────────────────────────┘
                       ↓ 实线（产出诊断）
                       ↓ 实线（回看执行过程）
┌────────────────────────────────────────────────┐
│ 反馈层（每次排查后触发）                        │
│  ④ 评估体系（Skill 形式）                      │
└────────────────────────────────────────────────┘
                       ↓ 虚线（修订 Skill/手册 → ②）

流向	类型	含义
① → ③	实线数据流	数字员工从 UModel 拿关联好的"现场"
② → ③	虚线配置约束	数字员工从三件套拿规则/工具/方法
③ → ④	实线数据流	数字员工执行过程喂给评估
④ → ②	虚线反哺	评估发现问题，修订 Skill/手册
④ → ①	虚线反哺（间接）	评估发现"现场关联不全"时，间接驱动 ① 补建（非自动）

UModel

官方定义

1.1 一句话定义

UModel（Universal Observability Model）是一种基于图模型的可观测数据建模方法，采用 Node（节点）和 Link（边）组成的图结构描述 IT 世界，通过标准化的数据建模方式实现可观测数据的统一表示、存储解耦和智能分析。

来源：阿里云官网 UModel 概览

1.2 三个原语（图模型基础）

UModel 用图论的三个原语描述 IT 系统：

原语	角色	说明
Node（节点）	数据集 + 存储类型	核心是 Set（数据集），表示同类型实体或数据的集合；附带 Storage（存储类型），如 SLS、Prometheus、MySQL
Link（关联）	节点之间的关系	如 EntitySetLink（实体关联）、DataLink（数据关联）、StorageLink（存储关联）
Field（字段）	描述 Set 和 Link 的属性	含名称、类型、约束规则、分析特性等 20 多种配置项

来源：阿里云官网设计概念

1.3 6 类核心 Set 类型

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

1.4 3 类 Link 类型

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

1.5 三大设计选择（来源：InfoQ 阿里官方技术博客）

来源：UModel 设计选择

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

Pod不是会发生迁移吗？在迁移的时候，它的Pod的名称都改变了。UModel怎么能做到它的身份和关系都是稳定的呢？

UModel 的关系是语义边：订单服务 → 部署在 → Deployment（或 Service）→ 当前有 → N 个 Pod。
Pod 换名字，新实例通过 “属于同一个 Deployment” 这条边重新挂上去。边本身不用改，因为它挂的锚点在上层。这正是它对外宣称 “应对资源漂移” 的真实机制：锚点选在上层，漂移只发生在下层。

也就是pod的主键没用运行时 ID。

用业务标识：应用编码 + 环境 + 命名空间。
Pod、容器、IP、副本数，全部放实例层当属性，随时可覆盖。
关系锚点挂到 Deployment 或 Service 这一层，别挂到 Pod。

1.6 三层运维语义（来源：腾讯云转载的阿里官方文章）

来源：腾讯云计算 - UModel 三层运维语义

UModel 把运维语义组织为三个层次：

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

1.7 关键澄清——UModel 不是什么

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

来源：InfoQ 阿里官方技术博客

数字员工案例

2.1 原文怎么用 UModel

原文 1.5 节"先让系统看懂自己的运行现场"原话：

我们在 UModel 中建立 AgentCore 的运行模型，将工作空间（Workspace）、Agent、会话（Session）与资源池、容量规格和 Sandbox 关联起来。从业务身份出发，就能找到运行资源，再定位对应的日志、指标和事件。

这层关联由实际运行状态驱动。即使底层实例更换，排查仍能沿着同一个 Agent 继续，而不必重新猜测资源名称。

2.2 对照官方定义看原文用法

原文用法	对应官方概念
工作空间 / Agent / 会话 / Sandbox	EntitySet（实体集合）
资源池 / 容量规格	EntitySet（实体集合）
日志 / 指标 / 事件	LogSet / MetricSet / EventSet
"将 Agent、会话与 Sandbox 关联起来"	EntitySetLink（实体关联）
"再定位对应的日志、指标和事件"	DataLink（实体到数据的关联）
"由实际运行状态驱动"	UModel 的"对象优先"——对象身份稳定，关联动态更新
"底层实例更换仍能沿 Agent 追"	UModel 的"对象优先"应对 Pod 重建

2.3 原文 UModel 实际作用

原文 1.5 节收束：

UModel 承担的价值，就在于把分散的运行记录组织成可追踪的业务现场。数字员工拿到的不再只是某一条日志，还包括"它属于谁、关联到哪里、对应哪一次运行"。

STAROps 把 UModel 怎么用（来源：官方+原文）

来源：阿里云开发者社区 - STAROps Agent 实践 + 原文 1.6 节

3.1 STAROps 官方概念

STAROps Agent：执行数据查询、证据聚合、故障判断和报告生成的智能分析单元
SLS：阿里云日志服务，保存每次拨测产生的原始执行记录，是"日志仓库"
UModel：描述任务、应用等可观测对象及其关系的统一模型，是"对象是谁、数据在哪里、彼此如何关联"的地图
APM：应用性能监控，Trace 一次完整请求，Span 是每个处理步骤
Workspace：一组相互隔离的可观测数据和资源范围。Agent 必须先确定 Workspace

3.2 STAROps 数字员工三件套（原文 1.6 节）

我们把数字员工的工作配置分成三个部分：默认规则、工具接入、领域方法。

默认规则规定工作范围（绑定地域/环境，明确只读权限、证据要求、输出方式）

工具接入提供查询能力（STAROps CLI 读 UModel 关系/SLS 日志/Prom 指标；Aliyun CLI 补充云资源；Runtime Ops 只读 MCP 补充管理信息）

领域方法决定怎么使用工具（Skill 按异常现象选 Runbook）

3.3 STAROps 默认规则的官方说明

来源：阿里云帮助中心 - 数字员工默认规则配置

默认规则（Rule Context）是指导数字员工工作行为的核心配置，使用 Markdown 语法编写。推荐结构：

角色定义 + 数据源聚焦 + 分析逻辑约束 + 输出要求

MVP实现

本节是自研实现，不是 UModel 官方代码。基于官方定义的三个原语（Node/Link/Field）+ 6 类 Set + 3 类 Link，结合原文 AgentCore 案例设计。MVP 阶段只实现最小子集。

MVP 实现范围（基于官方定义裁剪）

官方原语	MVP 实现	MVP 不实现
Node	✅ 实现 EntitySet（业务身份实体） + LogSet/MetricSet/EventSet（观测数据）	❌ TraceSet / ProfileSet / TelemetryDataSet 继承关系
Link	✅ 实现 EntitySetLink（实体→实体）+ DataLink（实体→数据）	❌ StorageLink（MVP 单地域，不抽象存储）
Field	✅ 实现最小字段集（id/type/required）	❌ 20 多种配置项
Storage	⚠️ 简化为 source 字段（file/elasticsearch/prometheus/redis）	❌ 完整 StorageLink 抽象
Set 类型	✅ EntitySet/LogSet/MetricSet/EventSet 四类	❌ TraceSet/ProfileSet
Schema 验证	⚠️ MVP 不做 JSON Schema 校验	❌ ajv 校验（迭代后上）

问答助学