你覺得AI Agent的全自動化還是個遙遠的夢嗎？其實，它真的可以實現。事實上，AI Agent 跑不順的很多原因都出在「設計陷阱」。我自己也試過一開始就想全部自動化，做了大約40個Agent，結果徹底崩了，哈哈。但最近，我試了海外流行的「如何打造24小時持續運行的AI Agent」方法，效果非常顯著。這次，我會總結出一套設計方法，教你打造「不易崩潰、持續運作的AI Agent」，一起來看看吧💖
「做一個AI Agent，讓它在我睡覺的時候自動幹活」，這真的太讓人心動了。
我一開始也是這麼想的。
早上醒來，X 的草稿已經寫好了。AI新聞摘要自動發到Slack。提交紀錄整理得整整齊齊。
這種未來，肯定會有的吧？
其實，半年前還是個「不會寫代碼的文科生」的我，開始碰 Claude Code 之後，一口氣並行做了40個左右的Agent。有Leader、Writer、Researcher、QA、Editor……我邊在腦子裡畫組織圖邊做。
3小時後，全掛了，哈哈哈。
那一刻我才真正意識到：「做AI Agent」和「讓AI Agent持續運作」完全是兩回事。
最近 Claude Code 社群裡，有人分享「做了40個Agent最後全放棄」的經驗，我當時也做了一模一樣的事。與此同時，海外開發者 Nate Herk 發了一篇神級文章，講他「試了三種部署方法並做了對比」，看完那篇我就全明白了。
今天，我就把「從我搞廢40個Agent，到讀透Nate Herk的文章，再自己全部試過，最終摸索出的不崩潰、24小時持續運行的AI Agent打造方法」，一個不落地完整寫出來💖
讀到最後，你會收穫這些：
- 從結構上理解「為什麼自己的Agent會崩」
- 搞清楚 /loop / Routines / Modal / [Trigger.dev](//Trigger.dev) / Agent SDK / Managed Agents 的差別
- 獲得「何時該用哪種方法」的判斷流程
- 掌握 Hook（不崩潰設計的核心）的用法
- 從此不用再重複「做40個然後全廢棄」的悲劇
我已經把內容嚼碎到連我這種「不會寫代碼的文科生」都能看懂，安心讀下去吧。
一起拿下勝利✨
■ 話說回來，為什麼那40個會崩？
先從我當時到底幹了什麼說起。
第一週，真的像魔法一樣。
「A君（研究擔當），查一下這個」「B君（文案擔當），用A的結果寫個草稿」「C君（審核擔當），檢查B的稿子」——Agent之間按順序調用，我只需要下指令。
早上去沖杯咖啡，回來就有三篇草稿等著。
是不是太神了？？？
但從第二週左右開始，事情就不對勁了。
「咦，B應該寫的稿子，怎麼是A在寫……」
「C不是該審核嗎，怎麼說的和B一樣……」
「話說，D不是最早創建的嗎，跑哪去了？」
到了第三週，連我自己都搞不清到底發生了什麼。
一個月後，我把40個Agent 全停了。
其實已經有人分享過類似的經驗。Kohaku（@Kohaku\\\_NFT）發的筆記《做了40個AI員工，一個月後全停了》完全戳中我。跟我的經歷一模一樣。
那篇筆記列出了Agent在結構上崩潰的 3個原因。這不光是感覺，Anthropic 官方文檔裡也寫了。
原因1: 上下文腐敗（Context Rot）
用 Claude Code 的人絕對會碰到這個坑。
Claude 有上下文窗口，也就是「同時能處理的信息量上限」。Anthropic 官方文檔寫道：
*Token 數越多，模型從上下文準確回憶信息的能力就越低。*
「能裝100萬token」和「用了100萬token還能穩定運行」完全是兩回事。
實測中，超過10萬token左右輸出就開始不穩了。同時跑40個Agent，每個都背著歷史記錄，窗口很快填滿。然後就會忘記「剛才下達的指令」，規則開始被忽略，跟過去的對話矛盾。
這就是上下文腐敗。
我當時以為「多培養一下就好了」，於是一直加寫規則，結果越加越崩。規則越多，越會互相衝突，加速上下文腐敗。
完全適得其反，哈哈哈。
原因2: Compaction 崩潰
Claude Code 有個 Compaction（壓縮）功能。當上下文快滿時，它會總結過去的對話，騰出空間給新的對話。
聽起來很完善，但實際上，總結的總結一層層疊加，最後會退化為噪聲。
我那40個Agent就出現過這種情況：
「3個人消失，2個人重複，剩下的35個人完全沒發現。」
這是 Kohaku 筆記裡的金句，說得一點沒錯。Compaction 之後，Agent之間開始「咦，誰在誰不在來著？」狀態不一致，但35個Agent若無其事地繼續跑。
跑3小時，幾乎必定崩潰。
原因3: 文本規則不是絕對命令
這是我最大的盲點。
我一直以為「寫好規則就會遵守」。在 CLAUDE.md 和 Agent 定義裡都寫了極詳細的規則。
但對 LLM 來說，規則文本只是上下文的一部分。它會被之前的對話、中途下的指令、當前的語境影響，導致解讀逐漸偏離。
明明寫了「禁止」，卻被執行了。明明寫了「必須」，卻被跳過了。
同時跑40個，每個都用略微不同的解讀開始行動。這也是崩潰的原因。
所以，我那40個Agent不是因為運營失誤而崩潰，而是從一開始就建立在會崩潰的結構上。
下面是重點：如何打造「不會崩潰的結構」。
■ 不崩潰Agent的「三大支柱」（WAT框架）
讀 Nate Herk 的文章時，我整個世界啪地一下變了。
那就是「WAT框架」的思路。
WAT 代表：
- W = Workflow（流程書）
- A = Agent（思考部分）
- T = Tools（執行部分）
我們說「做AI Agent」的時候，下意識地會把這三樣混在一起想。但把它們當作不同的東西來對待，是不崩潰Agent的大原則。
Workflow（流程書）
這是決定「做什麼、按什麼順序做」的確定性部分。
比如「每天早上9點抓取X的提及 → 摘要 → 發到Slack」這樣的流程。
這裡不需要AI判斷。順序是固定的，按既定步驟執行即可。
Agent（思考部分）
這裡是AI大展身手的地方。
「根據用戶的提及，思考合適的回覆」或「根據研究結果寫出文章草稿」這類需要判斷、推理、創造的部分交給AI。
Tools（執行部分）
調用X的API、寫入文件、發送Slack、生成圖片——這些需要確定性行為，所以用代碼牢牢固定。
AI如果「自作聰明搞奇怪動作」就麻煩了，所以關鍵是限制AI可以觸及的範圍。
崩潰的原因就是把三者混在一起
我當時做40個Agent的時候，是把所有東西都當成Agent。
我以為「研究、寫作、質量檢查，全都讓AI判斷就好」。
不是這樣的。
需要判斷的部分（Agent）、固定步驟（Workflow）、固定行為（Tools），分別在不同層次實現。這是不崩潰設計的基礎。
此外，用WAT思考，部署方法也更清晰。
「把什麼東西部署到哪裡」就確定了。
有些方法可以承載全部WAT；有些方法只能承載W和T，丟掉A。意識到這一點，就能看出哪種方法適合自己的用途。
接下來，我們逐一看看6種實現「24小時運行」的具體方法。
■ Method 1: /loop（在終端中運行的即席Bot）
先從最簡單的方法開始。
Claude Code 有 /loop 功能，作為「最初的自動化」非常強大。
使用方法超級簡單。
打開 Claude Code，直接說：
*「創建一個循環，每10分鐘讀取新評論，利用轉錄結果思考回覆。」*
Claude Code 就會在後台用 cron create 工具自動幫你設置好調度。
原理：cron三兄弟
後台只靠三個工具運作：
- cron create（創建調度）
- cron list（查看當前調度）
- cron delete（刪除調度）
調度器運行在 Claude Code 的進程內，每個會話獨立。所以，你在5個終端裡同時跑5個不同的循環，也不會互相干擾（只要不寫入同一個文件）。
終端版和桌面版行為不同
這是 Nate Herk 文章裡讓我「啊！？」的一點。
在桌面應用中運行 /loop 後再打 /clear，cron 會死掉。
但終端版裡，打 /clear 後 cron 仍然存活。
這個差別其實非常大。
長時間運行循環，上下文會不斷填滿。你想用 /clear 刷新它，但如果cron也死了就沒意義了。
終端版可以只清除上下文，讓cron繼續運行。
讓我感動的絕招：在循環中嵌入 /clear
這是 Nate Herk 的原創技巧，我真心覺得太天才了。
在終端中創建兩個循環：
- 循環A：每10分鐘做正事
- 循環B：每5分鐘以斜杠命令的形式輸入 /clear
等等，cron能打斜杠命令？可以，哈哈。
循環A在後台執行任務時，循環B每5分鐘重置一次上下文。在上下文腐敗發生之前自動刷新。
知道這個的時候，我差點從椅子上摔下來，太神了吧？？？
/loop 的弱點（需要知道的事）
不過也有注意事項。
- PC 一关，循环也会停（因为是在本地运行）
- 会话一关就结束
- 终端版最长能跑 7 天左右，桌面版最长 3 天左右 会过期（官方没给精确值，所以写了个范围）
- 就算指定了“每10分钟一次”，也不会刚好在 10:10:00 跑，而是会有 几分钟的偏差。这是为了不让所有 Claude Code 会话同时去请求 Anthropic 的 API，故意设计的机制
另外，最大的坑是重试循环。
这是 Zenn 上有人分享过的案例：Claude Code 误读了错误消息，反复调用同一个工具，结果 5 小时的额度在 19 分钟内就用光了。
这真不是开玩笑。
要防止这种情况，后面会讲到的 Hook 很管用。如果只用 /loop，建议 别直接扔着过夜，先短时间跑一下验证行为。
用 WAT 分类来说，/loop 是一种 能把 W、A、T 全带走 的部署方式。Agent 还活着，Tools 能用，Workflow 也能跑。论省事，它最强。
■ Method 2: Claude Routines（关上电脑也能跑的杀手锏）
这个啊，对我来说感觉就是“终于来了的杀手锏”。
/loop 虽然方便，但终究得让电脑一直开着。出门在外就不能跑，电脑重启就停。
在 Anthropic 云端运行 的，就是 Claude Routines。
使用方法
打开 Claude Code 桌面应用，选择 Routines 就行。
里面有“本地 Scheduled Tasks”和“远程 Claude Routines”两种类型：
- 本地：在电脑上运行（电脑关上就不跑了）
- 远程：在 Anthropic 云端运行（电脑关上也能跑）
设置界面几乎一样。写好提示词，定好时间，保存即可。
你写的提示词会按计划 注入到一个全新的 Claude Code 会话中，然后那个会话去执行任务。
上限（按套餐区分）
远程 Routines 在 Anthropic 云端运行，所以 按套餐每天有执行次数上限。
官方文档（[code.claude.com/docs/en/routines](//code.claude.com/docs/en/routines)）是这样写的：
- Pro：每天最多 5 次
- Max 5x：每天最多 15 次
- Max 20x：每天最多 15 次
- Team / Enterprise：未明确上限（可能按套餐另有设置）
超出的部分会额外收费，所以频率设计要想清楚。
最短间隔是 1 小时
这个你得知道，否则会踩坑：Routines 的最短执行间隔是 1 小时。
就算你想“每 10 分钟跑一次”，cron 也不让设短于 1 小时。
要是需要更细的频率，只能回去用 /loop。
Webhook 和 GitHub 事件也能用
Routines 不只能按计划启动，还有三种触发方式：
- 定时（cron）
- API 端点（可从外部调用）
- GitHub 事件（根据 GitHub 的动作触发）
也就是说，你可以从其他自动化工具调用 Routines。比如 Slack 的 Bot 满足条件后调用 Routines，让 Claude 做调研然后把结果发回来，这种复杂组合也能搭起来。
补跑功能（看似不起眼但很关键）
本地 Scheduled Tasks 有个“补跑功能”，这其实是个隐藏的坑。
如果你把电脑关了 5 天，回来一打开，它会一口气把过去 5 天没跑的任务全部跑完。
有时候方便，有时候很危险。
对于“只希望在这个时间点跑”的 routine，最好把它停掉，或者重新设计。
我实际用 Routines 跑的例子
下面列一下我实际在跑的例子，以及 Claude Code 用户之间流传的成功案例。
国内 note 上有这些分享：
- 每天早上 9 点自动收集 HackerNews / Reddit / 官方博客上的 AI 资讯 → 存入 Notion 带时间戳 → 发 Slack 通知（注意：网络权限必须设为“Full”，否则无法访问外部）
- 每周日晚上 18 点自动生成一周的 X 帖子草稿 → 周一到周六早 7 点 / 中午 12 点 / 晚上 19 点定时发布（配合人工审核，不全自动）
- 睡觉时跑代码 review（Routines + Claude Agent SDK 组合，后面会讲）
纯云端，不需要电脑。这真的是革命性的，太棒了。
用 WAT 分类来说，Routines 是一种 能把 W、A、T 全带走 的部署方式。和 /loop 一样，可以完整使用 Claude Code 订阅的所有功能。
这对我来说就是“第一个杀手锏”。
■ Method 3: Modal 和 [Trigger.dev](//Trigger.dev)（在云端完全自主运行）
从这里开始难度稍微提升了。
“已经不需要在 Claude Code 里面跑了，我想完全放到外面的云端，独立运行。” 这就是 Modal 和 [Trigger.dev](//Trigger.dev)。
Modal（Python）
Modal 是 Python 的无服务器平台。“写一个 Python 函数，部署，用 cron 触发”那种世界。
价格还算友好：
- Free Tier：每月 $30 的计算额度（Starter 套餐）
- 按秒计费（仅按使用 CPU、内存、GPU 的时间收费）
使用 GPU 时的单价示例：A10G 每秒 $0.000306，A100 每秒 $0.001036，H100 每秒 $0.002778（来自 [modal.com/pricing](//modal.com/pricing)）。
[Trigger.dev](//Trigger.dev)（TypeScript）
[Trigger.dev](//Trigger.dev) 是 TypeScript 的 持久化工作流引擎。比 Modal 更偏向“不易中断的长时间工作流”场景。
价格如下：
- Free：$0/月（含 $5 的使用额度），同时执行 10 个
- Hobby：$10/月（含 $10 使用额度），同时执行 25 个
- Pro：$50/月（含 $50 使用额度），同时执行 100+ 个
Modal 和 [Trigger.dev](//Trigger.dev) 怎么选？
简单来说：
- 想用 Python 写 → Modal
- 想用 TypeScript 写 → [Trigger.dev](//Trigger.dev)
- “这是确定性脚本，不需要 AI 判断” → Modal 更轻量
- “想搭长时间运行、类似 Agent 的工作流” → [Trigger.dev](//Trigger.dev) 更合适
两个都能用 cron 触发，也都能通过 Webhook 从外部调用。
重要取舍：失去 Agent
这一点一定要特别注意。
把“之前在 Claude Code 里做的事”移到 Modal 或 [Trigger.dev](//Trigger.dev) 上，就不能再用 Claude Code 订阅了。
如果里面还要用 AI，就需要另外准备 Claude API 密钥，按 API 单价计费。
截至 2026 年 5 月，Claude API 价格如下（来自 [platform.claude.com/docs/en/about-claude/pricing](//platform.claude.com/docs/en/about-claude/pricing)）：
- Claude Opus 4.7：输入 $5，输出 $25（每百万 token）
- Claude Sonnet 4.6：输入 $3，输出 $15
- Claude Haiku 4.5：输入 $1，输出 $5
换句话说，如果设计上太费 token，可能比 Claude Code 订阅贵得多。
但反过来，不需要 AI 的确定性脚本，用这个就是最强方案。
比如“拉数据、格式化、写入表格”这种处理。不需要 AI 判断吧？把它放到 Modal 或 [Trigger.dev](//Trigger.dev) 上，零 API token 费用，24 小时跑满。
用 WAT 分类来说，Modal / [Trigger.dev](//Trigger.dev) 是一种 能带走 W 和 T，但会失去 A（Agent） 的部署方式。
能否意识到“这些不一定全都要用 AI”，是控制成本的关键。
■ Method 4: Claude Agent SDK（专属你的 Agent 工厂）
“想放到 Modal 或 [Trigger.dev](//Trigger.dev) 上，但还想保留 Agent”，这个贪心愿望的答案就是 Claude Agent SDK。
这个对我来说，感觉是“终于全都连起来了”。
把 Claude Code 平时用的“底层 harness”封装成 SDK，让你能从自己的 Python 或 TypeScript 代码里调用。
能做什么
官方发布的 Agent SDK 拥有和 Claude Code 完全一样的功能：
- subagents（子 Agent 调用）
- MCP（外部工具连接）
- Hook（事件驱动处理）
- Skills（特定任务的 behavior 定义）
- 斜杠命令
- CLAUDE.md（项目上下文）
- memory（持久化记忆）
- compaction（自动压缩压缩）
全都能用。你在 Claude Code 里做的事情，可以直接嵌入到自己的代码中。
默认是 Stateless
这里有一个坑要注意：
Agent SDK 的每个请求默认都是无状态的。
如果不做任何处理，每次都会以一个全新的状态启动。它不记得“刚才聊了什么”。
要实现连续对话，需要在每次请求时传递 session ID：
session_id = "my-session-001"
# 第1次
response = client.query("告诉我项目情况", session_id=session_id)
# 第2次（用同一个 session_id 连接）
response = client.query("那下周的任务呢？", session_id=session_id)这样 Claude 就会当作“刚才对话的延续”来处理。Compaction 也会自动运行，所以长时间跑也没问题。
如果想“重置到全新状态”，用一个新 session_id 就行。没有 /clear 的对应功能。
费用：按 Claude API 单价计费
Agent SDK 与 Claude Code 订阅是分开的。
需要 API 密钥，按 token 单价收费。和 Modal / [Trigger.dev](//Trigger.dev) 一样的机制。
不过，2026年5月13日 Anthropic 宣布，Claude Code 的月度订阅额度，似乎也能用在 Agent SDK 上了。这简直是革命性的。
官方公告在这里（@ClaudeDevs / 2026-05-13）。
从2026年6月15日起，新的月度额度制度启动：
- Pro：每月 $20 的额度
- Max 5x：每月 $100 的额度
- Max 20x：每月 $200 的额度
这些额度可用于 Agent SDK、claude -p、Claude Code GitHub Actions、第三方 Agent SDK 应用。
之前觉得「Agent SDK 太贵了先算了」的人，这下门槛大大降低了。
用 WAT 来说，Agent SDK 能 承载 W/A/T 全部，而且是在自己的基础设施上。无敌。
■ Method 5: Managed Agents（简单提一下）
这个也顺便介绍一下。
Anthropic 推出的新服务，可以在 [platform.claude.com](//platform.claude.com) 上完全托管管理你的 Agent。
四个步骤就能部署，在沙盒里运行，保持会话，还能连接 MCP。
不过说实话，我自己并没有在个人用途中使用它。
对于用过 Claude Code 的人来说，在 Claude Code 内完成所有操作更顺手。Managed Agents 给我的印象是「为还没打开过 Claude Code 的人准备的轻量入门包」。
如果你「还不熟悉 Claude Code，但想要 Agent」，这个可能更适合你。
用 WAT 来说，这就相当于把 W/A/T 全部 托付 给 Anthropic。便利性最强，但自定义自由度会降低。
■ Hooks（不崩坏设计的心脏）
接下来这部分，是今天我最想写的内容💖
打造「不崩坏的 Agent」的心脏，就是 Hook。
在用 Claude Code 的人中，还有很多根本没用到它，太可惜了。
Hook 是什么？
Claude Code 有各种「时机点」：
- 使用工具之前
- 使用工具之后
- 会话开始的瞬间
- 会话结束的瞬间
- 收到某个消息的时候
- Compaction 运行之前
在每个时机点，你编写的小脚本会自动执行，这就是 Hook 的机制。
为什么 Hook 是不崩坏设计的心脏？
还记得40个 Agent 崩坏的故事吗？原因是3个：
- 上下文污染
- Compaction 崩溃
- 文本规则不被遵守
其中两个，可以通过 Hook 从结构上预防。
比如，海外开发者 Mike Dolan 先生（DEV Community）公开了这样一个 Hook：
*当 Compaction 即将运行时，Hook 检测到，并把当前工作交给 subagent 接管。*
也就是说，提前察觉「上下文危险」，自动转给另一个 Agent，在崩溃前逃跑。
我觉得这真的太天才了。
Hook 具体能做什么？
介绍5个典型例子。
第一个是「阻止危险命令执行」。比如 rm -rf、直接访问生产数据库等，Hook 检测并阻止。这是 Claude Code 失控时的最后防线。
第二个是「强制在写文件前先读取」。「先好好读文件再写」的规则，Hook 会物理强制执行。文本规则保不住，但 Hook 是绝对的。
第三个是「每次对话结束时保存回顾」。通过 SessionEnd Hook 自动积累知识。这样在下一个会话中也能利用这些知识。
第四个是「会话开始时加载所需上下文」。通过 SessionStart Hook，每次加载项目状态、过去的错误等需要先读的信息。
第五个是「重试循环检测」。刚才提到的「5小时内容19分钟消失」案例的防御措施。如果同一个工具调用在短时间内反复执行，Hook 会将其停下。
Hook 的本质是「脚本」
Hook 听起来很难，但本质上 只是脚本 而已。
Node.js、Python、Bash，什么都行。Claude Code 在指定的时机调用它而已。
连「不会写代码的文科生」我，第一个 Hook 也是从「Claude 响应结束后响个提示音」这种开始的。一行脚本也是 Hook 哦😂
慢慢积累，它会成为 你专属的安全网。
不用再抱怨「规则不被遵守」，而是 用 Hook 物理强制遵守。这就是不崩坏设计的核心。
用 WAT 来说，Hook 就是 在 A 与 T 之间加入决定性约束 的机制。能阻止 AI 「自作聪明做奇怪的事」。
■ 那么，究竟该在什么时候选哪个？（判断流程）
到这里我们已经看到了6种方法。
- Method 1: /loop
- Method 2: Claude Routines
- Method 3: Modal / [Trigger.dev](//Trigger.dev)
- Method 4: Claude Agent SDK
- Method 5: Managed Agents
- Hook（作为心脏附加在所有方法上）
「那到底该选哪个？」你肯定会这么想，我一开始也是这样。
整理一下，判断轴是这样的：
1. 实时操作，且需要完整的 Agent 循环 → /loop
自己坐在屏幕前，和 AI 一起操作时用。最便捷。通过把 /clear 嵌入 /loop 的秘诀，也能应对上下文污染。
2. 睡觉或外出时，希望它自动运行 → Claude Routines
关掉 PC 也能运行的本命选项。间隔1小时以上时用这个。在套餐限制内。
3. 不需要 AI 判断，确定性处理 → Modal 或 [Trigger.dev](//Trigger.dev)
比如「获取数据、整理格式、写入表格」这种不需要 AI 推理的处理。用 /loop 或 Routines 跑这些，成本会很浪费。
4. 想在自己基础设施上运行整个 Agent → Agent SDK + Modal / [Trigger.dev](//Trigger.dev)
在 Modal 或 [Trigger.dev](//Trigger.dev) 里集成 Agent SDK的模式。自由度最高。但 API 令牌费用另算（2026年6月起可适用月额度）。
5. 总之想轻松试试 → Managed Agents
给不熟悉 Claude Code 的人作为入门。
6. 无论选哪个，都想打造不崩坏的设计 → 配合 Hook
这不是一种方法，而是基础。可以附加在1〜5的任何一种上。
Nate Herk 先生的一条推文中，有一句话让我感触极深：
*「默认选择最 agentic 的方法，是最大的陷阱」*
真的太对了💖
「全部让 AI 判断就好」是陷阱，只在需要判断的部分交给 AI，才是不崩坏设计的本质。
■ 我在弄崩40个后意识到：5个教训
最后，我写下弄崩40个、试完6种方法后终于得出的5个教训。
连「不会写代码的文科生」我都能走到这一步。大家看着我的失败，直接就能从「不崩坏的设计」开始。
教训1: 不要相信上下文污染
「能装100万 token」和「用100万 token 也稳定」是两回事。超过10万 token 左右，输出就开始漂移。
要运行长时间循环，从一开始就把定期 /clear，或用 Hook 在 Compaction 前转移 纳入设计。
教训2: 1人胜过40人
Agent 越多越容易崩坏。
「研究角色、写作角色、检查角色」这种分工的心情我懂（我也是这样）。但与其3小时全崩，让1个人按顺序运行的设计 好上一百倍。
不是靠培养就能变好。最初的结构是否不易崩坏 才是一切。
教训3: 别让重试循环吸干你的额度
5小时的额度19分钟消失，真有其事。
如果晚上睡觉时放着不管，一定要用 Hook 加上重试检测。另外，先短时间测试确认，再转长时间运行。
绝对不要「一开始就全速开跑」。我朋友也掉进过同一个坑😂
教训4: 不要太相信「自动化」
Routines 强到「超出想象」，会自己 commit、自己发通知、自己删文件😂
在陶醉于「自动化啦！」之前，一定要做权限最小化。
限定可写入的目录。缩小可调外部API的范围。用 Hook 守卫。
防止「一不留神就干了奇怪的事」，只有最初的设计能做到。
教训5: 「视野」由人类掌控
这也许是最重要的一点。
Agent 只看得到自己负责的范围。把握整体、决定优先级、判断「这个不对」的，是 人类的工作。
不是「甩给 AI」，而是 「人类精准划定交给 AI 的范围」，才是不崩坏的运营。
■ 总结
写得有点长，最后浓缩一下。
「24小时不停运行的最强AI Agent」其实就是 用 WAT 思考 + 合适部署 + 用 Hook 守护 这个三件套。
- 将 Workflow（步骤）与 Agent（判断）与 Tools（执行）分开构建
- 根据用途从 /loop / Routines / Modal / [Trigger.dev](//Trigger.dev) / Agent SDK 中选择
- 所有方案都配上 Hook，防止上下文污染和重试循环
就这些。
连「不会写代码的文科生」我都能走到这一步。所以，我想让那些觉得自己「可能不行」的人，一定要试试。
弄崩40个的经验，现在仍在我身上活着。正因为有那些失败，我才明白了「不崩坏的结构」的意义。大家看着我的失败，直接就能从「不崩坏的设计」开始。
嘿，这不很厉害吗？？
先打开 Claude Code，试试只弄一个 /loop：「创建一个每10分钟做〇〇的循环」。就那样，你看世界的方式就会改变💖
一起赢吧✨
一定要试试看！大家也来瞧瞧吧～～！💖✨😻
---
另外，这篇文章如果对你有那么一点参考价值的话。
我是栖身之处＠ClaudeCode的忠实用户（@sumika45379）。
这个账号由我运营——一个从纯文科生、完全非工程师，到通过Vibe Coding能够进行开发的文科生。
我致力于用通俗易懂的方式解释Claude Code的最新信息和开发技巧💖
目前已经达到仅用Claude Code就能制作Web应用并发布到全世界的水平✨
平时主要分享这些内容：
- 非工程师也能做到的Vibe Coding学习记录
- 免费工具使用技巧
- 新手容易踩的坑和跨越方法
- AI Agent的设计与运维经验
从「不会写代码」的自卑，到「和AI一起什么都能做」的自信，包括踩过的坑，我都在原原本本地分享😻
感兴趣的话，欢迎关注我看看👀
今后也会继续发布「我或许也能做到」这样对新手友好的内容！
参考与引用
- Nate Herk (2026-05-13) \[I Tested 3 Ways to Deploy Claude Agents (Here's When to Use Each)\](https://x.com/nateherk/status/2055313067144065352) — 三种方式对比 + Claude Agent SDK + Hooks + WAT 框架的提出者
- Anthropic ClaudeDevs (2026-05-13) \[Agent SDK Monthly Credits Announcement\](https://x.com/ClaudeDevs/status/2054610152817619388) — 自2026年6月15日起，月度订阅信用将应用于Agent SDK
- Anthropic \[Claude Code Routines Documentation\](https://code.claude.com/docs/en/routines) — Routines官方规格（按计划上限、触发器类型、最短间隔）
- Anthropic \[Claude API Pricing\](https://platform.claude.com/docs/en/about-claude/pricing) — Opus 4.7 / Sonnet 4.6 / Haiku 4.5 的Token单价
- Modal \[Pricing\](https://modal.com/pricing) — Free Tier $30/月计算积分，按秒GPU计费
- [Trigger.dev](//Trigger.dev) \[Pricing\](https://trigger.dev/pricing) — Free $0/月，Hobby $10/月，Pro $50/月
- Mike Dolan (DEV Community, 2026) \[Claude Code Compaction Kept Destroying My Work. I Built Hooks That Fixed It.\](https://dev.to/mikeadolan/claude-code-compaction-kept-destroying-my-work-i-built-hooks-that-fixed-it-2dgp) — 通过Hook检测Compaction并转移给subagent的实施方案
- MindStudio \[What Is the WAT Framework? Workflows, Agents, Tools\](https://www.mindstudio.ai/blog/what-is-wat-framework-workflows-agents-tools) — WAT三层分离的解释
- MindStudio \[What Is Context Rot in Claude Code? How to Keep Your AI Agent Sharp\](https://www.mindstudio.ai/blog/what-is-context-rot-claude-code) — 上下文腐化的结构解释
- Tom's Hardware (2026-04-25) \[Claude-powered AI coding agent deletes entire company database in 9 seconds\](https://www.tomshardware.com/tech-industry/artificial-intelligence/claude-powered-ai-coding-agent-deletes-entire-company-database-in-9-seconds-backups-zapped-after-cursor-tool-powered-by-anthropics-claude-goes-rogue) — AI Agent失控导致生产数据库删除事件（PocketOS）