AI代理安全始於小軟體

Matt Sephton於2026年4月發表《Fits on a Floppy》，刻意設下一個近乎荒謬的限制：有用的軟體應該嘗試放進1.44 MB，也就是標準3.5吋軟碟的容量。¹

真正重要的不是大小上限，而是背後的取態。Sephton主張快速下載、即時啟動、低記憶體、低CPU、原生程式碼、支援舊系統，以及專注做好一件事的工具。¹最直觀的解讀是：小軟體尊重使用者。放到代理時代來看，意思更進一步：小軟體讓AI程式碼代理更難把錯誤藏起來。

AI代理安全始於小軟體，因為小而可檢查的系統，會縮小代理可能誤解、錯誤修改、錯誤授權或漏測的空間。沙箱與權限提示仍然重要。小軟體則把安全邊界往上游推，推到成品本身的形態裡。

重點摘要

程式碼代理表現最佳的時候，是它能在脈絡退化前讀完相關檔案、執行相關檢查，並說清楚相關差異。Anthropic的Claude Code指南指出，脈絡會很快填滿，而且效能會隨著脈絡變滿而下降；同一份指南也把驗證稱為最有價值的實務，並將CLI工具描述為節省脈絡的介面。²OpenAI的本機shell文件也警告，會執行shell命令的代理，在執行前需要沙箱，或嚴格的允許與拒絕清單。³

小軟體不能取代這些控制措施。它讓這些控制更容易落實。小工具需要授權的命令更少、要檢查的檔案更少、要信任的相依性更少、要跑的測試更少，也有更少分支能讓錯誤假設藏身。古老的Unix教訓並未過時：McIlroy把「做好一件事」追溯到早期的大小限制，接著說明文字串流為何成為程式與人都能使用的通用介面。⁴代理系統重新發現同一個模式，因為代理需要可檢查、可組合的表面。

關鍵結論

給代理建置者： - 在加入寬泛的API或大型工具結構描述之前，先偏好輸入明確、輸出明確、產物採純文字檔案的小工具。 - 把檔案路徑、差異、日誌與測試視為安全表面。代理可以檢查，審查者可以檢查，自動化流程也可以據此把關。

給軟體團隊： - 小軟體降低審查成本。審查者可以一次讀懂一個400行工具與它的測試；龐大的框架則會在本該有證據的地方迫使人信任。 - 讓權限範圍貼近動作本身。小命令可以唯讀執行、只寫入一個資料夾，或拒絕網路存取。通用命令通常會要求比任務所需更大的權力。

給產品領導者： - 小軟體不是懷舊。它是一種治理模式，適用於機器能太快產生太多程式碼的世界。 - 標準應該從「代理能不能做出來？」移到「團隊能不能驗證、擁有，並回復它？」

為什麼小軟體再次變得重要

軟體膨脹過去看起來像使用者體驗問題：下載慢、記憶體吃重、啟動延遲、電池耗盡，舊裝置被拋在後面。《Fits on a Floppy》透過一個刻意具象的標準，讓這種批判變得可見。1.44 MB徽章把克制變成使用者能理解的測試。¹

AI程式碼代理改變了克制之所以重要的理由。機器產生檔案的速度，可以快過人類閱讀檔案的速度。當周遭系統把產量當成進度，這種速度就會削弱品質。一個2,000行功能加上4個新相依性，在逐字稿裡可能看起來很壯觀，實際上卻可能比它增加的產品價值，更大幅增加缺陷表面。

小軟體給代理一個更難蒙混的目標，也給審查者一個更好的目標。提示可以要求一個可執行檔、一種資料格式、一個測試檔案，以及一條回復路徑。結果留下的自由度更少。模型仍然可能犯錯，但錯誤比較沒有空間偽裝自己。

Niklaus Wirth早在1995年就發表了名為《A Plea for Lean Software》的論文，遠早於程式碼代理進入工作流程之前。⁵這個標題今天仍然有力，因為底層失敗依舊存在：團隊花費硬體、相依性與抽象層，來逃避困難的設計決策。代理降低了新增程式碼的成本，因此拒絕新增程式碼變得更有價值。

脈絡就是安全預算

代理安全常被描述成權限問題：代理可以執行哪些命令、編輯哪些檔案、看見哪些秘密、發出哪些網路呼叫。這些問題都重要。但它們沒有涵蓋代理工作時最先碰到的限制：脈絡。

Anthropic的Claude Code最佳實務指南說，脈絡視窗會容納對話、訊息、已讀取檔案與命令輸出，而單次除錯會話就可能消耗數萬個token。²該指南也警告，隨著脈絡視窗填滿，Claude可能開始忘記較早的指示，或犯下更多錯誤。²

這項警告讓大小成為一種安全屬性。小型程式碼庫讓代理能讀完相關表面，不必讓會話淹沒在無關檔案中。小工具讓代理可以同時看見函式、測試、權限模型與邊界案例。小差異讓審查者能找到真正的變更，而不是掃過一堆生成出來的動作。

脈絡預算有3個實務限制：

大型系統仍然可以安全。它們需要更強的分解。如果程式碼庫無法變小，面向代理的表面就應該變小：一個套件、一個有界子系統、一個公開命令、一個測試目標、一個有明確歸屬的目錄。

純文字檔案勝過隱藏狀態

McIlroy的口述歷史讓舊教訓變得格外實用。他把「做好一件事」描述為源自於沒有空間做超過一件事的原則，接著說團隊在原始限制消失後仍然保留了這個模式。⁴他也說明文字串流為何重要：人類可讀的資料讓除錯不再那麼痛苦，而演進文字欄位也比修改固定的二進位版面省事。⁴

代理需要同樣的表面。檔案可以列出、搜尋、比較差異、分段讀取、提交、回復、lint與審查。隱藏的IDE狀態、不透明的本機資料庫，以及寬泛的託管工具都可能有用，但它們會迫使代理與審查者信任一個不容易檢查的表面。

一篇2026年1月的arXiv論文，把Unix的檔案抽象連到代理式AI系統。該文主張，類檔案抽象與以程式碼為基礎的規格，能把多樣資源收斂成一致且可組合的介面，並可能幫助代理系統變得更易維護、更可稽核，也更能穩定運作。⁶Oracle的代理記憶體分析提出了相關區分：檔案系統介面之所以有效，是因為模型已經理解儲存庫、資料夾、Markdown、日誌與CLI互動等開發者原生表面；同時，耐久儲存仍可能屬於資料庫。⁷

這個區分很重要。「使用檔案」不代表「永遠把所有東西都存成鬆散文字」。更安全的模式會把代理介面與儲存基底分開：

代理應該看見最小但有用的介面。產品底下仍可保留更強的儲存層。

工具越少，權限越少

MCP授權文章把授權教訓說得很清楚：驗證bearer token，並不代表使用者可以呼叫伺服器背後的每一個工具。⁸小軟體把同樣概念更早套用在設計階段。較小的工具要求較窄的權力。

OpenAI的本機shell文件直接點出危險：執行任意shell命令可能很危險；建置者在把命令轉送到系統shell之前，應該使用沙箱，或加入嚴格的允許與拒絕清單。³Anthropic的Claude Code指南則提供了大規模實務範例：跨檔案展開工作時，使用允許工具限制，讓無人看管的執行不能做超過任務所需的事。²

小命令更容易限制：

寬泛工具往往會累積寬泛權限。一般性的「發布」命令可能觸及內容、翻譯、資料庫列、快取清除、部署日誌與分析。有時候確實需要發布命令。更安全的模式是用較小命令搭配明確關口組成發布流程，等每一步都有證據後，再把序列自動化。

目標不是讓工作變慢。目標是讓權力變得可見。

測試應該符合工具大小

Anthropic第一個最佳實務章節告訴使用者，要給Claude一種驗證工作的方式：測試、截圖、預期輸出與命令檢查。²小軟體讓這項建議具體化。小工具可以帶著一份小型驗證契約。

對代理建置的軟體來說，這份契約應該能放在一個畫面裡：

Inputs:
- one source path
- one output path
- one optional flag

Allowed effects:
- read source path
- write output path
- no network unless --verify-sources is present

Evidence:
- unit tests for parsing
- fixture test for output
- dry-run output for the exact file
- git diff limited to owned paths

這份契約很重要，因為代理太容易滿足模糊要求。「改善管線」會引來架構翻動。「替這個命令新增dry-run旗標，並證明輸出不會寫入檔案」則會建立一條證據路徑。

工具維持小型時，測試也會更快。快速測試會改變代理行為。代理會更常執行測試，在相關程式碼仍留在脈絡中時看見失敗，並在逐字稿漂移前修掉根本原因。緩慢測試會把模型推向猜測，或開始敘述它本來會執行什麼。

小不等於做得不足

小軟體可能以可預期的方式失敗：

軟碟徽章衡量大小。代理安全需要不同的衡量方式：審查者能否在批准變更前，理解行為、權限範圍與證據路徑？

這個問題允許工具超過1.44 MB。它拒絕的是真正重要的部分：意外範圍。一個安全、無趣的20 MB原生app，可能勝過一個會呼叫未審查安裝程式的200 KB腳本。小軟體只有在克制抵達實際執行路徑時，才會服務安全。

給代理工作的「小」評分表

在代理建置或修改工具前，先從5個面向評分。重點不是懲罰大型系統，而是找出代理開始寫作前需要先分解的表面。

任何紅格都不代表工作應該停止。紅格代表代理需要更小的工作單位。當任務形狀讓正確行為更容易證明，安全性就會提升。

實務模式

我信任的最安全代理建置系統，通常具有同一種形狀：

1. 一個狹窄命令只做一件事。
2. 純文字檔案承載輸入、輸出、日誌、計畫與審查包。
3. 權限對應到命令的實際效果。
4. 測試快到足以讓代理在會話中使用。
5. 差異小到人類可以審查。
6. 發布路徑由小命令組合而成，而不是把寬泛權力藏在一個按鈕裡。

無建置宣言從web技術堆疊的角度描述了同一種偏好：更少建置層、更少生成產物，以及來源與執行環境之間更短的距離。⁹代理安全版本則對另一種讀者說同一件事。每多一層，機器就多一個地方能產生看似合理、但人類無法快速驗證的工作。

小軟體把克制變成基礎設施。較窄的模組改善脈絡適配。較樸素的檔案改善可稽核性。較快的測試改善回饋。較小的權限集改善爆炸半徑控制。較小的差異改善人類判斷。

FAQ：小軟體與代理安全

小軟體會讓AI程式碼代理變安全嗎？

不會。小軟體會降低代理可能誤解或造成損害的範圍。團隊仍然需要沙箱、允許與拒絕清單、測試、程式碼審查、憑證邊界與發布關口。小軟體讓這些控制更容易套用，也更不容易被意外繞過。

面向代理的工具應該多小？

有用的限制不是位元組數，而是可審查性。好的代理介面工具只有一項工作、小型輸入／輸出契約、清楚的權限輪廓、快速測試，以及審查者能一次讀懂的差異。

代理記憶體應該使用檔案還是資料庫？

當代理需要檢查、搜尋、比較差異與寫入產物時，使用檔案作為介面。當產品需要並行、索引、存取控制、耐久性或跨使用者狀態時，使用資料庫。更安全的架構會把面向代理的介面與儲存基底分開。⁷

MCP放在哪裡？

當代理需要通往外部工具或資料的型別化橋接時，MCP很合適。MCP不會消除小命令、範圍化權限與動作層級授權的需求。伺服器仍然必須判斷特定主體是否可以執行特定動作。⁸

結語

AI讓程式碼變便宜。便宜的程式碼提高了拒絕的價值。

小軟體給拒絕一種機器能遵守的形式：一個命令、一個輸出、一條權限邊界、一條測試路徑、一份差異。形式不能保證品質。但它會讓薄弱的工作更容易被看見。

軟碟不再是限制。可檢查性才是。

參考資料