让常驻智能体替你干活：4 个自动化分别活了 7 小时、6 天、11 天、12 天，全被删了
速览卡
- 分类：省时间行政 / 前沿实验（反面案例）
- 结果：4 个认真部署的常驻自动化全部在两周内被删（已实现，失败结果）；唯一活下来的是只回答“门口有人/无人”、不做任何决策的人员检测
- 状态：作者逐个记录了存活时长、死因与 token 实测；样本只有 4 个、且全是本地中型模型，作者自己注明不排除换大模型后部分结论变化
- 成本：$0 API 费（本地运行）
- 耗时：自查清单约 30 分钟
一句话
网上全是常驻智能体的“安装帖”，几乎没人写“后来怎么样了”——这位作者写了：凡是让智能体自己做决定的部分，全坏了；活下来的那个，恰好什么都不决定。
原作者怎么做的
- 他在 NixOS 声明式管理的家庭服务器上，先后认真部署了 4 个自动化，每个都走 PR 进配置仓库、不是随手玩玩：让 LLM 自己注册定时任务的调度器、常驻智能体 Hermes、语音晨间新闻、晨间简报定时器。
- 逐个记录真实寿命与死因：调度器 7 小时（模型谎报“注册成功”、其实没注册上）；Hermes 6 天（职责与他已在用的 Claude Code 正面冲突）；晨间新闻 11 天（播报时他在睡觉、醒来照样看手机，纯属没人听）；晨间简报 12 天（简体中文串入、在家人数数错、减法算反同时发生）。
- 怀疑响应慢时，他去实测 token 构成：问一次天气要约 58,000 token（基础提示词在每次工具调用的多轮往返中被反复重发）；把 67 个内置 skill 全删掉，基础提示词只从 19k 降到 16.9k——背着的成本一直在，真正注入的只有约 2k。
- 他还观察到“自改进”的腐烂：Hermes 的 curator 机制会自己生成新 skill，质量无人把关，答案随时间变差；要防腐烂就得定期人工盘点——而“需要人工盘点”本身就否定了“常驻放养”的前提。
- 唯一存活至今的是门口人员检测：摄像头画面进 Frigate，YOLOv9 只回答“有人/无人”，后续动作（播报）全是写死的脚本；它一个月里静默死过 4 次，最后靠一个确定性的恢复脚本（每分钟查帧率、异常连犯 8 次就重启）续命至今。
结果
- 4 个常驻自动化寿命：7 小时 / 6 天 / 11 天 / 12 天，全部删除（已实现，失败结果）。
- 量化实测：单次天气问答约 58k token；删除全部 67 个内置 skill 仅省 2.1k 基础 token。
- 作者的归纳（他的判断、非定理）：能写成步骤的活，脚本比智能体便宜可靠；写不成步骤的活，都是一次性的，本来就不适合“常驻自动化”——两者之间的地带，正是常驻智能体反复掉下去的缝。他准备搭的第 5 个（告警自动调查）在动手前先量了告警频率，发现真问题是“我根本不看告警”，于是没搭。
提示词结构
这篇没有提示词，值得复用的是他的“上线前三问”（据原文归纳，非原文照录）：
「1. 这个任务的步骤能不能完整写下来？能 → 用脚本，不要用智能体。2. 它需要智能体做哪个具体决定？把决定范围压到最小（最好是二值判断），其余全部写死。3. 它坏掉时谁会发现？先写好确定性的健康检查与自动恢复，再谈上线。上线后记录真实存活天数与死因，两周后复盘：还在跑吗？」
中国读者怎么迁移
国内“数字员工/常驻助手”类产品正在大量推销，这篇是最便宜的避坑镜子：先拿三问过一遍你想常驻的每个任务——能脚本化的用脚本（如定时任务+规则），需要判断的一次性任务随用随叫，只把“持续在线+二值判断”的窄活留给常驻系统，并先配好健康检查。不要先买年费再想场景。
风险与限制
- 样本只有 4 个、且全部跑在本地中型模型上；作者明确写了换成大型托管模型后，部分抱怨（如谎报、算错）可能消失、但会变成账单问题——本站引用时必须带这个限定，不许写成“常驻智能体都不行”。
- 这是家庭场景实测，不是企业生产环境结论；作者本人也列出了三个未决问题（是否只是他家任务太简单、是否因为他整天坐在终端前随用随叫很方便）。
- “失败结果”的价值在方法（记录寿命与死因、上线前先量频率），不在劝退一切常驻系统；门口检测恰恰证明窄场景常驻可行。