大綱
一、引言：AI 工程的三次典範轉移
2022 年底，ChatGPT 掀起了生成式 AI 的浪潮。短短三年多，AI 工程的核心問題已經歷了三次根本性的轉變：
- Prompt Engineering（2022–2024）：「我該怎麼問 AI？」
- Context Engineering（2025）：「我該餵給 AI 什麼資訊，讓它答得好？」
- Harness Engineering（2026）：「我該建造什麼環境，讓 AI Agent 穩定運作？」
這三個階段不是線性取代的關係，而是層層疊加。就像蓋房子——prompt 是地基，context 是結構，harness 是整套水電、消防、安全系統。沒有地基蓋不了房，但光有地基也住不了人。
對金融業而言，這個演化格外重要。金融業是高度監管的環境，AI Agent 犯錯的代價遠高於一般軟體開發——一次錯誤的授信決策可能產生數千萬的壞帳，一次合規疏失可能招來監管裁罰。因此，金融業比任何行業都更需要理解：如何從「讓 AI 回答得好」進化到「讓 AI Agent 在生產環境中穩定、可靠、可審計地運作」。
二、三個階段的演化歷程
2.1 Prompt Engineering：一問一答的優化藝術
Prompt Engineering 是 AI 工程的起點。它聚焦於單次輸入與單次輸出之間的優化，核心技巧包括 few-shot learning（給幾個範例讓模型學習格式）、chain-of-thought prompting（引導模型逐步推理）、以及 role-playing（賦予模型特定角色）。
在金融業的早期應用中，prompt engineering 已經展現了價值：撰寫信用審查報告的 prompt、讓 LLM 判斷交易是否可疑、自動生成法規解讀摘要。這些都是典型的「一問一答」場景。
然而，prompt engineering 有根本性的局限：它是 stateless 的。每一次對話都是全新的開始，模型不記得上一輪的結論，也無法存取外部資料。當任務需要多步驟、跨資料源、長時間執行時，光靠打磨 prompt 就力不從心了。
2.2 Context Engineering：從「問什麼」到「給什麼」
2025 年，Anthropic 在一篇 blog post 中正式探討了 context engineering 的重要性，Andrej Karpathy 等人也積極推動這個概念。Gartner 隨後將 context engineering 定義為：設計和結構化相關資料、工作流程與環境，讓 AI 系統能理解意圖、做出更好的決策，並產出符合企業需求的結果。
Context engineering 的核心洞察是：模型的推理品質取決於它在推理當下能看到什麼資訊。因此，工程師的工作從「寫出完美的 prompt」轉變為「動態管理 context window」——透過 RAG（檢索增強生成）注入即時資料、透過記憶系統保留跨對話的知識、透過工具定義讓模型能呼叫外部 API。
在金融業，context engineering 帶來了質的飛躍：授信 Agent 可以即時查詢客戶財務報表、法規資料庫和歷史案例；風險分析 Agent 可以動態載入市場數據和壓力測試參數。模型不再只是「回答問題」，而是「在充分資訊下做出判斷」。
但問題在於：context 告訴 Agent「看什麼」，卻無法阻止它「做錯事」。一個擁有完美 context 的 Agent 仍然可能忽略團隊慣例、產生違反架構方向的程式碼、在平行執行時自我碰撞、或透過熵值逐步降低產出品質。這些不是「模型應該看到什麼」的問題，而是「系統應該阻擋、衡量、修復什麼」的問題。
2.3 Harness Engineering：從指令到環境的典範轉移
2026 年 2 月 5 日，HashiCorp 共同創辦人 Mitchell Hashimoto 在他的 blog post 中首次命名了「harness engineering」這個概念。他的定義極為簡潔：「每當你發現 Agent 犯了一個錯誤，就花時間工程化一個解決方案，讓它再也無法犯同樣的錯誤。」
六天後，OpenAI 發表了一篇重量級的實驗報告。他們的 Codex 團隊從一個空的程式碼倉庫開始，在五個月內建構了一個超過百萬行程式碼的產品——而且零行人工撰寫的程式碼。工程師的工作不再是寫程式碼，而是設計讓 Agent 能可靠地寫程式碼的環境。這份報告的標題就叫「Harness engineering: leveraging Codex in an agent-first world」。
「Harness」這個詞源自馬具——韁繩、馬鞍、嚼子——一套完整的裝備，用來將一匹強壯但不可預測的動物的力量引導到有用的工作上。這個隱喻是刻意的：模型就是那匹馬，強壯、快速，但它自己不知道該往哪裡跑。工程師就是騎手，提供方向而不是自己跑。而 harness 就是那套裝備——沒有它，馬再快也沒用。
Harness engineering 的核心組成要素包括：
- 確定性護欄：linter、type checker、結構性測試等機械性的檢查機制，物理性地阻止 Agent 犯特定的錯誤
- 回饋迴路：當錯誤被攔截時，錯誤訊息本身成為 Agent 的 context，引導它自己修正
- 人類介入點（Human-in-the-Loop）：高風險決策保留人類判斷
- 可觀察性：完整的審計軌跡、token 使用追蹤、行為記錄
- 垃圾回收 Agent：定期掃描系統中的不一致、過期文件、架構違規
三、三者的關係——三種觀點的辯論
業界對 prompt、context、harness 三者的關係尚未達成共識。目前存在三種主要觀點：
觀點 A：巢狀結構（Harness ⊇ Context ⊇ Prompt）
這派認為三者是由小到大的包含關係。用馬的隱喻來說：prompt 是對馬的口頭指令，context 是你展示給牠的地圖，harness 是韁繩、馬鞍、圍欄和道路維護。你無法靠 prompt 達到 99.9% 的可靠性——prompt 只是系統的一個輸入，harness 才是系統本身。
觀點 B：Harness 是 Context 的子集
Dex Horthy（context engineering 概念的早期提出者之一）則主張 harness engineering 是 context engineering 的子集，專注於利用 coding agent 的配置點來管理 context window。他的邏輯是：你做 harness 的本質還是在管理 context。
觀點 C：兩者是不同維度的問題（本文立場）
技術部落客 mtrajan 在一篇標題為「Harness Engineering Is Not Context Engineering」的文章中提出了最清晰的區分：
- Context engineering 問的是：「Agent 應該看到什麼？」
- Harness engineering 問的是：「系統應該阻止、衡量、修正什麼？」
Context 給予資訊，Harness 創造一個 Agent 不需要被監督的環境。
為什麼我們需要這個新術語？不是為了追趕流行詞，而是因為它命名了一個之前沒有名字的工程實踐範疇。正如 SmartScope 的分析所指出的：重要的不是記住特定術語，而是認識到問題結構——「有些問題無法靠改善 prompt 來修復」，而且「有些品質無法靠改善 context 來維持」。
汽車比喻——對金融業最直觀的理解
技術評論者 Bouchard 提出了一個精妙的汽車比喻：模型是引擎，context 是燃料與儀表板，harness 是轉向系統、煞車、車道邊界，以及「車門不會在高速公路上掉下來」這件事。
金融業是不容許「車道偏移」的產業。引擎再強大、燃料再充足，如果沒有煞車和車道邊界，就不能上路。
四、Claude Code——Harness Engineering 的最佳範例
4.1 為什麼選 Claude Code 作為範例
根據 Anthropic 官方文件及技術社群對 Claude Code 架構的公開分析，Claude Code 完整體現了一個核心理念：Agent 本身已經聰明了——Claude 是一個經過大規模訓練的模型。Harness 不是讓 Claude 變聰明，而是給 Claude 雙手、眼睛和工作空間。
Claude Code 的完整公式可以拆解為：一個 agent loop + 工具（bash、read、write、edit、glob、grep、browser 等）+ 按需 skill 載入 + context 壓縮 + sub-agent 生成 + 帶相依圖的任務系統 + 帶非同步信箱的團隊協調 + worktree 隔離的平行執行 + 權限治理。
每一個組件都是 harness 機制——為 Agent 而建的世界。
4.2 六層架構全貌
根據技術社群的公開分析，Claude Code 採用了六層分層架構：
| 層次 | 職責 | Harness 意義 |
|---|---|---|
| 入口層 | 應用程式啟動與初始化 | 環境準備，harness 的「開機自檢」 |
| 展示層 | 終端 UI | 人機介面，HITL 的呈現層 |
| 核心引擎 | Agent Loop，處理所有 LLM 對話邏輯 | 最基礎的 while-true 迴圈 |
| 執行層 | 工具系統 + 命令系統 | Agent 的「手和腳」，40+ 個工具 |
| 協作層 | 多 Agent 系統 + 遠端橋接 | Sub-agent、Coordinator、Team |
| 管理層 | 權限、配置、狀態管理 | Harness 的核心所在 |
這六層的設計清楚說明了一件事：在整個系統中，模型只佔「核心引擎」這一層，其他五層全是 harness。
4.3 從公開分析看 12 個 Progressive Harness 機制
技術社群將 Claude Code 的 agent 設計歸納為 12 個遞進機制，正好對應了從 prompt 到 harness 的概念演進：
基礎層（Agent 能運作）——對應 Prompt Engineering
- The Loop：最基本的 agent 迴圈——接收 prompt、呼叫 API、檢查是否有 tool_use、執行工具、追加結果、繼續迴圈。這就是最原始的 agent。
- Tool Dispatch：工具注冊表模式。每加一個工具就是多一個 handler，迴圈本身不變。Agent 從此有了「手」。
- Knowledge on Demand：透過 tool_result 注入知識，而不是塞進 system prompt。這是 context engineering 的精髓——按需載入，不是一次全給。
可靠性層（Agent 不會失控）——對應 Context Engineering
- Planning：先列步驟再執行（Todo + Plan mode）。研究顯示這能將完成率翻倍。
- Context Compression：三層壓縮策略——自動摘要、移除過期訊息、重新結構化 context。防止 context window 溢出。
- Sub-Agents：子 agent 擁有獨立的對話歷史，保持主 context 乾淨。這就是「context 防火牆」。
- Persistent Tasks：檔案式任務圖，跨 session 記憶。目標不再隨對話結束而消失。
規模化層（多 Agent 協作）——對應 Harness Engineering
- Background Tasks：慢操作在背景執行，Agent 可以繼續思考。
- Agent Teams：持久的 teammate，帶非同步信箱。
- Team Protocols：統一的通訊介面（SendMessage），驅動所有 agent 間的協商。
- Autonomous Agents：Agent 自動掃描任務板並 claim 任務，不需要 lead 逐一分派。
- Worktree Isolation：每個 agent 有獨立的工作目錄，確保平行執行時不互相干擾。
4.4 五層權限評估鏈——Harness 的精華
根據 Anthropic 的官方 Hooks 文件，Claude Code 的每一次工具呼叫都要通過五層評估：
- validateInput()：在任何權限檢查之前，先拒絕無效的輸入
- PreToolUse Hooks：使用者自訂的 shell 腳本，可以核准、拒絕或修改輸入
- Permission Rules：alwaysAllow / alwaysDeny / alwaysAsk 規則比對
- Interactive Prompt：沒有規則匹配時，詢問使用者
- checkPermissions()：工具專屬的權限邏輯（例如路徑沙箱）
關鍵設計：Hooks 排在 Permission Rules 之前，意味著使用者自訂的 harness 邏輯比系統內建規則有更高的優先權。這個設計讓金融機構可以在 Hooks 層注入自己的合規檢查——例如「任何涉及客戶個資的操作一律阻擋」——它會在系統的內建規則之前攔截。
4.5 CLAUDE.md vs Hooks——Context 與 Harness 的分野
理解 harness engineering 最關鍵的一個區分：
- CLAUDE.md 寫「請跑 linter」→ Agent 可能遵守。這是 context 層——它只是一個建議。在長時間的 debug session 中，當 context window 接近上限時，CLAUDE.md 的內容可能被壓縮掉或被忽略。
- Hook 在 PreToolUse 事件攔截→ Agent 必定被檢查。這是 harness 層——它是機械性的強制執行。不管 context window 多滿、不管 Agent 多忙，Hook 都會觸發。
正如一位開發者的總結：「Permissions 是對系統的請求，Hooks 是強制執行。」
4.6 Coordinator 的「禁止甩鍋」原則
Claude Code 的多 Agent 協作系統中有一個值得金融業深思的設計：Coordinator（協調者）只有三個工具——派活、通信、停工。它不能自己執行任何任務。而系統提示中明確規定：「禁止甩鍋式委派」——不能把不清楚的需求直接丟給 Worker。
這看似是限制，實際上是 harness 哲學的精華：約束不是限制，而是讓系統更可靠。一個什麼都能做的 Coordinator 反而更容易出錯。
4.7 KAIROS 與持久 Agent 的 harness 挑戰
技術社群的分析還揭示了 Claude Code 未來的方向——KAIROS 系統：一個「永不關機」的 Agent，具備跨會話持久運行、每日自動日志、自動記憶整合（Dream）、以及主動模式（沒人說話時自己找活干）。
這對金融業有深遠的啟示：如果未來金融機構部署持久運行的 Agent（例如持續監控市場風險、自動產出日報），harness 的需求會更加複雜——不只要管「每次執行」的品質，還要管「持續運行中的衰退、漂移、記憶污染」。
五、實戰案例——多代理智慧機器學習平台的三層 Engineering 對照
5.1 平台簡介
筆者開發的「多代理智慧機器學習平台」是一個用於金融業機器學習建模的教學與實務平台。系統採用 LangGraph 協調六個專業 Agent（資料清洗 → 探索性分析 → 特徵工程 → 模型訓練 → 模型驗證 → 文件撰寫），搭配 Gradio 介面、PostgreSQL 資料持久化、MCP 模型治理工具，以及多 LLM 支援（Anthropic、Groq、Ollama）。
5.2 三層 Engineering 的實際體現
Prompt Engineering（成熟）
平台中每個 Agent 都有精心設計的 prompt。以特徵工程 Agent 為例，prompt 明確列出六種衍生變數類型（比率型、交互型、差異型、聚合型、分組型、對數型），並要求 LLM 以結構化 JSON 格式回傳決策結果。這些 prompt 設計確保了 LLM 能做出有業務邏輯的決策。
Context Engineering（良好）
平台的 Skill 系統是 context engineering 的具體體現。核心知識（data_preparation.md、feature_engineering.md、model_training.md 等八個知識檔案）在 Agent 執行前透過 load_skills_for_agent() 函式動態載入到 LLM 的 system prompt 中。領域知識（credit_scoring.md、fraud_detection.md）可根據建模任務切換。
同時，LangGraph 的 State 傳遞機制也是 context engineering——每個 Agent 讀取前一階段的輸出作為自己的 context（cleaned_data → eda_report → woe_data → model_metrics），形成跨 Agent 的 context 管理鏈。
MCP 工具（list_tables、query_data）讓 Agent 能動態查詢資料庫中的資訊，而非靠 prompt 寫死。
Harness Engineering（已建立核心機制）
平台已建立完整的確定性護欄系統（Harness Gates）：三個品質閘門分別在資料清洗後、特徵工程後、模型訓練後自動執行確定性檢查。Gate_變數一致性會比對 LLM 選定的入模變數與實際可用變數的差異，差異過大則 block 並回饋結構化的修正指令（JSON 格式，包含每個問題欄位的具體原因和建議）。Gate_模型品質會自動診斷 AUC 偏低的可能原因（入模變數不足、過擬合、類別不平衡）。所有 Gate block 最多重做兩次，超過則降級為 warning 交由人工審核。
此外，平台實現了累積式規則學習：當 Agent 被 Gate 攔截後重做並成功通過時，教訓會自動寫入對應的 Skill .md 檔案，並在報告面板通知審核者（例如「📝 已自動記錄 1 條經驗教訓到 feature_engineering.md（類別變數需做編碼）」）。下一次 Agent 載入 Skill 時就能看到這些教訓，避免重蹈覆轍。
LangGraph interrupt 實現 Human-in-the-Loop 暫停點；governance_server.py 提供審計軌跡（audit_log，包含 Gate 決策記錄）和模型登錄（model_registry）；挑戰者 LLM-B 會質疑代理的決策，形成回饋迴路。
5.3 一個真實的 debug 故事——為什麼金融業需要 Harness
在平台開發過程中，筆者遇到了一個極具啟發性的問題：使用 Groq LLM 跑信用評分建模時，AUC 不到 70%（German Credit 資料集的正常水準應在 70-78% 之間）。
Prompt 層面檢查：LLM 正確選出了 11 個高 IV 值的入模變數，包括 checking_status（查核狀態）、credit_history（信用歷史）等關鍵變數。Prompt engineering 成功了。
Context 層面檢查：Skill 檔案提供了充分的信用評分領域知識，LLM 的變數選擇決策有理有據。Context engineering 也成功了。
但 AUC 還是不到 70%。
經過深入排查，發現真正的原因是：模型訓練 Agent 的程式碼中有一行 df.select_dtypes(include=[np.number])，只取了數值型欄位。LLM 選的 11 個變數中，最重要的 checking_status（IV 值最高的變數）等類別型變數被靜默丟棄。實際進入模型的只有 duration、credit_amount、age、月均貸款額這 4 個數值型變數。
關鍵洞察：這個問題不在 prompt 也不在 context——LLM 做了正確的決策，但系統沒有機制確保決策被忠實執行。這正是 harness engineering 要解決的核心問題。
5.4 Harness 的實際效果
在發現上述問題後，筆者為平台建立了三個確定性護欄（Harness Gates）。以 Gate_變數一致性為例，它會在特徵工程完成後自動執行：
規則：「LLM 選定的變數清單 vs 實際可用的數值型變數清單，差異超過 2 個則 block，並將結構化的差異資訊回饋給 Agent」
當 Gate 攔截時，Agent 收到的不是模糊的錯誤訊息，而是結構化的修正指令：每個問題欄位的名稱、資料型態、為什麼無法使用、以及建議的 encoding 方式。Agent 就能自動修正，而不需要人工去翻程式碼。
Gate block 最多重做兩次。如果 Agent 連續兩次都無法通過，Gate 會降級為 warning 並放行，交由人工審核判斷。這避免了無限迴圈，同時確保品質問題不會被靜默忽略。
更重要的是，當 Agent 被 Gate 攔截後重做並成功通過時，系統會自動將這次經驗寫入對應的 Skill 知識檔案，並通知審核者。下一次建模時，Agent 載入 Skill 就能看到這些累積的教訓。
這就是 harness 的核心價值：把一次性的 debug 經驗轉化為永久的機械檢查，再轉化為 Agent 的長期記憶。
5.5 12 個 Harness 機制 × 平台對照表
| # | Claude Code 機制 | 平台對應 | 狀態 |
|---|---|---|---|
| 1 | The Loop | LangGraph StateGraph 主迴圈 | ✅ 有 |
| 2 | Tool Dispatch | MCP 工具（log_decision、query_data 等） | ✅ 有 |
| 3 | Knowledge on Demand | Skill 按需載入 + 累積式教訓自動寫回 | ✅ 有（P2-B 強化） |
| 4 | Planning | 六階段固定流程 | ⚠️ 固定管線，非動態規劃 |
| 5 | Context Compression | State 傳遞只帶前一階段輸出 | ⚠️ 手動設計，非自動壓縮 |
| 6 | Sub-Agents | 挑戰者 LLM-B | ⚠️ 不是獨立 context |
| 7 | Persistent Tasks | audit_log + model_registry + Gate 決策記錄 | ✅ 有（P1 強化） |
| 8 | Background Tasks | — | ❌ 缺 |
| 9 | Agent Teams | — | ❌ 缺 |
| 10 | Team Protocols | — | ❌ 缺 |
| 11 | Autonomous Agents | — | ❌ 缺 |
| 12 | Worktree Isolation | — | ❌ 缺 |
平台另有 Claude Code 沒有但金融業特有的 harness 機制：
| 機制 | 說明 |
|---|---|
| 三個確定性品質閘門（Harness Gates） | 資料型態 / 變數一致性 / 模型品質，自動 block + 結構化回饋 |
| 重做上限（MAX_RETRIES=2） | 防無限迴圈，超過降級為 warning 交人工 |
| 結構化錯誤回饋（JSON） | Gate block 時提供精確的問題診斷和修正指令 |
| 累積式規則學習 | 教訓自動寫回 Skill，並通知審核者 |
5.6 平台的三層成熟度
經過兩輪 harness 改善（P1：確定性護欄 + 品質閘門；P2：結構化回饋 + 累積式規則學習），平台目前的狀態是：
- Prompt Engineering：成熟（約 90%）
- Context Engineering：良好（約 82%，Skill + State + MCP + 累積式教訓回饋）
- Harness Engineering：已建立核心機制（約 65%，三個 Gate + 結構化回饋 + 重做上限 + 累積式規則 + 審計記錄）
剩餘的差距主要在 Sub-Agent 的 context 隔離、多使用者平行執行隔離、以及 Background Tasks 等進階機制。
六、金融業 Harness Engineering 的應用場景與特殊考量
6.1 金融業為什麼比軟體業更需要 Harness
軟體開發中，一個 Agent 犯的錯通常可以透過 git revert 回復。但在金融業：
- 一筆錯誤的授信核准可能產生數千萬的壞帳
- 一次違反法規的操作可能招來金管會裁罰
- 一份有瑕疵的模型驗證報告可能導致整個模型被撤回
金融業不只需要 Agent「大多數時候做對」，而是需要「系統性地阻止做錯」。這正是 harness 的價值所在。
6.2 金融場景的 Harness 設計
授信審查 Agent：法規 linter 自動檢查巴塞爾協議的資本計提規則，授信額度硬約束（單一客戶不得超過淨值的某個比例），行業集中度限制作為確定性閘門。
模型風險管理：SR 11-7 的驗證流程作為 harness gate——模型產出必須通過結構性驗證（PSI 穩定性測試、敏感度分析、反向測試），未通過則 block 進入下一階段。
裁罰分析 Agent：引用來源可追溯護欄——Agent 的每一個結論都必須附帶來源文件編號，無法引用的結論自動標記為「待人工確認」。
反洗錢 Agent：交易金額閾值的確定性攔截——超過法定申報門檻的交易，不管 Agent 的判斷如何，一律觸發人工審查流程。
6.3 三道防線 × Harness Engineering 的映射
金融業行之有年的「三道防線」架構，與 harness engineering 的理念高度契合：
| 防線 | 傳統職責 | Harness 對應 |
|---|---|---|
| 第一道（業務單位） | 日常風險控管 | Agent 的 prompt + context（知道該做什麼） |
| 第二道（風管/法遵） | 政策制定與監督 | 確定性護欄 + 品質閘門（機械性地阻止違規） |
| 第三道（稽核） | 獨立查核 | 審計軌跡 + 可觀察性 + 挑戰機制 |
這個映射不只是概念上的對應。在實務中，金融機構建置 AI Agent 系統時，可以直接按三道防線的框架來設計 harness 的各個組件，確保 AI 治理與既有的組織治理架構無縫接軌。
6.4 Kill Switch——金融業的緊急煞車
技術社群的分析揭示了 Claude Code 的一個重要機制：系統每小時向 Anthropic 輪詢設定，當偵測到危險的設定變更時，會彈出阻擋式對話框——拒絕就強制退出應用程式。
金融業的 Agent 系統同樣需要這樣的「緊急煞車」：當模型產出異常（例如授信額度計算偏離正常範圍的三個標準差）、當外部環境劇變（例如突發的市場崩盤觸發了壓力測試閾值）、或當監管要求即時生效時，系統必須能即時中斷整個 Agent 流程，而不是等到最終產出才發現問題。
七、結語：金融從業人員的下一步
Harness engineering 不是一個需要「一步到位」的宏大工程。從本文的分析可以看到，即使是 OpenAI 的團隊，也是花了五個月持續迭代才建立起成熟的 harness。
金融從業人員可以從以下步驟開始：
第一步：盤點現有的 harness 元素。 你的 AI 系統是否已有審計軌跡？是否有人工審核的暫停點？這些就是 harness 的雛形。
第二步：從最痛的錯誤開始。 回想 Agent 最近犯的錯誤，問自己：「這個錯誤能否被一個確定性的檢查攔截？」如果可以，就寫一個。這正是 Mitchell Hashimoto 的核心理念——每次犯錯都是建設 harness 的機會。
第三步：區分 context 問題和 harness 問題。 Agent 產出品質不好，是因為它「沒看到該看的資訊」（context 問題），還是「看到了但系統沒有阻止它做錯」（harness 問題）？前者改 Skill 和 RAG，後者加 Hook 和 Gate。
第四步：把三道防線思維融入 harness 設計。 不要另起爐灶，而是把 harness 的各個組件對應到既有的風控架構中。第一道防線管 prompt 和 context，第二道防線管確定性護欄，第三道防線管審計和挑戰。
模型會越來越聰明。未來某些 harness 機制可能會被模型本身吸收——就像今天的模型已經不需要像兩年前那樣精心打磨 prompt。但有一點在金融業永遠不會改變：確定性的護欄比聰明的模型更重要。 因為在金融業，「大多數時候做對」是不夠的。
本文 Claude Code 架構分析係根據 Anthropic 官方文件及技術社群之公開分析撰寫，不涉及任何非公開原始碼之引用。
