📌 本文重點
- Sonnet 5 適合作為預設 Agent 主力模型
- 成本遠低於頂級模型且能力接近 Opus
- 長上下文與工具調用適合多步驟工作流
- 安全策略偏保守，較利企業導入
Claude Sonnet 5 解決的痛點很直接：想做多步驟 Agent 工作流，但 Opus / GPT 旗艦太貴、開源模型又不夠穩。Sonnet 5 在長上下文、工具調用和安全策略上已能覆蓋大多數企業場景，同時單 token 成本顯著低於頂級模型，適合作為預設 Agent 基座，只在少數高難度任務再切換到更強模型。
重點說明：為什麼 Sonnet 5 值得當主力 Agent 模型？
1. 能力與成本曲線：接近 Opus，價格接近中階
根據公開基準與 The Decoder 報導，Claude Sonnet 5 在 GDPval-AA v2 知識工作測試上已超過 Opus 4.8，但定價仍是「中階模型」等級。
💡 關鍵： Sonnet 5 在知識工作表現已追近甚至超過頂級模型，但價格仍是中階，適合作為大多數任務的預設主力。
實際含義：
- 一般知識工作 / 文件處理 / 商務決策代理，Sonnet 5 足以勝任，不需要
Opus 級別。
- 若你現在線上大量跑
GPT-4.5 / GPT-5.5 這類旗艦模型，把 70–80% 任務切到 Sonnet 5，只在高風險、高價值 task 才升級模型，通常能立刻降下 30–50% API 費用。
2. 長上下文 + 工具調用：更適合多步驟流水線
實務上 agent 不是一兩輪對話，而是：
- 讀長文件 / 多來源資料
- 規劃任務
- 多輪工具調用（
DB / API / Code Interpreter）
- 產出決策或報告
Sonnet 5 的優勢：
- 長上下文：支援巨大
context（依官方規格，多數情境已可覆蓋數十萬 token 級）。對 RAG + workflow 代表：
- 可以減少 aggressive chunking，讓模型一次看到完整流程 / 合約 / 需求文檔。
- 可以把多輪工具結果與中間推理保留在同一對話，減少「忘記之前做了什麼」。
- 工具調用（Tool Use）：支援結構化工具
schema，類似 OpenAI functions / tools，並在安全策略上更保守（例如對可疑指令會自動拒絕調用某些敏感工具）。這對企業代理的好處是：
- 減少「亂調
API」的風險
- 在合規敏感場景（金融、法務）較容易通過審查
3. 安全策略：有意識地「不做太強」的資安能力
Anthropic 明確說 Sonnet 5 在網路攻擊和資安任務上的能力刻意壓低，低於某些已被政府封鎖的模型。這點對企業是加分：
- 在碼農代理 /
DevOps Agent場景，可以寫 code、修 bug，但不太會幫你設計攻擊腳本。
- 對內部稽核來說，可當作「內建安全減速器」，搭配額外安全層更容易說服安全部門。
實作範例：用 Sonnet 5 搭建多步驟 Agent 工作流
以下用類 pseudo-code 展示一個文件審閱 + 系統操作的多步驟 Agent pipeline，並示範如何在 Sonnet 5 / Opus / 開源模型間切分任務。
1. 基本呼叫：帶工具的 Sonnet 5 Agent
import anthropic
client = anthropic.Anthropic(api_key=ANTHROPIC_API_KEY)
TOOLS = [
{
"name": "fetch_contract",
"description": "依 contract_id 取得最新合約全文",
"input_schema": {
"type": "object",
"properties": {"contract_id": {"type": "string"}},
"required": ["contract_id"]
}
},
{
"name": "update_crm",
"description": "更新 CRM 中的客戶標籤與備註",
"input_schema": {
"type": "object",
"properties": {
"customer_id": {"type": "string"},
"tags": {"type": "array", "items": {"type": "string"}},
"note": {"type": "string"}
},
"required": ["customer_id", "note"]
}
}
]
SYSTEM_PROMPT = """
你是一個企業合約審閱 Agent：
- 先閱讀合約與上下文
- 給出風險摘要與建議
- 如有需要，呼叫工具 fetch_contract / update_crm 完成任務
- 僅在確定資訊足夠時才更新 CRM
"""
resp = client.messages.create(
model="claude-3.7-sonnet-5", # **核心：以 Sonnet 5 當主力 agent**
max_tokens=2048,
temperature=0.2,
system=SYSTEM_PROMPT,
tools=TOOLS,
messages=[{
"role": "user",
"content": [
{"type": "text", "text": "請審閱合約 C-2025-018，並視需要更新 CRM。"}
]
}]
)
for content_block in resp.content:
if content_block.type == "tool_use":
tool = content_block
if tool.name == "fetch_contract":
contract = fetch_contract_from_db(tool.input["contract_id"]) # 你的實作
# 把 tool result 回傳給 Sonnet 5，形成多輪 agent 流程
resp = client.messages.create(
model="claude-3.7-sonnet-5",
max_tokens=2048,
messages=[
{"role": "assistant", "content": [tool]},
{"role": "user", "content": [{
"type": "tool_result",
"tool_use_id": tool.id,
"content": contract
}]}
]
)
重點設定：
model：用 claude-3.7-sonnet-5 當預設 Agent，引導它做規劃 + 工具決策。tools：一定要寫清楚用途與輸入 schema，Sonnet 5 的工具調用在描述清晰時會穩定很多。temperature=0.2：工作流類場景建議偏低，避免「創造力」帶來流程偏離。
2. 多模型架構：什麼給 Sonnet 5，什麼留給 Opus / 開源？
可採用一個簡單的 routing layer：
from enum import Enum
class TaskClass(Enum):
KNOWLEDGE_WORK = "knowledge_work" # 合約審閱、報告撰寫
HEAVY_REASONING = "heavy_reasoning" # 複雜架構設計、難題推理
LIGHT_UTILITY = "light_utility" # 文本清洗、格式轉換
def route_model(task: TaskClass) -> str:
if task == TaskClass.KNOWLEDGE_WORK:
return "claude-3.7-sonnet-5" # **主力：成本與能力平衡點**
if task == TaskClass.HEAVY_REASONING:
return "claude-3.7-opus" # 僅在高價值、關鍵決策時啟用
if task == TaskClass.LIGHT_UTILITY:
return "local-llama-3.2-8b" # 或任一開源模型，跑在自家 GPU
# 用法
model_id = route_model(TaskClass.KNOWLEDGE_WORK)
resp = client.messages.create(
model=model_id,
...
)
實務建議：
- 70–80% 任務：給 Sonnet 5（常駐
Agent、日常工作流）。
- 10–20% 高難度：需要高可靠
reasoning / 風險極高決策 → 升級到 Opus / GPT-5.5 類。
- 剩餘雜務：可以用開源模型批量處理（
log 清洗、模板生成、簡單分類）。
3. 記憶系統整合：避免「每次都要重新教」
參考 Hermes 記憶系統的經驗，問題通常不在模型，而在記憶層設計。
核心做法：
- 把
Agent 視為「無狀態推理引擎」，持久狀態放在你自己的記憶服務（DB + 向量庫）。
簡化示意：
# 1) 從 persistent storage 取出該使用者的長期記憶
memories = memory_store.query(user_id="u_123", top_k=10)
# 2) 把記憶壓縮成 system / context 提示
memory_context = compress_memories(memories) # 用另一個 Sonnet 5 批次壓縮也可以
resp = client.messages.create(
model="claude-3.7-sonnet-5",
max_tokens=1536,
system=f"""
你是長期協助用戶的個人工作助理。
以下是你對此用戶的長期記憶摘要，請在回應時優先參考：
{memory_context}
""",
messages=[...
]
)
# 3) 回合結束後，把對話摘要寫回記憶系統
summary = summarize_with_sonnet5(conversation_turn)
memory_store.upsert(user_id="u_123", content=summary)
重點：不要期待 Sonnet 5 自己「記得」所有歷史；記憶是架構問題，不是換模型就會好的問題。
建議與注意事項：真實專案導入 Sonnet 5 的坑
1. Token 預算：Agent 能力被低估，成本也容易失控
英國 AISI 的研究指出：把 token budget 放大 10 倍，軟體工程任務成功率可提升約 25%。這對 Sonnet 5 有兩個實務啟示：
💡 關鍵： 在多步驟任務中適度提高 token budget，往往能顯著提升成功率，但必須搭配明確的預算控管機制。
- 不要用
benchmark 上的「單輪小 budget」結果直接低估 Sonnet 5 的 agent 能力。
- 真實系統要 顯式設計 token 過程控管，否則長上下文 + 多輪工具調用會把帳單拉爆。
實作建議：
- 在你的
orchestrator 層做全任務 token 上限，例如：
MAX_TASK_TOKENS = 40_000
state = {
"tokens_used": 0,
"steps": 0
}
while not done:
resp = client.messages.create(...)
state["tokens_used"] += resp.usage.input_tokens + resp.usage.output_tokens
state["steps"] += 1
if state["tokens_used"] > MAX_TASK_TOKENS:
raise BudgetExceededError("Agent token budget exceeded")
- 對於單次調用，根據場景設
max_tokens：
- 報告生成：
1024–4096
- 工具決策：
256–768
- 中間思考（
chain-of-thought）可用隱式提示 + 上限控制，避免瘋狂自言自語。
2. 錯誤恢復與重試：不要讓 Agent 一路跑到爆掉
Sonnet 5 在工具調用上普遍穩定，但實務上仍會遇到：
- 工具輸入
schema 不符合
- 工具執行失敗（
timeout / 400 / 500）
Agent 因缺 context 做出錯誤決策
最佳實踐：
- 工具層要有自己的驗證與重試，不要完全相信模型輸入。
from pydantic import BaseModel, ValidationError
class UpdateCrmPayload(BaseModel):
customer_id: str
tags: list[str] = []
note: str
def handle_tool_call(tool):
try:
payload = UpdateCrmPayload(**tool.input)
except ValidationError as e:
# 把錯誤回傳給 Sonnet 5，請它修正輸入
return {"status": "invalid_input", "error": str(e)}
try:
res = call_crm_api(payload)
return {"status": "success", "result": res}
except Exception as e:
return {"status": "tool_error", "error": str(e)}
- 對
Agent 本身做step-level checkpoint：每完成一個關鍵子任務就落盤，失敗時從最近 checkpoint 重跑，而不是從頭開始。
3. 任務適配：什麼放 Sonnet 5，什麼不要硬塞給它
適合用 Sonnet 5 當主力的任務：
- 多步驟 知識工作代理：合約 / 法遵審閱、財報分析、專案規劃、需求拆解。
- 工具中樞
Agent：負責 orchestrate 多個內部服務與子 Agent。
- 長上下文流程：需要消化大量規格、流程文件後再操作系統。
建議留給 Opus / 更強模型的任務：
- 高風險決策：例如金融交易策略生成、法務最終意見草擬。
- 需要極高推理深度的算法 / 架構設計題。
建議留給更小 / 開源模型的任務：
- 批量格式轉換、
log 清洗與標註。
- 嚴格成本敏感、但容錯率高的場景（例如內部搜尋候選排序）。
4. 安全防護與供應鏈攻擊：不要只相信模型的「安全訓練」
近期多個 AI Agent 供應鏈攻擊案例（prompt injection、工具回傳惡意內容、外部 API 回傳帶有攻擊指令的文字）提醒我們：
- Sonnet 5 的安全性 是加分項，但不是防火牆。
💡 關鍵： 模型層安全訓練無法取代系統層權限控管與審核機制，特別是在 Agent 能直接操作內部系統時。
- 尤其在
Agent 可以訪問內部系統時，要額外注意：
- 工具白名單 + 嚴格權限：不同
Agent 只能看 / 改自己該動的系統。
- 對所有來自外部世界的文字，在餵回模型前做最小化與清洗，避免讓外部
prompt 直接控制 Agent。
- 關鍵操作（轉帳、刪除資料、變更權限）一律加 人類確認 / 多重簽核，不要讓 Sonnet 5 直接下手。
把 Claude Sonnet 5 當成「預設 Agent 基座」來設計系統，搭配：
- 明確的多模型路由
- 顯式的
token 預算與錯誤恢復
- 外掛記憶系統與安全層
你可以在不爆成本的前提下，把原本只能在 POC 裡玩的 Agent 工作流，真正放進生產環境跑起來。
🚀 你現在可以做的事
- 審視現有
GPT-4.5 / 5.5 或 Opus 使用場景，標記出可降級給 claude-3.7-sonnet-5 的 70–80% 任務
- 在現有
Agent 架構中加入 route_model() 邏輯，實作多模型路由與 token 預算控管
- 建立一個簡單的記憶服務（
DB + 向量庫），將 Sonnet 5 當作無狀態推理引擎接入現有業務流程
