AI 代理可能讓自由軟體再次重要：當『能不能被代理改造』成為新採購標準

AI News · 2026-03-31

原文連結： AI Agents Could Make Free Software Matter Again

摘要

• George London 提出一個很有意思的觀點：AI coding agent 可能會讓「自由軟體」在 2026 年重新變得非常實際，而不只是理念口號。
• 過去 SaaS 把原始碼關在供應商伺服器裡，讓使用者就算拿到授權，也很難真正修改自己依賴的工具。
• 但現在代理可以替不會寫程式的人閱讀、理解、修改程式碼，讓「能否修改軟體」從理論權利變成可操作能力。
• 作者用 Sunsama 任務管理流程當案例，說明封閉 SaaS 會把本來 20 分鐘能完成的小客製化，硬生生變成六層 workaround 的脆弱機關。
• 他也提醒，這不代表大家都該回去自架服務；真正的問題是：未來軟體產品若不夠開放、不夠可被代理整合，競爭力會開始下降。
• 文章最後把問題拉到更高層：未來使用者選軟體時，會越來越常問一句——「我的 AI 代理能不能真正改這個東西？」

· · ·

當 AI 代理開始替人改軟體，自由軟體不再只是程式人的抽象信仰

George London 這篇文章的核心論點很直接：AI coding agent，可能會讓自由軟體重新變得重要，而且這次不是只對工程師重要。

他先回到 Richard Stallman 當年提出自由軟體運動的脈絡。自由軟體的重點，不只是「免費」，而是使用者擁有四種自由：能執行、能研究、能修改、能分享。這些自由在 1990 年代曾經是很真實的技術與政治主張，Linux、Apache、MySQL、PHP 這一整套網路基礎設施都深受其影響。

但後來 SaaS 改變了一切。

當軟體不再發到你手上，而是跑在別人的伺服器上時，使用者即使理論上在乎原始碼，也很難真的運用那份自由。你沒有在跑那個系統，也不會真的去改它。於是「自由軟體」逐漸從實際議題，退化成工程圈裡帶點理想主義的歷史殘響。

作者認為，AI 代理正在讓這件事翻盤。

因為只要代理能讀 codebase、理解資料模型、做出修改，那麼原本只有工程師能行使的自由，現在可能第一次能由代理代勞，替一般使用者執行。

「Open Source」的成功，也某種程度上拿掉了使用者權利的鋒芒

文章中一段很值得注意的歷史回顧，是作者重新梳理了 1998 年「free software」被重新包裝成「open source」的過程。

在這個轉向裡，程式碼共享的實務被保留下來，但自由軟體原本那種更帶有倫理與使用者權利色彩的主張，被刻意淡化了。企業可以很喜歡 open source，因為它能帶來更好的開發流程、更低成本、更健康的生態；但企業不需要因此承認，使用者對自己依賴的軟體其實應該有更深的控制權。

作者的意思不是說 open source 不好，而是說：這個語言上的切換，讓產業比較容易接納開源，卻也讓「使用者應該能改自己工具」這件事，慢慢失去中心位置。

而 SaaS 進一步把這個問題徹底邊緣化。因為 GPL 的義務很多時候建立在「你有把軟體發出去」，但 SaaS 公司只是在自己伺服器上執行軟體，使用者透過網路使用服務，根本沒有傳統意義上的 distribution。於是大量服務可以建立在自由軟體之上，卻不需要把自己的修改回饋出去。

這種模式最終讓「方便」壓過了「自由」。

一個 Sunsama 小需求，如何暴露封閉 SaaS 的整條限制鍊

這篇文章最好看的地方，不是抽象哲學，而是作者拿了一個超具體的例子。

他使用 Sunsama 做任務管理，想做一個其實很合理的小自動化：當他在 X / Twitter 看到之後想處理的推文時，希望能直接分享到 Sunsama，並由 LLM 自動幫他生成比較像任務的標題，還順手分進正確分類。

這個需求本身不誇張，甚至可以說是典型的「AI 時代應該很快就能補上的小客製化」。

但當他真的叫 Codex 幫忙做時，事情立刻變成一場繞路大賽：

• Sunsama 沒有官方 API，所以代理無法正規地建立任務。
• 幸好有人逆向工程做出 sunsama-relay 和 mcp-sunsama，不然整件事第一步就卡死。
• 因為沒有官方授權機制，整個流程還得直接保存 Sunsama 的帳號密碼。
• iOS Shortcut 也沒有公開可程式化建立任意 Shortcut 的方式，所以代理能寫完 serverless function，卻還是得由人自己去點 Shortcuts 那個痛苦的視覺化流程。
• 最終方案還依賴了第三方 reverse engineering、serverless hosting、Anthropic API key、X 的 oEmbed endpoint，以及一個無法好好版本控制的 iOS Shortcut。

作者說，這個東西最後是有做成，但它根本不是一個優雅的 solution，而是一台脆弱的 Rube Goldberg machine。

他的重點不是抱怨 Sunsama 爛，而是指出：如果這個服務本身足夠開放，代理原本可以直接讀原始碼、理解資料模型、改寫分享流程，十分鐘內解決。

AI 代理第一次讓「不會寫程式的人」也能實際行使軟體自由

這是全文最強的一段，也是最值得翻譯給更多人看的地方。

長年以來，自由軟體運動一直有一個很現實的弱點：即使你把程式碼公開，多數人依然沒有能力讀懂、更不可能修改。於是那些自由雖然存在，卻只對少數技術人真正可用。

作者認為，AI 代理正好補上這個缺口。

當你對 Claude、Codex 這類代理說：「幫我把這個任務管理工具改成能自動分類我儲存的推文」，你其實不是自己在改 code，而是透過代理，間接行使那份原本只屬於程式人的自由。

你不需要知道 GraphQL schema 是什麼，不需要知道哪個 service 負責寫入資料庫，也不需要理解 codebase 的歷史包袱。你只需要能描述你要什麼，代理就能替你碰那層技術複雜度。

這讓自由軟體第一次不只是「法律上允許你改」，而是「實際上有人可以替你改」。

如果這個推論成立，那未來軟體是否開放，對一般使用者的意義會比過去大很多。因為差別不再只是工程師能不能 fork，而是使用者的代理能不能真正替你完成客製化。

這個趨勢不是 George 一個人在講，越來越多人都在往同方向推

作者也整理了幾個相近觀點。

有人主張，AI 代理讓 open source 擁有對封閉軟體的「壓倒性優勢」，因為代理能直接讀、改、測完整原始碼，而不只是透過有限 API 打補丁。也有人提出，當代理讓人能在幾分鐘內做出剛剛好的內部工具時，過去很多 SaaS 的價值主張會被侵蝕。

還有人把問題拉到資料主權：如果你的資料在本地、在你掌控的系統裡，AI 才更可能真正幫你做事。否則你的代理永遠都只能在供應商設好的牆內活動。

這些論點雖然角度不同，但共識很接近：代理越強，封閉系統的代價越顯眼；開放系統的價值，反而越有機會重新上升。

但這不代表大家都該回去自架，真正難題是維護成本與生態永續

文章不是無腦吹自由軟體，這點也很重要。

作者很清楚承認，自架與自維護是有真成本的。SaaS 之所以大獲全勝，不是因為大家不在乎自由，而是因為 convenience 真的太強：不用自己處理更新、備份、SSL、DNS、值班、故障修復。對多數人來說，這個交易在很長一段時間內都非常合理。

他也指出另一個容易被忽略的問題：AI 代理可能會一邊抬高開源價值，一邊傷害開源維護者。

文中提到一些例子，包括 AI 生成內容讓低品質貢獻暴增、文件流量與商業收入下降、維護者開始考慮收緊貢獻模型。也就是說，如果代理只是把開源專案當成免費原料，不反哺維護者，那麼整個生態可能會先被掏空。

所以作者並不主張「回到 1998 年」，而是認為產業需要一種新的平衡：既保留 SaaS 的便利，又提供足夠的可改造性與可整合性，讓代理能真的替使用者工作。

他猜想，未來比較有競爭力的產品，可能會是那些擁有完整 API、真正可插拔、甚至允許你對自己的資料跑自訂邏輯的服務。

下一個軟體採購問題，可能是：我的代理能不能真正改它？

George 最後給了一個非常強的預測：在未來一到兩年內，人們選軟體時，會開始像今天問「有沒有 mobile app？」、「能不能串 Slack？」那樣，自然地問：

「我的 AI 代理能不能完整客製它？」

這句話其實非常關鍵。

因為它把 AI 從「附加功能」拉成「產品適配能力的評分標準」。如果一個 SaaS 產品的護城河只是 UI 還可以、搬家很麻煩、資料卡在裡面，那它面對代理時可能會變得很危險。代理會開始把封閉系統視為阻礙，然後想辦法繞過、重建、替代，或者乾脆把資料搬出來重做一套更合身的工具。

對使用者來說，這代表一件很現實的事：以前我們忍受一點爛 UX，是因為改不動；未來如果代理真的夠強，這種忍耐成本會快速變得難以接受。

而對產品公司來說，這篇文章其實是一個早期警告：如果你的產品無法被代理安全、完整、低摩擦地操作，那麼你的封閉性，可能會開始從護城河變成負債。

· · ·

論點很強，但「代理幫你行使自由」的前提還需要更多現實檢驗

George London 這篇文章的核心推論——AI 代理讓不會寫程式的人也能實際修改軟體，因此自由軟體的價值被重新啟動——是近期關於 AI + 開源討論裡最有結構感的一篇。Sunsama 那個案例特別有說服力：一個簡單的自動化需求，因為封閉 SaaS 沒有 API，硬是被逼成六層 workaround 的 Rube Goldberg machine。如果服務本身是開放的，代理可以直接讀 codebase、改流程，十分鐘解決。

但有幾個假設值得追問。

第一，「代理能改 code」和「代理能可靠地改 code」之間的差距，目前仍然很大。 讓 Claude 或 Codex 改一個小功能確實越來越容易，但真正有價值的客製化——改資料模型、調整權限邏輯、修改支付流程——需要的不只是「讀懂原始碼」，而是理解系統的隱含約束、歷史包袱和邊界情況。目前的 agent 在小規模修改上已經夠用，但在會影響資料一致性或安全性的變更上，仍然需要有判斷力的人類把關。

第二，開放性和可維護性之間的張力沒有消失。 文章正確地指出 SaaS 勝出是因為 convenience，但它可能低估了這個 convenience 的深度。自架服務不只是「設定一次就好」，還包括持續的安全更新、備份、監控、故障排除。即使代理變得更強，維護責任仍然存在——只是從「人手動維護」變成「人監督代理維護」。而監督代理本身，也需要一定程度的技術理解。

第三，也是最微妙的問題：代理增強開源價值的同時，可能正在侵蝕開源的維護基礎。 文章自己也提到了這點，但可以再強調。當 AI 代理大量使用開源專案作為修改和學習的素材，但不產生任何回饋（不開 PR、不提 issue、不贊助維護者），那開源生態就變成了一個被 extract 的公地。代理越強、使用越頻繁，公地被消耗的速度就越快。如果沒有新的經濟模式來支撐維護者，「自由軟體重新變得重要」可能只是短暫的——因為重要到一定程度後，沒有維護的自由軟體也不過是一堆沒人更新的程式碼。

George 最後那個預測——「未來選軟體會問：我的代理能不能改它？」——方向很可能是對的。但從預測到現實之間，還需要解決代理可靠性、維護成本分攤和開源永續性這三個並行問題。代理讓自由變得可操作，但可操作的自由如果沒有可持續的基礎設施支撐，最終也只是另一種形式的脆弱。