Agent 跑得快，但跑在對的方向上嗎？
一個常見的框架，和它沒說到的事
最近在 Dcard 軟體工程師板看到一篇討論：用 agentic engineering 做實際項目的人多嗎。裡面把 AI 輔助開發分成五層：從手敲程式、AI 輔助、agentic coding，一路到多 agent 並行、多 agent 自治協作。這種分類直覺上很好懂，但它描述的核心是「自動化程度」——人需要介入多少次、agent 能自己跑多遠。
原文部分術語與台灣習慣不同，簡單對照：
- 項目（project）→ 台灣用「專案」。例：「做一個新項目」→「開一個新專案」
- 代碼（code）→ 台灣用「程式碼」。例：「智能體接管代碼」→「agent 接管程式碼」
- 智能體（agent）→ 台灣直接用英文 agent，不另作翻譯
本文用我自己習慣的術語討論，大家可自行對應。
看到這篇，我試著在編輯器裡寫個回應草稿，但寫著寫著發現這件事可以整理成一篇獨立的文章。因為仔細看下來，我覺得這不是階層的關係，而是我們怎麼對待 context——不同的互動方式，決定了人類的 context 和 agent 的 context 怎麼碰撞，以及共享視野的程度有多大。
每個角色都有自己的 context
不管是人還是 agent，都在各自的 context 裡運作。人的 context 是你對這個專案的全部理解——架構、歷史決策、團隊習慣、這次要解決什麼。
Agent 也有自己的 context。你們之間協作得順不順，本質上是這兩個 context 的交集有多大。
環境 context：技術上能共享的部分
Agent 的 context 不只是對話記憶，而是三層合在一起：
- 對話記憶——這一輪說過什麼、做過什麼
- 可存取的 filesystem——它看得到哪些檔案、哪些 codebase
- 可呼叫的工具——它能對世界做什麼動作
這三層合起來，才是 agent 能感知到什麼、能影響什麼。
沿著工具演進來看，這個環境 context 的範圍一直在擴大：
在 Web UI 階段，三層都是殘缺的——沒有 filesystem、幾乎沒有工具、只有你手動貼進去的片段。你做的每一件事，其實都是在手動補齊那些殘缺，讓 agent 理解你的處境，然後再把結果手動搬回真實世界。
到了 IDE 整合，agent 開始看得到你正在編輯的檔案。Claude Code 這類工具再往前推，整個專案的 filesystem 都在它的可見範圍，bash、git 這些工具也都能呼叫。Multi-agent 架構則是把這個範圍分工——不同 agent 看不同區塊、呼叫不同工具。
這個距離一直在縮短。但還有另一種距離，技術手段縮不了。
意圖 context：技術給不了的部分
你做每一件事都帶著特定的意圖——不管是開發新功能、系統維運還是重構。這個意圖不是普世通用的常識，而是這個團隊、這個產品才有的地方色彩。
意圖 context 包含：
- 這件事的目標是什麼
- 這個團隊對「品質」的定義
- 哪些事情在任何情況下都不能違反
這些東西無法直接傳遞，只能靠對話、文件、反覆校正去對齊。它不是普世價值或共通常識，而是某個團隊、某個產品才有的地方色彩——用語言來比喻，更像是方言（dialect）。值得注意的是，agent 的「常識」也不是中立的基準，而是訓練資料帶進來的某種方言；兩者相遇時，是兩種方言在對話。所謂「共享視野」，量的就是這個距離：你的方言和 agent 的方言之間差多遠、能對齊多少。
從 Vibe Coding 到有約束的開發
用這個框架來看 Vibe Coding：意圖 context 集中在使用者互動的層面，提供大量的使用情境描述，但技術實作怎麼做——用什麼工具、搭什麼環境 context——則讓 agent 根據當下的判斷自由選擇。至少從結果來看，人只在意最外層的互動對不對。
往前推進，許多人開始走 Spec-Driven 的路——先寫規格、有推薦的實作流程、有文件格式。但這裡有個重要的區別：Spec-Driven 給的是容器，它告訴你怎麼寫，但不告訴你要寫什麼。容器本身不是意圖。
真正要填進去的是兩類約束。
技術約束：你願意採用哪些 solution、哪些付費哪些開源、偏好的部署環境、整個產品的語言選型。這不是「這個 function 用什麼寫」，而是整個 stack 必須維持的一致性。
商業約束：回到 Domain Driven Design 的語言——Invariant，不管怎麼實作都不能違反的 domain 規則。這是業務的核心，也是最難從外部猜到的 dialect。
能描述出來的約束，才能變成 agent 可以對齊的意圖。test case 是目前最精確的一種形式——它不說「我想要好的結果」，它直接說「這個輸入必須產生這個輸出」，可以驗證，沒有詮釋空間。
在對的時機給出足夠的約束
所以重點不是有多自動化。大部分的時間，agent 本來就不需要人一直在旁邊。
真正的問題是：你有沒有在對的時機，給出足夠的約束？
技術約束讓 agent 在對的選型範圍裡工作。商業約束讓它不會在不該越過的地方越過。這兩種約束不需要一開始就全部到位——你可以從很鬆散的地方出發，用 Vibe Coding 的方式做個 POC，先確認這條路走得通，等到要認真投入的時候，再把技術約束和商業約束一層一層補上來。約束是堆疊出來的，不是一次到位的。
這是我從 context 的角度重新思考之後，對那五個層次的詮釋：它們描述的不是「人介入多少」，而是在協作的過程中，兩種方言靠得多近。但方言對齊只是前提——我們真正要的是 outcome，不只是 output。做得很快不等於做得對，agent 產出大量結果也不等於走在對的方向上。要有 outcome，需要的是足夠的約束，以及能描述出「什麼叫做夠好」的能力；而一旦方向偏了，也要有辦法察覺、並重新給出指示。