【S1W3 交叉评测】对项目 Medroundtable-W3 的反馈 #5
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
交叉评测意见 - Medroundtable-W3
1. 项目理解
我理解该项目主要面向：医学科研工作者（医生、临床研究者、药企研发人员），通过多智能体协作的方式自动化产出临床试验方案、药物重定位分析、罕见病诊断路径和学术论文初稿。
项目想解决的问题是：
2. 项目亮点
真实的独立 Agent 调用架构：从 agents/orchestrator.py 和 docs/ARCHITECTURE.md 可以看出，每个 Agent 的
generate_response()都是独立调用 LLM API（DeepSeek V4 Pro / Moonshot Kimi），而非在单次 prompt 中切换角色。每个 Agent 有独立的system_prompt和expertise列表（见 agents/prompts.py），14 个 Agent 覆盖了临床主任、流行病学家、统计学家、药物基因组专家、GWAS 专家等不同专业视角。这比常见的"形式化多 Agent"方案有本质区别。完整的闭环流程设计：从问题输入 → 自动路由（medroundtable_agent.py 的
auto_detect_skill()函数按关键词匹配）→ 多阶段讨论 → 质量评估（5 维度：参与度、多样性、证据引用率、可操作性、辩论深度）→ 结构化输出，形成了清晰的产品闭环。4 个 Skill 场景的输入问题模板分别预置了 3 个子场景，内容专业度高（如 CAR-T 实体瘤 II 期试验设计中要求确定样本量、纳排标准、CRF 字段等具体产出）。证据溯源系统的设计意识：backend/citation_manager.py 和 docs/EVIDENCE_TRACING.md 设计了 PMID/DOI 标记 + 循证医学四级证据分级体系（Level I RCT → Level IV 专家共识），在输出报告末尾生成「参考文献溯源」表格。这是针对 LLM 医学幻觉问题的有针对性设计。
评测体系自洽：项目内置了完整的评测工具链，包括 skills_wave2/test_skills.py（6 个单元测试）、skills_wave2/evaluate_all.py（批量评测）、skills_wave2/ai_self_eval.py（AI 自测评按 4 维度 × 4 Skill 打分），还提供了 skills_wave2/REVIEW_RUBRIC.md 给外部评审者使用，可见团队对交付质量有自我要求。
部署与运行方式的多样性：支持 CLI 交互模式、
--demo一键演示、--question自定义问题、FastAPI Web 服务（backend/main.py）、Docker Compose（docker-compose.yml）五种运行方式，降低了评审者的体验门槛。3. 当前不足
引文数据库是硬编码的模拟数据，非实时检索：backend/citation_manager.py 中的
reference_database字典仅包含 17 篇预设的 PubMed 文献（如 UKPDS 1998、ADA 指南等），_PMID_MAP和_EVIDENCE_LEVEL_MAP都是静态映射表。这意味着无论用户输入什么临床问题，溯源系统只能匹配到这些固定的 17 篇文献，无法根据实际讨论内容动态检索真实 PubMed。团队的代码注释也承认这是"模拟文献数据库（实际应用中应连接真实数据库）"。在交叉评测中，这直接影响"循证性"评分的含金量。质量评估采用纯关键词匹配，缺乏语义理解：agents/quality_assessor.py 的
assess()方法使用硬编码关键词列表（如EVIDENCE_KEYWORDS、ACTION_KEYWORDS、DISCOURSE_DEPTH_KEYWORDS）统计出现次数来评分。例如判断"辩论深度"仅通过统计"质疑""不同意""但是""然而"等词的出现次数。这种方法无法区分 Agent 是否真的在辩论（例：Agent A 说"我同意"后 Agent B 说"但是我补充一下"也会被计为辩论），评估结果可能与实际讨论质量存在较大偏差。Docker 部署配置不完整：docker-compose.yml 中引用了
Dockerfile，但项目根目录下不存在该文件，Docker 部署实际上无法直接运行。此外 Docker compose 中硬编码了SECRET_KEY明文，存在安全隐患。各 Skill 入口代码高度重复：4 个 Skill 文件（skill_clinical_trial_design.py、skill_drug_repurposing.py、skill_rare_disease_diagnosis.py、skill_paper_coauthoring.py）的核心流程（创建 orchestrator → create_roundtable → start_discussion → 轮询完成 → 质量评估 → 保存输出）几乎完全相同，重复代码超过 60%。这不利于后续维护和新增 Skill。
前端与后端耦合松散，大量静态页面：
frontend/目录包含约 30 个独立 HTML 文件，大部分是静态演示页面，与 FastAPI 后端的实际 API（如/api/v1/roundtables）之间的数据绑定有限。例如login.html和login-v2.html两个登录页面并存，说明迭代过程中遗留了旧版本。数据库路径硬编码为 Linux-only：backend/database.py 中
RUNTIME_DATA_ROOT = Path("/tmp/medroundtable/data")是 Unix 路径，在 Windows 环境下会出错。作为声称支持跨平台的系统，这个细节处理不到位。997 项技能的数字缺乏实际支撑：README 和 API 返回中多处强调"整合 997 项技能，其中 869 项来自 OpenClaw 包装层"，但 skills/registry.py 中
TOTAL_SKILL_COUNT = 997和OPENCLAW_WRAPPED_COUNT = 869只是两个常量声明，实际的SkillPackage和Skill数据类并未填充 997 条技能实例。这些数字在评测中可能被理解为营销性描述。测试需要 API Key 才能通过：skills_wave2/test_skills.py 中的测试用例直接调用
run_xxx_skill()，这会触发真实 LLM API 调用。虽然系统有 fallback mock 机制，但测试环境如果未配置 API Key 会导致性能不稳定。没有提供pytestfixture 级别的 mock 注入方案。4. 建议补充的内容
用真实的 PubMed Entrez API 替代硬编码引文库：在
CitationManager中集成Biopython.Entrez或pubmed_parser，使find_relevant_references()能根据讨论内容的关键词动态检索 PubMed，而非只匹配 17 条固定记录。这将大幅提升循证评分的实际含金量。引入 LLM 辅助的质量评估：在
QualityAssessor的基础上，增加一个可选的 LLM-based 评估通道——将讨论消息摘要发给 LLM 做语义级评估（例如判断是否存在真实辩论、推理链是否完整），与关键词评分交叉验证。可参考 skills_wave2/ai_self_eval.py 中的自评逻辑思路。抽象公共 Skill 基类，消除重复代码：将 4 个 Skill 文件中共有的流程（orchestrator 初始化 → 讨论 → 评估 → 输出）抽取为一个
BaseSkill类或一个run_skill(orchestrator, question_config)通用函数，各 Skill 只需提供问题模板和报告生成逻辑。补充 Dockerfile：在项目根目录添加
Dockerfile，确保docker-compose up能真正运行。同时将SECRET_KEY改为通过环境变量或 secrets 文件注入。补充
skills/registry.py中声称的技能数据：如果 997 项技能确实存在（如 OpenClaw Medical Skills 包装层），应至少提供一个 JSON/YAML 技能清单文件作为佐证，否则建议在文档中明确标注为"设计容量"而非"已整合数量"，避免评审者产生误判。增加前端与后端的数据联动演示：至少让 frontend/index.html 能通过 frontend/api-config.js 连接到本地 FastAPI 后端，展示一个完整的创建圆桌会 → 实时消息流 → 查看报告的 Web 交互闭环，而不是仅停留在静态页面。
5. 综合评价
从当前材料来看，我认为该项目：
已较清楚地说明方向：项目的 README、ARCHITECTURE.md、EVIDENCE_TRACING.md 三份文档质量较高，架构图清晰，将 14 Agent × 4 Skill × 质量评估的定位传达得很明确。O（一人）→ P（问题）→ C（完整协作产出）的产品路径也表述清楚。
核心架构有实际的技术含量：14 个 Agent 独立调用 LLM API、上下文筛选注入、阶段合约驱动的讨论编排，这些在代码层面有真实实现（agents/orchestrator.py 1516 行），不是简单的 ChatGPT 套壳。
还需要补充部分实现或说明：最核心的两处短板是引文系统停留在硬编码模拟阶段、质量评估停留在关键词匹配阶段，这两点直接关系"循证性"和"辩论质量"的可信度。此外 Dockerfile 缺失、前端与后端联动不足、997 技能数据缺乏支撑等问题也需要在后续迭代中跟进。如果这些能在后续赛段中落地为真实实现，该项目的完成度将有质的飞跃。