很多人看 CLI 裡的 AI 工具，第一個反應還是：「這不就是把聊天機器人塞進終端機嗎？」
這個理解大概已經過期了。
比較值得盯的變化，不是模型在命令列回答得更順，也不是它會幫你補幾段 shell command。更大的轉折是：AI coding agent 正在從一個互動式助理，變成可以被派工、可以在背景跑、可以碰真實 repo、最後拿出 diff 給人驗收的執行環境。
一旦走到這一步，問題就變了。
以前我們問：「prompt 要怎麼寫，AI 才比較懂？」
現在更該問：「這個 agent 可以在哪裡跑？可以改什麼？誰授權的？跑完留下什麼證據？出事時誰負責收尾？」
這聽起來比較不性感，但比較像真的工程問題。
終端機一直是工程師最熟的控制面。它不是最漂亮的介面，但它夠直接，也夠接近真實工作：git、測試、build、deploy、log，全都在這裡。
所以 AI 進 CLI 不是小事。它代表 agent 不再只是在旁邊給建議，而是站到工作流的中間。
如果一個工具只能回答「這段錯誤是什麼意思」，那它還是問答工具。如果它可以讀專案、開 branch、改檔案、跑測試、產生 PR，甚至在你離開電腦後繼續處理工作，那它已經進入另一種分類。
這時候 CLI 的價值不是聊天，而是把任務包成一個可追蹤的工作階段。
一個健康的 agent session 至少要回答幾件事：
如果這些事情沒有被記下來，agent 做得越多，團隊越難 review。
這也是我覺得「更會聊天」不是下一個重點的原因。聊天能力會繼續進步，但真正決定能不能進團隊流程的，是 session 能不能被治理。
非同步 agent 很迷人。
你把一個重構任務丟出去，它在背景處理；你去開會，回來看結果。它可以跑在本機，也可以跑在雲端 VM。它不一定需要你盯著游標一行一行吐字。
這當然有效率。麻煩也跟著來：責任邊界開始變模糊。
以前 pair programming 時，你大概知道同伴什麼時候改了哪段 code。就算是 AI 在 IDE 裡即時補完，你也看得到它怎麼插進來。背景 agent 不一樣。它可能一次產生一個完整 diff，甚至附上測試結果，請你最後 review。
這會讓工程師的角色往前移，也往後移。
往前移，是因為你要把任務切得更清楚。不能只說「幫我整理一下這個模組」，而要說明目標、禁止事項、可接受的修改範圍，以及要跑哪些檢查。
往後移，是因為你最後看的不是過程，而是交付物。你要從 diff、測試輸出、PR description 和 agent 留下的紀錄，判斷它有沒有真的完成。
這比較像管理一個小型外包任務，而不是跟一個聊天視窗互動。
差別在於，這個外包對象很快、很便宜；你沒想清楚邊界時，它也很容易亂跑。
很多人看到 agent 跑在 Cloud VM，會先想到算力或方便性。
我反而覺得更重要的是隔離。
一個能改 code、跑測試、安裝依賴、讀取 repo 的 agent，不應該隨便在你日常工作的環境裡亂動。尤其是團隊專案。它可能需要乾淨的 checkout、固定的權限、可重現的依賴、明確的 secret 邊界，以及可以事後檢查的執行紀錄。
Cloud VM 或 sandbox 的價值就在這裡：它把「AI 可以動手」這件事關在一個比較可控的盒子裡。
這不等於保證安全。它只是讓安全有地方可以設計。
比如說：
這些規則看起來很麻煩，但如果沒有它們，agent 的能力越強，風險就越難說清楚。
工程團隊以前也不是沒有這種問題。CI runner、部署 bot、自動化 script，本來就需要權限控管。差別是 coding agent 的行為更像人：它會判斷、會改檔、會在模糊任務裡自己找路。
所以你不能只用「工具」的方式看它，也不能完全用「人」的方式相信它。
比較合理的做法，是把它當成一個有權限的執行者，再用系統設計的方式限制它。
如果團隊真的要導入 CLI agent，我會先寫的不是 prompt 範本，而是一份委派契約。
不用寫得很法律。它只要夠清楚，讓人跟 agent 都知道邊界。
例如一個 agent 任務可以長這樣：
請在
feature/search-filterbranch 上修復搜尋篩選器的空狀態 bug。允許修改src/search/與對應測試，不要調整 API contract，不要改全域樣式。完成後跑pnpm test search和pnpm lint，如果測試失敗，請在交付說明裡列出失敗原因，不要自行擴大重構。
這段文字沒有什麼魔法，但它比「幫我修 search bug」可靠很多。
它定義了 branch、範圍、禁止事項、驗證方式、失敗時的處理。這些資訊對人類同事也有用，對 agent 更是必要。
好的委派契約通常包含幾個欄位：
這些東西寫清楚後，prompt 反而變簡單了。
因為你不是在哄模型猜你的意思，而是在交代一個可驗收的工作單位。
當 agent task 可以透過 API、行動 app、issue、PR 或內部工具觸發，另一個問題會冒出來：誰可以派工？
這不是管理學問題，是工程問題。
如果任何 workflow 都能把失敗 log 轉成 agent task，任何內部系統都能叫 agent 開 PR，那團隊很快會遇到幾個麻煩：
所以 agent 的入口越多，越需要一個控制層。
不一定要很複雜。小團隊可以從幾條規則開始：
這些規則不是為了讓 agent 變慢，而是避免團隊被 agent 製造出來的工作淹沒。
很諷刺，但也很合理：AI 原本是來幫我們省事的，最後我們得先設計一套流程，防止它製造更多事。
我不太相信「未來工程師只要會下 prompt」這種說法。
Prompt 當然重要，但它比較像溝通技巧。真正會拉開差距的，是工程師能不能把一個模糊需求切成 agent 可以安全執行、團隊可以清楚驗收的工作階段。
這需要幾種能力：
這些聽起來不像新技能，其實都是老工程能力，只是被 AI 放大了。
以前你交代給同事、外包、CI bot、自動化 script 的那些規則，現在要交代給 agent。差別是 agent 更快，也更容易被誤以為「它應該自己懂」。
它不會自己懂你的團隊邊界。你要把邊界寫出來。
CLI agent 的下一步，不是把回答寫得更像人。
那只是表層。
真正的下一步，是讓 agent 在真實工程環境裡工作時，仍然能被限制、被稽核、被中止、被 review，必要時也能回滾。
如果一個 agent 只能在 demo 裡很聰明，那還不夠。它要能在權限有限的環境裡完成任務，在輸出裡留下足夠證據，讓人類 reviewer 快速判斷能不能收。
這才是 CLI agent 從玩具變成基礎設施的分界。
未來比較成熟的開發者，也許不是最會寫 prompt 的人，而是最會管理 agent session 的人。
因為真正難的不是叫 AI 動手。
真正難的是，讓它動手之後，整個團隊還知道發生了什麼。
ryanvale
iThome鐵人賽
看影片追技術