当11/11病例仍不够：用FalkorDB构建疫情调查智能体

11人患病，2种食材在全部11例病例中出现，2家供应商难分伯仲。病例数缩小了搜索范围，却无法告诉我们哪个批次是元凶。要打破平局，需要独立于暴露计数的证据，以及一条能清晰展示调查如何得出结论的路径。这正是 BatchZero 项目的挑战——一个为 FalkorDB 赛道打造的 Graph Hacks 2026 项目。

疫情与 Port Meridian 均为虚构。 BatchZero 使用合成数据演示调查工作流，并非真实公共卫生系统。

为什么用图来表示疫情调查？

流调本质上是在追踪关系链：Person → Case → Exposure → Menu item → Ingredient → Lot → Supplier → Shipment。我们不仅要问“这些病例有什么共同点？”，还要问“哪些设施使用了该食材？它们收到了哪些批次？这些批次流向了哪里？最终锁定来源的证据是什么？”

图数据库让我们能直接沿着连接路径追踪。在 BatchZero 中，病例与供应链数据、假设、证据、智能体会话和工具调用记录都存储在 FalkorDB 里。例如，共享食材查询从病例出发，穿过患者和暴露事件，到达菜单项和食材：

MATCH (c:Case)<-[:HAS_CASE]-(p:Person)-[:PARTICIPATED]->(e:ExposureEvent)
      -[:INVOLVES]->(m:MenuItem)-[:CONTAINS]->(i:Ingredient)
WHERE c.case_id IN $case_ids
RETURN i.name AS ingredient,
       count(DISTINCT c) AS cases
ORDER BY cases DESC, ingredient

这个遍历给出了共享暴露的图景，但并不能证明哪种食材导致了疫情。

Cypher 是 Neo4j 提出的属性图查询语言，FalkorDB 也兼容其核心语法。它用 ASCII 艺术风格的模式匹配来表达图遍历：(a)-[:REL]->(b) 表示节点 a 经 REL 关系指向节点 b。文章示例中的 MATCH ... WHERE ... RETURN ... ORDER BY 与 SQL 的对应子句语义相近，但匹配对象是路径而非表连接。Cypher 的 count(DISTINCT c) 用于对病例去重计数，避免同一病例经多条路径重复计入。变量绑定（如 c、p、e）使一条模式可同时约束多个节点与关系，因此能用简短语句表达多跳供应链追踪。对于流调场景，这意味着“从病例回溯到供应商”只需一条可读的路径模式，而无需手写多表 JOIN。

计数无法打破的平局

在合成案例中，两种食材出现在所有11例病例中，两家供应商并列。仅基于暴露频率的排名无法在两者之间做出选择。

下一步是寻找独立证据。BatchZero 将分离株和基因组匹配建模为图节点和关系。患者分离株与批次 MG-4417 相关的环境分离株匹配，SNP差异不超过2个。而竞争的生菜批次 LET-2210 在场景中没有匹配的分离株。

这一证据改变了调查方向：MG-4417 成为主要来源假设，竞争假设被否定。演示的关键不只是答案，更是从证据到答案的路径。

SNP（单核苷酸多态性）差异 是基因组流行病学中判断菌株亲缘关系的常用指标：对分离株全基因组测序后比对，统计两者之间单个碱基不同的位点数量。差异越小，说明共享最近共同祖先的时间越近，流行病学关联越强。公共卫生实践常设定阈值（如暴发调查中 ≤2 或 ≤5 个 SNP）来判定“匹配”，但阈值取决于病原体突变速率、测序质量和传播链长度，并非普适常数。文章用“SNP 差异不超过 2 个”把环境分离株与批次 MG-4417 关联起来，正是用独立于暴露计数的分子证据打破供应商平局。需要注意，SNP 匹配支持关联但不单独证明因果，仍需与时间、地点和供应链证据联合解释。

看似合理的记录也可能是错误的

我们还设置了一个时间陷阱：一条暴露记录的日期晚于患者症状发作时间。如果智能体将每条检索到的记录都视为有效，这顿饭就会成为误导性线索。

BatchZero 会检查暴露日期与病例发病时间及病原体潜伏窗口的关系。超出窗口的记录被排除在有效暴露集之外，而不是作为来源证据。这体现了我们想探索的区别：检索可以找到记录，但调查必须判断该记录是否合理。

四个智能体，各司其职

BatchZero 将工作流建模为四个角色：

1. Intake Officer：构建初始病例档案。
2. Cluster Analyst：比较病例并发展候选假设。
3. Supply Chain Tracer：追踪食材、批次、供应商和运输。
4. Briefing Officer：准备发现和响应行动。

每个角色使用独立的 MCP 服务器子进程，拥有自己的工具集。能力设计有助于强制流程顺序：例如，Cluster Analyst 无法起草召回，因为该操作未暴露在其工具界面中。我们使用 MCP 让可用操作成为运行时设置的一部分，而不仅仅依赖提示中的指令。

MCP（Model Context Protocol） 是 Anthropic 提出并于 2024 年底开源的协议，用于让 LLM 应用以标准化方式连接外部工具和数据源。其架构包含宿主应用、MCP 客户端与 MCP 服务器；服务器通过 JSON-RPC 暴露三类能力：tools（可调用函数）、resources（可读取数据）和 prompts（预置提示模板）。BatchZero 为每个角色启动独立的 MCP 服务器子进程，意味着各角色的工具清单在协议层就是隔离的——某个角色未获授权的操作不会出现在其工具列表中，模型即使被提示诱导也无从调用。这比单纯在系统提示中写“不要执行某操作”更可靠，因为约束发生在运行时能力边界而非语言指令层面。

保留推理过程，而不仅是答案

当结论可以追溯到证据时，审查会容易得多。BatchZero 在图中记录工具调用和会话，证据链接回产生它的工具调用。这形成了一条路径：Hypothesis → Evidence → ToolCall → Session。图还存储智能体记忆，包括调查假设和提炼的事实。这意味着系统既能表示疫情本身，也能表示调查过程中构建的推理。

智能体记忆（agent memory） 指智能体在会话之间持久保存并可检索的状态，通常分为短期（当前上下文窗口内的对话）与长期（写入外部存储、跨会话复用）两类。常见实现包括向量检索的记忆库、结构化数据库中的事实表，或知识图谱中的实体与关系。BatchZero 将调查假设和提炼后的事实作为图节点存储，使记忆本身可被图遍历查询，并与证据、工具调用相连。相比纯文本记忆，图结构记忆的优势在于能表达“某事实由哪次工具调用产生、支持哪个假设”这类溯源关系，从而让智能体的推理过程可审计、可在后续会话中重建，而不是只留下最终答案。

让演示可复现

现场演示可能因普通原因失败：缺少 API 密钥、网络故障或模型速率限制。BatchZero 保持智能体接口可替换。有 Groq API 密钥时，Groq 可以驱动工具循环；没有时，确定性回放会针对 FalkorDB 执行相同的工作流。仓库记录了一个基准命令，运行回放三次：

python -m batchzero.demo.replay --benchmark 3

项目报告在三次基准运行中均正确识别了来源。演示和实现可在 BatchZero 仓库 获取，演练视频 展示了调查在 UI 中的运行。

我们学到了什么

几个教训尤为突出：

• 建模驱动决策的关系。 图的有用之处不在于图表形状，而在于能够将暴露、供应和基因组关系作为调查的一部分进行遍历。
• 将计数视为起点。 共享暴露缩小了候选范围，但需要独立证据来打破平局。
• 在推理前验证记录。 记录可能存在，但仍落在相关时间窗口之外。
• 让溯源贴近结论。 将证据链接到产生它的工具调用，使结果更容易重建。
• 用能力强化流程。 角色限定的工具使某些无效操作在特定阶段对智能体不可用。

这个合成场景的来源是批次 MG-4417。图不仅帮助我们解释哪个假设胜出，还解释了支持它的证据以及调查如何到达那里。如果你构建的系统需要跨许多连接实体追踪证据来做出决策，我们很想知道哪些表示和审计轨迹对你有效。