Coding Agent 運作原理全解析：從工具呼叫到資料分析實戰

你可能已經用過 Claude Code、Cursor 或 OpenAI Codex 來幫你寫程式。但你有沒有想過：當你按下 Enter 送出指令之後，這些工具的背後到底在做什麼？

這不是一篇「Coding Agent 好棒棒」的入門介紹——那種文章已經夠多了。這篇文章要做的是掀開引擎蓋，帶你看清楚 Coding Agent 的運作機制：核心迴圈長什麼樣、工具呼叫怎麼串接、錯誤修復的策略是什麼，以及為什麼「資料分析」是目前 Agent 最被低估的應用場景。

不是聊天機器人，是一個 While Loop

理解 Coding Agent 最關鍵的第一步，是認清它不是聊天機器人。

一般的 LLM 對話是 request-response 模式：你問一個問題，模型回答一次，結束。但 Coding Agent 的核心是一個迴圈（loop），更精確地說，是一個帶有工具呼叫能力的 while loop：

while (任務未完成):
    1. LLM 分析當前狀態
    2. 決定下一步行動（呼叫工具 or 回覆使用者）
    3. 執行工具，取得結果
    4. 將結果回饋給 LLM
    5. LLM 判斷：任務完成了嗎？

這個迴圈看似簡單，但它帶來的能力差異是質變的。傳統的程式碼生成（像早期的 Copilot）是「一次性產出」——模型猜你下一行要寫什麼，猜對了是運氣，猜錯了你自己改。Coding Agent 則是「迭代式產出」——它寫了一段程式碼，自己跑測試，看到錯誤訊息，然後修正，再跑一次，直到通過。

這個「能自己驗證」的能力，才是 Agent 的靈魂所在。

Simon Willison 在他的 Agentic Engineering Patterns 系列中精準指出了這一點：沒有程式碼執行能力的 LLM，輸出的程式碼只是「看起來對」；有了執行能力的 Agent，能產出「真的能跑」的程式碼。這不是程度差異，是本質差異。

工具呼叫：Agent 的手和腳

如果核心迴圈是 Agent 的大腦，那「工具呼叫」（Tool Calling / Function Calling）就是它的手和腳。

Tool Use 的運作機制

現代 LLM 的工具呼叫機制大致是這樣運作的：

1. 工具定義：開發者在 system prompt 或 API 參數中定義一組可用工具，每個工具有名稱、描述和參數 schema（通常是 JSON Schema）
2. 模型決策：LLM 在生成回應時，可以選擇「呼叫工具」而不是「輸出文字」。它會生成一個結構化的工具呼叫請求，包含工具名稱和參數
3. 執行與回饋：外部系統（host）執行這個工具呼叫，把結果以 tool_result 的形式塞回對話上下文
4. 繼續推理：LLM 看到工具結果後，決定下一步——可能再呼叫另一個工具，或者直接回覆使用者

以 Claude Code 為例，它可以使用的工具包括：

• Read：讀取檔案內容
• Write/Edit：建立或修改檔案
• Bash：執行終端命令（包括跑測試、安裝套件、git 操作等）
• Grep/Glob：搜尋程式碼
• Agent（子任務代理）：把複雜任務分拆給子 agent 處理

這些工具組合在一起，Agent 就有了完整的開發環境存取能力。它可以讀你的 codebase、理解專案結構、寫新檔案、跑測試、看 log、修 bug——整個開發流程。

一個真實的工具呼叫序列

假設你跟 Coding Agent 說：「幫我在 utils.py 裡加一個 parse_date 函式，要能處理 ISO 8601 和 ‘YYYY/MM/DD’ 兩種格式。」

Agent 的內部呼叫序列大概會長這樣：

[Step 1] Read("utils.py")
  → 看到現有的程式碼結構和 import

[Step 2] Read("tests/test_utils.py")
  → 了解現有的測試風格

[Step 3] Edit("utils.py", 加入 parse_date 函式)
  → 寫入新的程式碼

[Step 4] Edit("tests/test_utils.py", 加入測試案例)
  → 寫入對應的單元測試

[Step 5] Bash("python -m pytest tests/test_utils.py -v")
  → 跑測試，看結果

[Step 6] 如果失敗 → 讀錯誤訊息 → Edit 修正 → 再跑測試
  → 迭代直到全部通過

關鍵觀察：Agent 不是「一口氣寫完」，而是每一步都有回饋。它先讀懂現有程式碼，再動手寫，寫完立刻驗證。這個流程跟經驗豐富的開發者做法是一樣的——差別在速度快了一個數量級。

錯誤修復：Agent 真正的價值所在

坦白說，Agent 第一次產出的程式碼不一定是對的。但這不重要——重要的是它能看到錯誤並修復。

錯誤修復迴圈的三個層次

第一層：語法與型別錯誤

這是最簡單的。Agent 跑完程式碼，看到 SyntaxError 或 TypeError，直接定位修復。成功率極高，幾乎 100%。

第二層：邏輯錯誤（測試失敗）

Agent 寫了程式碼跑測試，測試失敗了。它需要讀 traceback、理解預期行為和實際行為的差異、找出 root cause、修正。這一層對 LLM 的推理能力要求高很多，但 2025 年底以後的模型（Claude Opus 系列、GPT-5.4 等）在這方面已經相當可靠。

第三層：環境與依賴問題

最棘手的層次。Agent 可能遇到套件版本不對、環境變數沒設、資料庫連不上之類的問題。好的 Agent 會嘗試 debug（讀 log、檢查環境），但這通常需要更多的 context 和使用者介入。

我個人觀察到一個很有趣的現象：Agent 的 debug 能力跟你給它的 context 成正比。 如果你的專案有完整的 README.md、清晰的 CLAUDE.md（或 AGENTS.md）、以及充足的測試，Agent 修復問題的速度會快很多。這跟人類新手加入團隊是一樣的道理——onboarding 文件越好，上手越快。

為什麼 TDD 在 Agent 時代更重要了

這引出一個反直覺的結論：在 AI 時代，測試驅動開發（TDD）比以前更重要，而不是更不重要。

原因很簡單：測試是 Agent 唯一的「眼睛」。沒有測試，Agent 寫完程式碼就沒有回饋信號，無法確認自己寫的東西是不是正確的。有了測試，Agent 就有了一個明確的「完成條件」——跑過所有測試就是完成。

Simon Willison 提出的最佳實踐是：先寫測試，再讓 Agent 寫實作。 測試是人類定義「什麼是正確」的工具，Agent 則是高速抵達正確答案的執行者。這種分工讓人類專注在最有價值的工作（定義需求、設計架構、審查品質），Agent 處理最耗時的工作（實作、debug、重構）。

資料分析：Coding Agent 最被低估的戰場

大多數人談到 Coding Agent 想到的都是「寫 CRUD」、「做前端元件」。但我認為 Agent 目前最驚艷的應用場景是資料分析。

為什麼 Agent 做資料分析特別強？

傳統的資料分析工作流長這樣：

1. 拿到一份 CSV 或資料庫查詢結果
2. 用 pandas 做清理（處理缺失值、型別轉換、合併資料集）
3. 做探索性分析（EDA），算統計量、畫圖
4. 提出假設，做進一步分析
5. 整理結論，產出報告或視覺化

這個流程有幾個特性，讓它特別適合 Agent：

• 每一步都有明確的輸出可以驗證：資料的 shape、dtype、null count 都是可以自動檢查的
• 錯誤容易發現：跑不過就是跑不過，不像業務邏輯那樣「看起來對但其實錯」
• 迭代成本低：重跑一次分析通常只需要幾秒鐘
• 不需要理解業務 context 就能做大部分技術操作：清理資料、處理格式、跑統計，這些是 Agent 最擅長的

實戰場景：讓 Agent 分析一份銷售數據

想像你有一份電商平台的銷售紀錄 CSV，50 萬筆交易、20 個欄位。你想知道：哪些產品類別在過去三個月的退貨率上升了？

傳統做法：你可能得花半小時到一小時寫 pandas 程式碼——讀檔、清資料、做時間序列拆分、計算退貨率、做比較。

Agent 做法：

你：「讀取 sales_data.csv，分析過去三個月中退貨率上升幅度最大的前 5 個產品類別，
     用折線圖視覺化趨勢，並產出摘要報告。」

Agent 接到指令後，會自動進行一連串操作：

1. 讀取並理解資料結構：用 pd.read_csv() 讀檔，跑 df.info()、df.describe() 了解欄位
2. 清理資料：處理日期格式、缺失值、異常值
3. 計算退貨率：按月份和產品類別做 groupby 計算
4. 排序與篩選：找出退貨率上升幅度最大的前 5 類
5. 視覺化：用 matplotlib 或 plotly 畫折線圖
6. 產出報告：整理成可讀的摘要

整個過程中，Agent 每一步都在驗證：讀取成功了嗎？資料長什麼樣？有沒有缺值？計算結果合理嗎？圖表有沒有正確顯示？它會在中間遇到問題（例如日期欄位格式不統一），然後自動修復，繼續往下走。

這就是 Agent 在資料分析上的核心優勢：它把「寫程式碼」的認知負擔從你身上拿走了，你只需要思考「我想知道什麼」。

注意事項：Agent 不能替你思考

但這裡有一個重要的陷阱必須指出。

Agent 擅長執行分析，但它不擅長定義分析。它能幫你快速算出退貨率，但它不會主動告訴你「嘿，這個退貨率上升可能跟上個月的促銷活動有關，你要不要交叉比對一下？」

資料分析的價值不在 pandas 程式碼本身，而在問對問題和解讀結果。Agent 把前者的執行成本壓到接近零，但後者仍然需要領域知識和人類判斷。

我的建議是：把 Agent 當成一個手速極快、永遠不嫌煩的資料分析實習生。你告訴它要做什麼，它瞬間做完；你負責看結果、追問、調整方向。這種人機協作模式，才是資料分析 Agent 的正確打開方式。

System Prompt 與 Context：Agent 的「人格設定」

還有一個很多人忽略的面向：Agent 的行為很大程度取決於它的 system prompt 和 project context。

以 Claude Code 為例，它的行為受到幾層 context 影響：

1. 系統內建指令：定義基本行為準則（不要刪使用者的檔案、操作前先確認等）
2. CLAUDE.md：專案級別的設定檔，開發者可以在裡面定義編碼風格、測試規範、禁止事項等
3. 對話上下文：當前對話中使用者給的指令和先前的工具呼叫結果
4. 專案檔案：Agent 讀取的 codebase 本身就是 context

這意味著同一個 Agent 在不同專案中的表現可以天差地遠。如果你的 CLAUDE.md 寫得好（例如明確指定「使用 TypeScript strict mode」、「所有函式都要有 JSDoc 註解」、「commit message 用 Conventional Commits 格式」），Agent 就會嚴格遵守。反之，如果你什麼都沒設定，Agent 會用它認為「最合理」的預設行為——但這個預設不一定符合你的期望。

把 CLAUDE.md（或你用的工具對應的設定檔）當成你跟 Agent 之間的合約。 投資時間寫好它，回報是巨大的。

延伸思考：Agent 的邊界在哪裡？

理解了 Coding Agent 的運作原理之後，我們也應該誠實面對它的限制。

Agent 擅長的：

• 有明確完成條件的任務（有測試、有 spec、有範例）
• 重複性高但需要仔細處理的工作（資料清理、格式轉換、批量重構）
• 探索性工作（「讀這個 codebase 然後告訴我它的架構」）

Agent 不擅長的：

• 需要深度業務 context 的架構決策
• 跨多個系統的複雜整合
• 沒有明確成功標準的開放式問題

知道 Agent 的能力邊界，才能最有效地使用它。不要期待 Agent 替你做架構決策，但你完全可以讓它在你定義好架構之後，高速完成所有的實作細節。

結語

Coding Agent 不是魔法，它是一個設計得非常聰明的 while loop——搭配工具呼叫、錯誤修復迴圈、以及 LLM 的推理能力。理解這個機制，你就能更有效地使用它：給它明確的 context、為它準備好測試、用 CLAUDE.md 定義你的期望、讓它去做它最擅長的重複性執行工作。

資料分析是一個很好的切入點——下次拿到一份 CSV 的時候，不要急著開 Jupyter Notebook，試著直接跟 Agent 對話，你可能會被它的效率嚇到。

但記住：Agent 是你的加速器，不是你的替代品。定義問題、審查品質、做最終判斷——這些仍然是你的工作，而且在 Agent 時代，這些技能的價值只會更高。

References

• Simon Willison, How coding agents work — 本文對 coding agent 核心迴圈、工具呼叫與「LLM harness」觀點的主要參考。
• Simon Willison, Coding agents for data analysis — 資料分析段落的主要靈感來源，包含用 Claude Code / OpenAI Codex 探索、清理、視覺化資料的 workshop handout。
• OpenAI, Function calling / tool calling guide — 工具呼叫流程、JSON schema tool definition、tool call output 回傳模式的官方說明。
• Anthropic, Tool use with Claude — Claude tool use 與 agentic loop 的官方文件。
• Simon Willison, Use subagents and custom agents in Codex — 補充 Codex subagents、Claude Code subagents 與多 agent 工作流的背景。
• Anthropic, Claude Code overview — Claude Code 作為 coding agent 工具的官方入口文件。
• Anthropic, Claude Code subagents — 子 agent / delegated task pattern 的官方說明。
• OpenAI, Codex subagents — OpenAI Codex subagents 與 custom agents 的官方文件。