Anthropic 有 90% 的程式碼是由 Claude Agents 撰寫的。 不是工程師在聊天視窗中打字。而是由自主 Agent 執行迴圈、呼叫工具,並在團隊睡覺時交付程式碼。
追蹤我的 Substack 以獲取最新 AI 資訊:
這正是完整的設定方式。逐步說明。從第一次 API 呼叫到一個可運作的 Agent,你可以將其指向任何任務。
本文將涵蓋:
1 - 為什麼大多數人建立的「Agent」並非真正的 Agent
2 - 每個可運作 Agent 所需的 5 個部分
3 - 如何使用 Claude 搭配程式碼建立每個部分
4 - 在 Agent 上線前就讓它失敗的錯誤
把這篇存下來。以下每個程式碼區塊都可以運作。
01. 大多數「AI Agent」並非 Agent
我建立並搞砸過的 Agent 數量多到數不清。眼看它們整晚燒掉 Token 卻一事無成。看它們把同一個檔案重寫了 30 次。看它們為了通過自己的測試而刪除測試。

每一次失敗都教會我同一件事:模型本身不是問題,問題在於模型周圍的架構。這份指南是我學到的一切,濃縮成我能給你的最短捷徑。
以下是大多數人說「AI Agent」時實際建立的東西:
1while True:2 user_input = input("> ")3 response = call_claude(user_input)4 print(response)
那是聊天機器人。它等你輸入。它照你說的做。它會忘記每次對話之間的所有內容。當你關閉分頁,它就停止運作。
Agent 是一個不需要你坐在面前就能朝著目標運作的系統。它會自行發現需要做什麼、制定計畫、執行、檢查結果,如果還沒完成——就再試一次。你設定方向,Agent 負責執行。
「Claude Code 在幾個月內從零成長到 4 億美元營收。它最初只是個黑客松專案。而且它至今仍只使用公開 API。」——
Boris Cherny,Claude Code 負責人
你現在就能使用的相同 API,相同的模型。差別在於模型周圍的架構。

02. 真正 Agent 的 5 個部分
每個可運作的 Agent——Claude Code、Devin、Codex,或你自己建立的任何東西——都由五個部分組成。缺少一個就會失敗。

03. API 層
一切從這裡開始。你呼叫 Claude,Claude 回應。但你的呼叫方式決定了你得到的是聊天機器人還是 Agent。

三件事很重要:系統提示、結構化輸出和溫度。
系統提示不是打招呼。它是你 Agent 的操作手冊。所有規則、限制和行為都放在這裡。沒有它,Claude 會猜測你想要什麼;有了它,Claude 會遵循你的規範。
1import anthropic23client = anthropic.Anthropic()45response = client.messages.create(6 model="claude-sonnet-4-6",7 max_tokens=4096,8 system="""你是程式碼審查 Agent。910規則:11- 在評論之前先閱讀整個 diff12- 只標記真正的錯誤,而非風格偏好13- 如果沒有任何問題,請回覆「LGTM」並停止14- 永遠不要建議你未經心智測試的變更15- 輸出格式:JSON 陣列,包含 {file, line, issue, fix}""",16 messages=[{"role": "user", "content": diff_content}]17)
結構化輸出讓 Agent 的回應變成機器可讀。如果 Claude 回傳的是自由文字,你的程式碼需要解析它。如果 Claude 回傳 JSON,你的程式碼可以直接使用。
1# 強制 JSON 輸出,告訴 Claude 確切的形狀2system = """只回傳有效的 JSON。不要 Markdown。不要解釋。3結構:4{5 "status": "pass" | "fail",6 "issues": [{"file": str, "line": int, "issue": str}],7 "summary": str8}"""
溫度。 對於確定性 Agent 設定為 0。對於創意工作設定為 0.3-0.5。預設值 (1.0) 會增加隨機性,這在 Agent 中幾乎永遠不需要。
04. 工具
沒有工具的模型可以推理,但無法行動。它可以告訴你該編輯哪個檔案,但無法編輯它。它可以描述一個查詢,但無法執行它。

Claude 的工具使用功能讓你可以定義模型可以呼叫的函式。你描述函式,Claude 決定何時呼叫它。你執行它並回傳結果。Claude 使用結果繼續推理。
1tools = [{2 "name": "run_sql",3 "description": "對資料庫執行唯讀 SQL 查詢",4 "input_schema": {5 "type": "object",6 "properties": {7 "query": {8 "type": "string",9 "description": "要執行的 SQL SELECT 查詢"10 }11 },12 "required": ["query"]13 }14},15{16 "name": "write_file",17 "description": "將內容寫入磁碟上的檔案",18 "input_schema": {19 "type": "object",20 "properties": {21 "path": {"type": "string"},22 "content": {"type": "string"}23 },24 "required": ["path", "content"]25 }26}]
工具描述比你想象的重要。Claude 會讀取它來決定何時以及如何使用工具。模糊的描述會導致錯誤的呼叫。精確的描述會導致準確的呼叫。
從 3-5 個工具開始。讀取檔案、寫入檔案、執行命令、搜尋,以及一個針對你使用案例的領域特定工具。這涵蓋了 90% 的 Agent 任務。

05. 迴圈
這是將腳本轉變為 Agent 的部分。沒有迴圈,你的程式碼只會呼叫 Claude 一次然後停止。有了迴圈,你的程式碼會呼叫 Claude、檢查結果,然後再次呼叫,直到工作完成。

三個組成部分:
- 驗證器。 檢查輸出是否良好的東西。測試套件、型別檢查器、linter、第二個 Claude 呼叫並附上嚴格標準。沒有這個,Agent 會不斷重複同意自己的意見。
- 狀態。 已發生事件的記錄。什麼有效、什麼失敗、下一步該嘗試什麼。沒有狀態,Agent 每次都會犯同樣的錯誤。
- 停止條件。 目標已達成,或硬性限制說「N 次嘗試後停止並回報」。沒有這個,迴圈會永遠執行並耗盡你的帳戶。
1import json2from pathlib import Path34def run_agent(task: str, max_attempts: int = 5):5 state = {"task": task, "attempts": [], "done": False}67 for i in range(max_attempts):8 # 從狀態建立上下文9 context = build_prompt(state)1011 # 使用工具呼叫 Claude12 result = call_claude(context, tools)1314 # 執行任何工具呼叫15 output = execute_tools(result)1617 # 驗證結果18 check = verify(output)1920 # 更新狀態21 state["attempts"].append({22 "attempt": i + 1,23 "action": result.summary,24 "passed": check.passed,25 "reason": check.reason26 })2728 if check.passed:29 state["done"] = True30 break3132 # 儲存狀態以供下次執行33 Path("state.json").write_text(json.dumps(state, indent=2))34 return state
這是完整的骨架。每個生產環境的 Agent 都是這個模式的變體。細節會改變,但形狀不變。
06. 記憶
沒有記憶,每次對話都從零開始。Agent 會重新發現你的專案結構、重新學習你的慣例、重新犯下昨天犯過的錯誤。

Claude Agent 使用三層記憶:
CLAUDE.md 是專案根目錄下的一個 Markdown 檔案。Claude Code 會在每次對話開始時自動讀取它。你的規則、你的技術棧、你的慣例。寫一次,永遠讀取。
1# CLAUDE.md23## 專案4任務管理 API。Python 3.12、FastAPI、PostgreSQL。56## 規則7- 所有回應:{data, error, meta} 結構8- 每個新端點都需要測試9- 提交訊息:type(scope): description10- 永遠不要使用 print() 記錄日誌。使用 structlog。1112## 已知問題13- 認證中介軟體預期 x-auth-token,而非 Authorization14- 測試套件完整執行需 45 秒。使用 --filter 進行迭代。
技能 捕捉整個工作流程。不只是提示——而是完整的形狀:輸入格式、步驟、輸出格式、驗證規則。第一次執行需要 20 分鐘。重播只需 30 秒。
學習記錄檔 是一個持續記錄錯誤的檔案。Agent 會在每次對話後寫入它。下次對話時讀取它。錯誤會重複發生,直到被寫下來。然後它們就會停止。
1# learnings.md23- 付款 API 預期冪等性金鑰在標頭中,而非主體4- PostgreSQL NOTIFY 需要在連線池中明確 LISTEN5- 速率限制器按金鑰計數,而非 IP。測試需要唯一金鑰。
07. 驗證關卡
驗證關卡是最難建構且最容易被跳過的部分。大多數人跳過它。這就是為什麼大多數 Agent 在生產環境中崩潰。

驗證關卡是一種檢查 Agent 工作成果的機制,而不是讓 Agent 自己評分。 撰寫程式碼的模型在評分自己的作業時過於寬容。你需要第二次檢查。
三種可行的模式:
1. 自動化測試。 Agent 撰寫程式碼。測試套件執行。如果測試失敗,Agent 會收到錯誤輸出並再次嘗試。這就是 Claude Code 內部的運作方式。
1def verify(output):2 # 執行測試套件3 result = subprocess.run(4 ["pytest", "tests/", "-x", "--tb=short"],5 capture_output=True, text=True6 )7 return {8 "passed": result.returncode == 0,9 "reason": result.stdout if result.returncode != 0 else "all tests pass"10 }
2. 型別檢查器 / Linter。 每次變更後執行 mypy、ruff 或 tsc --noEmit。無需撰寫任何測試就能捕捉一整類的錯誤。
3. 第二個模型作為審查者。 使用另一個 Claude 呼叫,並附上嚴格的系統提示,只尋找問題。撰寫者快速且便宜。審查者緩慢且嚴格。這種分離是品質的主要來源。
1# 審查者提示——與建構者分開2reviewer_system = """你是嚴格的程式碼審查者。3你唯一的工作是找出問題。45檢查:6- 程式碼是否符合規格?7- 是否有未捕捉到的邊界情況?8- 所有測試是否真的測試了正確的東西?910如果一切正確,回覆:{"passed": true}11如果有任何錯誤,回覆:{"passed": false, "issues": [...]}1213不要建議改進。只標記真正的錯誤。"""
撰寫者快速且便宜。審查者緩慢且嚴格。這種分離是品質的主要來源。
08. 整合在一起
以下是完整的 Agent,它會接收 GitHub Issue 網址、讀取 Issue、撰寫程式碼、執行測試並開啟 PR。五個部分協同運作。
1import anthropic, subprocess, json2from pathlib import Path34client = anthropic.Anthropic()5CLAUDE_MD = Path("CLAUDE.md").read_text()6LEARNINGS = Path("learnings.md").read_text()78SYSTEM = f"""你是程式碼 Agent。9閱讀 Issue。撰寫修正。執行測試。1011專案上下文:12{CLAUDE_MD}1314已知問題:15{LEARNINGS}1617規則:18- 在變更任何內容之前先閱讀完整程式碼庫19- 為每個變更撰寫測試20- 如果測試失敗,修正程式碼,而非測試21- 當所有測試通過時停止"""2223TOOLS = [24 read_file_tool,25 write_file_tool,26 run_command_tool,27 search_codebase_tool,28]2930def run(issue_text, max_attempts=5):31 messages = [{"role": "user", "content": issue_text}]3233 for attempt in range(max_attempts):34 # 呼叫 Claude35 response = client.messages.create(36 model="claude-sonnet-4-6",37 max_tokens=8192,38 system=SYSTEM,39 tools=TOOLS,40 messages=messages41 )4243 # 執行工具呼叫44 messages = handle_tool_use(response, messages)4546 # 驗證:執行測試47 test_result = subprocess.run(48 ["pytest", "-x", "--tb=short"],49 capture_output=True, text=True50 )5152 if test_result.returncode == 0:53 print(f"在 {attempt + 1} 次嘗試後完成")54 return True5556 # 將失敗資訊回饋到迴圈中57 messages.append({58 "role": "user",59 "content": f"測試失敗:\n{test_result.stdout}\n請修正並重試。"60 })6162 return False
這就是一個可運作的 Agent。API 層,包含系統提示和 CLAUDE.md。用於檔案操作的工具。包含重試機制的迴圈。來自 learnings.md 的記憶。透過 pytest 進行的驗證關卡。
不到 50 行程式碼。與 Claude Code 內部使用的相同架構。
09. 會搞垮每個 Agent 的 5 個錯誤
- 沒有驗證關卡。 Agent 自己評分自己的作業。它撰寫程式碼,說「看起來不錯」,然後繼續。輸出看起來正確,但在生產環境中會崩潰。
- 沒有停止條件。 迴圈一直執行直到你的 API 帳單達到 200 美元。沒有硬性限制,Agent 會永遠重試,把同一個檔案重寫 40 次。永遠要設定 max_attempts。
- 沒有狀態檔案。 在第 1 次嘗試和第 50 次嘗試犯同樣的錯誤。Agent 不知道它已經嘗試過什麼。它會連續三次提出同樣的錯誤修正,因為沒有記錄失敗。
- 太多工具。 你給 Claude 20 個工具,它會選錯。有 5 個清晰工具的模型比有 20 個重疊工具的模型做出更好的選擇。從小處開始。只有當 Agent 遇到瓶頸時才新增工具。
- 模糊的系統提示。 「當個好的程式碼助手」會給你泛泛的輸出。「所有回應必須是有效的 JSON,每個變更都需要測試,永遠不要修改 /src 之外的檔案」會給你一個行為明確的 Agent。
結論:
一個可運作的 Agent 不是一個更好的提示。它是一個系統:API + 工具 + 迴圈 + 記憶 + 驗證關卡。五個部分。缺少一個就會失敗。
大多數人會讀完這篇,把它存下來,然後繼續把 Claude 當作聊天機器人使用。他們會一次貼一個問題,然後手動把回應複製到他們的程式碼庫中。
而那些建立迴圈的人,則會在睡覺時交付工作。相同的模型。相同的 API。相同的價格。不同的架構。
上面的程式碼區塊都可以運作。複製它們。執行它們。根據你的使用案例修改它們。
這週建立一個 Agent。把它指向你每天做的任務。讓它運作。





