---
source_url: "https://mp.weixin.qq.com/s/_cVR4O3Gg3XcxYmkO28K8Q"
ingested: 2026-06-23
sha256: c805bcc7333d756a
---

# 给 Agent 套上缰绳：基于 Harness Engineering 的 7×24 自动化运维实践

阿里妹导读

这篇文章记录了我们如何在 Devix 上构建一套 7x24 自动化运维系统——通过 Harness Engineering 为 AI Agent 建立可控的工程框架，使其能诊断故障、分级决策、自动处置，并从历史经验中持续进化。

（文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。）

## 一、凌晨两点的报警，你还在手动排查吗？

凌晨两点，手机响了。钉钉运维群里弹出一条「DataWorks 自定义报警」。没有错误原因，没有日志摘要，只有一行实例名称和ID，状态：Failed。

你知道该走什么流程：打开 DataWorks 运维中心 → 搜索这个实例 ID → 点进去看运行日志 → 日志里看到一些报错关键词但不够精确 → 再去 Logview 里翻 ODPS 引擎层的详细错误 → 终于定位到是 ODPS-0730012: CupidError... kube master stop → 判断是 Cupid Kubernetes 控制面瞬时抽风 → 确认这个节点是工作流内层的子节点，需要找到外层周期实例来重跑 → 执行重跑 → 在群里回一句"已处理"。

这不是最痛苦的。最痛苦的是——同一个错误这周出现过三次，每次都是你爬起来重跑的。

这就是我们阿里控股集团——消费者认知团队的日常，我们主要负责集团流量识别和消费者理解等核心基建能力的建设与运维。背后是几十个项目空间、数千个调度节点，任何一个环节出问题都可能影响下游数据产出。而我们的运维模式长期依赖人工值班，核心痛点可以总结为三个词：

| 痛点 | 具体表现 |
|------|----------|
| 慢 | 从告警到人工响应平均 15-30 分钟，凌晨更久；日志需要层层获取，排查链路长 |
| 重复 | 同类故障反复出现，每次都要重新走一遍完整的排查流程 |
| 断层 | 老手的排查经验停留在脑子里，新人上手门槛高 |

AI 把日志当文本读，人在把日志当业务读。这中间差的不是工具，是领域知识和工程化驾驭能力。

所以我们决定自己造一个。

## 二、给 Agent 套上缰绳：Harness Engineering 的设计哲学

造之前，我们先想清楚了一个问题：Agent 到底能不能干运维？

答案是：能，但不能放手让它干。

Agent 有两个致命问题：一是不稳定——同一个错误给它看两次，它可能给出不同的诊断；二是没记性——每次对话都是新的一天，上周处理过的同类故障它完全不记得。

这两个问题在聊天场景下无伤大雅，但在运维场景下是致命的。你不能接受 Agent 在凌晨"创造性地"做了一个错误决策，把核心节点的代码改了。

所以我们引入了 Harness Engineering 的理念——用工程化的手段来驾驭 Agent，让它在一个可控的框架内发挥作用。核心设计原则是三句话：

1. **Agent 负责语义理解与决策推理，脚本负责数据召回与动作执行**：发挥 Agent 的语义优势做诊断和决策，但所有数据获取和动作执行由确定性脚本完成
2. **用置信度换自动化程度**：高置信度全自动，中等置信度人工确认，低置信度升级处理
3. **让系统从自己的经验中学习**：每次诊断结果沉淀为案例，案例反馈到决策过程，规则库持续进化

最终的系统架构可以浓缩为一句话：

告警触发 → Agent 智能诊断 → 分级决策引擎 → 自动处置 / 人工确认 → 结果追踪 → 案例沉淀 → 规则进化

## 三、系统架构：基于 Devix 的运维闭环

### 3.1 为什么选择 Devix

自动化运维有两个硬性要求：一是 7x24 小时不间断运行，不能依赖任何人的本机；二是需要承载钉钉交互回调等公网中转服务。

Devix[1]是阿里控股集团——Aone团队推出的一站式 AI Native 研发平台，其提供云端常驻 Sandbox 环境和 Agent 能力，天然支持全天候无人值守运行和公网服务部署。

### 3.2 整体架构

系统由三个协同工作的组件构成，通过钉钉群进行信息协同和人机交互：

| 组件 | 部署方式 | 核心职责 |
|------|----------|----------|
| 监控脚本 | Devix 独立脚本轮询 | 轮询各项目空间的失败实例，推送告警并触发中转服务 |
| 中转服务 | Python Flask 常驻 Sandbox | 接收告警、触发诊断、承载重跑回调、轮询实例状态 |
| 诊断 Skill | Devix Agent 能力模块 | 解析日志、匹配错误模式、生成结构化诊断报告 |

端到端数据流：监控脚本发现故障 → 推送钉钉告警 + 转发至中转服务 → 触发 Agent 诊断 → 决策引擎分级处置 → 钉钉交互通知 → 后台轮询追踪结果 → 失败则重新触发，形成闭环。

## 四、Agent 诊断：从告警到根因的完整推理链

### 4.1 诊断引擎做了什么

Agent 诊断是整个系统的"第一层"。我们让 Agent 像真正的运维工程师一样执行一套完整的诊断流程：

1. **实例信息采集**：通过 DataWorks OpenAPI 查询失败实例的完整信息
2. **日志智能解析**：自动识别 SQL / Cupid / Mixed 三种日志类型，结构化提取错误信息
3. **深层错误获取**：通过 ODPS REST API 深入获取计算引擎层 Task 级别的精确错误
4. **关联分析**：检查代码变更、运维操作记录、上游依赖状态
5. **调度链路追溯**：自动定位正确的重跑目标（外层周期实例 > 根工作流实例 > 当前实例）
6. **知识库检索**：结合垂域领域知识库，理解节点间的依赖关系和业务语义

### 4.2 诊断报告：给人看的 + 给机器用的

| 输出 | 格式 | 受众 | 用途 |
|------|------|------|------|
| 诊断报告 | Markdown | 人 | 完整故障分析+日志证据+修复建议 |
| 诊断结论 | JSON | 决策引擎 | 结构化字段：错误模式+环境上下文+置信度+修复提案 |

诊断结论 JSON 包含四部分：
1. **错误诊断**：error_pattern（最关键——从已知模式列表匹配，无匹配填 unknown）、error_category、confidence(0~1)、severity、root_cause_summary、evidence
2. **环境上下文**：是否有代码变更、上游是否失败、资源压力、是否首次出现、数据量是否正常
3. **修复建议**：Agent 初步建议，但最终决策综合历史案例和规则数据

### 4.3 知识库：让 Agent 理解业务

分层递进：总览文档 → 业务域文档 → 分层文档 → 节点明细。Agent 诊断时先通过总览判断问题在哪一层，再通过分层文档理解处理逻辑，最后通过节点明细定位具体问题。

## 五、分级决策引擎：用置信度换自动化程度

### 5.1 为什么不让 Agent 直接决策？

最初设计确实让 Agent 一条龙做完诊断和决策。但实际运行发现三个问题：

- **决策不可控**：Agent 对同一个错误模式可能给出不同决策
- **策略难量化**：Agent 无法表达"历史重跑成功率 80% 以上才自动重跑"
- **经验难沉淀**：Agent 每次决策都是独立的，无法从历史案例中学习

### 5.2 三层流水线架构

| 层级 | 执行方式 | 输入 | 输出 |
|------|----------|------|------|
| Layer 1: 语义诊断层 | Agent | 实例日志 + ODPS 错误 + 知识库 | 诊断报告(Markdown) + 诊断结论(JSON) |
| Layer 2: 决策规则层 | 脚本召回→Agent综合决策 | 诊断结论 + 历史案例证据 | 决策结果(动作+参数+置信度) |
| Layer 3: 动作执行层 | 脚本 | 决策结果 | 钉钉通知/自动重跑/代码修复 |

核心范式：**脚本召回 → 回流 Agent → Agent 决策 → 脚本执行**。Agent 被夹在两层确定性脚本中间。

### 5.3 五种决策动作

| 动作 | 含义 | 触发场景 |
|------|------|----------|
| 自动重跑(rerun) | 系统直接执行 | 瞬时基础设施故障+历史成功率高+无代码变更 |
| 按钮重跑(rerun_with_approval) | 钉钉通知等人确认 | 首次出现的可恢复错误或置信度不足 |
| 代码修复(fix_code) | 生成修复提案确认后执行 | Agent 诊断出代码问题且有可行方案 |
| 排查建议(investigate) | 标注排查方向 | 数据量异常、上游依赖失败等需人工判断 |
| 升级人工(escalate) | 通知相关人员 | 权限问题、未知错误等无法自动恢复 |

### 5.4 决策流程

诊断结论 → ① 规则匹配 → ② 案例库查询+置信度调整 → ③ 决策树评估 → 决策结果

**规则匹配（三级降级）**：

| 级别 | 匹配方式 | 说明 |
|------|----------|------|
| 第一级 | error_pattern 精确匹配 | 与规则文件完全一致 |
| 第二级 | error_category 类目匹配 | 按故障大类匹配通用规则 |
| 第三级 | 全局默认 | _default.yaml，最保守策略 |

**置信度调整**：案例库按 error_pattern 全局聚合，计算整体重跑成功率。历史成功率高→上调，低→下调，样本不足→不调整。

**关键设计**：同一种故障，首次出现时和积累经验后的决策结果不同。首次→保守"按钮重跑"；积累后→更自动化分支。**系统不是被"配置"出来的，而是被"训练"出来的。**

## 六、故障规则库与规则更新：让 Agent 实现自进化

### 6.1 规则分类

当前规模：15 条精确匹配规则 + 2 条兜底规则，按故障类型分五大类：

| 类型 | 规则数 | 特点 |
|------|--------|------|
| 基础设施类 | 5 | Cupid/Grape 故障，全部标记"安全可重跑" |
| UDF 类 | 4 | 用户自定义函数故障，默认不允许自动重跑 |
| SQL 类 | 2 | 语法错误、类型转换 |
| 数据类 | 2 | 数据倾斜、表/分区不存在 |
| 兜底规则 | 2 | 未覆盖故障走全局默认 |

### 6.2 规则自进化（三条并行路径）

每条路径都遵循"脚本扫描 → Agent 语义分析 → 人工审核"三段式：

- **路径 A：新规则发现** — 扫描最近 30 天 error_pattern=unknown 的案例，按错误码前缀聚类，Agent 语义分析后设计规则
- **路径 B：规则效果评估修订** — 重跑成功率 < 30% 时触发，Agent 分析失败原因，建议调整决策树
- **路径 C：自动重跑安全审计** — 自动重跑失败率 > 50% 时触发，Agent 建议降级权限（安全性最后防线）

## 七、安全防护

三道防线：

1. **全自动重跑约束** — 必须同时满足：置信度 > 0.9 + 历史成功率 > 80% + 无近期代码变更 + 规则标记"安全可重跑"
2. **代码修复三层防护** — 诊断层(Agent生成完整建议) → 决策层(fix_code分支命中) → 执行层(钉钉三按钮卡片人工确认)
3. **未知故障兜底** — 未被规则覆盖的一律升级人工

## 八、回顾与思考

> "Harness Engineering 的本质，不是让 Agent 更聪明，而是让 Agent 更可控。模型能力的提升是永无止境的，但围绕模型构建的工程化约束——规则库、决策树、案例库、安全防护——才是让 Agent 真正可用于生产环境的关键。"

## 参考链接

[1] Devix: https://devix.alibaba-inc.com/