假設團隊換了一台開發機，裝上新版 Qt Creator，卻找不到原本使用的 AI Assistant extension。有人說：「換一個 agent 接上去就好。」如果只要它回答 QML 問題，或許夠了；原本若還要它改檔、建置、根據編譯錯誤修正，事情就沒那麼簡單。
先釐清時間：Qt 公告的 2026 年 9 月 30 日是停止隨 Qt Creator 配送 AI Assistant extension，技術支援則到 12 月 31 日。這不是宣告舊安裝在 9 月 30 日當天被遠端關掉。真正容易卡住的場景，是換機、升級或交接後，團隊不知道原本靠哪些 IDE 能力完成工作。
Qt Creator 的 ACP Client 讓 IDE 與外部 agent 建立對話。ACP 管的是編輯器與 agent 怎麼溝通、維持工作階段；它不是「所有 agent 都會建置 Qt 專案」的保證。
另一條路徑是 Qt Creator 的 MCP Server：它把建置、執行等 IDE 動作提供給 agent。官方的「build and fix」範例要求 ACP Client 與 MCP Server extension 都啟用。即使聊天視窗已連線，若 agent 不能取得這些工具，或沒有適當權限，編譯仍跑不起來；就算跑完，也要看這次實際的輸出，不能把 agent 說的「修好了」當成驗收。
遷移紀錄至少要分開寫：agent 是否連上，以及這次工作需要的 IDE 動作是否真的能用。其中任何一步沒過，都別用「支援 ACP」四個字帶過。
拿一個可重建的小型 Qt/QML 專案與測試分支，先確認目前 Qt Creator 版本、ACP Client extension 是否啟用，並記下原本的建置套件、目標裝置與 build 指令。後面若切到另一個 kit，編譯結果就很難拿來對照。
在 Preferences > AI > ACP Servers 選預設 agent 設定，或加一個 Custom 項目，填入可執行檔、參數與需要的環境變數。確認所選 agent 已安裝，且 Qt Creator 啟動時找得到它。若該 agent 透過 npx 啟動，要先備好 Node.js；走 uvx 則需要對應的 uv／Python 環境，別把兩套依賴一股腦都裝上。可執行檔找不到時，檢查 Preferences > Environment > System 的 PATH，再重新啟動 Qt Creator，回到 ACP chat 選 agent 並按 Connect。
先請 agent 指出目前開的是哪個專案、哪個 QML 檔案。這一步若連工作目錄都講錯，別急著讓它改碼。連線紀錄也留著：選用的 agent 與版本、啟動命令、連線是否成功，以及失敗訊息。不要把某個 agent 的成功設定，直接當作另一個 agent 也會繼承的狀態。
如果試跑範圍包含 IDE 建置，啟用 Qt Creator MCP Server extension，從 Preferences > AI > Qt Creator MCP Server 查看是否開啟、監聽位址和埠。Qt 文件說，Qt Creator 內使用 ACP Client 時會自動使用這個 MCP server；換成其他產品連線，則要另行設定。這裡的「自動」仍以相關 extension 與環境可用為前提，不代表每個 agent 都有相同的工具或授權。
測試題目可以很小：在測試分支改一處 QML 按鈕的錯誤提示，請 agent 嘗試建置。事先記下原始狀態，跑完再核對修改的檔案、Qt Creator 顯示的編譯輸出、實際使用的 kit，最後由人打開畫面，看看失敗狀態是否真的可見。無法讓 agent 觸發 build，就明記「人工執行建置」，不要假裝它已走完整段流程。
官方範例把模式設成 Accept Edits，用於示範讓 agent 建置並修編譯錯誤。那是範例條件，不是團隊應直接套用的權限預設。先限制在可丟棄的測試專案，不提供正式環境憑證；若沒有要讓 agent 改檔的理由，就由人審核變更並手動跑建置。MCP server 在本機監聽也不等於權限問題已經解決，位址、埠與可觸及的專案範圍都值得留下紀錄。
交接時我會留一份短紀錄：Qt Creator 版本、啟用的 extension、agent 的啟動設定、ACP 連線結果、MCP 實際可用的動作、監聽設定，以及這次 build 的輸出和人工檢查結果。舊流程如果還要保留一段時間，也註明哪個版本與環境可以回退；做不到回退就直說。
ACP 讓入口比較容易換，MCP 讓工具有機會接得上。兩者都不會替團隊搬走舊 session、複製權限，或替你看 QML 畫面。只有下一位同事照紀錄跑過同一個小任務，這次遷移才算有交代。
iThome鐵人賽
看影片追技術
看更多
ryanvale
