AIOps Agent Tool Calling 设计方案

生产级 Agent 通常不会让 Agent 自己随意生成命令或脚本执行，而是提前设计并封装好受控的 Tools，让 Agent 在这些工具范围内选择和组合。

也就是说：

Agent 决定“做什么”，系统决定“怎么安全地做”。

1. 最简单的 Agent：LLM 直接生成命令（一般不用于生产）

例如：

用户：

检查 Kubernetes 集群异常 Pod，并修复。

LLM：

kubectl get pods -A
kubectl delete pod xxx
systemctl restart kubelet

然后直接执行。

这种叫：

LLM → Shell → Environment

优点：

• 开发快

• Demo 很惊艳

• 灵活性高

缺点：

生产环境风险极高：

• 命令可能错误

• 参数可能错误

• 权限控制困难

• 容易误操作

• 审计困难

比如：

Agent 判断：

删除异常 Pod。

结果生成：

kubectl delete pods --all

灾难。

所以生产基本不会这样设计。

2. 生产最常见模式：Tool Calling

更典型的架构：

             用户
              |
              v
          LLM Agent
              |
       Tool Selection
              |
    --------------------
    |        |         |
 kubectl  Prometheus  Jira
 Tool       Tool       Tool

Agent 看到的是：

可用工具：

1. 查询Pod状态
2. 查看Pod日志
3. 查询Prometheus指标
4. 执行发布回滚
5. 扩容Deployment

它选择工具。

例如：

用户：

web服务延迟升高，帮忙分析

Agent：

思考：

需要：

1. 查询接口延迟
2. 查看Pod资源
3. 查看最近发布

调用：

{
 "tool": "query_prometheus",
 "args":{
   "metric":"http_latency"
 }
}

返回：

P99延迟从100ms升到3s

继续：

调用：

{
 "tool":"get_deployment_events"
}

发现：

10分钟前发布新版本

然后：

调用：

{
 "tool":"rollback_deployment",
 "args":{
    "name":"web"
 }
}

3. Tool 本质是什么？

其实就是一个受控 API。

比如：

你不会给 Agent：

root@server

权限。

而是封装：

查询工具

例如：

def get_pod_status(namespace):
    """
    获取pod状态
    """
    return kubernetes_client.list_namespaced_pod(namespace)

日志工具

def get_pod_logs(
    pod_name,
    namespace
):
    return kubernetes_client.read_namespaced_pod_log(
        pod_name,
        namespace
    )

扩容工具

def scale_deployment(
    name,
    replicas
):
    # 校验
    if replicas > 10:
        raise Exception(
          "超过最大扩容限制"
        )

    # 执行扩容

注意：

这里非常重要：

安全规则写在 Tool 里面，而不是 Prompt 里面。

因为：

Prompt:

不允许删除生产数据库。

不可靠。

Tool:

if environment=="prod":
    deny()

可靠。

4. 高级生产 Agent：Agent 生成代码，但不直接执行

有一些高级场景，会允许 Agent 写脚本。

但是流程通常是：

Agent

↓

生成方案

↓

生成代码

↓

代码检查

↓

人工审批

↓

沙箱执行

↓

上线

例如：

Agent：

生成：

#!/usr/bin/python

restart_service()

然后：

系统：

检查：

• 是否危险命令

• 是否访问生产

• 是否符合规范

通过：

进入测试环境。

类似 GitHub Copilot Workspace、自动化运维 Agent 都更接近这个思路。

5. 为什么不让 Agent 随便生成？

因为生产环境最大的要求不是：

智能。

而是：

可控。

传统自动化：

确定输入

↓

确定流程

↓

确定输出

Agent：

不确定输入

↓

概率模型决策

↓

可能出现未知行为

所以生产系统需要增加：

Guardrails（护栏）

例如：

权限控制

Agent：

只能：

kubectl get
kubectl describe
kubectl logs

不能：

kubectl delete namespace

审批机制

危险操作：

例如：

删除数据库
回滚生产
扩容GPU集群

需要：

人工确认。

沙箱

Agent：

先：

dry-run

确认：

kubectl apply --dry-run

再执行。

审计

记录：

时间

Agent决定

调用工具

参数

结果

操作者

6. 那 Agent 到底有多自主？

实际上生产环境通常分等级：

Level 0：辅助查询

Agent分析

人执行

例如：

生成故障报告。

Level 1：建议模式

Agent分析

Agent给方案

人批准

目前很多企业在这里。

Level 2：半自动

低风险操作自动

高风险人工确认

例如：

自动重启CrashLoop Pod。

Level 3：自动恢复

Agent发现

Agent判断

Agent修复

例如：

自动扩容。

Level 4：完全自主

类似：

AI SRE

目前还比较少。

7. 如果未来你开发 AIOps Agent，推荐架构

结合方向，我认为比较合理：

                 用户
                  |
                  v
              AIOps Agent
                  |
        +---------+----------+
        |                    |
     Planner             Memory
        |
        v
    Tool Router
        |
 -----------------------------
 |        |        |          |
K8s    Prom    Loki     CMDB
API    API     API      API

        |
        v

   Action Executor

        |
   ----------------
   |              |
低风险          高风险
自动执行        人工审批

8. 对当前学习路线有什么启发？

其实你前面学习：

• Kubernetes

• Python

• Go

• Prometheus

• 深度学习

这些正好对应 Agent 的组成：

所以未来做 AIOps Agent，不是从零开始。

传统运维经验反而是一种优势。

因为很多纯 AI 开发者不知道：

• 什么操作危险

• 什么指标重要

• 什么故障真实存在

• 什么恢复方案靠谱

而这些恰恰是生产 Agent 最需要的。

如果继续深入，你下一步其实可以研究一个很核心的问题：

“一个生产级 AIOps Agent 的 Agent Loop（感知-推理-行动循环）到底如何设计？”

这会比单纯学习 Prompt 更接近真正的 AI 运维系统开发。