你的 AI 工作流现在正在运行。
你只是不知道它三天前就已经停止正常工作了。
它仍在运行。仍在消耗 API 额度。仍在输出没人看的内容。你花了两个周末搭建的 Agent 正在以每个垃圾输出 0.40 美元的速度制造垃圾——而你要等到某个客户截图并周二发给你时才会发现。
这不是运气不好。这是默认结局。
收藏好这篇文章。你会读两遍的。
30 天墓地
每周都有数百位创始人搭建 AI 工作流，然后发到 Twitter 上。
演示看起来很棒。帖子收获了点赞。评论说“这是未来。”
三十天后，这个工作流就死了。
不是被删除了。不是被替换了。是死了但还在运行。还在扣费。却毫无产出。创始人已经去做别的事了。Agent 没收到消息。
如今 90% 的 AI 工作流在上线一个月内就会消亡。不是模型不好。不是想法不对。而是构建者犯了三个注定失败的错误——而且在他们发布之前，没人告诉过他们这些错误是什么。
这就是那篇文章。
为什么它们会死
工作流死亡的解剖图如下。顺序永远一样。
第一天：你构建了它。演示中完美运行。你觉得自己解锁了什么。
第三天：它仍然能工作。你不再那么仔细地检查了。
第九天：某些东西变了。API 响应格式略有变化。它读取的某个源被放到了登录墙后面。模型对边缘情况的解读与第一天不同了。输出悄悄地变差。没人注意到。
第十四天：工作流现在产出的东西，技术上算是响应，但实质上毫无用处。它还在运行。你还在付钱。
第二十三天：客户或同事提到有些不对劲。你去调查。发现 12 天的破损输出一直被你以为是正常处理的。
第三十天：你杀掉了它。你告诉自己 AI 还没准备好。然后继续前行。
模型没有辜负你。是构建辜负了模型。
区分那 10% 与其他人的 3 条规则
那些工作流能存活 30 天、90 天、一年的创始人——他们并不更聪明。他们的提示词并不更好。他们遵循了三条其他人忽略的规则来构建。
规则 1 — 没有职位描述，就没有 Agent
大多数人构建 Agent 时只凭感觉。
“帮我做内容。”“监控竞争对手。”“处理客户邮件。”
那不是职位描述。那是一个愿望。而愿望撑不过一个周末。
一个职位描述包含五个部分：
它监控什么。具体的触发条件或时间表。“每周一早上 7 点”或“每次有新的 GitHub Issue 被标记为 bug”或“每次收到不在我联系人列表中的域名的邮件”。不是“有时候”或“相关时”。
它读取什么。确切的来源。不是“检查互联网”。“从这三个 RSS 源、这个 Airtable 基座以及这个 Slack 频道最近 7 天的消息中提取。”具体。有边界。没有歧义。
它产出什么。确切的输出格式。不是“一段摘要”。“一份三节简报：一个句子概括核心发现，三个支持要点（每个附一个来源），一个建议行动。少于 300 字。放在这个 Google Doc 里。”
它不做什么。防护栏。“未经人工批准绝不发送外部邮件。”“绝不修改生产数据库。”“绝不直接发布。始终保存为草稿。”那些你以为显而易见的事情，正是会坑你的东西。
你如何知道它工作正常了。成功条件。“如果简报为空，发一条 Slack 消息说没有相关更新。不要发送空简报。”
感觉撑不过周末。职位描述可以。
从现在起你构建的每一个工作流，都要从职位描述开始。不是提示词。是职位描述。
规则 2 — 静默失败才是唯一能杀死你的失败
响亮失败没问题。响亮失败会发送错误。它会停止工作流。它会唤醒你。你修复它。
静默失败才是杀死企业的那些。
静默失败看起来像成功。工作流运行了。输出来了。格式正确。但内容错了——先是轻微错误，然后越来越严重，最后完全错了——而因为看起来正常，没人检查它。
静默失败在实践中是这样的：
你的内容 Agent 写了 30 篇帖子。你设置它自动安排那些在你内部评分标准里超过 80 分的帖子。这个评分标准是根据你最初的 20 篇帖子校准的。到了第 15 天，模型开始用不同的方式解读你的评分标准。得分 82 的帖子按你的实际标准充其量只是平庸。但它们还是发布了。你的互动率下降了。你责怪算法。
你的研究 Agent 每周发送一份简报。第 11 天，它读取的一个源改变了 URL 结构。Agent 静默地获取失败。它用旧的缓存数据填补了空白，并且没有标记这个缺口。你阅读了一份基于过时信息的简报，并据此做了决策。
你的收件箱分拣 Agent 起草回复。第 8 天，它开始将某类邮件归类为低优先级，因为发件人的名字与它训练数据中的某个模式匹配。你错过了来自一个新客户的三封重要邮件，而这位客户恰好与某个你从不阅读的新闻通讯同姓。
在每种情况下：工作流都运行了。没有抛出错误。你还是输了。
解决方案是强制输出验证。每个 Agent 需要三样东西：
一个金丝雀输出。每个输出中的一个字段，容易被验证且难以伪造。它最近读取来源的时间戳。它处理的项目数量。置信度分数。一个你扫一眼就能在两秒内知道 Agent 确实做了工作的东西。
一个静默失败警报。如果 Agent 什么也没产出，或产出低于某个阈值，它不是发送空输出。它发送一个警报。“本轮未找到结果——这是我所检查的内容以及我可能什么都没找到的原因。”空结果永远比一个有说服力的空结果更有用。
一个每周抽查。每周为每个 Agent 选一个输出。完整通读一遍。与你自己的判断作比较。这需要四分钟。能在漂移变成失败之前抓住它。
Agent 不会大声失败。要为无声的故障做准备。
规则 3 — 你的笔记本电脑不是基础设施
这就是 90% 的构建者失败的地方。
他们在本地构建。演示完美。他们发布了 Twitter 帖子。有人问它是否在生产环境运行。他们说是。但他们实际的意思是：它在他们的 MacBook 上运行，笔记本目前开着，放在公寓的桌子上，连着家里的 WiFi，当周四他们合上盖子去机场时就会停止工作。
你的笔记本电脑不是基础设施。它是一个开发环境，碰巧现在在运行一些重要的东西。
以下是笔记本托管的 Agent 会遇到的情况：
macOS 在凌晨 4 点推送更新。机器重启。Agent 停止。直到周一才有人知道。
你在飞机上合上盖子。六个小时的工作流被错过。收件箱分拣 Agent 没有分拣。Bug 猎人没有狩猎。每日站会 Agent 什么都没发。
你家 WiFi 断了二十分钟。Agent 重试。失败。继续。没有任何日志。它本应捕获的时间窗口已经消失了。
你去度假。笔记本电脑留在家里。一切也都留在家里。
真正的基础设施在你不在的时候也会运行。它在你睡觉时、在飞机上、在吃晚餐时、整个周末联系不上时也会运行。它不需要你把盖子开着。
规则很简单：如果这个工作流需要运行不止一次，而且你承受不起它错过一个周期，那它就不能放在你的笔记本电脑上。
实际上可行的三种基础设施选项：
带进程管理器的 VPS。一台每月 12 美元的服务器，运行 PM2 或 Supervisor。你的 Agent 以受管理进程的方式运行。如果崩溃了，PM2 会自动重启。如果服务器重启，PM2 会在启动时自动启动。便宜。可靠。不花哨。有效。
托管的 Agent 平台。专为此目的而建。处理重启、监控、警报。比 VPS 贵。省下了你花在调试进程为什么会死上的周末。一旦你的 Agent 产生真正的价值，就值了。
带调度器的无服务器方案。通过 EventBridge 或 Cloud Scheduler 触发的 AWS Lambda 或 Google Cloud Functions。无需管理任何基础设施。按执行次数付费。不运行时缩到零。最适合按固定时间表而非持续运行的 Agent。
这些都不复杂。全部只需十五分钟设置。每一个都能让你免受凌晨 4 点 macOS 更新杀死 Agent 并毁掉你周一早晨的痛苦。
合上你的笔记本电脑。Agent 应该继续运行。
能存活的工作流
以下是应用了全部三条规则时，一个 90 天工作流的样子。
职位描述：每周一早上 7 点，读取这 5 个竞争对手账户和这 3 个行业新闻通讯最近 7 天的帖子。提取任何产品公告、价格变动或互动超过 500 的内容。与上周的简报进行比较。标记任何新内容。输出一份三节简报：什么变了、什么正在获得关注、他们留下了什么缺口。如果未发现变化，发送警报：“安静的一周——已检查以下来源。”交付到这个 Notion 页面并发送一条 Slack 通知。
金丝雀输出：每份简报都包含：“已检查来源：8。已处理项目：[N]。最近项目时间戳：[时间戳]。”如果 N 为零或时间戳超过 8 天，则发送警报而非简报。
基础设施：运行在一台每月 12 美元的 VPS 上。PM2 管理进程。如果崩溃，会在 30 秒内重启。每周五花 3 分钟做一次日志审查。
抽查：每周五，通读一份简报。耗时 4 分钟。六个月里已经抓住了两次漂移。
那个工作流已经运行了六个月。错过了两个周期——两次都发送了警报解释原因。从未静默失败过。
这就是能存活的工作流与在第九天死去的工作流之间的区别。
令人不适的真相
大多数人会读这篇文章，点头，然后用和上次一样的方式构建他们的下一个 Agent。
一个提示词。一个演示。一条 Twitter 帖子。三十天的寂静。一个没人正式宣告死亡的工作流。
这三条规则并不复杂。写一份职位描述只需二十分钟。输出验证只需要一个字段和一个条件。基础设施只需十五分钟设置。
差距不是知识。差距在于你是发布之前做这些，还是等工作流失败之后再做。
你构建的每一个没有职位描述的 Agent，都是你将要重建的 Agent。每一个没有输出验证的 Agent，都是会静默失败的 Agent。每一个放在你笔记本电脑上的 Agent，都是下次你合上盖子就会死掉的 Agent。
正确地构建它们一次。它们永远运行下去。
关注 @sairahul1 获取更多关于构建能够与现实世界接触后存活的 AI 工作流的完整实操指南。
TL;DR
90% 的 AI 工作流在 30 天内消亡。总是同样的三个原因。
规则 1 — 没有职位描述，就没有 Agent。感觉撑不过周末。定义它监控什么、读取什么、产出什么、避免什么，以及你如何知道它工作正常。在写任何提示词之前。
规则 2 — 静默失败才是唯一能杀死你的失败。响亮失败没问题。静默失败看起来像成功，直到客户发现它们。在每个 Agent 中构建一个金丝雀输出、一个静默失败警报和一个每周抽查。
规则 3 — 你的笔记本电脑不是基础设施。它只在盖子打开时运行。真正的 Agent 在你睡觉时、在飞机上、整个周末联系不上时也要运行。VPS、托管平台或无服务器。选一个。发布之前设置好。
能存活的 Agent 并不更聪明。它们是被正确构建的。
