恶劣天气助手 Stormwise 的作者在一篇技术博文中，梳理了多智能体系统的三种常见模式，并结合自己基于 Claude 开发的项目复盘故障。其自测显示，缺少官方警报数据时，助手可能在有效预警期间告诉用户天气平静；补充提示词也未能解决这一问题。这份实践记录关注的不只是智能体如何分工，还有交接数据、评测和预算如何影响结果。
作者称，自己开发的大多数 AI agent 都是单智能体。例如，晚餐推荐助手只用了一个模型，配合定位、天气、餐馆搜索三个工具，并设置步数上限，就能完成任务。他认为，将其拆成多个智能体只会增加延迟和成本。
文章建议，当不同部分需要明显不同的指令或工具、可以并行执行，或需要独立测试时，再考虑拆分。三种模式各有适用条件：
Stormwise 的核心是一条两阶段流水线：先获取官方警报，再让模型据此回答。作者用基于美国国家气象局真实警报构建的 117 个案例进行评测。
据作者自测，在无法访问警报数据的条件下，助手在 69 个案例中的 26 个里，于有效预警期间声称天气平静，占 38%；增加「承认无法查看官方警报」的指令后，这一数字升至 31 个，占 45%。使用真实警报数据和普通提示词时，此类错误为零。
数据接入本身也会出错。作者的流水线曾将气象部门发布的测试警报当作真实预警，模型随后据此作答。他因此建议，在每次交接时用普通代码检查数据格式、时效性和合理性。
作者最初用模式匹配脚本检测「虚假安抚」，却漏掉了 57 个真实案例中的 53 个，还得出了相反结论。最终，他手工阅读并标注了全部 342 条回复。
预算同样存在边界：日常问题够用的 token 预算，在复杂案例上可能不足。作者建议为每个请求统一追踪预算，预先确定耗尽时的简短、安全回退答案，同时限制任务跳转次数、记录智能体之间的全部消息，并用真实案例测试、人工抽查自动评分。
步数限制也不等于成本可承受。作者称，晚餐助手从第一天起就设有步数上限，从未失控，但最终仍因 API 账单超过业余项目可承担的范围而下线。
