一、制药分析师的四步法
ZS Associates 服务于全球大部分头部制药公司。制药行业有两大功能：研发（药物发现和临床试验）和商业化（把药送到患者手里）。商业化领域产生大量分析工作——品牌表现、销售代表效率、患者用药路径、竞品动态，全都需要数据驱动的判断。
一个分析师日常做的事可以归结为四个问题，按顺序回答：
- Signal — 信号检测：变化是真实的吗？（比如：处方量下降了 18%）
- Why — 归因分析：什么导致了这个变化？（竞品？保险覆盖？销售代表活跃度？）
- Action — 行动建议：我们该做什么？
- Outlook — 前瞻展望：如果执行这个行动，接下来会怎样？
二、V1：每一步一个 Agent
ZS 团队的第一反应是：既然分析师分四步做，那就给每一步造一个 Agent。
- Signal Detection Agent — 发现 KPI 异常信号
- Source Localization Agent — 定位信号发生在哪个层级（全国？区域？某个 Territory？某个 Payer？）
- Driver Attribution Agent — 找出根因
- Synthesis Agent — 汇总结论，给出行动建议和前瞻
上面再加一个 Orchestrator 把这四个 Agent 串起来。
三、输出看似正确，实则不连贯
系统生成了一份看起来完整的分析报告：
- Signal：Brand A 在 Territory X 的新处方量四周内下降了 18%
- Why：Payer Y 把这款药调到了更差的保险覆盖层级，患者自付费用增加，很多人到了药房柜台就放弃了
- Action：派更多销售代表去 Territory X 拜访医生，推动处方量回升
- Outlook：品牌整体前景健康
问题在哪？原因找对了——保险公司把药调到了更差的层级，患者负担不起。但行动建议完全牛头不对马嘴——去派更多销售代表拜访医生。这是一个保险覆盖问题，靠多派 rep 解决不了。因为行动错了，前瞻自然也不靠谱。
每一层都推导出了正确的事实，但没有任何一个 Agent 理解端到端的全貌。
四、三个致命问题
Subbiah 的总结很直接：不是模型失败了，是我们分工的方式失败了。
1. 用语言模型做信号检测
我们让一个 LLM 来判断 18% 的波动是真实信号还是正常噪音——这是统计学该回答的问题，不是模型。
信号检测 Agent 有时候跑了一些统计方法，有时候只看了一眼数据就宣布"这是信号"。有时候确实是信号，有时候只是噪音。这件事本来就不该交给 Agent 做。
2. 每次交接都丢失上下文
每个 Agent 传递的是自己的结论，不是推理过程。解释下降原因的那条关键线索，始终没有到达写行动建议的那个 Agent。
Driver Attribution Agent 正确识别了保险覆盖变化是根因，但它只把"结论"传给了 Synthesis Agent——后者不理解为什么保险覆盖比销售代表更重要，于是给出了一个跟原因不匹配的行动建议。
3. 没有共享的业务领域理解
每个 Agent 都从原始表格自行推断制药指标之间的关系。没有任何东西告诉它们：什么真正驱动处方量？TRx（处方总量）跟 NRx（新处方量）是什么关系？保险覆盖层级如何影响患者行为？这些领域知识完全缺失。
五、停止设计，开始推导架构
团队的第一反应是回到白板重新设计——也许拓扑不对，也许需要更好的交接 schema，也许 Skill 划分有问题。
但他们退了一步，做了一件不同的事。
我们打开了一个空目录，启动 Claude Code，只给它 Bash 和数据库，再给它一个真实的 KPI 下降信号。然后我们观察。
Agent 碰了什么，我们从 trace 里推导。数学该住在哪里，我们提前决定。
通过观察 Claude Code 在空白环境中如何处理同一个分析任务，他们为前面三个问题分别找到了修复方案。
六、Fix 1：统计做信号，Agent 做解释
第一个修复：把信号检测完全从 agentic 系统中拆出来，变成一个纯确定性管线。
这个管线用统计方法扫描数据、检测异常、设置阈值、做优先级排序——全部在 Agent 启动之前完成。检测到的信号放到队列里，Agent 从队列接到信号后才醒来。Agent 的职责是调查和解释，不是判断信号是否存在。
语言模型是推理引擎，不是统计引擎。
七、Fix 2：单 Agent 拥有推理权，子 Agent 只做调查
第二个修复来自观察 Claude Code 的行为模式：它自己就能处理大量操作——反复写函数、查数据库。团队据此把整个流程整合到一个 Analyst Agent 中。
我们没有取消并行——取消的是分布式推理。判断权集中在一个 Agent，调查任务可以委派。
关键区分：
| V1（砍掉前） | V2（重建后） | |
|---|---|---|
| Agent 数量 | 4 个专职 + Orchestrator | 1 个主 Agent + 按需子 Agent |
| 推理权 | 分散在每个 Agent | 集中在 Analyst Agent |
| 子 Agent 职责 | 各自做判断 | 只做调查，返回结果 |
| 上下文 | 每次交接丢失 | 主 Agent 全程持有 |
子 Agent 只在需要聚焦调查时才启动——比如"验证一下这个区域的销售代表活跃度是否真的下降了？"子 Agent 返回的是调查结果，不是推理判断。判断权始终在主 Agent 手里。
八、Fix 3：知识图谱作为控制平面
架构简化了，但业务领域知识的缺失仍然没解决。Agent 还是在看原始表格，自己推断指标之间的关系——这不可扩展，经常产出数据中并不存在的因果关系。
ZS 有大量制药领域专家，他们多年来为客户做商业分析。团队找到这些专家，开始构建一个制药知识图谱。
图谱映射了所有实体和关系：
- 地理层级：National → Region → Territory → Account → HCP
- 业务实体：Brand、Payer、Coverage Tier
- KPI 关系：NRx（新处方量）受哪些因素影响？Coverage Tier 下降 → Patient Cost 上升 → Abandoned Fills 增加 → NRx 下降
- 方向性：每条边标注了影响方向（raises / suppresses / + small）
但关键不是图谱本身——而是图谱在系统中扮演的角色。
图谱不只是增加了上下文。它结构化了整个调查过程。
知识图谱不是一个查找层（"这个指标的定义是什么？"），而是一个控制平面——它规定了 Agent 可以看什么、可以走哪条路径、可以评估哪些假设。
具体机制：
- WHERE Protocol（定位信号集中在哪里）：按贡献度对子节点排序，返回 top_n = 5，如果是系统性的（非集中的）就停止
- WHY Protocol（找出原因）：沿驱动因子 KPI 遍历，max_depth = 6，环路保护，对每个假设做 SUPPORTS / CONTRADICTS 分类——基于确定性证据检查，不是即兴推测
每一条边都是一个假设，数据仍然需要验证它——不是因果的证明。
Agent 的工作循环：从一个实体开始 → 查看图谱中的邻域 → 从边获取假设 → 回到原始数据验证假设 → 推理判断 → 如果假设成立就继续遍历图谱。如此循环，直到所有假设都被穷尽，或者找到根因。
九、结果与四条关键收获
重建后的系统，经过 50 多个 turn、大量 token 消耗后，能够生成一份分析师过去需要三到四周才能完成的分析报告——现在只要 20 到 30 分钟。
- 架构应该被推导，不是被设计 — 不要把人类的工作分工强加给 Agent 系统。观察 Agent 自己会怎么做，再从 trace 中提炼架构。
- 分离确定性部分和 agentic 部分 — 统计检验、阈值判断、数据清洗这些事不需要 LLM。让确定性管线先跑完，Agent 只处理需要推理的部分。
- 一个 Agent 端到端拥有推理权 — 子 Agent 可以做调查，但判断权不能分散。分布式推理是这类系统最大的陷阱。
- 把图谱当控制平面，不是查找层 — 图谱不只提供上下文信息，它规定 Agent 的调查边界和假设空间。每条边都是一个待验证的假设，不是已确认的因果。
一个制药分析系统的架构演进：从"模仿人类分工"到"让 Agent 自己告诉你分工该怎么做"。关键不是更多 Agent，而是更清晰的边界——哪些是确定性的、哪些需要推理、谁拥有判断权、什么约束 Agent 的搜索空间。