以下是繁體中文版的精要整理與說明：
https://arstechnica.com/information-technology/2025/12/how-do-ai-coding-agents-work-we-look-under-the-hood/AI 程式設計代理如何運作——以及使用時該記住的事
從壓縮上下文的技巧到多代理協作，以下說明 AI coding agents（AI 程式設計代理）為何能運作、又為何不能被神話。
AI 程式設計代理的核心原理
1. 基礎是大型語言模型（LLM）
每一個 AI coding agent 的核心，都是一個大型語言模型（LLM）。
LLM 是在大量文字與程式碼資料上訓練的神經網路，本質上是一種模式預測器：
它根據提示（prompt）
從訓練中「壓縮」過的統計模式
產生看起來合理的延續內容
這使它能跨領域推理，但也會在判斷失準時產生自信但錯誤的結果（幻覺）。
為了讓模型更有用，基礎模型通常還會經過：
精細微調（fine-tuning）
人類回饋強化學習（RLHF）
以學會遵循指令、使用工具、完成實際任務。
2. Coding agent 不是單一模型
所謂的「代理」其實是一個多模型系統：
一個「主管模型」負責理解使用者的目標
多個「工作模型」並行執行子任務（寫程式、跑測試、檢查檔案）
主管模型負責中斷、檢查與整合結果
常見的運作循環是：
蒐集脈絡 → 採取行動 → 驗證成果 → 重複
3. 工具存取讓代理強大，也帶來風險
Coding agents 通常能：
讀寫檔案
執行 shell 指令
跑測試與 lint
抓取網頁或下載程式
本機 CLI 工具需要使用者明確授權；
網頁版代理則通常在沙箱雲端環境中執行，以隔離風險。
最大限制：上下文（Context）
LLM 有有限的「短期記憶」，稱為上下文視窗。
重點問題包括：
每次回應都要重新處理整個對話與程式碼歷史
計算成本隨上下文大小呈平方成長
上下文越長，模型回憶準確度越低（稱為「context rot」）
大型程式碼庫很快就會耗盡 token 與成本
研究人員把這稱為有限的注意力預算。
Coding agents 的應對技巧
1. 把工作外包給工具
代理會主動：
撰寫腳本
使用
grep、head、tail直接查詢資料庫
而不是把整個大型檔案塞進模型上下文，既省 token 又更準確。
2. 上下文壓縮（Context Compression）
當接近上下文上限時，代理會：
摘要自己的歷史內容
保留：架構決策、未解 bug、重要限制
丟棄：冗長的工具輸出與細節
這代表代理會「忘記」很多事，但能透過重新讀取程式碼與說明文件快速恢復方向。
3. 外部記憶文件
為了跨越上下文重置，建議使用：
CLAUDE.md：常用指令、架構、風格AGENTS.md：代理行為指引（已成跨公司標準）
這些檔案就像代理的「長期筆記」。
4. 多代理並行架構
在長時間任務中：
主代理負責規劃與協調
子代理並行探索不同面向
只回傳濃縮後的重要結果
代價是：
token 使用量約為聊天的 4 倍
多代理系統可達 15 倍
因此只適合價值夠高的任務。
人類使用者該記住的事
1. 「Vibe coding」很危險
在不了解程式碼的情況下直接部署，會：
引入安全漏洞
累積技術債
在專案成長時迅速崩壞
真正有價值的不是產生大量程式碼，而是證明它能正確運作。
2. 規劃比提示更重要
建議流程：
先讓代理只讀檔案，不寫程式
要求它提出完整計畫
人類審核與修正
再開始實作
否則模型常會選擇短期可行、但長期脆弱的解法。
3. AI 不一定讓你更快
2025 年一項隨機對照研究發現：
資深開發者使用 AI 工具反而慢了約 19%
儘管主觀感覺更快
對大型、成熟程式庫特別明顯
新模型是否改變結果，仍是未知數。
目前最適合的使用場景
較適合：
概念驗證（PoC）
內部工具
實驗性重構
大量樣板程式碼任務
較不適合：
安全關鍵系統
成熟的大型產品
缺乏人類審核的專案
總結
AI 程式設計代理是強大的半自主工具，而不是能負責任的工程師。
它們用壓縮換規模、用成本換速度、用自動化換取人類監督。
用得好，它們是助力；用得盲目，它們會讓事情更糟。