標籤: Claude

📌 本文重點

• 全上下文重送會讓長期 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
• 把 完整對話歷史 + 工具定義 + 系統提示 一起丟進去

問題：

1. token 費用幾乎線性成長：對話越長，每次重送的 tokens 越多，長期 Agent 變成「每句話都在重付歷史學費」。
2. 延遲被序列化成本綁死：100K context 每次 encode / decode 都是固定開銷，沒做 cache 再快的模型也救不了。
3. 易爆 context：聊久一點就逼近上限，被系統自動截斷，Agent 出現「金魚記憶」。

結論：永續 Agent 若不做 Prompt Caching，本質上不具備經濟可行性。

💡 關鍵： 對長期 Agent 而言，不做 Prompt Caching 意味著 token 成本和延遲會隨時間線性惡化，最終失去經濟可行性。

2. Warm-Cache 三層設計：工具、系統提示、歷史

核心想法：把「幾乎不變」的部分從請求中抽出來，讓 Claude 的 Prompt Caching 真正生效，同時在你自己的系統再加一層 cache。

三層結構：

1. 工具定義層（Tools Cache）
2. 例如 AWS 管理、Git 操作、MemPalace 查詢等工具定義
3. 用 穩定的 ID + 版本號 來標記（例如 aws_tools:v3）

4. 實作：

   • 本地用 JSON 檔 或 TypeScript enum 管理
   • 對 Claude 端利用 prompt_cache_key（概念上，可用 system prompt 方式固定）

5. 系統提示層（System Prompt Cache）

6. 定義 Agent 的角色、邊界、倫理規則（例如只能操作 Private VPC 而非公網）
7. 變動頻率低，但會跟版本、環境（staging/prod）綁定

8. 推薦：用 template + 版本號，例如 discord_infra_agent:v5

9. 歷史記錄層（Conversation Cache）

10. 只快取「近期對話 + 工具呼叫結果」的短期記憶
11. 長期記憶丟給向量庫（MemPalace / 自建 Milvus / PGvector），避免塞爆 context
12. 每個 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，做法是：

1. 短期記憶（Context Window）
2. Warm-Cache 上的歷史層，只保留最近 N 回合（例如 30）

3. 專門服務「連續對話」與「工具呼叫之前的局部上下文」

4. 長期記憶（向量庫 / MemPalace）

5. 把：
   • 專案 README
   • 關鍵 AWS 架構說明
   • 常見 Runbook / SOP

6. 全部 embed 成向量，存進 MemPalace / 其他向量庫

7. 查詢流程：

8. 使用者問問題 →

9. 先以「channel + user + 問題」做 embedding，去 MemPalace 找 Top-K 相關記憶片段
10. 把這些片段壓縮後，丟進當次 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-hit
• request_latency_ms：P50 / P95 / P99，分 model / route
• tool_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. 避免「刪庫跑路」：幾個實務守則

1. 只給「建議權」不給「直接執行權」 在 production
2. 例如：Agent 只能產生 Terraform / CloudFormation patch，由人類 review + apply。
3. 所有破壞性操作都經過雙重 gate：
4. system prompt 要求二次確認
5. backend 還要檢查「環境 + 操作類型」，prod 一律走人工流程
6. 完整審計 log：
7. 記錄：使用者指令、模型輸出、工具參數、執行結果
8. 存在 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，驗證一條完整安全鏈路