研究AIOps已有1年多，目前手里有不少可落地的方案了，而且目前我们已经有了自研的AIOps平台，欢迎关注并与我链接。
昨天DeepSeek-v4-Pro正式版上线，随后官方又发布了一个开源项目deepseek-harness，项目地址就是: github.com/deepseek-ai/deepseek-harness。
按照官方的定义，DeepSeek Harness （下文简称DSH）是一个开源的 Agent Harness，核心理念只有一句话：Everything is a Plugin。
也就是说，模型、工具、Agent Loop、Session、沙箱、审批、持久化、Web UI，甚至很多运行时能力，本质上都可以通过插件进行组合和替换。
官方甚至明确写道，模型适配器、工具注册表、会话日志以及 Agent Loop 本身都是插件。
很多人第一眼看到这个项目，可能会把它理解成 DeepSeek 版本的 Claude Code、Codex 或者某种 Coding Agent。
但我看完它的架构以后，反而产生了另外一个想法：如果把 DSH 从“软件开发”场景里抽出来，它其实非常适合拿来做 AIOps Agent 的底层执行框架。
01 | 先搞清楚：Harness 到底是什么？
理解这个项目之前，首先要区分两个东西：
1）LLM 是大脑，Harness 是身体。
一个大模型即使推理能力再强，如果不能查询 Prometheus、不能读取 Kubernetes Event、不能搜索日志、不能查看发布记录，更不能经过权限控制之后执行回滚，那么它依然只是一个“懂运维知识的聊天机器人”。
2）真正的 AIOps Agent 需要的是：
模型 + 工具 + 上下文 + 状态 + 工作流 + 权限 + 审计 + 执行环境。
DSH 做的，恰恰就是模型之外这一层。
DSH 本质上是一棵插件树。Dsh-base 会提供模型适配器、Tools、Persistence、Sandbox、Approval Policy、Credentials、Telemetry 等基础能力；Web UI 和 Headless Runner 则是在此基础上继续叠加。
所以，我更愿意把 Harness 理解成一种：Agent Runtime / Agent OS。
02 | 为什么它特别适合 AIOps？DSH 的架构里面，有几个设计点和 AIOps 的需求几乎天然对应。比如，Everything is a Plugin：特别适合接企业现有运维系统。
企业的运维环境通常不会只有一套系统。可能同时存在：
Prometheus、VictoriaMetrics、Grafana、Loki、ElasticSearch、SkyWalking、Jaeger、Kubernetes、VMware、阿里云、AWS、CMDB、GitLab、Jenkins、Argo CD、数据库平台、工单系统……
传统做 AIOps Agent 最大的问题之一，就是很容易变成一个巨大的“胶水工程”。
但 Harness 的核心思想恰恰是：不要把所有能力写进 Agent 核心，而是把能力做成插件。
我们完全可以构造这样一套 AIOps 插件体系：
最终 Agent 面对的不是具体系统，而是一组标准化能力。这对 AIOps 很重要。
03 | 真正值得关注的，是 Harness 的 Tool PipelineDSH 的 Tool 调用并不是：LLM → Shell → 执行 这么简单。而是实现了一条完整的 Tool Execution Pipeline。
大致可以理解为：
而且 tools/pre-execute、tools/execute 和 tools/post-execute 都是扩展点，可以加入权限判断、超时、重试、Metric、结果过滤等逻辑。
这件事情对于 AIOps 来说，价值巨大。因为：运维 Agent 最难解决的问题，从来不是“能不能执行命令”，而是“什么时候允许它执行什么命令”。
生产环境绝不能简单地：LLM 认为应该回滚 → 直接回滚。而是，中间一定需要一个行为策略层。
例如：
DSH 已经提供了一个很好的“插入位置”，完全可以在 tools/pre-execute 上挂自己的 AIOps Policy Engine。
这可能是 DSH 用于 AIOps 时最有价值的能力之一。
04 | Subagent + Workflow，非常适合做“虚拟运维专家组”干运维的朋友都了解：复杂故障往往不是查一次日志就能解决的。例如：“订单系统 P99 延迟突然上涨。”这样的一个故障，至少可能涉及：应用、数据库、Redis、网络、Kubernetes、云负载均衡、最近发布。
如果让一个 Agent 从头查到底，很容易造成上下文爆炸。
而 DSH 已经提供了 Subagent、Workflow、Background Jobs 等能力。
其 Workflow 还能通过 Subagent Provider 执行子任务，官方还提供了 Ralph 这种多轮 fresh-agent 工作流。
那么 AIOps 完全可以采用：Supervisor Agent + Domain Agents 的模式。
比如主 Agent 收到事故之后，同时分派：
Metrics Agent ：分析指标异常时间点。 Log Agent ：分析错误日志。 Trace Agent ：定位慢调用链。 Change Agent ：检查最近发布与配置变更。 Infrastructure Agent ：检查 Pod、Node、网络和云资源。
最后主 Agent 汇总证据，例如：
Metrics Agent：异常开始于 10:32。Change Agent：10:29 payment-service 发布 v2.7.3。Trace Agent：慢请求集中在 MySQL span。Log Agent：10:32 开始大量出现 connection acquire timeout。Infrastructure Agent：节点 CPU、网络、磁盘正常。
最终假设就变成了：新版本数据库连接池配置异常，置信度 92%。这就比一句：“根据经验可能是数据库问题。” 可信得多。
05 | 如果把 DSH 做成AIOps框架，我会这样设计整个架构可以分成六层：
第一层：可观测数据层
这一层解决的是最基础的问题：现在系统到底发生了什么？
它相当于整个 AIOps Agent 的“眼睛”和“耳朵”。
Agent 自己并不知道 CPU 有没有升高，也不知道哪个接口突然变慢，更不知道某个 Pod 有没有 CrashLoopBackOff。
所有这些信息，都必须从现有可观测系统中获取。
典型的数据包括：
指标数据；
日志数据；
调用链数据；
Kubernetes Event；
云资源监控数据；
网络监控数据；
数据库性能数据；
中间件运行状态。
对应的典型系统包括：
指标系统
Prometheus、VictoriaMetrics、Zabbix、云监控等。
日志系统
Loki、Elasticsearch、OpenSearch、Splunk 等。
调用链系统
Jaeger、Tempo、SkyWalking、Zipkin 等。
第二层：运维上下文层
这一层要告诉 AI：这个东西到底是什么。这是很多所谓 AIOps 系统特别容易忽略的一层。
比如 Prometheus 告诉 Agent：payment-service error_rate = 17%。但光知道这一点远远不够。Agent 还需要知道：
payment-service 是什么系统？是不是核心业务？属于哪个业务线？负责人是谁？部署在哪个 Namespace？上游是谁？下游依赖谁？对应哪个数据库？有没有 Redis？当前运行哪个版本？最近有没有发布？有没有历史故障？SLO 是多少？有没有现成 Runbook？
这些信息一般来自：
CMDB；
Kubernetes Metadata；
GitLab / GitHub；
Jenkins；
Argo CD；
Terraform；
云资产系统；
工单系统；
运维知识库；
Runbook；
历史 Incident。
第三层：智能分析与编排层
第三层，才真正轮到 DSH 登场。
这一层可以理解成整个系统的：AIOps 大脑。它并不直接保存所有监控数据，也不直接管理运维资源，如 Kubernetes。
它主要负责：决定下一步应该做什么。比如收到告警：
checkout-service P99 latency > 2sAgent 可能形成这样的调查过程：
第一步： 查询 checkout-service 最近 30 分钟延迟。第二步：确认异常开始时间。第三步：查询同一时间 CPU、Memory、QPS。第四步：搜索异常日志。第五步：查询 Trace。第六步：查询最近 30 分钟发布记录。第七步：检查依赖数据库。第八步：形成 Root Cause 假设。
所以 DSH 真正做的是：动态调查编排。
第四层：安全治理与权限控制层
这一层是整个 AIOps Agent 架构里：最重要，但也最容易被忽视的一层。
很多 Demo 看起来非常酷：“AI 自动发现问题，然后自动 kubectl rollout restart。”
但真正放进生产环境，最大的问题从来不是：模型聪不聪明。而是：它凭什么能执行这个命令？
因此第四层专门解决：AI 可以做什么，不能做什么。
这一层需要考虑的问题有：身份控制、权限控制、风险等级、人工审批、审计等细节。
第五层： 运维执行层
第五层才是真正：动生产环境的地方。这一层负责把 Agent 的“决策”转换成真正的系统操作。
例如：
Kubernetes：
Restart PodScale DeploymentRollback DeploymentDrain Node
CI/CD：
Rollback ReleasePause PipelineRe-deploy
云平台：
Scale ASGRestart VMSwitch Load Balancer
数据库：
Kill QuerySwitch Read ReplicaAdjust Connection Pool
对应的底层系统可能是：
Kubernetes；
Argo CD；
Jenkins；
Ansible；
Terraform；
阿里云；
腾讯云；
VMware；
数据库管理平台。
第六层：结果验证与持续学习层
最后一层是很多所谓“自动修复系统”最容易漏掉的一层。
Agent 执行完：rollback deployment，不能直接说：“故障已经解决。”
因为：命令执行成功 ≠ 业务恢复。
Rollback 成功只代表：Kubernetes 接受了这个操作。
真正需要验证的是：用户体验有没有恢复？验证应该重新回到第一层，例如回滚以后，重新检查：
P99 latency 有没有下降 Error Rate 有没有下降 DB Connection Pool 有没有下降 Pod Ready 有没有恢复 SLO 有没有恢复到正常
然后才能判断： Remediation Successful。
因此一个完整闭环应该是：
这时候 Agent 才真正具备：闭环运维能力。
最后介绍下我新上的《AIOps极简入门》小课，这套AIOps智能体落地案例集是我大模型课程里AIOps章节中的10个案例，现在单独把它拆出来售卖！
虽然只有10个小案例，但价值巨大！
