/always-on-agent-inputs — 為持續性代理提供情境輸入
你正在設計一個永遠在線的代理能看到、聽到和知道些什麼。架構技能負責處理記憶的存放位置。這個技能則負責處理輸入的內容——原始訊號、它們的結構化方式、代理何時被喚醒，以及如何保持情境視窗的誠實性。
決策點
檢索策略選擇
代理任務類型 → 檢索策略
如果是對話/聊天：
├─ 使用近期優先（70% 時間性，30% 語義性）
├─ 預算：15K 對話歷史 + 4K 近期回憶
└─ 除非使用者問「還記得…」，否則跳過歸檔
如果是問題解決/除錯：
├─ 使用相關性優先（60% 語義性，40% 時間性）
├─ 預算：8K 歸檔 + 4K 回憶 + 2K 環境
└─ 包含過去解決方案的錯誤模式
如果檢測到情境切換：
├─ 使用頻率優先（使用者最常處理什麼？）
├─ 預算：6K 專案情境 + 2K 近期 + 4K 目標
└─ 為活躍檔案/人員提取實體歷史
如果是排程觸發（早晨簡報）：
├─ 使用結構化議程（行事曆 + 任務 + 更新）
├─ 預算：4K 行事曆 + 4K 未完成任務 + 2K 變更
└─ 不需要對話歷史
如果是反應式觸發（CI 失敗、會議開始）：
├─ 使用特定事件的情境載入
├─ 預算：8K 事件情境 + 4K 相關歷史
└─ 除非相關，否則跳過一般對話
環境資料過濾
螢幕/音訊觀測 → 過濾決策
如果相同應用程式 + 相同文字超過 5 分鐘：
└─ 丟棄（無變化，視為雜訊）
如果檢測到應用程式切換：
├─ 保留切換記錄
└─ 評估新應用程式內容的相關性分數
如果發現高訊號關鍵字：
├─ 對照活躍專案/目標進行檢查
├─ 如果匹配分數 >0.6 → 儲存至歸檔 + 回憶
├─ 如果匹配分數 0.3-0.6 → 僅儲存至回憶
└─ 如果匹配分數 <0.3 → 丟棄
如果看到技術錯誤/例外：
├─ 總是儲存（除錯情境）
└─ 標記緊急程度
如果提到行事曆事件：
├─ 總是儲存（時間錨點）
└─ 與實際行事曆交叉比對
觸發緊急度指派
事件類型 + 情境 → 緊急程度
如果是 CI 失敗：
├─ 生產分支 → 主動（通知使用者）
├─ 功能分支 + 使用者正在編碼 → 被動（下次使用者互動時提及）
└─ 舊分支/PR → 靜默（僅記錄）
如果是會議即將開始：
├─ <5 分鐘 → 主動（中斷並提供準備事項）
├─ 5-15 分鐘 → 徽章（顯示準備事項可用）
└─ >15 分鐘 → 靜默（背景準備）
如果檢測到程式碼變更：
├─ 新分支的首次提交 → 被動（記錄新工作）
├─ 提交修正先前的錯誤 → 被動（記錄解決方案）
└─ 一般提交 → 靜默（追蹤進度）
如果在 Slack 中被提及：
├─ 直接訊息 → 主動（需要回應）
├─ 頻道提及 + 緊急關鍵字 → 主動
└─ 頻道提及，一般 → 徽章（方便時檢閱）
失敗模式
結構膨脹
- 症狀： 情境視窗持續滿載，回應緩慢，儘管有過濾機制，token 成本仍高
- 根本原因： 觀測結構擷取每個欄位，而非僅代理推理所需的內容
- 檢測規則： 如果平均情境大小 >50K tokens 或觀測儲存空間 >1MB/天，表示有結構膨脹
- 修正方式： 每月稽核結構。移除過去 30 天未影響決策的欄位。使用摘要而非原始儲存。
檢索抖動
- 症狀： 代理提及過時資訊，遺漏近期情境，或反覆檢索不相關的記憶
- 根本原因： 單次向量搜尋未經重新排序，或時間/語義權重調整不佳
- 檢測規則： 如果超過 30% 的檢索情境在回應中未被使用，或使用者糾正代理關於近期事件
- 修正方式： 實作兩階段檢索（廣泛搜尋 + 重新排序）。A/B 測試不同的時間/語義權重比例。
觸發垃圾訊息
- 症狀： 使用者關閉代理通知，抱怨中斷，或代理被忽略
- 根本原因： 沒有緊急度分層，或主動/中斷觸發的門檻設定過低
- 檢測規則： 如果使用者關閉超過 50% 的主動通知，或平均使用者互動間隔 >4 小時
- 修正方式： 預設所有為靜默。讓使用者明確設定哪些值得主動通知。追蹤關閉率。
情境過時
- 症狀： 代理根據過時資訊行動，忽略使用者已改變關注點/專案
- 根本原因： 情境缺乏新鮮度衰減，或檢索權重未充分考慮時效性
- 檢測規則： 如果代理在已有近期情境時仍引用超過 7 天的資訊，或提及已完成的專案
- 修正方式： 對相關性分數添加指數衰減。對近期觀測給予 2-3 倍於歸檔的權重。
環境雜訊氾濫
- 症狀： 高成本，回應品質差，代理提及無關的螢幕內容
- 根本原因： 原始環境資料繞過過濾機制，或相關性門檻設定過於寬鬆
- 檢測規則： 如果環境觀測占儲存記憶超過 30%，或 token 成本 >10 美元/天
- 修正方式： 緊縮相關性評分。將環境觀測批次處理為 5 分鐘視窗。需要 2 個以上訊號來確認相關性。
實作範例
情境：在 Token 預算限制下調查帳務錯誤
使用者回報：「企業客戶的帳務計算有問題。」
步驟 1：情境預算分配（總計 40K）
系統 + 身份：4K tokens（固定）
核心記憶：2K tokens（使用者偏好、活躍專案）
決策：問題解決任務 → 使用相關性優先檢索
分配：8K 歸檔 + 4K 回憶 + 2K 環境 + 15K 對話 + 5K 輸出緩衝區
步驟 2：執行檢索策略
# 針對帳務相關記憶進行廣泛語義搜尋
archival_candidates = vector_search(
query="企業客戶帳務計算錯誤錯誤"，
top_k=20,
filters={"project": ["帳務", "付款"]}
)
# 根據真實相關性重新排序（而非僅嵌入相似度）
reranked = rerank_results(archival_candidates, query, top_k=5)
# 結果：取得「3 週前的企業折扣邏輯錯誤」
# 純向量搜尋將其排在第 12 位
# 針對近期帳務工作的時間搜尋
recent_work = temporal_search(
time_range="last_7_days",
entity_filters=["帳務", "企業"],
max_results=3
)
# 結果：使用者昨天正在除錯定價層級
步驟 3：整合環境情境
# 檢查使用者目前正在做什麼
screen_summary = get_ambient_summary(last_30_minutes)
# 結果：「使用者開啟了 billing_calculator.py，正在查看
# calculate_enterprise_discount() 函數」
# 預算檢查：8K 歸檔 + 4K 近期 + 2K 環境 = 14K（符合預算）
步驟 4：快速 vs 完整權衡 代理有兩個選擇：
- 快速檢索（當前）： 14K 情境，專注於近期錯誤模式
- 完整情境： 添加 git 歷史、相關 PR 討論（+8K tokens，超出預算）
決策： 為初始回應保留快速檢索。如果使用者要求深入調查，則觸發後續動作並擴展情境預算。
代理回應品質：
- 新手方法： 會傾倒所有帳務相關情境，超過預算，得到混亂的回應
- 專家方法： 策劃最相關的 14K 情境，提及 3 週前僅靠向量搜尋可能會遺漏的特定企業折扣錯誤，並維持在預算內
品質門檻
- 情境視窗分配已明確按層級預算（系統/核心/檢索/對話）
- 常規互動中，每次請求的 token 總數平均低於 40K
- 環境觀測在儲存前已通過相關性管線過濾
- 檢索使用兩階段流程（廣泛搜尋 + 重新排序）
- 所有觸發器都按緊急程度分類（靜默/徽章/被動/主動/中斷）
- 觀測結構包含時間戳記、信心分數和來源
- 過濾管線已測試：在回應中未使用的檢索情境少於 30%
- 使用者關閉的主動通知少於 20%（觸發垃圾訊息檢查）
- 代理在可用時會優先引用近期資訊（過去 24 小時），而非預設使用歸檔
- 每位使用者的儲存成長率低於 100MB/週（效率檢查）
「不適用」範圍
使用 /always-on-agent-inputs 來處理：
- 決定應從使用者環境中擷取哪些資料
- 建構觸發器和觀測結構
- 情境視窗預算配置和檢索策略選擇
- 在環境資料到達代理前對其進行過濾
請勿用於：
- 記憶體架構設計（向量資料庫、資料庫、記憶層級）→ 請使用
/always-on-agent-architecture - 應用程式與使用案例發想 → 請使用
/always-on-agent-applications - 所擷取資料的隱私與安全 → 請使用
/always-on-agent-safety - 一般提示工程技巧 → 請使用
/prompt-engineer - 代理推理模式 → 請使用
/agentic-patterns