从医疗视角重读 Anthropic 智能体设计模式：可验证性才是落地的关键

Anthropic 发布《Building Effective AI Agents》指南后，开发者社区掀起了对智能体设计模式的讨论热潮。最近一位曾在医疗 AI 领域做过实际部署的工程师撰文，从医疗场景出发重新审视这套模式，并提出「可验证性」才是决定智能体能否落地的核心标尺。

Anthropic 在指南中将常见智能体工程模式归纳为五类：

Prompt chaining（提示链）：将任务拆成顺序执行的步骤，每步只做一件事。例如把问诊录音转写后，再分阶段结构化为 SOAP 病历；又如将临床试验入选标准分阶段剥离术语，向患者输出通俗说明。
Routing（路由）：按问题性质分发到不同处理路径。例如把「我的预约几点？」分流到数据查询工具，把一般健康问题交给大模型，把模糊或高风险问题转人工。路由本身就是一种安全机制。
Parallelization（并行化）：同时触发多个子任务。例如生成 FHIR 资源时，并行校验结构、编码、字段值，再汇总返回。
Orchestrator-workers（编排者-工作者）：由编排者调度多个工作者并行拉取各系统数据，再合并为统一视图，适用于跨院区病历合并。
Evaluator-optimizers（评估者-优化者）：生成器产出内容，评估者打分并反馈，循环迭代直到达标。

作者在逐一映射时发现，越往后的模式越像「加了步骤的路由」，并不容易找到对应用例。最终他意识到，更合理的视角是把这五种模式看作一条由简到繁的能力阶梯，随需求增长逐级引入，而非每种模式都必须塞进独立用例。

在医疗领域真正能跑通的是两类任务：

临床文档生成：问诊转写 → 结构化 → 校验，链路短、步骤清晰。
去标识化与临床编码：生成器产出脱敏后的病历或 ICD 编码，评估者扫描是否仍残留姓名、MRN、异常日期等 PHI，并反馈给生成器迭代。这类问题有近乎二元的质量标准，LLM 可自评反馈，每一轮都能可验证地改进。一旦评估需要临床判断（「这是否安全？」），循环就必须打开给人类。

作者反复回到一个核心问题——哪些医疗问题真的可以验证？他引用 Dario Amodei 在 Code with Claude 大会上的观点：编码之所以成为智能体的首个滩头阵地，正因为它是可验证的；下一个前沿是让更多领域变得可验证。

由此他重新审视 FHIR：FHIR 是结构化、标准化的 JSON，本身具备可验证性；只要问题落在 FHIR 这类结构之上，相应任务也就变得可验证。他由此区分了医疗智能体的两个光谱端：

临床决策类智能体：动作空间开放、关乎患者健康，永远需要人在回路中，「可验证」无法完全自动化。
医疗数据调和类智能体：当数据已是 FHIR 这类标准化格式时，可以接近完全自主。这超越 orchestrator-workers 模式的关键差异在于自主性：workflow 有边界、任务收束即结束，真正的 agent 是在边界模糊时接管。

贯穿全文的是一条原则——医疗 AI 不是铁板一块，存在一个从低风险、可自验证到高风险、需临床判断的光谱。Evaluator-optimizer 恰好落在光谱的低风险端；一旦评估超出 LLM 自身能力，循环就必须打开给人类。

作者把智能体系统第一原则概括为「简单优于复杂，透明优于抽象」。智能体本质上只是带工具、记忆与检索的大模型在环境中自由行动；工程上的功力在于克制——为用例量身定制而不过度设计，并把工具清晰地文档化。把 LLM 比作「初级开发者」，是一种贴切且迷人的视角。