drizzle digest
⌕ ESC
↑↓ 选择↵ 打开esc 关闭⌘K 唤起
← 主页 NO.91
专栏 · Agent 工程手艺 ›
第 91 期 · AGENT 工程 · 收录于 2026 年 8 月 16 日

我们为什么砍掉了自己的多 agent 流水线——ZS Associates

SS
Subbiah Sethuraman · AI Engineer
Agent 工程
视频 15:00 原文约 1.5 万字 预计阅读 10 分钟 来源视频 ↗ 中英对照全文
原平台热度 YouTube ↗
2.9万观看
535赞
1.8%点赞率
45评论
62.7万频道订阅
数据截至 8 月 27 日
双人对谈 · 本期速读电台 00:00 / 11:02
TL;DR · 三句话
  1. 一ZS 把药企分析师"信号检测→找原因→定行动→看展望"四步各拆成一个 agent、再用一个 orchestrator（编排器，把多个 agent 串起来调度的总控）连起来，系统给的结论却"对因错药"——每一步事实都对，却没有任何一个 agent 统筹端到端全局。 → 详细
  2. 二三个根因：让大模型去做"统计方法就能搞定"的信号检测、多 agent 交接时上下文层层丢失、所有 agent 都不懂 TRX（处方总量）这类业务指标之间的关系。 → 详细
  3. 三解法不是回炉重设计，而是打开一个空目录、只给 Claude Code 一个 bash 加数据库看它怎么做，据此重建为"确定性信号 pipeline + 一个统筹推理的单 agent（按需派子 agent 去调查）+ 当控制平面用的知识图谱"，把分析师三四周的活压到 20–30 分钟。 → 详细
01

背景：ZS 是谁、pharma 商业化为什么全是分析活

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

分析师的四步工作法（后面被照搬成架构）

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

原始方案：每步各配一个 agent，再用 orchestrator 串起来（益项·写厚）

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

系统产出：一份"对因错药"的 information packet（益项·写厚，保留原数字）

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

三个根因：不是模型不行，是活拆错了（益项·写厚）

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

关键方法论：先别回炉重设计，去"看 Claude Code 怎么做"（益项·写厚）

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

修复一：把信号检测剥成确定性 pipeline（益项·写厚）

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

修复二：把判断收进一个 agent，只有调查才外包给 sub-agent（益项·写厚）

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

修复三：知识图谱不是查询层，是 control plane（益项·写厚）

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

agent 的调查循环：每条边就是一个假设

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

成果

  • 一轮 50+ turns（回合）、烧一大堆 token，把分析师原本要三四周的活压缩到约 20–30 分钟。 → 详细
12

四条 takeaway（益项·写厚，可迁移的元教训）

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

闪电问答 / 收尾

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

14

联系方式

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

接着读
NO.90 · 产品 AI 时代 Netflix 为什么押注系统思考者而不是专才——Elizabeth Stone(CPTO) Elizabeth Stone · 33 分钟 NO.89 · Agent 工程 我如何用 Claude Code 在 40 分钟里规划、构建、运行循环——Thariq Shihipar Thariq Shihipar · 30 分钟