M6第 3 课 · 医疗机构研究M6-L3.2M6-L3.3

Technical Design：医疗机构研究

一句话： 一份”agent 规划、代码构建”的数据产品参考设计：模型决定数据源、代码集和质疑意见，确定性流水线在会让构建失败的断言之下完成每一次下载、关联和计数，两道人工 gate 分别卡在高成本和高风险的步骤前，合规是一个无法绕过的函数。

教学参考。 这份设计遵循 handbook 的九节骨架，大部分内容来自 Provider Research 仓库中的方法论文档，并满足 Provider Research PRD。第 9 节说明当前构建与它的关系。

1. 设计原则

编排用确定性代码，模型只用于判断。 模型只用在正确答案取决于推理的地方：找数据源、解析代码集、攻击结果、解释结果。所有搬运和计算数据的工作都是可以用断言约束的脚本。

2. 架构与所有权

查询 ──► Research Lead ──► 第 1 层：Source Scout ×n · Taxonomy Specialist（表头核对由代码完成）
                                 │
                            GATE R（人工）：数据源、代码集、大小、预算
                                 ▼
             第 2 层下载 ─► 第 3 层筛选 → 补充 → 标准化（确定性）
                                 ▼
             第 4 层 QA：确定性检查 → 对抗视角 → 复核者
                                 ▼
             第 5 层打包 → 文档 → 输出校验
                                 │
                            GATE D（人工）：交付物
                                 ▼
             已交付 ─► 下游模块经由合规 gate 读取营销视图

五个角色及各自负责的判断：

角色	判断
Research Lead	下一步做什么；什么时候停下来问人
Source Scout	哪些来源是权威的、里面真正有什么
Taxonomy Specialist	哪些代码定义这个群体
Challenger	结果哪里不对
Documentation Writer	怎样解释结果

各组件及其负责的内容：

组件	负责
Research Lead	状态机、派生子 agent、运行脚本、在 gate 处停下；唯一和人对话的 agent
Source Scout 与 Taxonomy Specialist	带真实列名的数据源清单；带理由的代码集
流水线	下载、流式筛选、关联、标准化、打包；每一个数字
断言	九条会让构建失败的条件
Manifest	一次运行的身份，与上一次运行对比
Challenger	七个视角、每条问题三个复核者、一个盲审 critic；每条问题附可复现步骤
合规 gate	一个函数，每个渠道一个结论，无法绕过
营销视图	数据集的投影，受限字段在结构上就不存在；下游模块的接口

3. 信任边界与 gate

GATE R 在任何大文件下载之前： 人批准数据源、大小、带理由的代码集和磁盘预算。错误的数据源在这里被发现只需一次审阅，之后发现则赔上整次运行。
GATE D 在交付之前： 人批准交付物。批准作为带姓名和时间的数据存储。
构造上的盲审 critic： ontology critic 由 QA 一方委派，通过白名单只拿到专科名称和词表引用，并在代码集发布到任何它可能读到的地方之前运行。
合规是一个函数： 每个渠道决策都调用它；未知渠道一律阻止；没有强制开关。受限联系字段在营销视图中根本不存在，而不是被过滤。
系统中任何地方都没有发送路径； 构建发送路径是另一个决定，且必须先有 gate。

4. 状态与数据

运行状态只向前推进：proposed、research、manifest-approved、fetching、filtering、qa、packaging、dataset-approved、delivered。转换由一个命令完成，它检查前置条件，并拒绝在 spec 已被更早阶段读取后又被修改的情况下运行某个阶段。
阶段之间的类型化契约： 数据源清单、来源结构、代码集、筛选结果、带匹配率和声明最低值的补充结果、带复现步骤的 QA 问题、构建 manifest。
溯源： 每个输入都有版本、大小和哈希；构建 manifest 记录它们；从已提交的输入重建，结果逐字节相同。
提交什么： 冻结的 spec、已批准的数据源、manifest 和每一条 QA 问题。数据文件可复现，从不提交。

5. 独立检查

七个视角问不同的问题（结构、覆盖、完整性、跨来源总数、真实抽样、状态剔除、本体重推导）；相同的检查器找到的问题比多样的检查器少。
每条问题都附可复现步骤；每条交给三个被要求推翻它的复核者，至少两个确认才成立；不确定的问题被放弃。
连续两轮无问题后循环结束，且受每次运行的轮数和模型调用预算约束。
QA 小组不修复任何东西；修复是流水线或 spec 的改动，下一次运行会继承。

6. 失败处理与幂等

失败	行为
断言触发	构建停止；在上游修复原因；绝不放宽阈值让它通过
关联什么都匹配不上	视为 bug（有声明的最低匹配率），而不是结果
数据源结构变了	任何匹配率相对下降 20%，manifest 对比就报警
下载中断	下载可续传；重跑不会重新下载或解压已完成的部分
构建中途修改 spec	后续阶段拒绝运行，直到更早的阶段重跑
QA 循环不收敛	预算用完；运行停止，问题交到 gate

7. 评测与测试

合成测试用已知答案的小型注册库文件，让每条断言和检查都能在不下载的情况下运行。
故意破坏： 逐一破坏每条断言，证明它会中止构建。
埋入缺陷的数据集，QA 小组必须用可复现的证据找到；没有证据的问题必须被放弃。
可复现性： 重建一次已提交的运行，得到相同的文件。
manifest 对比： 同一 spec 两次运行之间的差异在交付时一并审阅。

8. 运维

用配置实现隔离： 每个业务一个仓库、一个 agent space、一个会话根目录；就绪检查核实 space 成员关系，并确认运行时 profile 与 brief 一致。
成本与额度： 下载是最长的一步，在后台运行；QA 轮数和复核者扇出有上限；大模型档位留给判断类角色。
可观测性： 每个阶段写出自己的契约文件；每轮 QA 都保留，包括被推翻的问题，作为检查确实运行过的证据；汇报的是数量和匹配率，从不用形容词。
推广： 换目标只改专科和代码集；美国以外的工作换的是数据源，不是架构。

9. 当前构建

当前构建用自己的角色名（Orchestrator、Source Discovery、Ontology、QA Panel、Documentation）实现了这份设计的大部分：带断言和阶段驱动器的确定性流水线、manifest 对比、带”三个复核者两个确认”规则的七视角 QA、合规函数和剥离了字段的营销视图，以及三个已交付的数据集。它与参考设计有三处不同：它运行七个 agent，多出一个单独做表头核对的 Schema Probe，以及一个在同一系统内做分群、排序和内容简报的 Marketing agent；它的运行状态机写在 orchestrator 的 brief 里而不是在命令中；隔离靠规则而不是启动检查。第 2、4、8 节描述的正是补上这些缺口的设计，营销模块作为下游产品的位置见迁移。

典型面试题

为什么用白名单限制 critic 的输入，而不是告诉它不要读答案？

因为黑名单必须预见答案可能泄漏的每一条渠道，而泄漏的总是没人列出来的那一条。白名单只给 critic 两个输入，别的什么都没有，也就不存在”它可能看到了什么”的问题。

"bug 在断言的上游"在实践中是什么意思？

意思是构建失败时，修复方式永远不是放宽检查。匹配率断言失败，意味着数据源变了、声明写错了，或者下载被截断了。团队要找出是哪一种，修好它，再重跑这个阶段。