# SSA-Pro 工具体系规划方案 > **日期：** 2026-02-21 > **版本：** v3.1（融合方案 + 工程补强） > **议题：** SSA 智能统计分析助手的工具定义与规划 > **背景：** 当前 100 个 R 执行工具是基础能力，但工具体系过于单一。需要规划更完整的工具层，让 LLM Agent 能够在分析的全生命周期中为用户服务。 > **结论：** 经过多轮讨论和团队评审，确定融合方案（四层 7 工具 + 反思编排 + Session 黑板 + Token 控制 + data_source 自动注入） --- ## 一、当前问题 **现状**：系统只有 R 执行工具（约 100 个），用户发消息 → 系统直接匹配统计方法 → 执行 R 脚本。 **问题**： - 用户无法与系统自由对话（每条消息都被当作分析请求） - LLM 面对 100 个 R 工具会决策瘫痪（工具过载） - 缺少"看数据""选方法""解读结果"等非执行类工具 - 分析全过程对用户不透明 --- ## 二、工具设计原则 | 原则 | 含义 | |------|------| | **正交性** | 每个工具有唯一职责，不重叠 | | **清晰触发** | LLM 看到工具名就知道何时该用 | | **组合性** | 工具可按不同顺序组合，下游只依赖上游输出而非特定调用链 | | **粒度适中** | 太粗=黑箱，太细=决策负担；5-8 个工具是 LLM 的甜区 | | **安全分级** | 只读工具随时调用，执行工具需确认 | | **最小暴露** | 每个阶段只暴露完成当前任务所必需的工具子集 | | **工具 vs 智能体** | 需要外部信息或改变外部世界 → 工具；纯 LLM 推理 → Prompt 职责，不封装为工具 | --- ## 三、融合方案总览 ### 3.1 四层架构 ``` ┌─────────────────────────────────────────────────────────────┐ │ LLM Agent 决策层 │ │ 根据对话上下文 + 当前阶段，选择调用哪个工具 │ └──┬─────────────┬──────────────┬──────────────┬──────────────┘ │ │ │ │ ▼ ▼ ▼ ▼ READ 层 INTERACT 层 THINK 层 ACT 层 只读，零风险 人机交互 生成方案 执行，有成本 随时可调用 零风险 需用户审查 需用户确认 ``` ### 3.2 工具清单（7 个） | 层 | # | 工具名 | 类型 | 一句话职责 | |----|---|--------|------|-----------| | **READ** | 1 | **get_data_overview** | 只读 | 数据全貌：统计摘要 + 缺失 + 变量分类 + PICO 自动推断 | | **READ** | 2 | **get_variable_detail** | 只读 | 单变量深入：分布 + 异常值 + 唯一值（按需查看，控制 Token） | | **READ** | 3 | **method_consult** | 只读 | 方法咨询：推荐统计方法 + 理由 + 前提 + 替代方案 | | **INTERACT** | 4 | **ask_user** | 交互 | 向用户提问/确认：渲染为选择卡片，用于 PICO 确认、方案审查 | | **THINK** | 5 | **analysis_plan** | 生成 | 分析规划：有序步骤 + 参数 + 依赖（输出确定的 tool_code + params） | | **ACT** | 6 | **run_step** | 执行 | 傻瓜式 R 执行：接收 tool_code + params，转发 R 引擎，返回结果 | | **ACT** | 7 | **write_report** | 生成 | 论文级报告 / 结果解读（双模式：generate + interpret） | ### 3.3 反思机制（不是工具，是编排层逻辑） 反思不定义为独立工具，而是系统编排机制，采用**双轨触发**： **自动触发（静默重试）**：当 `run_step` 返回硬性错误（Column not found、NaN produced 等参数级错误），系统自动将错误日志注入 LLM 上下文，LLM 修正参数后静默重试，最多 2 次。用户无感知。 **手动触发（用户驱动）**：当执行成功但用户不满意（"能不能换个方法""把极值删了再跑一次"），意图路由器识别为 feedback 意图，将完整 QPER 记录注入 LLM，LLM 分析问题后生成新的 `analysis_plan`。 ``` run_step 返回 error → 错误分类器 → 可自愈（参数拼写、列名错误） → 自动修正 → 重试（最多 2 次） → 不可自愈（方法不适用、数据不足） → 报告用户 + 建议替代方案 用户表达不满 → 意图路由器 → feedback 意图 → 注入完整 QPER 记录 → LLM 分析原因 → 新的 analysis_plan → 重新执行 ``` ### 3.4 PICO 需求梳理（不是工具，是 Prompt 职责） PICO 梳理在对话过程中自然完成，不需要专门的工具： ``` 1. LLM 调用 get_data_overview → 返回中包含 AI 自动推断的 PICO 分类（置信度标记） 2. LLM 基于推断结果 + 临床知识 + System Prompt 组织 PICO 描述 3. LLM 调用 ask_user → 让用户确认/修正 PICO 分类 4. 确认后的 PICO 写入 Session 黑板，后续所有工具调用都携带 ``` --- ## 四、各工具详细定义 ### 工具 1: get_data_overview ``` 名称: get_data_overview 层级: READ（只读，零风险） 触发时机: 数据上传后自动调用 / 用户询问数据概况时 底层实现: DataProfileService（Python） 输入: { session_id: string } 输出: { total_rows: number, total_columns: number, missing_overview: { overall_rate: number, columns_with_missing: [{ name, rate }] }, categorical_vars: [{ name, levels_count, top_levels }], continuous_vars: [{ name, mean, sd, min, max }], id_like_vars: [string], data_structure: "cross-sectional" | "longitudinal" | "repeated-measures" | "unknown", sample_size_warning: string | null, // PICO 自动推断（AI 猜测，需用户通过 ask_user 确认后才生效） pico_inference: { population: string | null, intervention_var: string | null, intervention_levels: [string], outcome_candidates: [{ var, type, confidence }], design_guess: string | null, confidence: number // 整体推断置信度 } } ``` **设计要点**： - 输出一次性包含"下游需要的一切只读信息"，满足组合性原则 - PICO 推断标记为 inference（推断），不是 confirmed（确认），后续必须经过 ask_user 确认 - 输出写入 Session 黑板缓存，后续工具直接读缓存，不重复调用 ### 工具 2: get_variable_detail ``` 名称: get_variable_detail 层级: READ（只读，零风险） 触发时机: LLM 需要深入了解某个变量时（按需 drill-down） 底层实现: DataProfileService（Python），按需查询单列 输入: { session_id: string, variable_name: string } 输出: { name: string, type: "continuous" | "categorical" | "ordinal" | "datetime" | "id", missing_rate: number, unique_values: number, distribution: { // 连续型: { mean, median, sd, q1, q3, min, max, histogram_bins } // 分类型: { levels: [{ value, count, percentage }] } }, outliers: { count, threshold }, sample_values: [...] } ``` **设计要点**： - 解决大数据集 Token 爆炸 — LLM 先看 overview 概览，再按需 drill-down 单列 - 多次调用查看不同变量，每次只增加一列的 Token 消耗 ### 工具 3: method_consult ``` 名称: method_consult 层级: READ（只读，零风险） 触发时机: 用户询问"应该用什么方法" / LLM 需要方法推荐时 底层实现: DecisionTableService 四维匹配 + LLM 推理补充 输入: { research_question: string, outcome_var: string, predictor_vars: [string], data_context: DataContext // 从 Session 黑板读取 } 输出: { recommended_method: { name: string, // "Independent Samples T-Test" tool_code: string, // "ST_T_TEST_IND" rationale: string, prerequisites: [string], // ["正态性", "方差齐性"] limitations: [string] }, alternatives: [{ name, tool_code, when_to_use // 何时该用替代方案 }], warnings: [string] } ``` **设计要点**： - 当前 R 工具数量 7 个，决策表四维匹配（Goal × OutcomeType × PredictorType × Design）已足够精准 - 未来工具扩展到 30+ 时，可在此处引入 RAG Top-K 检索替代/增强决策表 - 只返回推荐，不执行。用户通过 ask_user 确认后才进入 THINK 层 ### 工具 4: ask_user ``` 名称: ask_user 层级: INTERACT（人机交互，零风险） 触发时机: LLM 需要用户确认或澄清时 前端渲染: 选择卡片（单选/多选）或输入框，嵌入对话流 输入: { question: string, context: string, options: [{ id: string, label: string, description?: string }], allow_multiple: boolean, allow_free_text: boolean } 输出: { selected_options: [string], free_text: string | null } ``` **设计要点**： - 强制 LLM 在不确定时向用户提问，而非自行猜测 - 贯穿全流程：PICO 确认、变量角色确认、方法选择确认、方案审查 - 前端已有 ClarificationCard 组件基础，需要标准化接口 **实现方式（请求-响应模式，非 Function Calling 挂起）**： - 当前架构是 Node.js 编排层控制流程，不是 LLM 自主调用链 - ask_user 不需要"挂起 LLM 推理线程"：Node.js 生成卡片 → 返回前端 → 用户点击 → 前端 POST 新请求 → Node.js 从 Session 黑板恢复上下文 → 继续流程 - 已有实现基础：`QueryService.generateClarificationCards()` + `/workflow/clarify` 路由 - 未来若演进为 LLM Function Calling 模式（LLM 自主编排），需引入 Session 状态机 + 消息历史持久化（Phase 4 预研） ### 工具 5: analysis_plan ``` 名称: analysis_plan 层级: THINK（生成方案，需用户审查） 触发时机: 用户确认需求和方法后 底层实现: FlowTemplateService 模板填充 + DecisionTableService 匹配 输入: { confirmed_question: string, confirmed_methods: [string], // 用户确认的 tool_code 列表 variable_mapping: { outcome: string, predictors: [string], confounders?: [string], group_var?: string }, data_context: DataContext // 从 Session 黑板读取 } 输出: { plan_id: string, title: string, steps: [{ step_id: string, order: number, tool_code: string, // 确定的 R 工具代码，如 "ST_T_TEST_IND" tool_name: string, description: string, params: { ... }, // 已填好的参数，run_step 直接透传 depends_on: [step_id], expected_output: string }], estimated_duration: string, notes: [string] } ``` **设计要点**： - 输出包含确定的 `tool_code` 和完整 `params`，`run_step` 只需要傻瓜式执行 - 方法选择由 `method_consult`（决策表）+ 用户确认完成，`analysis_plan` 只负责编排顺序和填充参数 - 生成后展示给用户审查，用户确认后才进入 ACT 层 ### 工具 6: run_step ``` 名称: run_step 层级: ACT（执行，有计算成本） 触发时机: 用户确认分析计划后，逐步执行 底层实现: WorkflowExecutorService → RClientService → R Plumber API 输入: { step_definition: { // 直接来自 analysis_plan 输出的某一步 step_id: string, tool_code: string, // 如 "ST_T_TEST_IND" params: { ... } }, session_id: string } 输出: { status: "success" | "warning" | "error", result: { blocks: ReportBlock[], figures: [{ type, data, title }], raw_output: { ... } }, r_code: string, warnings: [string], error_message: string | null } ``` **设计要点**： - **傻瓜式 API 转发器** — 不做任何方法选择决策，只接收 tool_code + params → 调用 R → 返回结果 - **data_source 自动注入** — LLM 和 analysis_plan 都不需要关心数据文件位置。Node.js 编排层自动从 Session 黑板取出 `dataOssKey`，生成预签名 URL，注入 `{ type: 'oss', oss_url: signedUrl }` 后再 POST 给 R 服务（代码已实现：`WorkflowExecutorService.resolveDataSource()`） - 错误处理由编排层接管（双轨反思机制） - warning 状态的结果正常展示（R 引擎的 ggplot2 废弃警告等不影响结果） ### 工具 7: write_report ``` 名称: write_report 层级: ACT（生成，有 LLM Token 成本） 触发时机: 步骤全部执行完成后 / 用户要求解读结果时 底层实现: ReflectionService（LLM 结论生成）+ 槽位注入 + Zod 校验 输入: { mode: "generate" | "interpret", step_results: [StepResult], // generate 模式：全部步骤结果 data_context: DataContext, user_question?: string // interpret 模式：用户的具体问题 } 输出: { conclusion: { summary: string, detailed: string, clinical_significance: string, limitations: [string], recommendations: [string] }, export_formats: ["word", "markdown"] } ``` **设计要点**： - **双模式**：`generate` 生成完整论文级报告（QPER R 层），`interpret` 解读已有结果（新增能力，支持 discuss 意图） - generate 模式在全部 run_step 完成后自动触发 - interpret 模式在用户追问结果时触发（"p 值说明什么""为什么置信区间这么宽"） --- ## 五、Session 黑板（状态管理） ### 5.1 为什么需要 Session 黑板 7 个工具本身是无状态函数。要让它们协同工作，需要一个后端"会话黑板"（Session Context Blackboard）在工具之间传递上下文。 **核心规则：切勿让 LLM 反复重新生成上下文。** `get_data_overview` 的输出缓存到 Session，后续 `analysis_plan` / `run_step` / `write_report` 直接从 Session 读取，不重新调用。 ### 5.2 Session 黑板结构 ```typescript interface SessionBlackboard { sessionId: string; uploadedAt: string; // get_data_overview 的缓存输出 dataOverview: DataOverviewResult | null; // 用户确认的 PICO（经过 ask_user 确认后写入） confirmedPico: { population: string; intervention: { var: string; levels: string[] }; outcomes: [{ var: string; type: string; role: string }]; confirmed: boolean; } | null; // 变量字典（对话中逐步丰富） variableDictionary: Array<{ name: string; label: string; type: string; role: string; confirmed: boolean; }>; // 当前分析计划（analysis_plan 输出后写入） currentPlan: AnalysisPlanResult | null; // 数据文件信息（上传时写入，run_step 自动注入 data_source 用） dataOssKey: string | null; // 执行结果（run_step 每完成一步追加） // ⚠️ Token 控制：只保留当前生效计划的结果，废弃试错结果 stepResults: StepResult[]; // 结论报告（write_report 输出后写入） report: ReportResult | null; // QPER 执行记录（反思机制需要） // ⚠️ Token 控制：注入 LLM 前只保留最近 3 次关键事件，做摘要压缩 qperTrace: Array<{ timestamp: string; tool: string; input: any; output: any; }>; } ``` ### 5.3 Token 控制策略 Session 黑板会随着对话和试错不断膨胀。如果全量注入 LLM，会导致 Token 爆炸和注意力涣散。 **规则 1：stepResults 只保留当前生效计划的结果** - 用户确认新的 analysis_plan 后，清空旧的 stepResults - 反思迭代产生新方案时，旧方案的结果标记为 `deprecated`，不注入 LLM **规则 2：qperTrace 滑动窗口** - 注入 LLM 前，只保留最近 3 次关键事件（tool 调用 + 错误 + 修复动作） - 早期的 trace 条目压缩为一行摘要（如"第 1 轮：T 检验成功"） **规则 3：R 引擎原始输出不入 LLM** - stepResults 中的 `raw_output` 只存储在黑板中供前端展示 - 注入 LLM 时只提取结构化摘要（关键数值、p 值、置信区间），不灌入完整日志 ### 5.4 数据流 ``` get_data_overview → 输出写入 blackboard.dataOverview → LLM 基于输出推断 PICO ask_user（确认 PICO） → 用户选择写入 blackboard.confirmedPico method_consult → 读取 blackboard.dataOverview + confirmedPico → 返回推荐方法（不写入 blackboard，只是对话中的回复） analysis_plan → 读取 blackboard 全部上下文 → 输出写入 blackboard.currentPlan run_step ×N → 读取 blackboard.currentPlan 中的 step 定义 → 每步输出追加到 blackboard.stepResults write_report → 读取 blackboard.stepResults + dataOverview → 输出写入 blackboard.report 反思（自动/手动） → 读取 blackboard.qperTrace（完整记录） → 生成新的 analysis_plan → 覆盖 blackboard.currentPlan ``` ### 5.5 持久化策略 | 层级 | 策略 | 理由 | |------|------|------| | 内存缓存 | 当前会话有效，进程重启丢失 | 快速读写，满足当前需求 | | 数据库持久化 | 跨会话保留，支持历史回溯 | 后续扩展，用于分析记录和审计 | | 当前实现 | 先用内存缓存（已有 DataProfileService 缓存机制） | 快速落地 | --- ## 六、安全梯度与阶段性工具可见性 ### 6.1 安全梯度 ``` READ 层: get_data_overview / get_variable_detail / method_consult → 零风险，调用 100 次也无副作用 → 对话阶段主要使用，支持自由探索 → LLM 不确定时的安全默认选择 INTERACT 层: ask_user → 零风险，让用户参与决策 → 贯穿全流程：PICO 确认、方案审查、结果追问 THINK 层: analysis_plan → 低风险，只生成方案不执行 → 用户审查确认后才进入 ACT 层 ACT 层: run_step / write_report → 有成本（R 计算资源、LLM Token） → 产生真实结果，但可重新执行 ``` ### 6.2 阶段性工具可见性 不同阶段向 LLM 暴露不同的工具子集： | 阶段 | 可见工具 | 隐藏工具 | |------|---------|---------| | **数据探索** | get_data_overview, get_variable_detail, ask_user | method_consult, analysis_plan, run_step, write_report | | **需求梳理** | 全部 READ + ask_user | analysis_plan, run_step, write_report | | **方案规划** | method_consult, ask_user, analysis_plan | run_step, write_report | | **分析执行** | run_step, ask_user | 其他 | | **报告生成** | write_report, ask_user | 其他 | | **自由对话** | 全部 READ + INTERACT | THINK + ACT | --- ## 七、典型调用链 ### 场景 1：完整分析旅程 ``` 用户上传数据 → get_data_overview [自动] → 写入 Session 黑板 → "您的数据有 200 行 15 列，推断为横截面..." [LLM 回复] → 用户: "帮我看看 BMI 这个变量" → get_variable_detail("bmi") [LLM 调用] → ask_user("推断结局变量为 bp_change， [LLM 调用] 分组变量为 group，是否正确？") → 用户确认 → 写入 Session 黑板 confirmedPico → 用户: "帮我比较两组血压差异" → method_consult(...) [LLM 调用，从 Session 读上下文] → "建议独立样本 T 检验，理由..." [LLM 回复] → ask_user("确认使用 T 检验分析？") [LLM 调用] → 用户确认 → analysis_plan(...) [LLM 调用] → 写入 Session 黑板 → "分析计划：步骤1 描述统计 → 步骤2 T 检验" [展示给用户] → 用户: "确认，开始执行" → run_step(step_1) [逐步执行] → 追加到 Session → run_step(step_2) [逐步执行] → 追加到 Session → write_report(mode: "generate") [生成报告] → 写入 Session ``` ### 场景 2：用户只是了解数据 ``` 用户: "这个数据有什么特点？" → get_data_overview [LLM 调用] → "您的数据包含 200 例患者，15 个变量..." [LLM 基于缓存回复] 用户: "age 的分布怎样？" → get_variable_detail("age") [LLM 调用] 用户: "哪些变量缺失比较严重？" → [LLM 从 Session 黑板缓存直接回答，无需再调工具] ``` ### 场景 3：方法咨询 ``` 用户: "BMI 和血压有关系吗？应该怎么分析？" → method_consult(...) [LLM 调用] → "建议 Pearson 相关分析，因为两个变量均为连续型..." → ask_user("是否需要控制混杂因素？", options: ["不需要", "控制年龄", "控制年龄和性别"]) → 用户选择后 LLM 更新建议 ``` ### 场景 4：结果不满意，反思迭代 ``` 用户: "结果不对，p 值不应该这么大" → [编排层] 注入完整 qperTrace 到 LLM 上下文 → LLM: "可能原因：样本量不足导致检验效能低..." → ask_user("建议：1)换用非参数检验 2)排除极值后重新分析 3)合并亚组") → 用户选择 "换用非参数检验" → analysis_plan(...) [生成新方案] → run_step(...) [重新执行] → write_report(mode: "generate") [新报告] ``` ### 场景 5：执行出错，自动修正 ``` → run_step(step_2) [执行] → R 返回 error: "Column 'Blood_Pressure' not found" → [编排层] 错误分类 → 可自愈（列名拼写） → [编排层] 自动注入错误 + 数据概览 → LLM 修正参数（bp_change） → run_step(step_2, 修正后参数) [静默重试] → 成功 → 用户无感知 ``` --- ## 八、R 工具路由策略 ### 当前方案：决策表四维匹配 100 个 R 脚本通过 `run_step` 调用时，方法选择在 `method_consult` / `analysis_plan` 阶段已确定： ``` 用户需求 → method_consult 调用 DecisionTableService → 四维匹配（Goal × OutcomeType × PredictorType × Design） → 命中规则：primaryTool = ST_T_TEST_IND, fallbackTool = ST_MANN_WHITNEY → 用户确认 → analysis_plan 填充参数 → run_step 傻瓜式执行 ``` 决策表（`decision_tables.json`）当前有 ~10 条规则，覆盖 7 个 R 工具。规则驱动的确定性匹配比语义检索更精准、更可控。 ### 未来扩展：RAG 增强 当 R 工具扩展到 30+ 且四维规则无法穷举时，可在 `method_consult` 内部增加 RAG 层： ``` method_consult 内部路由： 1. 先走决策表匹配 → 命中则直接返回 2. 未命中 → pgvector 语义检索 Top-5 工具 → LLM 从中选择 → 返回推荐 ``` 当前阶段不需要实现 RAG，决策表已足够。 --- ## 九、与意图识别架构的关系 工具体系与意图路由器（详见《SSA-Pro 意图识别与对话架构设计》）配套工作： ``` 意图路由器输出 可见工具 典型调用 ───────────── ────────── ──────── chat（自由对话） → READ + INTERACT data_overview / variable_detail explore（数据探索） → READ + INTERACT data_overview / variable_detail / ask_user consult（方法咨询） → READ + INTERACT method_consult / ask_user analyze（分析执行） → THINK + ACT + INTERACT analysis_plan → run_step → write_report discuss（结果讨论） → ACT(write_report) + READ write_report(interpret) feedback（不满意） → 反思编排 → THINK + ACT analysis_plan → run_step → write_report ``` **两个设计合在一起**： - **意图路由器**决定"用户想干什么"→ 控制工具可见性 - **工具体系**决定"系统能干什么"→ 提供能力边界 - **Session 黑板**贯穿全流程 → 所有工具共享上下文，避免重复生成 --- ## 十、与现有 QPER 代码的映射 | 工具 | 现有组件 | 改造程度 | |------|---------|---------| | get_data_overview | DataProfileService（已有） | **低** — 封装为 Tool 接口 + 新增 PICO 推断字段 | | get_variable_detail | DataProfileService（需扩展） | **中** — 新增单列查询 API | | method_consult | DecisionTableService（已有） | **中** — 封装为 Tool 接口 + LLM 推理补充 | | ask_user | ClarificationCard 前端组件（已有） | **低** — 标准化后端接口 | | analysis_plan | Q 层 + P 层（FlowTemplateService 已有） | **低** — 封装为 Tool 接口 | | run_step | E 层 WorkflowExecutorService（已有） | **已有** — 当前就是傻瓜式执行 | | write_report | R 层 ReflectionService（已有） | **中** — 新增 interpret 模式 | | Session 黑板 | DataProfileService 缓存（部分已有） | **中** — 扩展为完整 Blackboard | | 反思编排 | 无 | **新增** — 错误分类器 + 自动重试 + 手动触发 | **核心结论：QPER 四层的底层实现基本可复用，主要工作是封装 Tool 接口 + 新增 READ/INTERACT 层 + Session 黑板 + 意图路由。** --- ## 十一、落地路线 | Phase | 工作内容 | 依赖现有组件 | 核心产出 | |-------|---------|-------------|---------| | **Phase 1** | **READ + INTERACT 层** | DataProfileService | get_data_overview + get_variable_detail + ask_user + Session 黑板 | | | 目标：让系统能陪用户聊天，能看懂数据 | | 即使不能跑分析，用户也能感受到 AI 的价值 | | **Phase 2** | **意图路由器 + method_consult** | DecisionTableService | 意图分类 + 方法咨询 + 阶段性工具可见性 | | | 目标：系统能区分对话/探索/咨询/分析意图 | | | | **Phase 3** | **THINK + ACT 对接** | QPER 全链路 | analysis_plan + run_step + write_report 封装为 Tool 接口 | | | 目标：把已有 QPER 挂载到新工具体系上 | | | | **Phase 4** | **反思编排 + 高级特性** | 全部 | 双轨反思 + write_report interpret 模式 + 持久化 | --- **附：参考文档** - `00-系统设计/SSA-Pro 意图识别与对话架构设计.md` — 意图路由器设计 - `00-系统设计/SSA-Pro 严谨型智能统计分析架构设计方案V4.md` — QPER 架构 - `00-系统设计/SSA-Pro 理想状态与智能化愿景设计.md` — 智能化愿景 - `06-开发记录/J技术报告审核评估与建议/SSA-Pro 智能体边界与工具生态规划报告.md` — 团队架构评审