砍掉多智能体流水线

• Suba（Subbiah Sethuraman，ZS AI 工程负责人） 与 Abhilash（Abhilash Asokan，ZS AI 工程总监） 分享。ZS 是家科技公司，服务全球顶尖企业、含大量顶尖药企；pharma（医药/制药）两大职能——R&D（研发：药物发现 + 临床试验）和 commercial（商业化：把药送到患者手里那一端）。 → 详细
• 商业化里全是分析：品牌卖得怎样、在不同市场表现如何、一线 reps（药企派去拜访医生的销售代表）触达有多有效、patient journey（患者旅程）如何、有没有发生治疗方案切换。 → 详细

• ①signal detection（信号检测）：处方由医生开出，处方量有没有下降？下降就是一个 signal。 → 详细
• ②找原因：竞品进来了？某 payer（付款方，美国医保里的保险/PBM，决定一款药报不报销、报多少）砍了报销？还是 reps 没把药的好处讲到医生那儿？ → 详细
• ③定 action + ④看 outlook：找到原因就定行动（如某区 reps 不够就加派），再看展望——销售会不会因此改善。 → 详细

• 他们为四步各建一个 agent 来"模拟"分析师：signal detection agent 负责识别信号。 → 详细
• 找根因用了两个 agent：source localization（来源定位）——全国销售下滑，到底集中在某个区域、还是某个 payer？先把问题来源定住。 → 详细
• 再接 driver attribution（驱动因素归因）agent 判断"销售为何下滑"，最后 synthesis（综合归纳）agent 据因给出 action + outlook；所有 agent 由一个 orchestrator 串联调度。 → 详细

• 系统吐出一份 information packet（信息包，给分析师的一页结论）：signal = 某区域处方量在约四周内掉了 18%；原因 = 某 payer 把这款药挪到更低的 tier（报销档位，档位越低患者自付越多），患者买这药变贵、负担不起。 → 详细
• 但它给的 action 却是"医生开得少，那就多派 reps 去找医生"，outlook 说照做销售会回升——高层扫一眼都对。 → 详细
• 细看就崩了：cause 抓对了（患者负担不起），action 却完全没落到 payer/保险这条线，只会喊"加 reps"；action 错，outlook 自然对不上。Suba 一句定性：每一步都推出了正确的事实，但"没有任何一个 agent 统筹、理解端到端整体图景"。 → 详细

• 不是 LLM（大语言模型）失败，是拆活的方式错了——他们照搬了分析师的人工分工。根因一：让语言模型去判定 signal，可"销售下滑"是统计方法就能取出的简单信息，根本不该让模型去猜。 → 详细
• 根因二：上下文在交接中层层丢失。多 agent 之间大量 context handoff（上下文交接），driver attribution 已算出对的原因，synthesis agent 却理解不了"payer 觉得贵""报销覆盖下降"这件事的分量，关键信息就这么蒸发了。 → 详细
• 根因三：所有 agent 对业务领域知识没有共同理解——都不懂 TRX 这类 metrics（业务指标）彼此什么关系、为什么涨跌。于是 Suba 把 Abhilash 叫来解决这三个问题。 → 详细

• 第一反应是回炉重设计：也许 topology（拓扑，agent 之间怎么连接的结构）错了、skills/tools 错了，或该定义更好的 handoff（交接）/schema（数据契约）。 → 详细
• 但他们退了一步、一件都没做：打开一个朴素的空目录，只给 Claude Code 一个 bash + 数据库 + 一个真实 signal，然后单纯观察它怎么干——三个问题的解法全是从这次"观察"里长出来的。 → 详细

• 观察发现 agent 看着数据自己判 signal——有时用统计、有时几乎不看就说"是 signal"，有时是真信号、有时是噪声。这正是不该交给 agent 的活。 → 详细
• 信号检测是完全确定性（deterministic，同样输入必给同样输出、不靠模型猜）的工作，于是从 agentic 系统里剥出来，用统计方法搭纯确定性 pipeline，加护栏、阈值、优先级——全部在 agent 启动之前跑完。 → 详细
• 自动 pipeline 扫数据、为每个 KPI（关键绩效指标）找异常/趋势，识别出 signal 就丢进 queue（队列）；signal 一进队列，agent 才被唤醒。agent 的职责是"调查"，不是"识别"。 → 详细

• 针对"输出不连贯"，他们开始整合。看 Claude Code 怎么运作：它反复"写个函数→查数据库"，那就给它一个专门干这事的工具，把整个流程收进单个 agent。 → 详细
• 收成单 agent 不等于放弃并行——parallelism（并行）照做；去掉的是 distributed reasoning（分布式推理，把判断分散到多个 agent 各做一块）。判断权必须集中在一个 agent。 → 详细
• 又观察到 Claude Code 会为某个很聚焦的任务动态启动 sub-agent（子 agent），于是照做：想查"某区域 rep 活动"就派个 sub-agent 去调查、拿结果回来——但推理/判断仍归主 agent，只把"调查"这一段外包。这套比最初轻得多，但仍没解决问题，所以图里还要一个知识图谱。 → 详细

• 这套轻架构仍缺 business context（业务上下文）：不懂实体、领域、KPI 怎么关联。agent 靠看表推关系既不可扩展，还常"推断出数据里根本不存在的关系"。 → 详细
• 他们深耕这行多年、手里有懂 pharma 的领域专家，坐下来一起把领域画成 knowledge graph（知识图谱）：地理实体、payer、account、brand、KPI，以及"地理→payer→brand→KPI→二级/三级 KPI、一个 KPI 如何驱动另一个"这些关系。 → 详细
• 关键定性：知识图谱不是 agent 查数据的 lookup（查询层），而是它的 control plane（控制平面——借自网络工程，指决定"能往哪走"的那层，区别于只负责取数的数据层）——它规定 agent 能看什么、能走哪些路径、能验证哪些调查假设。 → 详细

• 先"where"后"why"：如 TRX 全国下滑，先做 source localization 定位到 territory（辖区）/payer/account 的某种组合（维度多、全是排列组合，靠图引路）；定住 where 再查 why——哪个 KPI 在驱动，graph 在这充当 control surface（控制面）。 → 详细
• 对 agent 而言 graph 每条 edge（边，连接两个节点的关系）就是一个 hypothesis（假设），只在图内验证、不越界。loop（循环）：从一个 entity（实体）出发→看邻居节点→取边当假设→回原始数据看真实数字→推理→证据支持就沿图继续遍历、矛盾就换，直到假设穷尽或找到 root cause（根因）。 → 详细

• ①别把人为/设计约束塞进架构，让架构自然被"推导"出来（业务上有 N 种分析师角色 ≠ 就该建 N 个 agent）。 → 详细
• ②复杂工作流都有"确定性部分"和"agentic 部分"，别让 agent 去跑确定性部分，必须拆开。 → 详细
• ③必须有一个 agent 端到端掌控 reasoning（推理），它可自行决定调用 sub-agent/tool/skill 去派活，但判断权归它一个。 → 详细
• ④（可能最重要）graph 不能只当 lookup layer（查询层），必须当 control plane，让 agent 用它导航、决定下一步。 → 详细

本场为纯复盘/演示式分享，无闪电问答（lightning round）环节。收尾即上文主题 12 的「四条 takeaway」，此处不重复。 → 详细

无——分享中未提供两位讲者的联系方式，仅提及所属公司 ZS Associates 及各自职务（Suba：AI 工程负责人；Abhilash：AI 工程总监）。