作者：徐浩博
以 UModel 关联现场，在 STAROps 中构建运维数字员工，用 AgentLoop 持续检验诊断质量。
UModel（Universal Observability Model） 是阿里云可观测体系中的统一数据建模方法，通过实体及其关系，将业务对象、运行资源与日志、指标、事件关联起来。在本文实践中，它将 Agent、会话与底层 Sandbox 串联起来，为排查提供可追踪的运行现场。
STAROps 是阿里云基于大模型和智能体技术构建的全域智能运维平台，支持结合观测数据、工具与业务技能，构建企业专属的运维数字员工。在本文实践中，它承载 AgentCore 的诊断能力，让团队通过自然语言发起排查，由数字员工按领域方法查询证据、分析问题。
AgentLoop 是阿里云面向智能体的观测、评估与持续优化平台，支持记录模型调用、工具执行和最终输出，并评估执行过程与结果质量。在本文实践中，它用于复核诊断是否找到关键证据、结论是否可靠，为修订排查手册和规则提供依据。
AgentCore 是阿里云的智能体构建和治理平台，提供 Agent 的构建运行、工具接入、身份权限与多智能体协作能力。在本文实践中，它既是被运维的系统，也通过 Team 组织诊断 Agent 与代码 Agent 分工协作，将现场排查与源码分析衔接起来。
在 AgentCore 的团队（Team）房间里，多个 Agent 可以分工完成一项任务。一次，开发同学在房间里 @ 了其中一个 Agent，却迟迟没有等到回复。问题可能出在消息投递，也可能出在运行环境、模型调用或结果交付。一个简单的"没有回复"，背后往往跨着几条不同的链路。
要查清原因，通常需要几位熟悉系统的同学一起参与：先找到对应的环境和资源，再查询各组件的日志、对齐时间与状态，最后判断下一步。真正费时的，既有查询本身，也有查询之间的衔接------谁知道该查哪里，谁能解释这条记录，又该把问题交给谁继续处理。
我们希望把这些经验变成团队随时可以使用的能力。测试同学发现异常后，就能先查清问题大致发生在哪一层；开发同学接手时，可以沿着已有证据分析代码；需要调整运行环境时，再通过统一入口完成操作与验证。
围绕这个目标，我们在 STAROps 上搭建了 AgentCore 运维数字员工。它通过 UModel 识别业务对象和运行资源，结合日志、指标与管理状态，按照领域方法推进诊断。默认规则、MCP 与 CLI 工具、业务 Skill 共同构成它的工作环境，AgentLoop 则用于回看执行过程、评估诊断质量，让方法在使用中得到修订。
这套诊断能力也接入了本地开发环境和 AgentCore 运维 Team，需要时可以继续关联本地或无影上的代码仓库。运维操作统一由泰山内的 AgentCore 入口承接，后台保留状态、权限和执行管理，日常排查则进入大家已经在使用的开发工具与钉钉会话。
AI Native 运维在这里改变的是工作的组织方式：由数字员工关联现场、推进诊断，人根据证据深入分析、决定处置，再用结果检验判断。
图 1：围绕同一个问题组织诊断、源码分析、处置与验证。UModel 提供运行关联，数字员工承担诊断，AgentLoop 支撑质量复核。
先让系统看懂自己的运行现场
排查首先要从开发同学提供的 Agent 或会话标识，找到对应的运行资源。一个 Agent 在版本更新或实例重建后，可能已经运行在另一个 Sandbox 中。要查到与问题相关的日志和指标，就需要明确它在问题发生时对应哪些运行资源。
我们先补齐排查所需的观测数据：ACK 集群的容器日志、生命周期事件和审计记录进入日志体系，资源使用、Sandbox 状态和预热容量纳入指标体系。沿着业务链路，配置发布、资源协调、网关访问、Runtime 执行和协作交付的记录，也一并纳入排查范围。
数据接进来之后，还要让不同组件的记录对应到同一个业务对象。为此，我们在 UModel 中建立 AgentCore 的运行模型，将工作空间（Workspace）、Agent、会话（Session）与资源池、容量规格和 Sandbox 关联起来。从业务身份出发，就能找到运行资源，再定位对应的日志、指标和事件。
这层关联由实际运行状态驱动。Runtime Manager 提供业务状态，配套的只读采集 SQL 和加工规则将其转化为实体与关系，保留地域、版本、运行代次和观察时间。即使底层实例更换，排查仍能沿着同一个 Agent 继续，而不必重新猜测资源名称。
我们还为各类数据明确了查询入口、关联标识与结果含义，并将地域坐标从业务定义中分离出来。同一套模型和排查方法可以部署到不同地域，各自连接当地的数据源。新增地域主要是绑定和核验环境；新增场景则补充业务方法，两类变化可以分别维护。
UModel 承担的价值，就在于把分散的运行记录组织成可追踪的业务现场。数字员工拿到的不再只是某一条日志，还包括"它属于谁、关联到哪里、对应哪一次运行"。
把排查经验装进运维数字员工
有了现场，接下来才是怎样判断。同样是 Agent 不可用，创建失败需要检查配置与资源准备，启动缓慢需要检查容量、分配和初始化，请求连接异常则需要沿路由、网关与网络继续取证。
我们把数字员工的工作配置分成三个部分，让工具、规则和业务经验各自承担清楚的职责。
默认规则规定工作范围。 每个数字员工绑定一个地域和环境，明确只读权限、证据要求和输出方式。跨地域入口负责选择正确的对象；进入诊断后，不能混用其他环境的数据。这样，同一套方法可以复用，现场却始终保持明确。
工具接入提供查询能力。 观测查询通过 STAROps CLI 完成，分别读取 UModel 关系、SLS 日志与事件、Prometheus 指标；集群、网络和存储等云资源信息，则按场景使用 Aliyun CLI 补充。对于 UModel 尚未覆盖的管理信息，我们通过 Runtime Ops 的只读 MCP 补充查询，将运行模型中的对象关系与管理侧的操作记录结合起来。
领域方法决定怎么使用工具。 业务 Skill 按异常现象选择排查手册（Runbook），说明先确认哪些对象、取得什么证据、怎样解释结果，以及信息不足时如何继续。默认规则保留公共约束，具体业务判断放在各自的手册中，避免将所有组件知识堆进一段长提示词。
例如，查不到日志时，需要先确认对象、时间窗口和数据源；查到心跳失败时，需要继续区分配置准备、网络发送和响应处理；看到资源重建时，则要核对触发条件与后续状态。工具返回一次结果，排查方法决定这次结果意味着什么。
这些内容共同组成了一个可维护的运维数字员工：连接配置让它取得数据，规则约束工作范围，领域方法指导判断，地域配置确定现场。更新业务经验时，我们同步发布手册与配套规则，并读回核对实际生效的内容，让各地域使用一致的方法。
图 2：运维数字员工的能力组成。Skill 是领域方法的交付形式，MCP 与 CLI 是工具接入方式，业务模型和观测数据共同提供判断依据。
这个 Agent 为什么一直触发 Sandbox 重建
一次生产排查中，开发同学发现，某个 Agent 对应的 Sandbox 在反复重建，Agent 却迟迟不能正常工作。排查需要回答的是：为什么运行资源一直在更换，问题却没有随之消失？
数字员工根据症状加载 Runtime Manager 排查手册，通过 UModel 找到这个 Agent 关联的 Sandbox、集群和底层资源，再查询指标、事件与日志。查询发现，底层资源曾显示 Running、Ready，业务侧却仍未就绪。随着排查继续，同一个逻辑 Sandbox 的运行代次持续增加，关联实例也在更换。
UModel 保留的对象关系在这里发挥了作用：即使底层实例换了，数字员工仍能沿着同一个 Agent 找到对应的运行记录，继续追查每次启动发生了什么。
进一步查看 Runtime 日志，排查找到了一个具体阻塞点。Sandbox 中的 Runtime 需要通过心跳向 Runtime Manager 上报运行状态，而本次查到的 Runtime 在准备上报内容时，就因启动配置缺失而失败。同一实例还记录了配置文件不存在、Runtime 等待配置等信息。这些记录将问题范围缩小到了 Runtime 的启动配置与心跳准备阶段。
有了这些证据，后续分析就有了明确方向：开发同学可以沿配置的生成、投递和读取链路检查实现，再结合 Runtime Manager 的管理记录，核实上报异常与各次重建之间的关系。
这次排查体现了几层能力的配合：观测保留运行过程，业务模型串起不断变化的资源，领域方法将异常现象转化为具体的检查步骤。测试同学也能先取得问题范围和关键证据，开发同学接手后，就可以从已经定位的环节继续分析。
图 3：生产排查中的证据关联过程。从 Sandbox 反复重建的现象出发，定位 Runtime 的具体阻塞点，再继续核实配置来源与重建触发条件。
从运行证据继续追到代码
运行诊断确定了问题出现的位置，源码分析进一步解释它为什么发生。为了让这两步在日常开发中自然衔接，我们提供了本地诊断 Skill：通过 acops 选择环境、调用对应数字员工，并延续已有会话；需要深入实现时，再引导开发工具中的 Agent 查找本地仓库，将日志中的错误和执行阶段对应到具体文件与代码位置。
已有可用证据时可以直接复用，需要补充现场信息时，再回到同一诊断会话中追问。以前面的案例为例，配置读取失败已经有日志依据，接下来就可以查看配置由哪个组件生成、如何投递、Runtime 在什么条件下读取，以及异常怎样影响心跳上报。
这条路径也被组织成了一个 AgentCore 运维 Team。协调 Agent 负责分派与汇总，诊断 Agent 调用云上的运维数字员工，运行在无影上的代码 Agent 则在预先准备的仓库中分析实现。各成员通过任务与结果交换信息，由协调 Agent 审核并回复。
这就是 AgentCore for AgentCore：用 AgentCore 组织协作，排查 AgentCore 自身的问题。 无影承载代码分析环境，平台负责成员协作与任务管理，运行证据和代码分析在同一项任务中汇合。
使用者可以在已接入的钉钉会话中描述问题，按需提出"结合源码看看原因"，并在收到结果后继续追问。本地开发环境使用本地仓库，运维 Team 使用无影中的仓库，两种方式都能从已有现场继续深入。
已有的定时任务机制也可以按范围调用诊断能力，通过钉钉发送检查结果。被动排查与定期巡检由此复用同一套业务方法；发现问题后，还可以继续沿着记录中的对象和证据追查。
用 AgentLoop 持续检验诊断质量
当排查方法开始被团队反复使用，下一步要回答的是：哪些判断可靠，哪些地方仍会误导后续工作。AgentLoop 为这项改进提供过程记录与评估依据。
我们把实际排查中的问题、工具调用、返回证据和最终回答整理到 AgentLoop 中进行评估。复核时，沿着一次诊断的过程逐步检查：是否找对了对象，是否取得了关键证据，结论能否由证据支持，以及还有哪些必要的检查被遗漏。
历史复评曾发现，诊断在查到早先的启动失败日志后，没有继续确认后续状态，就判断当前仍然异常。维护者据此修订了排查手册，要求结合后续启动与健康状态核查，避免把已经恢复的问题当作当前故障。
这样的复核将改进落实到具体位置：数据关系不完整，就补模型与采集；查询能力不足，就补工具；判断遗漏，就修订规则或手册。当前仍由评估与人工修订共同推进，确认有效的经验再用于后续诊断，尚未实现自动更新规则的自进化。
回到开头那个没有回复的 Agent，发现问题的同学可以先取得诊断结果，开发同学沿证据继续查代码，必要的操作在泰山完成，处理结果再用于复核和改进排查方法。
UModel 让现场能够被关联，运维数字员工让经验能够被调用，AgentCore Team 让分析能够协作，AgentLoop 让质量能够被检验。这些建设共同服务于一件事：让团队对系统的理解，成为每个人处理问题时都能接上的能力。
相关链接：
1 UModel
help.aliyun.com/zh/cms/clou...
2 STAROps
help.aliyun.com/zh/starops/...
3 AgentLoop
help.aliyun.com/zh/cms/clou...
4 AgentCore