07-数字员工（运维向）

为什么需要数字员工？

有好用的Agent工具，为什么还要数字员工呢？

在 AgentCore 的团队（Team）房间里，多个 Agent 分工完成一项任务。一次，开发同学在房间里 @ 了其中一个 Agent，却迟迟没有等到回复。

▼
mermaid
复制代码
flowchart LR
    Q[Agent 没回复]:::q
    Q --> P1[消息投递]:::p
    Q --> P2[运行环境]:::p
    Q --> P3[模型调用]:::p
    Q --> P4[结果交付]:::p
    classDef q fill:#fde2e2,stroke:#c0392b,stroke-width:2px,color:#000
    classDef p fill:#fff5e6,stroke:#e67e22,color:#000

人工排查

要查清原因，通常需要几位熟悉系统的同学一起参与：

• 先找到对应的环境和资源
• 再查询各组件的日志、对齐时间与状态
• 最后判断下一步。真正费时的，既有查询本身，也有查询之间的衔接——谁知道该查哪里，谁能解释这条记录，又该把问题交给谁继续处理。

Agent工具+Skill方式排查

要做到好用，就必须补齐大量的上下文信息。让系统能看懂自己要做什么？ 要补充，比如日志信息、指标信息、告警信息 还有部署信息：Agent 名字，对应哪个 Sandbox 可以上工具，让Agent自己去查吗？当然可以，但是会遇到其他情况：

1. 如果查日志——结果那个 Sandbox 已经被销毁了，新的 Sandbox 又起来了，日志又被换了
2. 工具按资源名查，资源漂移，工具就抓瞎（云原生环境下资源是动态漂移的）
3. 终于查到了，工具返回了一堆日志——但这一堆日志意味着什么？ Skill 里如果没写"心跳失败要继续区分配置准备/网络发送/响应处理"这种判断逻辑，工具就只会把日志原样返回，要不要继续查、查什么，还得人自己判断
4. 这次排查完，方法对不对没人记录——下次同样的问题，从头再走一遍

数字员工会如何排查**

排查步骤

▼
mermaid
复制代码
sequenceDiagram
    autonumber
    participant Sym as 现象: Sandbox 反复重建
    participant DW as 运维数字员工
    participant UM as UModel
    participant Obs as 指标/事件/日志
    participant RT as Runtime 日志

    Sym->>DW: 触发排查
    DW->>DW: ① 加载 Runtime Manager 排查手册
    DW->>UM: ② 找 Agent 关联的 Sandbox/集群/底层资源
    UM-->>DW: 返回关联对象
    DW->>Obs: ③ 查询指标/事件/日志
    Obs-->>DW: 底层 Running/Ready，业务侧未就绪；运行代次持续增加
    Note over DW: ④ 发现矛盾
    DW->>UM: ⑤ 沿同一 Agent 追查每次启动记录
    UM-->>DW: 返回各代次运行记录
    DW->>RT: ⑥ 查 Runtime 日志
    RT-->>DW: 心跳准备失败 + 配置文件不存在 + Runtime 等待配置
    Note over DW: ⑦ 锁定：启动配置与心跳准备阶段
    DW-->>Sym: 交付：定位到具体阻塞点

1. 加载手册：数字员工根据症状加载 Runtime Manager 排查手册
2. 关联现场：通过 UModel 找到这个 Agent 关联的 Sandbox、集群和底层资源
3. 查数据：查询指标、事件与日志
4. 发现矛盾：底层资源显示 Running、Ready，业务侧却仍未就绪；同一个逻辑 Sandbox 的运行代次持续增加，关联实例也在更换
5. 沿关系追查：靠 UModel 保留的对象关系，即使底层实例换了，仍能沿着同一个 Agent 找到运行记录，追查每次启动发生了什么
6. 定位阻塞点：查看 Runtime 日志，发现 Runtime 需要通过心跳向 Runtime Manager 上报运行状态，本次在准备上报内容时因启动配置缺失而失败；同实例还记录了配置文件不存在、Runtime 等待配置等
7. 缩小范围：问题锁定在 Runtime 的启动配置与心跳准备阶段

更重要的是数字员工独有的"质量回看"（AgentLoop）

质量评估AgentLoop

到这里，普通 Agent 工具就结束了——交付诊断报告："启动配置缺失导致心跳失败"。 但文章里数字员工还会做一件事：把这个排查过程喂给 AgentLoop 评估。 AgentLoop 沿着这次诊断过程逐步检查：

• ✅ 是否找对了对象？—— 找对了，从 Agent 业务身份出发
• ✅ 是否取得了关键证据？—— 取得了，Runtime 日志里有"配置文件不存在"明确证据
• ✅ 结论能否由证据支持？—— 能，"心跳准备失败"这条证据能直接支持"配置缺失导致心跳失败"的结论
• ⚠️ 还有哪些必要的检查被遗漏？

也就是，它还有评测！！！

其实就是Agent工具+skill+各种tool的超级增强版，而且引入评测后，组成了——数字员工！

目标

"AI Native 运维在这里改变的是工作的组织方式：由数字员工关联现场、推进诊断，人根据证据深入分析、决定处置，再用结果检验判断。"

▼
markdown
复制代码
开发同学发现异常（Agent 没回复），直接交给数字员工
        │
        ▼
数字员工端到端跑排查：按对应"排查手册"的步骤走
  → 用"业务关系图"找到关联的运行资源（即使容器一直在换，也能沿着业务身份追）
  → 查指标 / 事件 / 日志
  → 发现矛盾（资源说"我好了" 业务说"我没好"）
  → 沿关系继续追
  → 定位到具体阻塞点（启动配置缺失导致心跳报不出去）
        │
        ▼
数字员工交付：定位到具体环节 + 证据
        │
        ▼
质检环节（AgentLoop）评估这次诊断：
  ✓ 找对对象了吗 ✓ 关键证据拿到了吗 ✓ 结论有证据支持吗 ✗ 有没有该查却没查的
        │
        ├─ 评估不通过 ──→ 数字员工回炉补查 ──→ 重新评估
        │
        ▼ （评估通过）
交付给人处理：开发同学沿配置生成/投递/读取链路分析代码
        │
        ▼
处理结果 → 反馈记录
        │
        ▼
积累多次排查后，质检发现共性问题→ 修订Runbook"排查手册"
        │
        ▼
下次数字员工用修订后的"排查手册"排查

数字员工数据流图

▼
mermaid
复制代码
flowchart TD
    %% ===== 顶部：构建层（资产，建好备用） =====
    subgraph BUILD ["构建层（资产，建好备用）"]
        direction LR
        subgraph M1 ["① 业务关系模型（UModel）"]
            UModel[("业务身份 → 运行资源<br/>→ 日志/指标/事件<br/>关联关系")]:::m1
        end
        subgraph M2 ["② 三件套（规则+工具+Skill）"]
            direction TB
            Rule["📋 默认规则<br/>工作范围约束"]:::m2
            Tool["🔧 MCP + CLI 工具<br/>查询能力"]:::m2
            SkillC["📚 业务 Skill / 排查手册<br/>领域方法"]:::m2
        end
    end

    %% ===== 中间：执行层（每次排查触发） =====
    subgraph EXEC ["执行层（每次排查触发）"]
        DW{{"③ 数字员工本体<br/>（执行 Agent）<br/>按手册走、调工具、出结论"}}:::m3
    end

    %% ===== 底部：反馈层（每次排查后触发） =====
    subgraph FEEDBACK ["反馈层（每次排查后触发）"]
        direction TB
        AL[("④ AgentLoop<br/>执行过程记录")]:::m4
        Eval{{"评估诊断质量<br/>找对对象？取得证据？<br/>结论可支持？无遗漏？"}}:::m4
    end

    %% ===== 输出 =====
    Diag["📄 诊断结果<br/>（证据 + 结论 + 后续方向）"]:::out
    Human["👤 人处理<br/>沿已定位环节分析代码"]:::human

    %% ===== 数据流（实线，构建层 → 执行层） =====
    UModel ==>|"提供关联好的现场"| DW
    Diag2[("日志 / 指标 / 管理状态<br/>观测数据")]:::obs
    Diag2 ==>|"提供观测证据"| DW

    %% ===== 配置约束（虚线，构建层 → 执行层） =====
    Rule -.->|"约束工作范围"| DW
    Tool -.->|"提供查询能力"| DW
    SkillC -.->|"提供领域方法"| DW

    %% ===== 执行 → 输出（实线） =====
    DW ==>|"产出诊断结果"| Diag
    Diag ==>|"交付已验证的证据"| Human

    %% ===== 执行 → 反馈（实线） =====
    DW -->|"回看执行过程<br/>问题/工具调用/证据/回答"| AL
    AL -->|"输入执行记录"| Eval

    %% ===== 反馈 → 构建层（虚线，修订资产） =====
    Eval -.->|"修订手册/规则"| SkillC
    Eval -.->|"补建关系（间接）"| UModel

    %% ===== 样式 =====
    classDef m1 fill:#e8f4fd,stroke:#2980b9,stroke-width:2px,color:#000
    classDef m2 fill:#fdebd0,stroke:#e67e22,color:#000
    classDef m3 fill:#fef9e7,stroke:#f39c12,stroke-width:3px,color:#000
    classDef m4 fill:#f4ecf7,stroke:#8e44ad,stroke-width:2px,color:#000
    classDef out fill:#eafaf1,stroke:#27ae60,stroke-width:2px,color:#000
    classDef obs fill:#fadbd8,stroke:#c0392b,color:#000
    classDef human fill:#d6eaf8,stroke:#3498db,stroke-width:2px,color:#000

1. 业务关系模块（UModel）

把工作空间、Agent、会话与资源池、容量规格、Sandbox 关联起来，从业务身份出发找到对应的运行资源，再定位到日志、指标和事件。

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

数字员工拿到的不再只是某一条日志，还包括"它属于谁、关联到哪里、对应哪一次运行"。

2. 规则、工具与 Skill

把数字员工的工作配置分成三个部分，让工具、规则和业务经验各自承担清楚的职责。

默认规则：规定工作范围。每个数字员工绑定一个地域和环境，明确只读权限、证据要求和输出方式。跨地域入口负责选择正确的对象；进入诊断后，不能混用其他环境的数据。

工具接入：提供查询能力。观测查询通过 STAROps CLI 完成，分别读取 UModel 关系、SLS 日志与事件、Prometheus 指标；云资源信息按场景用 Aliyun CLI 补充；UModel 尚未覆盖的管理信息，通过 Runtime Ops 的只读 MCP 补充查询。

领域方法：决定怎么使用工具。业务 Skill 按异常现象选择排查手册（Runbook），说明先确认哪些对象、取得什么证据、怎样解释结果，以及信息不足时如何继续。默认规则保留公共约束，具体业务判断放在各自的手册中，避免将所有组件知识堆进一段长提示词。

例如，查不到日志时，需要先确认对象、时间窗口和数据源；查到心跳失败时，需要继续区分配置准备、网络发送和响应处理；看到资源重建时，则要核对触发条件与后续状态。工具返回一次结果，排查方法决定这次结果意味着什么。

3.数字员工本体（执行 Agent）

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

同样是 Agent 不可用，创建失败需要检查配置与资源准备，启动缓慢需要检查容量、分配和初始化，请求连接异常则需要沿路由、网关与网络继续取证。数字员工根据症状加载对应的排查手册，查询证据、发现矛盾、沿关系继续追查，定位到具体的阻塞点后，把"具体环节 + 证据"交付出去。

后续分析因此有了明确方向：开发同学可以从已经定位的环节继续分析代码，必要的操作在统一入口完成，处理结果再用于复核和改进排查方法。

4. 评估体系

当排查方法开始被团队反复使用，下一步要回答的是：哪些判断可靠，哪些地方仍会误导后续工作。

把实际排查中的问题、工具调用、返回证据和最终回答整理到 AgentLoop 中进行评估。复核时，沿着一次诊断的过程逐步检查：是否找对了对象，是否取得了关键证据，结论能否由证据支持，以及还有哪些必要的检查被遗漏。

这样的复核将改进落实到具体位置：数据关系不完整，就补模型与采集；查询能力不足，就补工具；判断遗漏，就修订规则或手册。确认有效的经验再用于后续诊断，让方法在使用中得到修订。

增强：Agent Team

增强版：从单数字员工到 Agent Team 以上 4 环节是 MVP 形态——单个数字员工按手册走、调工具、出结论。 当排查链路变长、跨多个系统、需要"诊断"和"代码分析"两种不同性质的工作时，单个数字员工干不完。这时把环节 ③ 从"单个执行 Agent"升级为"Agent Team"——多个 Agent 分工协作。

▼
mermaid
复制代码
flowchart TD
    Coord["协调 Agent<br/>（分派 + 汇总 + 审核）"]:::coord
    Coord -->|"分派任务"| Diag["诊断 Agent<br/>（云上运维数字员工）"]:::diag
    Coord -->|"分派任务"| Code["代码 Agent<br/>（无影代码分析）"]:::code
    Coord -->|"调度"| Sched["定时任务<br/>（钉钉推送巡检结果）"]:::sched
    Diag -->|"返回结果"| Coord
    Code -->|"返回结果"| Coord
    Sched -->|"巡检结果"| Coord
    classDef coord fill:#e8f4fd,stroke:#2980b9,stroke-width:2px,color:#000
    classDef diag fill:#eafaf1,stroke:#27ae60,color:#000
    classDef code fill:#fef9e7,stroke:#f39c12,color:#000
    classDef sched fill:#f4ecf7,stroke:#8e44ad,color:#000

Team 的组织方式：

• 协调 Agent：负责分派与汇总，审核各成员的结果后统一回复
• 诊断 Agent：调用云上的运维数字员工，按手册推进运行现场的诊断
• 代码 Agent（运行在无影上）：在预先准备的仓库中分析实现，把日志里的错误和执行阶段对应到具体文件与代码位置

各成员通过任务和结果交换信息，由协调 Agent 审核并回复。使用者可以在已接入的钉钉会话中描述问题，按需提出"结合源码看看原因"，并在收到结果后继续追问。

运行证据和代码分析在同一项任务中汇合——这就是"用平台组织协作，排查平台自身的问题"。被动排查与定期巡检由此复用同一套业务方法；已有可用证据时可以直接复用，需要补充现场信息时，再回到同一诊断会话中追问。

背景知识

UModel（Universal Observability Model） 是阿里云可观测体系中的统一数据建模方法，通过实体及其关系，将业务对象、运行资源与日志、指标、事件关联起来。在本文实践中，它将 Agent、会话与底层 Sandbox 串联起来，为排查提供可追踪的运行现场。

STAROps 是阿里云基于大模型和智能体技术构建的全域智能运维平台，支持结合观测数据、工具与业务技能，构建企业专属的运维数字员工。在本文实践中，它承载 AgentCore 的诊断能力，让团队通过自然语言发起排查，由数字员工按领域方法查询证据、分析问题。

AgentLoop 是阿里云面向智能体的观测、评估与持续优化平台，支持记录模型调用、工具执行和最终输出，并评估执行过程与结果质量。在本文实践中，它用于复核诊断是否找到关键证据、结论是否可靠，为修订排查手册和规则提供依据。

AgentCore 是阿里云的智能体构建和治理平台，提供 Agent 的构建运行、工具接入、身份权限与多智能体协作能力。在本文实践中，它既是被运维的系统，也通过 Team 组织诊断 Agent 与代码 Agent 分工协作，将现场排查与源码分析衔接起来。

MVP实现