Google 的下一個寫程式代理人：Jitro 若成真，開發者將不只下指令，而是設定目標

【 AI 新聞 ｜ 編輯：Sandy】

截至 2026 年 4 月底，DevOps.com 在〈Google’s Next Coding Agent Could Change How Developers Think About Their Work〉（https://devops.com/googles-next-coding-agent-could-change-how-developers-think-about-their-work/）中披露，Google 似乎正在以內部代號「Jitro」打造下一代 Jules 編程代理人。若相關線索最終落地，這不會只是又一個能修 bug、寫測試、開 pull request 的 AI 工具，而可能代表軟體開發工具的一次更深轉向：開發者不再逐條告訴代理人要修改哪個檔案、補哪段程式，而是設定「提高測試覆蓋率」、「降低錯誤率」、「改善無障礙合規」等工程目標，讓代理人自行判斷程式庫中哪些部分需要改變。

這種變化之所以重要，是因為它觸及了 AI coding agent 競賽的核心問題。過去幾年，產業焦點多放在模型能否更快補完程式碼、更準確理解大型程式庫，或更可靠地通過測試。但 Jitro 的想像若成立，Google 正試圖把競爭從「生成程式碼」推向「管理工程成果」。這是一個更接近企業軟體開發日常的戰場，也更符合大型組織對品質、安全、效率與治理的長期焦慮。

Jules 是起點，不是終點

要理解 Jitro 的潛在意義，必須先看 Jules 已經站在哪裡。根據 Google 官方部落格〈Build with Jules, your asynchronous coding agent〉（https://blog.google/innovation-and-ai/models-and-research/google-labs/jules/），Jules 在 2025 年 5 月進入公開 beta，定位為非同步、具代理能力的 coding assistant。它會把開發者的程式庫複製到安全的 Google Cloud 虛擬機中，理解專案脈絡，執行寫測試、修 bug、建立新功能、更新相依套件版本等任務，完成後再呈現計畫、推理過程與程式差異。

這與傳統程式碼補完工具不同。GitHub Copilot 早期讓開發者在 IDE 中更快打出下一行程式，Cursor、Windsurf 等工具則把聊天介面與編輯器深度結合；Jules 的差異在於，它能在背景中工作。Google 的 Jules 文件〈Getting started〉（https://jules.google/docs/）也描述，Jules 連接 GitHub 後，會在虛擬機裡 clone 程式碼、安裝依賴、修改檔案，開發者則可在它運作期間處理其他工作。這使 Jules 更像一名可被指派任務的初階工程師，而不是貼在游標旁邊的自動完成器。

Google 之後又把 Jules 往開發者日常工作流推近一步。根據 Google Developers Blog 的〈Meet Jules Tools: A Command Line Companion for Google’s Async Coding Agent〉（https://developers.googleblog.com/en/meet-jules-tools-a-command-line-companion-for-googles-async-coding-agent/），Jules Tools 讓開發者可直接在命令列啟動任務、檢查代理人狀態，甚至把 Jules 編入自動化流程。這顯示 Google 並不滿足於把 AI 放在瀏覽器裡，而是想讓它進入終端機、GitHub、CI/CD 與企業工程管理鏈條。

從 prompt 到 KPI：Jitro 的真正野心

DevOps.com 對 Jitro 的描述中，最值得注意的不是名稱，而是範式轉移。多數 coding agent 仍以「任務」為基本單位：修復這個錯誤、為這個函式補測試、把這個 API 改成新版介面。Jitro 若真以高階目標為核心，則其工作方式更接近「KPI-driven development」。開發者或工程主管不再把每個工單拆成細碎步驟，而是設定可追蹤的工程成果，代理人再跨越程式碼、測試、文件與部署脈絡，尋找能推動指標改善的修改路徑。

這聽起來像管理語言進入程式世界，但並非空泛口號。大型程式庫的問題往往不是單一 bug，而是長期累積的技術債、測試盲區、相依套件老化、效能退化與安全風險。人類工程師當然能處理這些事，但它們常因不夠醒目、不夠有成就感，或排不進短期產品路線圖而被延後。若代理人能在受控範圍內持續追蹤目標、提出修補計畫、分批送出變更，AI 對軟體工程的價值就會從「加速個人」變成「降低組織摩擦」。

這也是 Google 可能押注 Jitro 的策略意圖。Gemini 生態系需要的不只是聊天機器人或模型 API，而是能證明模型可進入高價值工作流的產品。開發者工具是最佳試驗場之一：程式碼可被測試，變更可被 diff，流程可被審核，成效也能以測試覆蓋率、建置通過率、缺陷率、部署頻率等指標衡量。換言之，軟體工程比許多知識工作更容易讓 AI 代理人的產出被驗證，也更容易形成訂閱與雲端運算收入。

美國巨頭的競賽：Google、Microsoft、OpenAI 與 Anthropic

Jitro 若走向目標型代理，將進入一個已相當擁擠、但仍未定型的市場。Microsoft 與 GitHub 的位置最接近企業開發主幹。根據 GitHub 官方新聞稿〈GitHub Introduces Coding Agent For GitHub Copilot〉（https://github.com/newsroom/press-releases/coding-agent-for-github-copilot），GitHub 在 Microsoft Build 2025 推出 Copilot coding agent，強調它是嵌入 GitHub 與 VS Code 的非同步代理人，可從 GitHub issue 或 Copilot Chat 啟動，並透過 draft pull request、session logs、人類審核與 branch protection 等機制維持可控性。GitHub 的優勢不在單一模型，而在它掌握了全球開發者協作場域。

OpenAI 則從 ChatGPT 與模型能力切入。根據 OpenAI 官方公告〈Introducing Codex〉（https://openai.com/index/introducing-codex/），Codex 是雲端軟體工程代理人，能平行處理多項任務，包括寫功能、回答程式庫問題、修 bug、提出 pull request，並在預載使用者程式庫的隔離環境中執行。OpenAI 的敘事是把 coding agent 變成 ChatGPT 中的「軟體工程隊友」，它的長處是模型品牌與使用者入口，但挑戰是如何深入企業既有的開發、權限與審計流程。

Anthropic 的 Claude Code 則更強調工程師與代理人的角色重分配。根據 Anthropic 產品頁〈Claude Code | Anthropic’s agentic coding system〉（https://www.anthropic.com/product/claude-code），Claude Code 主打「agentic, not autocomplete」，宣稱工程師將更多專注於架構、產品思考與持續協調，管理多個代理人並決定要建造什麼。這與 Jitro 可能的方向有明顯交集：未來的競爭不只是誰能寫出較漂亮的函式，而是誰能讓工程團隊放心把更大範圍的決策交給代理人。

中國與歐洲的不同壓力

從國際視角看，美國公司正在把 coding agent 與雲端、開發平台、模型訂閱綁在一起，形成一場平台戰。Google 有 Gemini、Google Cloud、Android Studio、Firebase 與 Workspace；Microsoft 有 GitHub、Azure、VS Code 與企業客戶；OpenAI 則藉 ChatGPT、Codex 與合作雲平台擴大觸角。這些公司都在爭奪同一件事：讓 AI 成為軟體生產鏈的預設層，而不是外掛。

中國市場的競爭邏輯不同。百度、阿里、騰訊、華為與多家新創同樣投入程式生成與企業 AI 工具，但它們更常與本土雲端、政企客戶、資料合規與國產化軟硬體生態綁定。對中國企業而言，coding agent 的吸引力不只在節省工程師時間，也在於支援大型內部系統改造、遷移舊系統、降低對外部開發工具鏈的依賴。若美國公司以 GitHub 和雲端沙盒建立全球標準，中國公司則可能在私有化部署、內網開發環境與垂直產業場景上形成差異化。

歐洲則會把監管與信任問題推到前台。AI 代理人若能自主修改程式碼，便牽涉可解釋性、責任歸屬、資料處理、資安審計與供應鏈風險。對金融、醫療、公共部門與關鍵基礎設施而言，「代理人做了什麼」不只是工程問題，更是治理問題。因此，Jitro 這類目標型代理若要進入歐洲大型企業，透明的推理紀錄、變更證據、審批流程與可撤回機制，可能比模型跑分更重要。

最大瓶頸不是會不會寫，而是能不能被信任

Jitro 的想像最誘人之處，也正是最大風險所在。當代理人只被要求修一個明確 bug，錯誤範圍通常有限；當代理人被要求「降低錯誤率」或「改善安全姿態」，它可能需要跨越多個模組、調整測試、改動相依套件，甚至重新詮釋系統設計。這類任務越接近真實工程管理，越難完全用單次測試確認正確。

因此，未來 coding agent 的競爭將由「生成能力」轉向「控制能力」。企業需要知道代理人為何選擇某條修改路徑、忽略哪些替代方案、是否遵守安全政策、能否在合規環境中留下足夠紀錄。DevOps.com 原文也引述 Futurum Group 的觀點指出，當代理人跨越生產程式庫自主追求目標時，團隊必須理解其優化目標、推理過程與約束條件，這會成為信任基礎。這種觀察切中要害：工程組織不缺會產生程式碼的工具，缺的是可被授權、可被追責、可被治理的工具。

這也解釋了為何 Jitro 若推出，可能不會立即大規模開放。目標型代理適合大型成熟程式庫，但這些程式庫同時也是風險最高的場域。對 Google 而言，最合理的路線可能是先以 waitlist 或受控 preview 形式導入，讓企業在限定權限、限定 repo、限定目標下測試，再逐步擴大代理人的自主程度。

產業意義：工程師角色正在被重新定義

AI coding agent 的中長期影響不會只是「少雇幾名工程師」這麼簡單。更可能發生的是，工程師工作的重心向上移動。初階任務、重複性修補、測試補齊、文件更新與相依套件整理，將逐步交給代理人；人類工程師則更多負責設定目標、審查設計、定義邊界、評估風險、協調多個代理人與決定產品方向。這不代表寫程式能力不再重要，而是寫程式將更常與審查、規劃、架構與系統思考交織。

對企業而言，商業模式也會改變。過去開發者工具多以每席授權收費，AI 代理人則可能疊加模型使用量、雲端執行時間、平行任務數與企業治理功能。當代理人能長時間在雲端虛擬機中工作，軟體開發工具市場就更接近雲端基礎設施市場。這對 Google 是機會，因為它可把 Gemini、Google Cloud 與開發工具綁成閉環；但也是挑戰，因為 Microsoft/GitHub 已掌握開發者協作入口，OpenAI 擁有強大的模型心智，Anthropic 則在 agentic coding 社群中建立了高黏著度。

對使用者行為而言，最深的變化可能是「工程任務的單位」被重寫。今天的工程師建立 issue、寫需求、切 branch、送 PR；明天的工程主管可能會建立一組長期工程目標，讓多個代理人在背景中持續提出小幅、可審核、可回滾的改善。這聽起來像軟體工程版的自動駕駛：人類仍握有方向盤，但越來越多微小操作交由系統完成。

開放式結尾：Jitro 的成敗，取決於 Google 能否把自主性包進治理框架

Jitro 目前仍是外媒披露的內部項目線索，而不是 Google 已正式發布的產品。因此，任何對其功能、上市時間與命名的判斷都應保持審慎。然而，這則消息之所以值得關注，正在於它符合整個產業正在移動的方向：coding agent 已不再滿足於補完程式碼，而是試圖進入任務分配、品質改善與工程管理。

若 Google 能把 Jules 已有的非同步工作、雲端 VM、GitHub 整合、計畫與 diff 可視化，進一步升級為可追蹤目標、可審核推理、可設定約束的 Jitro，它將有機會把 AI coding agent 從「開發者效率工具」推向「企業工程治理平台」。但若透明度、權限控管與結果驗證跟不上，自主代理人也可能成為另一種技術債，只是這次技術債由 AI 自動生成。下一階段的問題因此不是 AI 能否寫更多程式碼，而是企業是否願意讓它為工程成果負起一部分責任。