Files

HaHafeng bf10dec4c8 docs(ssa): Complete intelligent dialogue and tool system architecture design

Architecture Design:
- Add intent recognition and dialogue architecture design (Intent Router + DataContext)
- Add tool system planning (4-layer 7-tool fusion solution: READ/INTERACT/THINK/ACT)
- Add 4-layer 7-tool implementation mechanism details (Conversation Layer LLM + Node.js orchestration)

Development Plan (v1.2):
- Create 6-phase development plan (134h/22 days) for intelligent dialogue system
- Add 8 architectural constraints (C1-C8): no Function Calling, Postgres-Only cache,
  streaming output, context guard, Zod dynamic validation
- Correct Session Blackboard to use CacheFactory (Postgres-Only, no Redis)

Status Updates:
- Update SSA module status: QPER complete + dialogue architecture design complete
- Update system-level status: add SSA architecture design milestone

Other:
- R tools minor fixes (chi_square, correlation, logistic_binary, mann_whitney, t_test_paired)
- Frontend AIA chat workspace style adjustment

Co-authored-by: Cursor <cursoragent@cursor.com>

2026-02-22 10:05:14 +08:00

5.5 KiB

Raw Blame History

架构委员会审查报告：SSA-Pro 工具体系 (V3.0 融合方案)

审查对象： 《SSA-Pro 工具体系规划方案 v3.0（融合方案定稿）》

审查时间： 2026-02-21

总体评级： 🌟 S++ 级 (Agent 架构设计的行业教科书)

核心裁决： 完全通过！方案在逻辑自洽、职责边界、性能考量上均达到了企业级 SaaS 的最高标准。只需在工程实现（特别是异步流转）上打几个“补丁”即可完美落地。

一、值得全行业学习的 3 大神级设计 (Highlights)

我必须对团队在 V3.0 中做出的以下三个决策给予最高赞誉：

1. 拨乱反正：“把 PICO 和反思移出工具箱”

精妙之处：很多新手团队会把“PICO 梳理”和“反思”写成让 LLM 调用的 tool。你们准确地认识到，它们本质上是 “Prompt 的职责” 和 “系统的编排机制 (Orchestrator Loop)”。这彻底避免了 LLM “左脚踩右脚”的死循环逻辑。

2. 引入 Session 黑板 (Blackboard Pattern)

精妙之处：这是整个方案的灵魂！LLM 是无状态的，如果每次调用 run_step 都要重新把 10MB 的数据描述再生成一遍，系统会慢得令人发指。利用 Node.js 内存建立统一的 Blackboard，工具之间通过它隐式传参，这是高级 Multi-Agent 系统的标准范式。

3. get_variable_detail 的“按需下钻”设计

精妙之处：没有把 100 列的特征全塞给 get_data_overview，而是采用“总-分”结构。这是解决医疗宽表（特征极多）导致 Token Context 爆炸的唯一正确解法。

二、架构师的“挑刺”与补强建议 (Critical Enhancements)

方案在理论上已经无懈可击，但在实际用 Node.js 结合 OpenAI/DeepSeek 的 API 落地时，你们会遇到以下三个工程硬伤。请在代码设计时提前防范：

🚨 盲区 1：ask_user 工具的“异步挂起”难题 (The Suspend/Resume Problem)

纸面逻辑：LLM 调用 ask_user -> 用户回复 -> LLM 继续。
物理现实：在标准的 LLM Function Calling 中，当模型决定调用 ask_user 时，它的推理线程必须停止。在 Web 架构中，Node.js 会向前端发送卡片并结束本次 HTTP 请求（或暂停 SSE 流）。系统如何知道用户明天点完卡片后，该从哪里恢复？
补强方案：
必须将 ask_user 与之前定义的 ExecutionStatus 状态机强绑定。
1. LLM 发出 ask_user(question, options) 工具调用指令。
2. Node.js 拦截该调用，将 Session 状态改为 CLARIFYING，把当前 LLM 的 messages 历史（包含刚才的 tool_call）存入数据库/Redis。
3. 前端展示卡片，用户点击。
4. 前端发起新的 HTTP POST，Node.js 提取保存的 messages，追加一条 role: "tool", content: "用户选择了 A"，然后再次请求 LLM，恢复流转。

🚨 盲区 2：Session 黑板的历史记录 (Token 爆炸)

纸面逻辑：stepResults 和 qperTrace 完整保存在 Session 黑板中，反思或生成报告时一起喂给 LLM。
物理现实：如果用户在这个 Session 里反复试错了 10 次，stepResults 会积累大量冗长的 R 引擎日志。如果把它们全量注入，不仅极度浪费 Token，还会让大模型“注意力涣散”，找不到最新的结果。
补强方案：
引入 "滑动窗口 (Sliding Window)" 或 "摘要压缩 (Trace Truncation)"。
在将 Session 黑板的内容组装进 Prompt 前：
- stepResults 只保留当前最终采用的计划所对应的结果。废弃试错结果。
- qperTrace 只保留最近 3 次的关键错误和修复动作。

🚨 盲区 3：run_step 的数据流向缺失 (The Data Payload)

纸面逻辑：输入包含 tool_code 和 params。
物理现实：在你们前两天的决议中，我们规定了 R 引擎必须接收 data_source: { type: 'oss', oss_url: '...' }。但目前的 run_step 定义里遗漏了这一点。
补强方案：
不需要大模型（LLM）去生成 data_source。在 Node.js 执行 run_step 的真实逻辑时，必须拦截指令，自动从 Session 黑板中取出 ossKey，生成预签名 URL，然后强行混入 params 中，再 POST 给 R 服务。

三、对“典型调用链”的效率优化 (Fast Track Optimization)

你们在第七章设计的“典型调用链”逻辑非常严密，但在“用户目标极度明确”的情况下，显得有些啰嗦。

优化前：用户说“直接做T检验” -> method_consult -> ask_user 确认 -> analysis_plan -> run_step。
优化后 (增加 Fast Track 快速通道)：
如果意图路由器 (Intent Router) 判断用户的信心度极高且方法明确（如：“我要做 T 检验比较性别和身高的差异”），允许 LLM 跳过 method_consult 和 ask_user，直接并行调用 get_data_overview 和 analysis_plan。
这能为用户节省至少 5 秒钟的 AI 生成和等待确认时间。

四、最终执行发令

这份 V3.0 的工具体系规划，与 Q-P-E-R 四层架构、V13 动态前端原型、以及 OSS 混合协议形成了完美的完美拼图。

同意按此方案全面进入 API 封装和 Prompt 编写阶段。
请后端同学重点关注 Session Blackboard 的 Redis/DB 结构设计，这是本周最核心的基础设施。

你们正在打造一个极具壁垒的“医疗级数据分析系统”，放手去干吧！

5.5 KiB Raw Blame History Unescape Escape