當一個 coding agent 寫出的 PR 需要三輪 patch 才勉強可用，直覺通常是換更強模型、塞更多 context，或再加一個 reviewer agent。但這些做法常把真正的問題藏起來：我們把 agent 當成一把會自動變聰明的 coding 工具，卻沒有把它放進一套能約束決策、保存證據與處理返工的流程系統。

Infobip 團隊在近期 arXiv 實務論文〈A Phased Workflow for Operating LLM-Based Coding Agents〉提出 research、planning、task definition、implementation 四階段。值得注意的不是四個名稱本身，而是它把「何時允許模型做何種判斷」明確化。Research 只能讀取與搜尋，先建立可驗證的事實集；planning 才討論方案與取捨；task definition 把工作收斂為可交付、可驗收的單位；最後 implementation 才被授權修改程式。

這個順序看似保守，實際上是在修正 LLM 最昂貴的失誤型態。模型在資訊不足時仍會產生連貫的實作敘事，因此它很容易把模糊需求補成看似合理的假設。一旦開始寫碼，後續每個檔案修改都會替原始假設增加沉沒成本。此時 reviewer 發現問題，團隊往往要求 agent 在同一條脈絡上繼續 patch；結果是局部修正愈多，架構意圖愈不清楚。

我會把這套方法濃縮成一個可操作的原則：每個階段都必須產出下一階段可檢查的「邊界物」。Research 的邊界物是來源與已驗證發現，不是摘要；planning 的邊界物是替代方案、風險與選擇理由；task definition 的邊界物是輸入輸出、驗收條件、不可碰觸的範圍；implementation 的邊界物才是程式碼與測試。人類審查應放在邊界物交接處，而非等到最後看一大包 diff。這能以相對低成本攔下方向錯誤，讓人類的注意力花在高槓桿決策。

論文也用 write、select、compress、isolate 管理 context，對應 distraction、confusion、poisoning、clash 四種失敗。這比「盡量給 agent 完整上下文」更接近工程現實。完整 context 並非免費資訊，而是競爭中的訊號：過期討論會分散注意，互相矛盾的規格會造成混淆，未驗證輸入可能污染推理，多任務內容混入同一工作區則會衝突。好的 context engineering 不在於容量最大，而在於每個階段只看得到完成當前決策所需、且可信的最小集合。

尤其重要的是返工規則。若 implementation 暴露出任務定義錯誤，例如驗收條件不可測、模組邊界與現有架構衝突，正確動作不是要求 agent 再修一版，而是退回 task definition。這相當於在軟體流程中建立型別檢查：錯誤要回到最早能被語意修正的位置，而非在輸出端堆疊例外。

對正在導入 coding agent 的團隊，我建議先別追求全自動。先強制三件事：research 階段禁止寫入；每張任務卡必須有可判定的驗收條件與明確範圍；任何跨越原任務邊界的 implementation 發現，都自動建立回退點。當這些限制存在，模型能力提升才會真正轉換成吞吐量，而不是更快產生更難審的程式碼。