# 01 - 项目概述与设计哲学

> 本文描述 AIOps 当前 AI Agent / Agent CLI 的产品定位和工程原则。// Logan.Li

---

## 项目定位

AIOps Agent CLI 是一个面向运维场景的 Web 智能执行器。它不是普通聊天助手，而是能在受控目标上调用工具的 Agent：

- 主机模式：通过 SSH 在服务器上执行只读排查或受控变更。
- Kubernetes 模式：通过 AIOps 后端 K8s 客户端查询资源、查看日志、进入 Pod 或执行受控操作。
- 会话模式：任务过程实时推送，任务结束后可回放和继续追问。

适用任务：

| 场景 | 示例 |
|------|------|
| 主机排障 | “检查 nginx 为什么启动失败” |
| 服务检查 | “看看磁盘空间和最近错误日志” |
| K8s 排障 | “分析这个 Pod CrashLoopBackOff 的原因” |
| 输出分析 | “总结这段 journalctl 输出里的关键错误” |
| 变更建议 | “给出修复步骤，执行前让我确认” |

---

## 与普通 AI 助手的区别

| 维度 | AIOps Assistant | Agent CLI |
|------|-----------------|-----------|
| 交互 | 普通问答 / 分析 | ReAct 执行流 |
| 工具 | 通常不执行远程工具 | 可调用 SSH/K8s 工具 |
| 目标 | 平台知识、告警分析 | 具体主机、Pod、集群 |
| 安全 | 输入输出安全 | 工具风险、确认、审计 |
| 历史 | 对话历史 | 会话 + 工具调用 + 输出回放 |

---

## 核心设计哲学

### 1. 工具少，但边界清楚

Agent 不需要暴露大量工具。当前工具按模式注册：

| 模式 | 工具 |
|------|------|
| host | `ssh_execute`、`analyze_output` |
| kubernetes | `kubernetes_get`、`pod_logs`、`pod_execute`、`kubernetes_action`、`analyze_output` |

工具越少，Prompt 越清晰，模型越不容易绕路。

### 2. 过程优先于结果

运维场景不能只给最终答案，必须知道 Agent 做了什么：

- 每轮思考。
- 调用了什么工具。
- 传了哪些参数。
- 输出是什么。
- 是否触发安全确认。
- 最终结论如何得出。

这些过程通过 WebSocket 推给前端，并写入 `agent_cli_messages`。

### 3. 安全是执行引擎的一部分

安全不是前端弹框，也不是事后审计。它在工具执行前生效：

```text
tool_call
  → assess risk
  → critical hard reject
  → high risk confirm
  → execute if approved
  → persist event
```

### 4. 平台上下文比裸模型更重要

Agent 的价值来自 AIOps 上下文：

- 当前登录用户。
- 资产和凭据。
- 服务器 IP、端口、OS。
- K8s 集群、Namespace、Pod、Container。
- 历史会话和 Evolver 记忆。
- 后续可加入告警、监控、日志、审批状态。

### 5. 记忆必须可控

Evolver 能把成功经验和事实写入本地记忆文件，但企业平台必须逐步做到：

- 按用户/团队隔离。
- 可查看、可删除、可禁用。
- 可审计 AI 记住了什么。
- 可区分事实、经验、流程和偏好。

---

## 运行边界

Agent CLI 当前不做这些事情：

| 不做 | 原因 |
|------|------|
| 后端本机任意命令执行 | 多用户 Web 平台风险过高 |
| 绕过资产凭据系统 | 必须受 AIOps 资产权限控制 |
| 自动执行高危变更 | 必须确认，后续接审批 |
| 长期保存明文敏感输出 | 后续需要输出脱敏和保留策略 |
| 替代客户端 Agent | 客户端 Agent 负责采集，不负责 LLM 推理 |

---

## 成功标准

1. 用户能用自然语言描述任务。
2. Agent 能选择正确工具获取事实。
3. 高危动作不会静默执行。
4. 过程可追溯，历史可回放。
5. 失败时能给出明确原因和下一步建议。
6. 同类任务能从历史经验中得到更好的提示。