AI 一旦進 workflow，問題就從工具變成治理
大概三、四年前，我曾經受邀協助一個大型集團做開發流程優化相關顧問案的人選遴選。因為是股東介紹，所以我當時不是以外部顧問的角色進去，而是從實務角度幫忙看人、看方法，也看這些建議到底有沒有機會真的落地。
有一些大型 SI 公司，也有一些管顧公司來爭取這個機會。
那次我印象很深，有些看起來很專業、簡報很完整、框架講得很漂亮的人，其實從畢業後就沒有真正進過多少第一線開發現場。方法會講，報告會寫，但很多內容本質上還是照本宣科。
流程這種東西，如果沒有真的做過產品、踩過協作、扛過交付壓力，最後很容易只剩下漂亮的說法。
所以不管是看開發流程、看團隊協作，還是現在看 AI workflow，我都會特別在意一件事：它到底能不能真的進到第一線，而不是只停留在簡報跟文件上。
這也是為什麼這段時間在幫幾間新創跟集團導入 agentic development 時，我反而越來越在意一些看起來很基本、但其實最容易被低估的事情。
真正困難的從來不是 agent 接不接得進來，而是 agent 一旦開始進入 workflow，哪些事情不能再模糊處理。
先給結論，底下是我認為在導入AI Agent進入完整的SDLC中，管理者應該要關注的五件事：
決策權有沒有先劃清楚。
執行完成能不能直接被當成流程完成。
workflow 在彈性之下，有沒有保留最基本的骨架。
多 agent 到底是在增加能力，還是在釐清責任。
整個流程到底能不能被追蹤、被理解、被接手。
且聽我細細道來。
比起自動化，我現在更在意決策權怎麼劃分
很多團隊一開始談 agentic development，最自然的反應都是：能不能再多自動一點？能不能再少人工一點？能不能讓 agent 直接往下做？
這個想法很正常，我們自己也走過。
但真的做下去之後，第一個要先處理的根本不是自動化本身，而是決策權。
哪些事情 AI 可以直接做。
哪些事情 AI 可以提建議，但不能自己決定。
哪些事情一定還是要有人負責拍板。
這件事如果沒有先切清楚，後面的自動化越多，很多時候不是越穩，而是越危險。
因為 agent 一旦開始碰到的不只是單點執行，而是流程推進、跨角色交接、驗證結論，甚至影響下一步要不要往下走時，你在管理的就不是工具，而是一個會影響組織判斷的系統。
而這種東西，一開始如果還想用模糊帶過，後面通常都會補更大的代價。
Agent 做完了，不等於這個流程真的完成了
這件事也是我最近很有感的。
AI 很容易讓人有一種錯覺，就是它做得很快、產出很多，所以事情好像也完成得很快。
但 workflow 最怕的，其實就是這種錯覺。
Agent 幫你整理了一份分析，不代表分析就成立。
Agent 幫你做完一段實作，不代表需求就真的被滿足。
Agent 幫你跑完一輪驗證，也不代表這個階段就真的可以往下走。
這種「有產出」跟「已完成」被混在一起的情況，我最近看過很多次。而且老實說，這也是 AI 導入之後很容易讓團隊不小心鬆掉的地方。
因為以前人慢，所以大家知道每一步都要確認。
現在 AI 快，大家反而更容易跳過確認，直接把「做完了」當成「可以了」。
但這兩件事差很多。
所以我現在越來越在意的是，執行完成跟流程完成一定要分開。
中間還是要有人能夠定義：這一步現在到底算不算過，能不能往下走。
不然最後整個流程會跑得很快，但未必跑得準。
Workflow 可以彈性，但不能沒有最基本的骨架
我現在其實不太相信那種「一套標準 agentic workflow 可以套所有團隊」的說法。
真實世界裡，任務差異太大了。
有些是研究型的。
有些是 hotfix。
有些只是很小的調整。
有些則是跨團隊、跨系統，還牽涉很多協作的大項目。
這些事情本來就不可能走完全一樣的流程。
所以我認同 workflow 要彈性，但，我不認同 workflow 可以沒有骨架。
也就是說，你可以有不同模板，可以根據任務類型調整順序，可以在不同組織裡長出不同走法；但不管怎麼變，最基本的幾個問題還是不能消失：
這一輪到底要做什麼？
誰負責做？
誰負責檢查？
檢查之後是往下走、退回，還是改方向？
如果這些事情沒有被說清楚，那很多所謂的 agent workflow，到最後其實只是把一堆 prompt chain 跟 automation script 包裝得比較漂亮而已。
看起來很像流程，其實不是。
多 Agent 真正有價值的，不是角色變多，而是責任變清楚
這一波 Agentic development 還有一個很常見的誤區，就是大家很容易把「多 agent」跟「更進步」直接畫上等號。
但我這段時間真的看下來，越來越覺得關鍵根本不是 Agent 數量或完成的工作數量(時間)，而是責任有沒有被切清楚。
分析、實作、驗證、協調，這些事情本來就不一樣。
如果只是把同一種 generalist agent 複製很多份，系統不一定會更好，很多時候只是更熱鬧而已。
真正有價值的多 agent，不是每個 agent 都很萬能，而是每個角色該看什麼、該做什麼、該對什麼結果負責，開始變清楚。
這件事的好處不是「比較像人類組織」而已。
它真正的好處是，出了問題之後，你終於有機會回頭知道問題是在哪一段發生的。
不然如果分析、實作、驗證、協調，最後全部都還是混在一起，那你只是把原本人身上的模糊，轉移到系統身上而已。
如果沒辦法追蹤流程怎麼被推進，那它還不算 Workflow
很多 agent demo 都很好看，因為它們真的可以做事。
但一進到真實團隊裡，大家最終在意的問題其實不是它能不能做，而是：
它現在做到哪裡？
為什麼卡住？
這一步是誰決定往下走的？
這次失敗到底出在分析、實作，還是驗證？
如果要接手，現在該從哪裡接？
如果這些問題答不出來，那我會覺得這還不算真正的 Workflow management，比較像是 agent 在背景執行而已。
所以我自己現在會把 tracking 跟 observability 看得很重。
不是因為這件事很酷，而是因為只要流程沒辦法被追蹤、被理解、被接手，它就很難真的進入團隊日常。
很多人以為導入 Agent 之後，最重要的是「讓它自己跑」。
真正重要的其實是：它跑的時候，人能不能看得懂它在幹嘛。
Teams Hub 是我們給它的名字
說了那麼多，其實都是經驗的提取，我們自己去年Q3就開始建構的Agentic開發框架，迄今也改到了第八個版本，這些都是一步步發現問題，慢慢調整過來，過年後，大家覺得是時候給他個名字，投票結果就是Teams Hub，如果你們團隊也想自己建一套自己的，下面是一些建議。
紀錄很重要
RD最常看的就是 Agent(PM)跟 Agent(RD)的工作分配，還有階段性狀態切換的決策，因為我們一開始繞了一點彎路，後來找到一套方法論，就是工作可以錯，可以重來，但是一定要找到讓這個工作下次可以走上正確道路的方法。
基本上人都是需求提出者跟監督者
其實那個需求只有三行，加起來不到50字，但是我們的Agent會根據產品、既有規格、規範，就定出那麼多要求跟實作計劃，關鍵是自適應的workflow與retrospective機制，當然，還得有厲害的模型支撐著，不然看不出什麼毛病。
規劃者都必須是SOTA model
Agent的部分，可以用Codex/CC/Gemini CLI，可以用API也可以用訂閱製，通常我們在Planner / Orchestrator這樣的角色上，只會用當時的SOTA model，也只能用他們，現在Opus 1M Context的規劃能力真的非常值得一試。
設計師也可以有Agent團隊支持
我們家設計師從一次指揮多個Agent，到現在弄出好幾套workflow後，基本上每天就是負責跟Agent一起review設計結果(其實是Agent一直找他Endorse設計稿)，大部分設計稿也從Figma轉到Pencil上，雖然說功能還沒那麼強，但有時候夠用就好。
建構適合自己組織的Agent框架
這是最近開的新業務線，我們拿這套方法論，配合規格與訪談，一到兩天就能上線一套好用又符合每個組織內部流程的Agent框架，而且這套框架是會自己成長跟修正workflow，不會說建完後就固定下來，想改不好改。
其實，上線Agent框架最難的是把內部流程理順，知道應該把人擺在什麼位置，做什麼事，還有，最關鍵的是，怎麼驗證Agent做的跟你要的是同一件事。
如果你跟你的團隊，還在找尋Agent平台，或許擁有一個自己的，會是比較好的選擇，不知道怎麼挑，也可以找我們聊聊。
ps.如果您是金融業，可以聯繫安永台灣(EY)的DE團隊，除了我們這套Agent框架，他們會同時提供合規與資安要求的相關服務。