48小時內(nèi)，RapidClaw的代碼庫經(jīng)歷了一次靜默重構(gòu)。不是因為客戶投訴，而是因為Anthropic發(fā)布了一個功能：Claude Code Routines。這家只有兩名成員、服務(wù) handful 客戶的精品代理運維工作室，突然發(fā)現(xiàn)自己過去一年的工作模式被重新定義了。

從"每次從零開始"到"代理自己記得"

Tijo Bear和他的兄弟Brandon運營RapidClaw的方式很典型：客戶需要每周競品掃描，他們就寫一段一次性提示詞，周一調(diào)用API，把輸出粘貼進文檔，然后結(jié)束。每個運行都是獨立的孤島。

問題在于：代理兩周前已經(jīng)分析過競爭對手X，這次運行卻一無所知。Tijo Bear為此手寫了一個去重層——300行Python代碼，凌晨三點客戶報告缺失時還得自己調(diào)試。

Routines的功能描述很樸素：讓代理定義一段工作，保存它，按調(diào)度或觸發(fā)器運行，無需人類每次重新提示。但關(guān)鍵差異在于所有權(quán)轉(zhuǎn)移——調(diào)度邏輯和跨運行狀態(tài)，現(xiàn)在由代理自己持有。

那個300行的外部膠水層，可以消失了。

狀態(tài)持久化的隱性賬單

技術(shù)討論區(qū)熱衷把Routines比作定時任務(wù)（cron）或Zapier流程，這種類比沒錯，但漏掉了成本維度。Tijo Bear在48小時的重寫中重新計算了內(nèi)部估算器：代理跨運行保持狀態(tài)，需要為狀態(tài)付費——以token、存儲或熱進程計算資源的形式。

這不是反對意見，而是運營現(xiàn)實。小型團隊的優(yōu)勢在于精簡，任何"看起來免費"的抽象層都需要被拆解到資源消耗層面重新評估。

當(dāng)代理擁有日歷，人類失去什么

Routines制造了一個反直覺的困境：自動化程度越高，可審計性越差。Tijo Bear此前寫過為什么監(jiān)控AI代理會"悄悄吃掉你的周末"，而持久化例程讓這個問題更尖銳。

需要的追蹤維度在膨脹：代理做了什么、跳過了什么、推遲了什么、為什么推遲。如果無法端到端追蹤一次運行，"你運行的不是代理，而是一個帶著日歷邀請的黑箱"——這是RapidClaw從實踐中學(xué)到的邊界定義。

兩人工作室的架構(gòu)選擇

RapidClaw的客戶規(guī)模決定了他們的決策權(quán)重與大型平臺完全不同。一個需要凌晨三點調(diào)試的300行Python模塊，對十人團隊可能是可接受的運維成本；對兩人工作室則是睡眠債務(wù)和客戶服務(wù)風(fēng)險的直接換算。

Routines的價值在這個尺度上被重新校準(zhǔn)：不是"能調(diào)度什么"，而是"能刪除多少外部膠水代碼"。每減少一層手動維護的中間件，就減少了一個故障點和一份認知負擔(dān)。

但Tijo Bear的48小時重寫也暴露了一個未解決的 tension：代理自主性的提升，與人類監(jiān)督責(zé)任的重新分配。當(dāng)代理自己決定"推遲到下次處理"時，推遲的標(biāo)準(zhǔn)是什么？如何被審計？這些不是技術(shù)實現(xiàn)問題，是服務(wù)提供商對客戶的解釋責(zé)任問題。

對于銷售"精品白手套代理運維"的兩人工作室，這或許是比代碼重構(gòu)更根本的商業(yè)模式問題：當(dāng)代理越來越像長期雇員而非臨時承包商，服務(wù)邊界在哪里劃定，計費邏輯如何重新設(shè)計？