0. 這不是炫技 demo｜真正的主角是一套代理工作系統
Kun Chen 這支影片的表面主題，是一位曾在 Meta、Microsoft、Atlassian 擔任 L8 Principal Engineer 的工程師，用 agentic engineering 從零開始做一個全端 app。影片原始來源在這裡：L8 Principal Building a Full Stack App with Agentic Engineering。
但如果只把它看成「AI 幫我寫 app」，會漏掉最有價值的部分。這支將近 100 分鐘的實作，真正示範的是一套工作系統：人類不直接管理每一個 agent，也不盯每一次 tool call，而是把自己放在 captain 的位置，只和一個協調者 FirstMate 對話。FirstMate 再去派出不同 crewmates，分別處理市場研究、技術規劃、UX 原型、GitHub repo、基礎設施、iOS app、後端部署與端到端測試。
這裡的差別很關鍵。一般人談 coding agent，常把焦點放在模型能不能一次寫出正確 code。Kun 展示的不是這件事。他展示的是：當模型能力已經足夠做很多工作時，人的問題會變成「怎麼管理這些工作」。代理多了之後，真正的瓶頸不再只是 prompt，而是任務拆分、上下文切換、權限管理、成本判斷、產品範圍、驗收標準，以及出錯時誰來把系統拉回軌道。
影片從一個空 terminal 開始。Kun 先啟動 Herder，這是他拿來管理 agent sessions 的環境；接著設置 FirstMate，也就是他開源的協調者工作流。他要求所有 crewmates 都使用同一類模型配置，還刻意不用最強模型，而是用更有效率的 Luna，想證明「不是每件事都需要最貴、最強的模型」。
這個選擇本身就透露他的工程觀：agentic workflow 的目標不是把所有問題丟給單一最強模型，而是設計一個可以把中等模型能力放大的系統。更好的流程、文件化狀態、可視化決策面板、權限閘門與驗收迴路，會比單純換模型更能決定最後能不能出貨。
1. 單一入口降低切換成本｜Captain 只和 FirstMate 對話
FirstMate 的核心價值，是把多代理工作流變成「單一入口」。Kun 不需要自己想：市場研究 agent 在哪個 tab？技術研究 agent 卡在哪裡？UX 原型要不要重跑？GitHub repo 誰去建？他只要持續把想法丟給 FirstMate。
這不是因為人類不重要，而是因為人類不該浪費注意力在 agent routing 上。當 Kun 說「先做市場研究和技術規劃」時，FirstMate 會派出兩條平行 workstream。當他又想到前端也要先看使用者旅程時，他直接補一句給 FirstMate，FirstMate 再新增 UX prototype agent。當他發現 repo 名字拼錯、或想把 PR 合併策略改成直接合併，他也不用自己追每個子任務，只要對 FirstMate 說出新的判斷。
這種工作模式最大的改變，是人類從「每個終端的操作員」變成「系統的產品與架構決策者」。他仍然做決定，但不再親手做所有 coordination。
影片早段有一個很有意思的小細節：Kun 開了 calm mode，讓終端不再顯示大量 tool calls，只留下他的 prompt 與 FirstMate 的回覆。他說，一兩年前模型還比較容易走錯路，盯 tool calls 有助於即時修正；但今天模型能力提高後，他越來越少需要用那種方式介入。
這句話不是說 observability 不重要。相反，FirstMate 的子代理仍然跑在可觀察的 Herder tabs 裡，必要時可以點進去看，也可以直接和子代理互動。重點是預設體驗不該逼人類一直盯底層噪音。好的 agent UI 應該讓人類在需要時能 drill down，不需要時能留在高階決策層。
這也是很多 agent 產品還沒處理好的地方：它們要嘛把所有細節藏掉，讓使用者無法理解系統在做什麼；要嘛把所有 token、tool call、log 都倒給使用者，讓人像在看一台很吵的機器。Kun 的工作流想找的是中間點：日常只看決策摘要，出問題時可以進到具體 agent session。
2. 決策畫布比長報告有用｜Lavish 把研究變成可互動判斷
FirstMate 派出的市場研究與技術研究會產生長報告。Kun 很快指出一個問題：報告本身有用，但 351 行 markdown wall of text 不適合人類做互動決策。於是他要求 FirstMate 把技術方案放到 Lavish 裡討論。
Lavish 是他用 HTML artifacts 做的互動決策工具。代理不是只丟一篇報告，而是把架構、選項、成本、開放問題、流程圖與決策點整理成可以點、可以標註、可以排隊回饋的畫布。這個差異很大：報告是「請你讀完」；決策畫布是「請你判斷」。
在後端方案上，代理一開始建議 hosted Supabase Pro，估計成本約每月 25 美元。Kun 立刻反應：對一個只有少數使用者的家庭錢包 MVP，這太貴。他根據自己經驗指出，Hetzner 低成本 VPS 應該可以把成本壓到每月 5 美元左右。代理修正假設後，方案才轉向低成本 VPS。
這段是整支影片最值得反覆看的地方之一。代理不是完全錯，它只是用了偏 SaaS、偏 operational simplicity 的假設。但 MVP 的產品現實是：三個人用的家庭工具，不能一開始就背每月 25 美元以上的固定成本。這個判斷不是模型缺不缺資料，而是人類對產品階段與成本結構的取捨。
Kun 也在畫布上刪掉一些隱性過度設計，例如 audit events、encrypted export 等早期不需要的需求。他保留「手機只是 client、Postgres 是權威狀態」這種重要架構邊界，但砍掉會拖慢 MVP 的附加功能。這正是人類在 agentic workflow 裡仍然不可替代的工作：辨識哪些是架構原則，哪些只是模型順手補出來的漂亮包袱。
3. 人類負責判斷而不是盯工具｜好的代理會把問題端上桌
Kun 在影片裡不斷做出小而重要的判斷。
他看到 UX prototype 裡用「tokens」當孩子的錢包單位，立刻說不要，應該用使用者當地貨幣，因為 Eddie 本來就用真實 allowance 的語境理解金錢。他看到 child view 裡同時有 recent activity list 和 recent activity button，指出這會重複。他看到設計稿把「Eddie」當成所有使用者的名字，提醒品牌可以叫 Eddie's Wallet，但 app 不能假設每個孩子都叫 Eddie。
這些看起來都是小意見，但它們是產品品質的核心。代理可以產出 wireframe、設計系統、iOS app 與後端 API，可是「這句文案是否混淆品牌和使用者」、「這個成本是否符合 MVP 階段」、「這個功能是否過度設計」、「這個驗收標準是否真的代表完成」，仍然需要人類判斷。
所以這支影片其實不是在宣告工程師可以離開現場。Kun 幾乎全程都在現場，只是他的工作內容改變了。他不寫每一行 code，不逐一操作每個 tab，也不讀完整報告；他做的是更高層的 shaping：
第一，決定產品範圍。哪些功能進 MVP，哪些之後再說。
第二，修正模型假設。Supabase 成本、VPS 成本、是否需要多環境、是否需要 audit/export。
第三，保護使用者體驗。語氣、命名、畫面流程、孩子與家長的角色邊界。
第四，定義完成標準。不是 PR merge 就好，而是 simulator 要能用真實 Apple account 連到真實後端完成端到端流程。
這是 agentic engineering 很容易被低估的一點：它不是讓人類消失，而是把人類的注意力從「怎麼做」轉到「什麼才算對」。
4. 給代理能力但保留權限閘門｜Atomic Vault 是這套流程的安全邊界
影片中段進入基礎設施時，代理需要碰到真實外部世界：Hetzner API、Apple Developer、Cloudflare DNS、GitHub repo、VPS、backend deployment。這裡如果處理不好，agentic workflow 就會從「很方便」變成「很危險」。
Kun 的做法是用 Atomic Vault 管理 production secrets。代理可以請求使用某個 token，但每次要真的拿 token 去執行命令時，人類會看到授權對話框，可以檢查它要執行什麼命令、要把 secret 用在哪裡，再決定 approve 或 deny。
這比把 secrets 放進 .env 安全很多。.env 的問題不只是可能被 commit，更麻煩的是一旦 agent 可以讀，它在任何 tool call 裡都可能不小心把 secret 帶出去。人類通常不會盯每一個 tool call，因此權限必須在工具層被切開，而不是只靠「我相信模型不會亂來」。
Kun 的原則很清楚：給代理很多能力，但當它觸碰 production 環境或敏感憑證時，要有明確授權。這讓代理可以真的做事，而不是只能產生建議；同時也讓人類保留最後控制權。
這點對所有想把 agent 接到公司內部系統的人都很重要。真正可用的 agentic workflow 不能停在「代理會寫 code」，它必須回答：
代理什麼時候能讀資料？
代理什麼時候能寫資料？
代理什麼時候可以部署？
代理使用 secret 前誰看得到？
出了問題能不能追溯是誰、在什麼指令中用了哪個權限？
如果這些問題沒有答案，把 agent 接進 production 就會變成賭運氣。Kun 這支影片展示的是另一條路：讓 agent 具備行動能力，但把高風險行動收斂到可審核的授權閘門。
5. MVP gate 不是 PR 合併｜端到端測試才是完成
影片後段，FirstMate 已經合併了幾個 PR：後端基礎設施有了，native iOS/iPadOS app 和 design system 也有了，甚至通過了 iPhone simulator validation。一般 demo 到這裡可能就會停下來，宣布成功。
Kun 沒有。他追問：「iOS app 已經真的連到 backend 了嗎？」答案是沒有，還是 mock。這就是 agentic workflow 最容易自我感覺良好的陷阱：每個局部都完成了，PR 都綠了，文件也很完整，但真正的產品路徑還沒打通。
他重新定義 MVP gate：在 simulator 裡，用真實 Apple account 登入，連到真實 VPS 上的 backend，完成端到端體驗。這才算 MVP done。
這個判斷把整個工作流推進下一層。代理需要處理 Apple Sign in、後端 auth、HTTPS hostname、Cloudflare DNS、部署與 simulator 測試。Kun 甚至注意到代理想設置 development/production 多環境，立刻糾正：這個階段只需要一個 production MVP environment，不要過度工程。
這段很像真實軟體開發的縮影。你可以有 PRD、repo、設計稿、API、部署腳本、mock UI，但只要端到端路徑沒打通，使用者仍然不能用。Agentic engineering 的驗收也一樣：不能只看 agent 做了多少事，要看它是否把最重要的使用者路徑完成。
Kun 後面還請 FirstMate 自己做 e2e testing，不要除非只有人類能做才來問他。這句話很值得記下來：Don't ask me unless there's something only I can do. 它不是偷懶，而是在設定代理的預期行為。能查的自己查，能測的自己測，能修的自己修；真的需要人類的地方，再把問題端上來。
6. 魚塘觀點｜下一代工程師的核心技能，是設計代理組織
這支影片最有價值的地方，不是 Eddie's Wallet 這個 app 本身，而是它把「和 AI 一起寫 code」往前推了一層。問題不再是單次 prompt 能不能生成一段 code，而是：
你能不能把一個模糊產品想法，拆成可並行研究、可視化決策、可驗收實作、可控部署與可測試 MVP？
你能不能讓代理自己忙起來，同時不讓它們在高風險區域亂碰？
你能不能讓人類的注意力集中在最有價值的判斷，而不是被 tool calls、terminal panes、長報告、PR 雜務淹沒？
Kun 的答案，是把代理當成一支需要管理的工程團隊，而不是一個會說話的 autocomplete。FirstMate 是 coordinator，crewmates 是執行者，Lavish 是決策介面，Atomic Vault 是安全邊界，GitHub PR 是工作交接，simulator e2e 是驗收 gate。
這套系統仍然有很多現實限制。模型會過度工程，會拼錯名字，會把 mock 當進度，會對成本做錯假設，也會在真實 Apple/Cloudflare/Hetzner 流程裡遇到外部摩擦。但這些問題不代表 agentic engineering 不可行；它們反而指出真正需要設計的地方。
魚塘的結論是：未來的高槓桿工程師，不只是會用 coding agent，而是會設計 agent organization。知道哪些任務能平行、哪些決策要人類判斷、哪些權限要 gate、哪些文件要落地、哪些測試才算真的完成。
這支 100 分鐘影片最重要的提醒也許是：AI 工程的下一步，不是讓代理看起來更像人，而是讓一群代理在人的決策框架下，像一支可以出貨的團隊。