From 407ca778563bd5bdfc087f5c1b0eca361e71abb1 Mon Sep 17 00:00:00 2001 From: rookit Date: Tue, 14 Apr 2026 10:02:14 +0800 Subject: [PATCH] remove unneeded content, less is more --- .gemini/GEMINI.md | 8 --- .gemini/settings.json | 7 -- .github/copilot-instructions.md | 6 -- .gitignore | 4 +- ARCHITECTURE.md | 67 ++----------------- CLAUDE.md | 8 --- TODO.md | 110 -------------------------------- 7 files changed, 8 insertions(+), 202 deletions(-) delete mode 100644 .gemini/GEMINI.md delete mode 100644 .gemini/settings.json delete mode 100644 .github/copilot-instructions.md delete mode 100644 CLAUDE.md delete mode 100644 TODO.md diff --git a/.gemini/GEMINI.md b/.gemini/GEMINI.md deleted file mode 100644 index 5211f4b..0000000 --- a/.gemini/GEMINI.md +++ /dev/null @@ -1,8 +0,0 @@ -# 必须遵守的规则 - -- 每次生成代码前,需要描述方案和代码结构 -- 除非用户明确要求,否则代码中不要添加任何注释 -- 除非用户明确要求,否则不要生成和添加任何文档 -- 不要运行任何测试,不要添加任何测试脚本和代码,不要进行语法检查 -- 不要进行任何语法检查 -- 不要生成任何总结性内容和报告 \ No newline at end of file diff --git a/.gemini/settings.json b/.gemini/settings.json deleted file mode 100644 index 6e6de9d..0000000 --- a/.gemini/settings.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "general": { - "checkpointing": { - "enabled": true - } - } -} \ No newline at end of file diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md deleted file mode 100644 index 914fff8..0000000 --- a/.github/copilot-instructions.md +++ /dev/null @@ -1,6 +0,0 @@ -# 必须遵守的规则 - -- 每次生成代码前,需要简要描述方案 -- 除非用户明确要求,代码中不要添加任何注释,不要生成和添加任何文档 -- 不要运行任何测试和语法检查,不要添加任何测试脚本和代码 -- 不要生成任何总结内容和报告 \ No newline at end of file diff --git a/.gitignore b/.gitignore index 59a0f07..2168189 100644 --- a/.gitignore +++ b/.gitignore @@ -183,10 +183,8 @@ Docker/Huggingface/bm25/* Docker/mcp_uuid -Docker/db_chroma/* PLAYBOOKS/Debug_* DATA/Debug_*/ -PLUGINS/Embeddings/db/* -.claude/* +.claude/*.local.* .vscode/* \ No newline at end of file diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md index 1279d6a..c1e6936 100644 --- a/ARCHITECTURE.md +++ b/ARCHITECTURE.md @@ -2,7 +2,8 @@ ## 1. 平台核心设计目标 -该平台的核心目标不是单纯做告警展示，而是围绕安全运营与应急响应流程，构建一个可以承载分析、富化、工单协同、自动化处置、知识沉淀与 AI 智能体编排的统一数据与执行平台。 +该平台的核心目标不是单纯做告警展示，而是围绕安全运营与应急响应流程，构建一个可以承载分析、富化、工单协同、自动化处置、知识沉淀与 +AI 智能体编排的统一数据与执行平台。 平台设计上有几个明确的方向： @@ -138,7 +139,8 @@ Ticket 的设计定位是“同步与关联”，不是“平台内部替代工 Playbook 对应 SOAR 的 playbook 理念。 -当前设计里，用户可以针对不同对象编写 Python 脚本，脚本位于 PLAYBOOKS 目录。未来这部分很适合逐步演进为以 LangGraph 为主的 AI 分析/处置智能体执行层。 +当前设计里，用户可以针对不同对象编写 Python 脚本，脚本位于 PLAYBOOKS 目录。未来这部分很适合逐步演进为以 LangGraph 为主的 AI +分析/处置智能体执行层。 Playbook 可以面向： @@ -210,68 +212,13 @@ Knowledge 的 Action 字段很重要，因为它天然适合承载“待存储 --- -## 4. 当前更合理的 MCP 设计原则 +## 4. MCP 设计原则 -基于当前平台设计，MCP 层应尽量遵守以下原则： +MCP 层应尽量遵守以下原则： 1. MCP 主要暴露工具，不承载复杂业务逻辑。 2. 业务逻辑应尽量下沉到 sirpapi.py 这类领域层。 3. MCP 层只做参数 schema、对象路由、最小封装和返回格式整理。 4. 对象关系和回写逻辑要以领域模型真实结构为基础，不能在 MCP 层假设不存在的关系。 -例如： - -1. Artifact 应挂在 Alert 下，因此应区分“创建 Artifact”和“将现有 Artifact 挂载到 Alert”两个动作。 -2. Enrichment 可以挂到 Case、Alert、Artifact，因此领域层应分别支持 attach_enrichment，而 MCP 可以采用 `create_enrichment + attach_enrichment_to_target` 的两步模式按 target_type 路由。 -3. Ticket 的逻辑重点是同步外部工单信息，不应该被设计成平台内部的完整工单系统；因此也应区分“创建 Ticket”和“将现有 Ticket 挂载到 Case”。 - ---- - -## 5. Knowledge 与 AgentKnowledge 的关系 - -`AGENTS/agent_knowledge.py` 更像面向 Agent 的“知识消费层”，而 Knowledge MCP 更像平台级“知识读写工具层”。 - -两者并不冲突： - -1. MCP 提供通用读写工具 -2. AgentKnowledge 提供更面向 AI 检索和 rerank 的消费接口 - ---- - -## 6. 当前对象分层的推荐理解 - -如果从调查视角理解整个系统，可以按以下层级看待： - -1. Case：事件调查与处置层 -2. Alert：检测与关联层 -3. Artifact：最小原子与 pivot 层 -4. Enrichment：结构化补充信息层 -5. Ticket：外部协同层 -6. Playbook：自动化执行层 -7. Knowledge：共享上下文与实时知识层 - -这个分层是相互配合的，不是互相替代的。 - ---- - -## 7. 总结 - -这个平台的真正核心不是单个表，而是围绕 Case、Alert、Artifact、Enrichment、Ticket、Playbook、Knowledge 形成的一套面向 SOC/IR 的统一对象模型。 - -其中最重要的几个设计判断是： - -1. Case 是调查入口和用户主视图。 -2. Alert 是检测与汇总之间的关键层。 -3. Artifact 是最小原子，是最适合做 pivot 与情报富化的对象。 -4. Enrichment 是结构化结果层，应当广泛用于保存 AI、情报、查询与分析结果。 -5. Ticket 用于同步外部系统而不是替代外部工单平台。 -6. Playbook 是自动化执行层，未来非常适合和 AI Agent 深度结合。 -7. Knowledge 是高时效内部共享知识层，既服务人，也服务 AI。 - -从平台长期演进来看，最值得继续强化的方向是： - -1. Artifact 驱动的查询与富化 -2. Enrichment 驱动的结果沉淀 -3. Playbook 驱动的自动化分析 -4. Knowledge 驱动的内部上下文增强 -5. MCP 工具层统一、轻量、领域逻辑下沉 +--- \ No newline at end of file diff --git a/CLAUDE.md b/CLAUDE.md deleted file mode 100644 index 46cfd8f..0000000 --- a/CLAUDE.md +++ /dev/null @@ -1,8 +0,0 @@ -# 必须遵守的规则 - -- 每次生成代码前,需要描述方案和代码结构 -- 除非用户明确要求,否则代码中不要添加任何注释 -- 除非用户明确要求,否则不要生成和添加任何文档 -- 不要运行任何测试,不要添加任何测试脚本和代码,不要进行语法检查 -- 不要进行任何语法检查 -- 不要生成任何总结性内容和报告 diff --git a/TODO.md b/TODO.md deleted file mode 100644 index 44aa426..0000000 --- a/TODO.md +++ /dev/null @@ -1,110 +0,0 @@ -# TODO - -## 1. 文档定位 - -这个文件用于持续记录平台后续待推进的事项。 - -维护方式： - -1. 已完成的事项直接删除。 -2. 新增事项按优先级加入对应分组。 -3. 尽量记录“要做什么”，避免把这里写成背景说明文档。 -4. 如果某项已经拆成多个子任务，优先保留可执行的子任务。 - ---- - -## 2. 高优先级 - -### 2.2 Artifact - -1. 基于 Artifact 的内部资产查询 -2. 基于 Artifact 的外部威胁情报查询 -3. 基于 Artifact 的历史日志 pivot 查询 -4. 基于 Artifact 的相似告警查询 -5. 基于 Artifact 的图谱或关系查询 - -### 2.3 Enrichment - -1. 增加 enrichment 查询接口 -2. 增加 enrichment 更新接口 -3. 增加按 provider/type 检索 enrichment 的接口 -4. 增加 enrichment 来源追踪与时间线展示能力 - ---- - -## 3. 中优先级 - -### 3.1 接口模型统一化 - -1. 继续统一 MCP 列表接口的公共参数与返回风格 -2. 收口 `list_*` 类接口中的重复过滤与序列化逻辑 -3. 继续统一 `create_* + attach_*` 两步式 MCP 接口命名与描述文字 -4. 在统一路由接口中继续统一 `target_type + target_id` 风格 -5. 明确对象 ID、记录 row ID、运行记录 ID、定义名四类标识的命名边界 - -### 3.2 Playbook - -1. 对 `execute_playbook` 增加 definition 名称校验或友好错误返回 -2. 视需要增加按对象视角查询 playbook run 的更清晰别名接口 -3. 评估是否需要为 playbook run 增加独立详情接口，而不是仅依赖 `list_playbook_runs` - -### 3.3 Knowledge - -1. 语义搜索接口 -2. 按标签或场景批量检索 -3. 将 Playbook/Agent 输出结果直接写入 Knowledge -4. 更清晰的知识生命周期，例如 `STORE`、`REMOVE`、`ACTIVE`、`EXPIRED` - -### 3.4 结果沉淀方式 - -1. 原始字段保留源事实 -2. Enrichment 承载扩展结果 -3. AI 分析与 Playbook 输出优先沉淀为 Enrichment - ---- - -## 4. 低优先级 - -### 4.1 Agent / Knowledge / Playbook 联动 - -1. Agent/Playbook 查询 Knowledge -2. Agent/Playbook 完成分析 -3. 将高价值结构化结果写回 Enrichment 或 Knowledge -4. 后续 Agent 再次消费这些知识 - -### 4.2 Case - -1. Case 视角的全景上下文查询 -2. Case 时间线视图 -3. Case 复盘资料结构化沉淀 -4. Case 级别的自动摘要与交接信息生成 - -### 4.3 Alert - -1. Alert 解释型 enrichment 模板 -2. 告警误报原因结构化沉淀 -3. 跨告警相似性分析 -4. 规则解释与命中依据回填 - -### 4.4 Ticket - -1. 工单状态同步任务完善 -2. 工单与 Case 双向追踪能力 -3. 工单同步失败重试与审计 - -### 4.5 AI Agent - -1. LangGraph Playbook 标准模板 -2. Agent 输出结构化写回 Enrichment -3. Agent 结合 Knowledge 做实时分析 -4. Agent 调用 Artifact 相关工具做 pivot 分析 - ---- - -## 5. 后续维护原则 - -1. 领域逻辑尽量下沉到 `sirpapi.py` 等领域层 -2. MCP 层尽量保持为参数 schema、对象路由、结果包装 -3. 新能力优先围绕真实对象关系建模，不在 MCP 层虚构关系 -4. 优先强化 Artifact、Enrichment、Knowledge、Playbook 之间的联动 -5. 优先消除 MCP 接口命名歧义，尤其区分 definition、run、record、target object