Claude Code 真正難抄的不是 agent loop，而是包在外圍的 permission、context 與 recovery 系統
這則 Threads 很短，只貼了一句話：UCL 的團隊根據外洩的 Claude Code 原始碼寫了一篇 paper，並附上 arXiv 與 GitHub repo。真正值得記錄的，不是「Claude Code 被看光了」這種八卦感，而是這份研究替 AI agent 設計丟出了一個很關鍵的提醒：
大家最容易模仿的是 agent loop，但真正把產品撐起來的，通常是 loop 外圍那一大圈 deterministic infrastructure。
根據論文與 repo 的摘要，研究團隊分析的是 Claude Code v2.1.88、約 1,900 個 TypeScript 檔案、約 51.2 萬行程式碼。他們提煉出的核心結論非常值得 agent builder 記住：真正屬於「AI 決策」的部分只佔很小一塊，絕大多數複雜度都在權限、上下文、工具執行、延展能力與故障復原。
這篇真正值得記錄的重點
1. Agent 的核心 loop 其實很簡單，難的是把它變成能交付工作的系統
論文直接點出 Claude Code 的核心是一個簡單的 while-loop：
- 呼叫模型
- 執行工具
- 把結果回灌
- 繼續下一輪
這個 loop 本身不是祕密，也不是難點。真正的工程重量，來自它外圍的那些問題：
- 哪些操作要擋、哪些要放
- 什麼情況需要人類批准
- context 太長時怎麼壓縮、保留什麼
- 工具如何註冊、路由、隔離、失敗重試
- session 狀態怎麼保存，才能讓任務可恢復、可審計
- subagent 如何委派，才能既提升能力又不互相污染
也就是說，很多人以為自己在做「agent」，其實只是把模型接到一個 loop；真正有產品價值的部分，是把 loop 變成一台能長時間穩定工作的機器。
2. 這份研究把 AI agent 的設計問題，重新拉回系統工程而不是 prompt 魔法
README 裡有一句很值得記：Only 1.6% of Claude Code's codebase is AI decision logic. The other 98.4% is deterministic infrastructure.
這個比例本身不一定要逐字奉為定律，但它揭露了一件很現實的事：
- AI 模型很重要
- prompt 很重要
- 但真正讓 agent 好不好用、穩不穩、敢不敢上生產，往往不是 prompt，而是系統工程
所以如果有人只抄到一個 agent loop，就以為自己抄到了 Claude Code，通常還差得很遠。你抄到的是骨架，不是器官系統。
3. Permission、compaction、extensibility、delegation，才是 agent product 的真正護城河之一
從論文摘要與 repo 結構來看，研究聚焦在幾個典型模組：
- permission system
- context compaction pipeline
- extensibility（例如 MCP、plugins、skills、hooks）
- subagent delegation
- session persistence
這些模組有一個共同點：它們不一定最 flashy，但它們決定了 agent 能不能真的被人信任地用。
例如：
- 沒有好的 permission 模型，能力越強越危險
- 沒有好的 context 管理，對話越長越失真
- 沒有好的擴充機制，系統越做越封閉
- 沒有好的 delegation，複雜任務很難擴張
- 沒有好的 persistence，長任務就不可靠
所以這份研究真正有價值的地方，不只是「幫大家看懂 Claude Code」，而是提供了一張 agent 系統設計的 checklist。
4. 「原始碼外洩」最終產生的，不只是模仿，而是一種 design-space 公開化
很多人看到 leaked code，第一反應是複製產品；但對研究者與 builder 來說，更有價值的是把原本封閉的設計選擇攤出來，讓大家開始比較：
- 哪些是 Anthropic 的具體實作選擇
- 哪些是所有 agent 系統遲早都要回答的共通問題
- 不同部署環境下，這些問題可以有哪些不同答案
論文把 Claude Code 和 OpenClaw 這類不同脈絡的 agent 系統放在一起比較，這件事很重要，因為它讓討論從「誰抄誰」變成「哪些設計是通用問題，哪些解法只適合特定產品邊界」。
5. 對 AI agent builder 來說，這類分析最有價值的輸出不是八卦，而是反向設計能力
真正應該被帶走的，不是「Claude Code 有幾個工具、幾個 slash command」，而是這些問題：
- 我的 agent 在什麼邊界下運作？CLI、IDE、gateway 還是 SaaS？
- 安全控制應該放在 action 級，還是 perimeter 級？
- context window 不夠時，我的 compaction 策略是什麼？
- 我要怎麼設計 extension surface，才不會一擴充就失控？
- 我的 session/state 儲存，是否足以支撐長任務與追蹤？
這些才是 builder 看完之後能真的拿回自己系統裡用的東西。
為什麼這值得收進知識庫
這篇 paper 的價值，不只是因為它分析 Claude Code，而是它把「今天的 AI agent 系統到底在解哪些工程問題」拆得更清楚了。它提醒我們：agent 產品的差距，往往不在模型多聰明，而在週邊系統設計有多成熟。
如果你正在做 agent、評估 agent，或只是想判斷某個產品的護城河到底在哪，這篇研究是一個很好的觀察框架。
參考資料：