DeepSeek Harness上线：把它用在 AIOps，可能更有意思

DeepSeek Harness是什么

DeepSeek Harness（DSH）是一个开源的Agent Harness，核心理念是“Everything is a Plugin”。模型、工具、Agent Loop、Session、沙箱、审批、持久化、Web UI，甚至很多运行时能力，本质上都可以通过插件进行组合和替换。官方明确指出，模型适配器、工具注册表、会话日志以及Agent Loop本身都是插件。

DSH本质上是一棵插件树。Dsh-base提供模型适配器、Tools、Persistence、Sandbox、Approval Policy、Credentials、Telemetry等基础能力；Web UI和Headless Runner则是在此基础上继续叠加。因此，Harness更应被理解为一种Agent Runtime / Agent OS。

为什么DSH特别适合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核心，而是把能力做成插件。

最终Agent面对的不是具体系统，而是一组标准化能力。这对AIOps很重要。

Tool Execution Pipeline的价值

DSH的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时最有价值的能力之一。

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%。这就比一句：“根据经验可能是数据库问题。” 可信得多。

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 > 2s，Agent可能形成这样的调查过程：

第一步： 查询 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才真正具备：闭环运维能力。