116 lines (87 loc) · 6.95 KB

Roadmap

本路线图基于当前代码库能力（Next.js App Router、多终端 + xterm、SSH（SSE + exec）、AI 指令解析、审计、管理员面板）整理后续可迭代方向，按版本分层推进：先补“体验闭环”，再抽象“任务系统”，最后补齐“安全治理/资产化/可观测性”。

版本约定

v0.2：不引入复杂后端新模型（或只引入轻量 JSON 结构），以 UI/交互与状态可视化为主。
v0.3：引入可持久化的 Job（长任务）模型与日志流，能力从“当前页面逻辑”升级为“系统能力”。
v0.4+：开始引入策略/审批/团队协作/资产管理等治理能力。

v0.2（体验与交互闭环）

目标

让“AI 下发多条命令”的执行体验可控、可追踪、可回看。
默认不打扰：执行与分析解耦（已具备“执行 / 执行并分析”）。

Backlog（P0）

指令执行状态机：为每条指令记录并展示 queued/running/succeeded/failed/timed_out/canceled、开始/结束时间、耗时、exit code（有则显示）。
输出抽屉：单条指令的 stdout/stderr（或合并流）在抽屉/面板内查看（支持滚动、复制、搜索），避免终端屏幕被“回放/聚合文本”污染。
执行历史：把已执行的指令从 “pendingDirectives” 迁移到 “history”（对话级），支持筛选（成功/失败/超时）与一键重试。

Backlog（P1）

多选与批量：勾选多条指令 → 执行 / 执行并分析 / 删除。
输出可用性：支持“下载当前终端 transcript”“下载某条指令输出（txt）”。
终端体验：将内边距/字号/行高做成偏好项（用户级或对话级），支持快捷键提示。

验收标准（示例）

执行一条命令后，列表能看到状态变化与耗时；刷新页面后仍能看到历史记录（至少对话级 workspace 持久化）。
“执行”不会触发 AI 分析；只有“执行并分析”才会追加分析回复。
单条指令输出在 UI 可回看、可复制、可搜索，不依赖用户再次提问。

v0.3（长任务与后台执行：Job 系统）

目标

让“几分钟脚本/批量跑命令”的过程具备后台任务能力：可持续运行、可取消、可重连、可审计。

核心设计

引入 Job：一次指令执行 = 一个 Job（也可扩展为 JobGroup 支持批量聚合）。
日志流：Job 有独立的日志通道（SSE/WS），前端可在任何页面订阅。
取消：支持取消等待与中断远端执行（优先发送 Ctrl+C；必要时关闭 exec 通道）。

建议数据模型（草案）

Job
- id, ownerUserId, conversationId?, terminalId?, sshSessionId?
- command（原始文本，保留多行）
- status（queued/running/succeeded/failed/timed_out/canceled）
- createdAt/startedAt/endedAt, exitCode?, timedOut?
- summary?（用户触发“分析”后的 AI 总结文本，或人工备注）
JobLog
- jobId, seq, stream（stdout/stderr/merged）, chunk, createdAt
- 存储策略：默认只保留尾部 N KB + 可配置保留期

建议 API（草案）

POST /api/jobs：创建 job（支持 terminal/host/sshSession 绑定）
GET /api/jobs?conversationId=...：列表
GET /api/jobs/:id：详情
GET /api/jobs/:id/stream：SSE 日志流
POST /api/jobs/:id/cancel：取消（软中断/硬中断策略）
POST /api/jobs/:id/analyze：显式触发 AI 分析（把输出 tail 作为输入）

验收标准（示例）

启动一个 2 分钟脚本：刷新页面/切换对话后仍能看到 job 运行状态与持续输出。
点击取消后，job 状态进入 canceled，并在终端侧停止（或明确提示“无法中断，仅取消等待”）。
管理员可在后台看到运行中的 job 数量与失败率（metrics）。

v0.4（安全与风控：从 prompt 约束升级为硬控制）

目标

把“能否执行”从模型自律变成系统规则：可解释、可审计、可配置。

Backlog（P0）

命令策略引擎（服务端拦截点）：在 /api/ssh/run（以及未来 job runner）执行前评估策略。
- deny：直接拒绝（返回明确原因）
- confirm：需要用户在 UI 二次确认（带风险提示与审计）
- allow：直接执行
高危命令内置规则（默认）：例如 rm -rf /、格式化磁盘、写入 ssh key、导出 kubeconfig 等。
输出脱敏增强：对 job 输出 tail 与 AI 输入做规则化脱敏（扩展现有 audit 脱敏思路）。

Backlog（P1）

审批流（可选）：两人审批/管理员审批后才可执行（适用于生产环境）。
权限分级：角色/用户维度限制可执行主机组与命令类型（读/写/重启/部署）。

验收标准（示例）

高危命令在服务端被拦截，前端得到明确可读的失败原因，且审计落库。
用户确认后的执行可追溯到“谁确认、何时确认、执行到哪些主机、结果如何”。

v0.5（资产化与团队协作）

目标

从“单人对话 + 临时 SSH 会话”升级到“团队资产与权限边界清晰”的运维协作系统。

Backlog

主机资产：Host/HostGroup/tag/env（prod/stage）管理；指令可对主机组执行。
凭据治理：SSH key 的组织级/项目级共享策略、轮转提示、使用统计与审计。
协作：对话/任务分享（只读与可执行分离），可复制运行记录作为工单材料。

验收标准（示例）

新人加入后不需要导入私钥即可在授权范围内执行（通过共享凭据或托管连接）。
主机组执行的结果能按主机聚合回看，并可导出。

v0.6（可观测性与运维完善）

目标

让系统在生产可运营：更可靠的审计、更强的检索导出、更完整的健康指标与告警。

Backlog

审计可靠性：把“审计表可选”升级为可配置策略（强制/降级/告警），并在管理端明确展示状态。
审计检索与导出：按用户/主机/动作/关键字检索；CSV/JSON 导出；告警（失败率、异常主机、异常高危命令）。
系统健康：在线 SSH、job 队列、错误率、延迟、外部依赖（DB/AI provider）健康；管理员强制断开/冻结用户会话。

验收标准（示例）

管理员能在 1 分钟内定位“谁在什么时候对哪台主机执行了什么命令，结果如何”。\n+- 关键动作在审计不可用时有清晰行为（阻止/降级）并产生可观测告警。

推荐落地顺序（关键技术切入点）

v0.2：先把“指令结果”结构化保存（最小字段：status/exitCode/duration/outputTail），并完善 UI 展示。\n+2. v0.3：把执行从页面抽离为 Job（持久化 + 日志流 + 取消）。\n+3. v0.4：把策略拦截点放在服务端执行入口（run/job runner），建立统一“执行前检查”。\n+4. v0.5/v0.6：在 Job 与策略成熟后再做资产化与运营能力，避免早期反复返工。\n+