核心洞察
模型没有辜负你，构建辜负了模型。
90% 的 AI 工作流在 30 天内死亡——不是因为模型不好，不是因为想法错误，而是因为三个可避免的构建错误。
30 天墓地
死亡时间线
| 天数 | 状态 |
|---|---|
| 第 1 天 | 构建完成，演示完美，感觉解锁了什么 |
| 第 3 天 | 仍在工作，检查变得不那么仔细 |
| 第 9 天 | 某处变化：API 响应格式偏移 / 源站加登录墙 / 模型对边界案例解释不同 → 输出静默退化 |
| 第 14 天 | 输出技术上正确，但实质上无用。仍在运行，仍在付费 |
| 第 23 天 | 客户/同事提到不对劲 → 调查 → 发现 12 天破碎输出 |
| 第 30 天 | 杀死它。告诉自己 AI 还没准备好。继续前进 |
关键认知
工作流没有被删除、没有被替换——它死了但仍在运行，继续扣费，继续产出无用的东西。
三条生存规则
规则一：没有职位描述，就没有 Agent
问题：大多数人用 vibe（感觉）构建 Agent。
❌ "帮我做内容" / "监控竞品" / "处理客户邮件"
这是愿望，不是职位描述。愿望熬不过周末。
职位描述五要素
| 要素 | 说明 | 示例 |
|---|---|---|
| 监视什么 | 具体触发器或调度 | "每周一早上 7 点" / "每次新的 GitHub issue 带 'bug' 标签打开" / "每次来自不在联系人列表域名的邮件到达" |
| 读取什么 | 确切来源 | "拉取这 3 个 RSS feed、这个 Airtable base、这个 Slack 频道最近 7 天" |
| 产出什么 | 确切输出格式 | "三段式简报：一句话标题发现、三个带来源的支持要点、一个推荐行动。300 字以内。在这个 Google Doc 中" |
| 不做什么 | 护栏 | "未经人工批准绝不发送外部邮件" / "绝不修改生产数据库" / "绝不直接发布，总是保存到草稿" |
| 怎么知道它工作了 | 成功条件 | "如果简报为空，给我发 Slack 消息说没找到相关更新。不要发空简报" |
从今天开始，每个工作流从职位描述开始——不是 prompt，是职位描述。
规则二：静默失败是唯一会杀死你的失败
** loud 失败很好**：发错误、停止工作流、叫醒你、你修复它。
静默失败杀死企业：
- 工作流在运行
- 输出到达
- 格式正确
- 内容错了——轻微地，然后更多，然后完全——但因为看起来对，没人检查
静默失败实例
内容 Agent：
- 写了 30 篇帖子
- 自动调度评分 > 80 的帖子
- 评分基于前 20 篇帖子校准
- 第 15 天，模型开始不同地解释评分标准
- 82 分的帖子实际平庸 → 仍然发出 → 参与度下降 → 你怪算法
研究 Agent：
- 每周发送简报
- 第 11 天，一个来源改变 URL 结构
- Agent 静默获取失败 → 用旧缓存数据填补缺口 → 不标记缺口
- 你基于过时信息做决策
收件箱分类 Agent：
- 起草回复
- 第 8 天，开始将某类邮件归类为低优先级
- 原因：发件人名字匹配训练中的某个模式
- 错过 3 封重要邮件——新客户恰好与你从不读的某个 newsletter 共享姓氏
三个防御机制
1. Canary 输出
每份输出包含易验证、难伪造的字段：
- 读取的最近源时间戳
- 处理的项目数
- 置信度分数
2 秒扫一眼就知道 Agent 是否真的做了工作。
2. 静默失败警报
如果 Agent 什么都没产出，或产出低于阈值：
- ❌ 不发空输出
- ✅ 发警报："本周期无结果——这是我检查的及为何可能没找到"
没有什么比令人信服的空结果更有用。
3. 每周抽查
每周挑一个输出完整阅读：
- 与自己会写的内容对比
- 4 分钟
- 在漂移变成失败前捕获
规则三：你的笔记本电脑不是基础设施
问题：90% 的构建者死在这里。
本地构建 → 演示工作 → 发 Twitter thread → 有人问是否在生产环境运行 → 你说「是」→ 实际意思是：它在你 MacBook 上运行，盖子开着，在你公寓桌上，连着你家 WiFi，周四你去机场合上盖子就会停止工作。
笔记本电脑托管 Agent 的灾难
| 场景 | 后果 |
|---|---|
| macOS 凌晨 4 点推送更新，机器重启 | Agent 停止，周一才知道 |
| 飞机上合上盖子 6 小时 | 收件箱分类没分类，bug 猎手没狩猎，standup Agent 没发送 |
| 家 WiFi 断 20 分钟 | Agent 重试 → 失败 → 继续 → 没日志 → 窗口丢失 |
| 去度假，笔记本留在家 | 一切跟着留在家里 |
真正的基础设施在你不看时运行——睡觉时、飞机上、吃饭时、整个周末 unreachable。
三个真实选项
| 选项 | 成本 | 特点 | 适用 |
|---|---|---|---|
| VPS + 进程管理器 | $12/月 | PM2/Supervisor，崩溃自动重启，服务器重启自动启动 | 便宜、可靠、不华丽、工作 |
| 托管 Agent 平台 | 更高 | purpose-built，处理重启/监控/警报 | Agent 产生真实价值后值得 |
| Serverless + 调度器 | 按执行付费 | AWS Lambda / Google Cloud Functions，零基础设施管理，固定调度最佳 | 固定调度而非持续运行 |
都不复杂，全部需要 15 分钟设置。每一个都会救你于凌晨 4 点 macOS 更新杀死你的 Agent 和周一早晨。
90 天存活工作流示例
职位描述
每周一早上 7 点，读取这 5 个竞品账户和 3 个行业 newsletter 最近 7 天的帖子。提取任何产品公告、定价变化或互动量 > 500 的内容。与上周简报对比，标记任何新内容。输出三段式简报：什么变了、什么在增长、他们留下了什么空白。如果没找到变化，发警报："安静的一周——这是我检查的"。交付到这个 Notion 页面并发送 Slack 通知。
Canary 输出
每份简报包含：
"Sources checked: 8. Items processed: [N]. Most recent item timestamp: [timestamp]."
如果 N 为零或时间戳 > 8 天 → 发警报而非简报。
基础设施
- $12/月 VPS
- PM2 管理进程
- 崩溃 → 30 秒内重启
- 每周五日志审查：3 分钟
抽查
每周五完整阅读一份简报：4 分钟。六个月内捕获两次漂移。
结果
- 运行六个月
- 错过两个周期——两次都发了警报解释原因
- 从未静默失败
不舒服的真相
大多数人会读这篇文章，点头，然后以和上次一样的方式构建下一个 Agent：
一个 prompt → 一个演示 → 一个 Twitter thread → 30 天静默 → 一个没人正式杀死的死亡工作流。
三条规则不复杂：
- 职位描述：20 分钟写完
- 输出验证：一个字段 + 一个条件
- 基础设施：15 分钟设置
差距不是知识，差距是你是在发货前做还是在工作流失败后做。
TL;DR
| 规则 | 核心 |
|---|---|
| 规则一 | 没有职位描述，就没有 Agent。Vibe 熬不过周末。定义监视什么、读取什么、产出什么、不做什么、怎么知道它工作了。在写第一个 prompt 之前。 |
| 规则二 | 静默失败是唯一会杀死你的失败。Loud 失败很好。构建 canary 输出、静默失败警报、每周抽查。 |
| 规则三 | 你的笔记本电脑不是基础设施。真正的 Agent 在你睡觉时、飞机上、整个周末 unreachable 时运行。VPS、托管平台或 serverless。选一个。在发货前设置好。 |
存活的 Agent 不是更聪明。它们是构建正确的。
资源
- 作者：Rahul (@sairahul1)
- 原文：https://x.com/sairahul1/status/2055935584158531815
- 基础设施选项：
- VPS + PM2/Supervisor
- 托管 Agent 平台
- AWS Lambda / Google Cloud Functions + EventBridge/Cloud Scheduler