📌 本文重點
- 全上下文重送會讓長期 Agent 在成本與延遲上崩盤
- 用 Warm-Cache 三層快取可把成本壓到約 1/8
- 短期 context + 向量庫分層記憶可兼顧長期記憶與成本
- 嚴格工具邊界與審計是讓 Claude Agent 能上線的關鍵
在 Discord 上跑一個長期管理 AWS 基礎設施與程式碼的 Claude Agent，如果每次請求都把 全上下文重送，你很快就會發現兩個殘酷事實：token 費用爆炸、延遲高到用不下去。實測數據來看，透過 Warm-Cache + 分層記憶架構，可以把成本壓到原本的 1/8 左右，P95 latency 也從 10+ 秒壓到 3 秒內，而且邏輯與安全性更可控。
💡 關鍵： 透過結構化快取與記憶分層設計，可以同時把成本壓到約 1/8，並把 P95 延遲從 10 秒級降到 3 秒內，讓長期 Agent 實際可用。
重點說明
1. 為什麼「全上下文重送」會崩盤？
典型實作：
- 每個 Discord 訊息 → 直接呼叫
/v1/messages - 把 完整對話歷史 + 工具定義 + 系統提示 一起丟進去
問題：
- token 費用幾乎線性成長：對話越長，每次重送的 tokens 越多，長期 Agent 變成「每句話都在重付歷史學費」。
- 延遲被序列化成本綁死：100K context 每次 encode / decode 都是固定開銷，沒做 cache 再快的模型也救不了。
- 易爆 context：聊久一點就逼近上限，被系統自動截斷，Agent 出現「金魚記憶」。
結論：永續 Agent 若不做 Prompt Caching，本質上不具備經濟可行性。
💡 關鍵： 對長期 Agent 而言，不做 Prompt Caching 意味著 token 成本和延遲會隨時間線性惡化，最終失去經濟可行性。
2. Warm-Cache 三層設計：工具、系統提示、歷史
核心想法：把「幾乎不變」的部分從請求中抽出來，讓 Claude 的 Prompt Caching 真正生效，同時在你自己的系統再加一層 cache。
三層結構：
- 工具定義層（Tools Cache）
- 例如 AWS 管理、Git 操作、MemPalace 查詢等工具定義
- 用 穩定的 ID + 版本號 來標記（例如
aws_tools:v3） -
實作：
- 本地用 JSON 檔 或 TypeScript enum 管理
- 對 Claude 端利用
prompt_cache_key（概念上，可用 system prompt 方式固定）
-
系統提示層（System Prompt Cache）
- 定義 Agent 的角色、邊界、倫理規則（例如只能操作 Private VPC 而非公網）
- 變動頻率低，但會跟版本、環境（staging/prod）綁定
-
推薦：用 template + 版本號，例如
discord_infra_agent:v5 -
歷史記錄層（Conversation Cache）
- 只快取「近期對話 + 工具呼叫結果」的短期記憶
- 長期記憶丟給向量庫（MemPalace / 自建 Milvus / PGvector），避免塞爆 context
- 每個 channel / user 維護一個 sliding window，例如最近 30 則訊息
典型資料結構（TypeScript）：
type CacheKey = string; // e.g. "tools:aws:v3", "sys:discord_agent:v5"
interface WarmCacheEntry {
version: string;
contentHash: string;
serialized: string; // 已處理過、可直接拼進 messages 的 JSON 字串
updatedAt: number;
}
class WarmCache {
private store = new Map<CacheKey, WarmCacheEntry>();
get(key: CacheKey): WarmCacheEntry | undefined {
return this.store.get(key);
}
set(key: CacheKey, entry: WarmCacheEntry) {
this.store.set(key, entry);
}
}
版本管理與失效策略：
- 工具或系統提示改版 → 直接 變更 version（
v3→v4），讓舊 cache 自然失效 - 每次啟動時計算一遍
contentHash，若 hash 改變但 version 沒變，log 出警告避免「隱性分叉」
3. 長期記憶：MemPalace + 短期上下文的分層設計
要讓 Agent 在 Discord 長期「記得」你的 AWS 結構、服務慣例，又不把所有東西塞進 context，做法是：
- 短期記憶（Context Window）
- Warm-Cache 上的歷史層，只保留最近 N 回合（例如 30）
-
專門服務「連續對話」與「工具呼叫之前的局部上下文」
-
長期記憶（向量庫 / MemPalace）
- 把：
- 專案 README
- 關鍵 AWS 架構說明
- 常見 Runbook / SOP
-
全部 embed 成向量，存進 MemPalace / 其他向量庫
-
查詢流程：
-
使用者問問題 →
- 先以「channel + user + 問題」做 embedding，去 MemPalace 找 Top-K 相關記憶片段
- 把這些片段壓縮後，丟進當次 system 或 user message 的前置 context
簡單 Python 記憶層（SQLite + 向量庫 ID）示意：
import sqlite3
conn = sqlite3.connect("memory.db")
cur = conn.cursor()
cur.execute("""
CREATE TABLE IF NOT EXISTS long_term_memory (
id INTEGER PRIMARY KEY,
user_id TEXT,
channel_id TEXT,
vector_id TEXT, -- 真正的向量存在 MemPalace / pgvector
summary TEXT,
created_at INTEGER
);
""")
# 檢索時：先從 MemPalace 拿相關 vector_id，再 join 回 summary
好處：
- context 永遠保持在一個可以預估的上限
- 記憶可審計、可搜索，而不是全埋在 opaque 的 token 流裡
實作範例
1. Node.js：Claude Warm-Cache middleware
以下是假想的 middleware，包裝 /v1/messages 呼叫，示意如何組合三層快取與向量記憶：
import { claudeClient } from "./claude";
import { WarmCache } from "./warmCache";
import { fetchMemories } from "./memPalace";
const cache = new WarmCache();
export async function handleDiscordMessage(ctx: {
channelId: string;
userId: string;
message: string;
history: any[]; // 最近 N 則對話
}) {
const toolsKey = "tools:aws:v3";
const sysKey = "sys:discord_infra_agent:v5";
const tools = cache.get(toolsKey) ?? buildAndCacheTools(toolsKey);
const systemPrompt = cache.get(sysKey) ?? buildAndCacheSystem(sysKey);
const longTerm = await fetchMemories(ctx.userId, ctx.channelId, ctx.message);
const messages = [
{ role: "system", content: systemPrompt.serialized },
{ role: "user", content: buildUserContent(ctx.message, longTerm) },
...ctx.history
];
const res = await claudeClient.messages.create({
model: "claude-3.7-sonnet",
max_tokens: 1024,
tools: JSON.parse(tools.serialized),
messages
});
return res;
}
關鍵點：
tools、systemPrompt都是快取後的 序列化結果，避免每請求重組history控制在固定長度，長期記憶透過fetchMemories注入
2. Claude 系統 Prompt 模板（安全與邊界）
你是一個在 Discord 裡專門協助管理 AWS 基礎設施與程式碼庫的 Agent。
嚴格規則：
- 只能透過提供的工具存取資源，禁止自行連線外部網路。
- 所有操作必須限制在指定的 AWS Account 與 VPC，禁止新增具有公開網路權限的資源。
- 若使用者要求執行具破壞性的操作（刪庫、清 bucket、關閉整個叢集），必須：
1. 先以自然語言解釋風險與影響。
2. 要求使用者提供明確確認字串（例如 "CONFIRM_DELETE_PROD"）。
3. 仍應優先建議更安全的替代方案。
審計要求：
- 對每一次工具呼叫，以簡潔 JSON 描述操作意圖與參數，方便後續寫入 audit log。
3. Redis-based 歷史快取（短期記憶）
import redis
import json
r = redis.Redis(host="localhost", port=6379, db=0)
HISTORY_LIMIT = 30
def push_history(channel_id: str, message: dict):
key = f"history:{channel_id}"
r.lpush(key, json.dumps(message))
r.ltrim(key, 0, HISTORY_LIMIT - 1)
def get_history(channel_id: str):
key = f"history:{channel_id}"
return [json.loads(x) for x in r.lrange(key, 0, -1)][::-1]
建議與注意事項
1. 監控：請求數、token、P95 latency 要一起看
至少打三個 metrics：
token_usage_total：區分 prompt / completion / cache-hitrequest_latency_ms：P50 / P95 / P99，分 model / routetool_invocation_count：看 Agent 是否頻繁誤用工具
優化策略：
- 發現 P95 延遲高但 token 不高 → 多半是工具 / 外部 API 慢
- 發現 token 緩慢上升 → 歷史快取 window 太大、向量記憶注入過多
2. MCP / 工具設計：少而精 + 嚴格邊界
- 像 PullMD 那樣，利用 MCP 把「HTML 轉 Markdown」這種重複工作下沉到工具層，避免讓 LLM 直接吃原始 HTML，token 省很大。
- 工具要：
- 明確輸入輸出 schema
- 在私有網路中運行（Docker / Kubernetes namespace）
- 只開最小必要權限（IAM 最小權限 + security group 限制）
3. 避免「刪庫跑路」：幾個實務守則
- 只給「建議權」不給「直接執行權」 在 production
- 例如：Agent 只能產生 Terraform / CloudFormation patch，由人類 review + apply。
- 所有破壞性操作都經過雙重 gate：
- system prompt 要求二次確認
- backend 還要檢查「環境 + 操作類型」，prod 一律走人工流程
- 完整審計 log：
- 記錄：使用者指令、模型輸出、工具參數、執行結果
- 存在 append-only storage（CloudWatch Logs / Loki / S3 + Object Lock）
4. 部署拓撲：限制在私有網路
- Discord Bot → Gateway → Agent 後端（VPC 內）→ MCP 工具（同 VPC）
- 往外只有到 Claude API + 向量庫（若是 SaaS） 的 egress
- 不讓 Agent 直接 hit 公網，避免「自己 curl 一個 random script 來跑」這類事故
總結：
- 用 Warm-Cache 三層快取（工具、系統、歷史）+ 分層記憶（短期 context + MemPalace 長期記憶），可以在實戰中穩定做到 成本 ≈ 1/8、P95 latency < 3s。
- 關鍵不是「多堆一點 GPU」，而是把「一次性 prompt」變成「可重用的結構」，再加上嚴格邊界與審計，讓你的 Claude 永續 Agent 真正能上 production。
把上面的 middleware + Redis + SQLite/向量庫實作搬進你的客服 bot、infra bot 或內部 Copilot，大部分情況下只需要換掉工具與系統 prompt，就能直接開始省錢又提速。
🚀 你現在可以做的事
- 在現有 Discord / Slack Bot 中，先實作一層 Warm-Cache，把工具定義與系統提示抽出並版本化
- 建一個最小可行的向量庫（MemPalace 或 pgvector），將 README、架構文件與 Runbook 全部 embed 進去
- 為 production 環境補上系統 prompt 邊界、工具權限縮減與審計 log pipeline，驗證一條完整安全鏈路
