我亲手关掉的智能体比留下的还多。分享一下它们消亡的模式和原因。

过去6个月里，我大约尝试部署了30个不同的智能体。其中8个仍在运行。另外22个在第一周或第二周就挂了，原因翻来覆去就那么几个。分享一下我反复观察到的五个典型死因，希望能帮大家少踩同样的坑。 **一个智能体承担太多任务** 每个号称“全能接单”的智能体我都死得很快。一旦你让一个智能体同时处理邮件分类、草拟回复、安排会议和记录工单，边缘情况就会几何级增加。单独做每个任务都没问题，但组合在一起就炸了。 替代方案：一个智能体只干一件事。五个小智能体各司其职，比一个试图包揽五件事的巨型智能体可靠得多。听起来无聊，但这是事实。 **破坏性操作缺少人工审核** 凡是涉及发送、发布、扣费或删除的操作——如果你让智能体不经审批直接执行，迟早会因为一次失误付出比省下的成本更高的代价。我有次因一个收件箱智能体把半成品草稿直接发给了真实客户，尴尬至极。 现在：先起草稿，放入队列，在Slack里给我发审批按钮，点一下就好。延迟可以接受，但公开出丑不能接受。 **LLM输出非结构化** 如果你让模型返回纯文本，然后用正则或字符串匹配来解析，差不多每五次就会有一次因模型表述稍有不同而解析失败。强制使用结构化JSON，消费前验证schema。如果解析失败，重试一次，然后大声报错（通过Slack告警，不要默默忽略）。听起来很基础，但我回顾每一个死掉的智能体时，发现几乎都跳过了这一步。 **没有费用上限** 半年内我遇到过两次智能体因bug陷入轮询循环，一晚吃掉200多美元的API费用。现在每个智能体都设了月度硬性上限。一旦超限，智能体暂停并给我发Slack消息。花90秒设置，能省下几百美元。如果你在用Anthropic或OpenAI，它们都有针对密钥的内置费用限制，用起来。 **智能体不知道何时自己错了** 那些自信地胡编乱造的智能体，比说“我不确定，请升级”的智能体更糟糕。最终存活下来的智能体都在提示词里明确设定了不确定性路径：“如果没有足够信息可以自信回答，请输出{escalate: true, reason: '...'}。”而那些死掉的智能体则连续几天自信满满地犯错，直到我注意到。 这五个模式的共同点：智能体不会大声报错。它们不会崩溃。它们只是慢慢地产生错误输出，直到你在下游发现问题。大声报错容易处理，静默失败才会让你阵亡。 目前我在让智能体无人值守前会检查这五点： - 是否只承担一个任务？ - 破坏性操作是否有审批队列？ - 输出是否是结构化数据并经过验证？ - 是否有硬性费用上限并设置告警？ - 是否有明确的“不知道就升级”路径？ 如果满足全部五点，它通常能撑过第一个月。任何一点缺失，我基本能预测它会在第几周挂掉。 另外我不再尝试做的事：为频率低于每周一次的任务构建智能体。低频任务的维护成本几乎总是超过节省的时间。智能体最适合高频重复的模式。 好奇你们遇到过的智能体死因是哪些？跟我的模式一样，还是有所不同？