/always-on-agent-applications — 持久性與記憶力真正解鎖了什麼
你正在幫助某人規劃該用一個具有情節記憶的常駐型 AI 代理來建構什麼。這是「所以呢？」的技能 — 架構已經存在，輸入正在流動，現在它到底能做出什麼無狀態聊天機器人做不到的事情？
決策點
1. 常駐型 vs 基於會話的決策樹
評估任務需求：
├─ 任務需要跨會話的記憶？
│ └─ 否 → 使用基於會話的代理（更便宜、更簡單）
│ └─ 是 ↓
├─ 任務能從主動行為中受益？
│ └─ 否 → 使用具有記憶的排程代理
│ └─ 是 ↓
├─ [持久性 ROI] > [基礎設施成本]？
│ └─ 否 → 從基於會話開始，之後再升級
│ └─ 是 ↓
├─ 領域夠狹窄以確保記憶品質？
│ └─ 否 → 縮小範圍（僅限會議、僅限程式碼）
│ └─ 是 → 建構常駐型代理
ROI 計算：
- 持久性 ROI = (任務頻率 × 每次任務節省的時間 × 用戶每小時價值)
- 基礎設施成本 = (伺服器成本 + 記憶儲存 + 開發時間)
如果 ROI > 3 倍成本：建構常駐型 如果 ROI 在 1-3 倍成本之間：從基於會話開始，先驗證價值 如果 ROI < 1 倍成本：使用現有工具
2. 應用類別選擇
用戶問「我該建構什麼？」：
├─ 主要工作流程是寫程式？
│ └─ 是 → 開發者伴侶模式
│ └─ 否 ↓
├─ 主要需求是會議/溝通管理？
│ └─ 是 → 個人幕僚長模式
│ └─ 否 ↓
├─ 主要目標是學習/知識工作？
│ └─ 是 → 學習日誌模式
│ └─ 否 ↓
├─ 重點是健康/習慣追蹤？
│ └─ 是 → 健康觀察者模式（安全敏感性高）
│ └─ 否 → 專案協調者或環境智能
3. 範圍邊界決策
用戶提出跨領域代理：
├─ 這是他們第一個常駐型代理嗎？
│ └─ 是 → 強制單一垂直領域（選擇 ROI 最高的）
│ └─ 否 ↓
├─ 他們有超過 6 個月的開發時間嗎？
│ └─ 否 → 僅限單一垂直領域
│ └─ 是 ↓
├─ 他們能為每個領域定義成功指標嗎？
│ └─ 否 → 縮小範圍直到能做到為止
│ └─ 是 → 允許多領域，但需分階段推出
4. 主動行為校準
配置代理打斷頻率：
├─ 用戶工作風格是深度專注時段？
│ └─ 是 → 批次通知，尊重專注訊號
│ └─ 否 ↓
├─ 用戶明確要求高互動協助？
│ └─ 是 → 允許即時打斷，但需符合相關性門檻
│ └─ 否 ↓
├─ 預設值：80% 被動反應，15% 被動主動，5% 主動主動
失敗模式
1. 幻覺記憶症候群
症狀：代理自信地引用從未發生過的對話或事件 檢測規則：如果代理聲稱具體引述/日期/事實，但無法提供確切的來源時間戳 根本原因：檢索到的上下文與生成的回應之間記憶邊界不佳 修復方法：實施嚴格的記憶引用要求 — 代理必須將每個聲明連結到具有時間戳的特定記憶條目
2. 記憶污染級聯
症狀：代理效能隨時間下降，回應中出現矛盾資訊 檢測規則：如果代理在 7 天內針對同一主題給出相互矛盾的建議，且未承認變化 根本原因：低品質觀察累積速度超過有價值訊號 修復方法：實施記憶衛生措施：相關性評分、自動壓縮、用戶觸發的記憶清理
3. 成本失控爆炸
症狀：月度帳單增加 30% 以上，但價值沒有成比例增加 檢測規則：如果每次有用互動的成本在 30 天內比基準線上升超過 50% 根本原因：代理過度處理低價值輸入（通知、垃圾郵件、自動化電子郵件） 修復方法：輸入過濾管道、記憶存取預算、主動成本監控與自動限流
4. 範圍蔓延癱瘓
症狀：代理試圖處理所有事情，但無一精通，用戶在 2 週後放棄使用 檢測規則：如果代理有超過 5 個不同的應用垂直領域，且未為每個領域定義明確的成功指標 根本原因：建構「通用助手」而非聚焦工具 修復方法：強制從單一垂直領域開始，要求設定畢業條件才能擴展
5. 隱私違規漂移
症狀：代理意外地在不同上下文之間分享敏感資訊 檢測規則：如果代理在錯誤的上下文中提到個人/工作細節（在個人聊天中提及工作資訊） 根本原因：記憶邊界與用戶隱私期望不一致 修復方法：上下文隔離、明確的記憶分區、定期隱私審計
實際範例
範例：建構開發者伴侶代理
情境：軟體工程師希望代理協助程式碼審查和 PR 描述
步驟 1 - 範圍定義
- 用戶：「我想要一個能幫我寫更好程式的 AI」
- 應用決策樹：寫程式工作流程 = 開發者伴侶模式
- 縮小範圍：「僅限 PR 描述生成」（非完整的編碼助手）
步驟 2 - ROI 計算
- 任務頻率：每天 3 個 PR × 5 天 = 每週 15 個 PR
- 節省時間：每個 PR 描述 5 分鐘 = 每週 75 分鐘 = 每年 65 小時
- 用戶價值：每小時 $150 × 65 小時 = 每年 $9,750
- 基礎設施成本：每月約 $50 = 每年 $600
- ROI = 16 倍 → 建構常駐型代理
步驟 3 - 記憶策略
- 核心記憶：目前功能分支、最近 5 次提交、關於程式碼變更的近期對話
- 回顧記憶：用戶偏好的 PR 模板、審查者回饋模式、專案編碼標準
- 歸檔記憶：歷史 PR、團隊溝通風格、專案決策與理由
步驟 4 - 觸發器設計
triggers:
- git_push_to_feature_branch: 草擬 PR 描述
- pr_opened: 用上下文增強描述
- code_review_received: 記錄回饋模式供未來使用
步驟 5 - 品質閘門
- PR 描述包含實際理由（非一般性摘要）
- 代理引用具體的提交/檔案
- 80% 的生成描述需要少於 2 分鐘的編輯
- 代理正確識別 PR 何時橫跨多個關注點
新手會錯過的重點：從「萬能 AI 編碼助手」開始 專家會注意的重點：聚焦於單一高價值工作流程（PR 描述），其中持久性對無狀態解決方案具有明顯優勢
品質閘門
當滿足所有條件時，應用設計才算完成：
- 清晰的 ROI 計算，顯示 >3 倍成本效益
- 單一垂直領域範圍，含定義的邊界
- 記憶成長受到壓縮策略的限制
- 主動行為頻率已配置（低於總互動的 20%）
- 成功指標已定義且可衡量
- 用戶隱私邊界已明確標示
- 冷啟動體驗無需累積記憶即可運作
- 已實施用戶記憶控制的終止開關
- 已設定成本監控與自動限流閾值
- 已定義範圍擴展的畢業條件
非適用範圍
請勿將此技能用於：
- 建構記憶架構 → 請改用
always-on-agent-architecture - 設計輸入來源與觸發器 → 請改用
always-on-agent-inputs - 安全、隱私與成本問題 → 請改用
always-on-agent-safety - 通用代理模式與循環 → 請改用
agentic-patterns - 評估 AI 安全風險 → 請改用
ai-safety-engineer - 技術基礎設施決策 → 請改用
systems-architecture
當用戶詢問時，委派給其他技能：
- 「如何儲存情節記憶？」 →
always-on-agent-architecture - 「我的代理應該監看哪些資料？」 →
always-on-agent-inputs - 「這樣安全/私密嗎？」 →
always-on-agent-safety - 「如何建構代理循環？」 →
agentic-patterns