分享一下最近對 workflow 和 agent 的認知
最近剛忙完一階段的工作，是時候整理一下最近開發筆記和一些認知了。
大約在今年四月初時，我有收到一封信件是來自 Hive 維護者 Richard 的信件，我們彼此交換了有關 AI agent 的看法。
Hi Richard,
不好意思，信件被收入到垃圾郵件中，所以才這麼晚回覆你。
首先，我很開心您有注意到我的開發作品，有關於 ai agent 和 application 的看法，我稍微提及一下，但僅個人觀點，如您有不同想法和看法也歡迎回覆我，我們彼此可以討論交流。
有關最近很紅的 ai agent ，其實現階段的我暫時還沒有使用類似 openclaw 這類型的 ai agent 。原因在於目前對我來說大部分的需求使用習慣都可以自己透過 ai-coding 去創建 workflow 來處理。
我目前不需要一個 agent 去代勞我做任何事情，也許也僅是因為我尚未遇到這需求情境。
我發現到，社群上許多使用者其實分不太清楚 workflow 和 ai agent 分別的功用，所以也時常看見很多人抱怨 token 的花費爆表等等。
其實很多需求都有固定的流程模式，在這情境下就很適合整理成 workflow 去透過 crontab 或是事件觸發。
在這情境下，token 的損耗就是零，且行為的穩定度也會提高許多。
我有關注 Hive 這個專案，但目前我仍然尚未踏入其中，不好意思可能讓您失望了。
我有看過這專案裡頭的部分內容，我認為如果未來我有使用情境我會優先採用它，屆時再向您互相交流討論使用上的大小問題。
謝謝你。
BR,
Tai
以及他的回覆
Hey Tai,
We’ve observed the same thing when running automation ourselves. In the majority of cases, a workflow—or an AI-powered workflow (with an LLM in certain steps, combined with programmed logic)—can already do the job perfectly. For software engineers like you and me, this is very easy to build. That’s because we have the skills to creatively solve problems, but many people don’t.
Our idea is that there should be an agent (we call it the “queen agent”) that acts as the creative problem solver—first trying to understand and solve the problem on its own, and then handing it off to a graph-based workflow.
It’s perfectly fine - in fact, I’m glad to hear you don’t need to use agents yet. I think the whole industry is still evolving and finding its direction. Let’s stay in touch. I’d be happy to discuss if you come across interesting use cases where agents add value.
Best,
Richard
Sent with Shortwave
在當下我還沒有使用 Agent 的需求情境，所以這方面的體悟還不夠深入。
直到最近，我開始在我開發的系統裡頭加入了 Agent 來為我做些事情。
舉例來說：爬蟲的撰寫。有一個 workflow 是爬取資料來源 A ，清洗完資料後收入到持久層。而我無法確定的是資料來源的格式是否有變動。所以需要創建 agent routine ，當 workflow 如果出錯時，會觸發 agent 去檢視 error log ，來解析錯誤內容。接著提交 commit 發起 PR （甚至 auto merge），並通知創建者進行的哪些修正，以及更新累積的知識庫。
名詞定義：Workflow & Agent
在分享我得實際使用情境前，我認為我們應該先明確定義 Workflow & Agent 的邊界。
Workflow： LLM 和工具透過預先寫死的程式路徑被編排。
Agent： 由模型在 runtime 期間自行決定要做的事項、調用哪些工具等等，以達成某個較宏觀的目標。
也就是說，兩者間的界線並不在於有沒有使用 AI ，而是在於控制流程的掌控權是存在於編譯期間還是執行期間。
以上面提到的爬蟲來說，即使流程中加入了 LLM 去做欄位語意的理解和對齊，這仍然是 workflow 的範疇，因為整個流程在寫下程式碼的那一刻就已經固定住了。
這名詞的定義上有實際的意義存在：它讓你不會因為某一步驟需要仰賴 AI ，而整坨丟在 Agent 裡頭。這樣做不只 token 耗費巨大，且行為的穩定度也會大幅降低。
使用凝，讓我們看清事物本質
擁有確定性的 happy path 加上 agentic 的 exception path，這就是我們例子的本體。
爬蟲的行為本身很固定，假設跑 100 次，有 99 次的執行路徑都會是一樣的。這 99 次我們要的是穩定性、便宜、產出可重現，在這情境下做成 workflow 再適合不過。如果做成 Agent 代表著每次都要付 LLM 成本，且每次的產出結果都不一樣，難比較前次的成果好壞差在哪裡。
而剩下的那 1 次則是開放式的問題診斷，不知道壞在哪、無法知道要調整哪些檔案，它是各種非預期的可能狀況。這種沒辦法定義的才是 Agent 的舞台。
呼叫 Agent 的前置作業
在處理非預期的錯誤情境時，我們要盡可能的給足 Agent 足夠的資訊還有錯誤分類，才有辦法讓 Agent 可以順利的診斷問題並且修正我們的 workflow。
錯誤分類
在爬蟲上常見的錯誤可能有哪些，我們必須得明確的規範清楚。
暫時： 503, 429, timeout 等，這類情境理論上不應該提報 Agent 做處理，而是 retry workflow 即可。
結構更改： selector 改變、欄位變動、json schema 更改等，這需要 Agent 介入。
語意更改： 都回傳 200 ，原本期望檢索出 100 筆資料，但是突然變成 3 筆資料，這得要仰賴欄位的 contract 和 schema 斷言...等（詳見下文），和 Agent 的介入。
資料源消失： 加上了登入驗證、加上了付費牆，這類沒救，必須人為介入決策。
Silent Failure
爬蟲最怕的就是失敗時不拋 exception：像是某天起某個欄位變成空字串、某欄位日期格式變換了、分頁的呈現行為改變（原本每頁100筆變20筆），這些沒有明確定義 contract 和 schema 斷言驗證的話，就是被當成正常值然後送進我們的 parse 甚至收錄到持久層中。
所以我們要讓 workflow 盡可能明確的定義這些錯誤。這些檢查、驗證，也都是 workflow 的一部分內容，他們是確定性高、可重現的行為。帶來的效益和整體穩定度都能提高。
沒有這層前置的檢核機制，Agent 根本無法被觸發。資料也會很快爛光光。
更多充足的線索
要讓 Agent 可以更有把握的修復錯誤情境，我們還可以做哪些？思考看看人類會怎麼做。
原始失敗的 payload 留存，可作為該次修復 TDD 驗證的標準來源。
最近一次成功的 payload、成功結果。
error fingerprint 等摘要資訊。
關鍵步驟的解析前後狀態。
基本上我們人類過去怎麼做 error handle，留哪些 trace 資訊，就比照辦理留存給 Agent。讓 Agent 有足夠的 context 去解析錯誤情境，並寫嘗試修復。
至於修復驗收的標準除了參考 TDD 概念以外，既有的測試驗證流程也應該全數通過才行。
Agent
Agent 的本身行為相較 workflow 就顯得抽象許多。以 claude code routine 為例子，我們能給予的就是 instruction 和 tools 。在 instruction 的撰寫上就很需要去設計提示該如何調用到哪些 skill, CLI 等細節，來去嘗試約束 Agent 的行為範圍。
auto-merging 前須知（授權分級和保護準則）
要期望可以做到 agent 提交 PR 後自動合 PR，來達到一個自我修復 workflow 的效果，前提是我們必須明確將授權給分級和保護的準則。
像是，我們可以粗略區分 L0 ~ L3 級別的授權分級：
L0: 只開 issue，不做調整。（不可逆，e.g. 涉及到外部系統的連動調整）
L1: 開 PR，人類 review。（可逆但有代價，e.g. Contract 的更改、朔及既往資料的 migrate、環境變數的增減）
L2: 限定的錯誤類別，如果驗證通過的話允許 auto-merging。（可逆且有驗證，e.g. 修改 selector、調整欄位對齊邏輯）
L3: 全自動放行，要有驗證監控、如果上線炸了要能自動退回。（可逆且可自動退回，e.g. 不影響任何既有 contract）
映照到十年大博士的 PO 文，此處分級的方式恰好正式以是否可以 rollback 為標準，而非以任務的難度來做分級。
再者，修復 parser 對 agent 來說相對困難，但移除斷言規則是很容易的。我們無法預期 agent 為了完成任務，是否會走捷徑，選擇將斷言條件放寬甚至移除，只為了快速的交付。
所以我們還要準備保護準則：contract 定義、schema 斷言、測試驗證，只要任何 diff 碰觸到這些邊界，就強制歸屬在 L1 級別，必須人工 review。
當我們給足明確的評級標準交付給 Agent ，則 Agent 的行為就不會那麼不受限制。
結語
從這例子我們得出一些簡單的重點。
worflow 和 agent 的劃分界線可以由 control flow 在編譯時期還是執行時期來判斷。
擁有確定性的 happy path 加上 agentic 的 exception path，這是目前我實作出來定義最明確的 workflow + agent 的流程模式，也符合我心中所想的樣貌：過往只能是人類處理的工作，再交由 AI Agent。
在不同的領域上，仍然需仰賴大量的領域知識和經驗判定，才能有效地讓 Agent 的行為可以被約束和執行。比方說這次的爬蟲例子，如果過往沒撰寫過爬蟲，則會很難明白該注意的細節和 Agent 行為的權限分級。但慶幸的是透過現在 AI 的幫助，在領域知識的獲取上，變得更加容易和迅速。
從三四月的 openclaw 熱潮到現在，發現還在玩 Agent 的玩家，在規劃的意識上都變得很成熟。甚至 Agent 的框架也規劃的越來越完善。曾經被懷疑是 token maxxing 的資本陰謀論（要讓鏟子賣得動，就先製造需求），到現在能看到真正透過 AI 工具在改善生活、提升生產力的案例，真的很好。
不再是一昧的為了 AI 而去設計需求，而是情境在先，再逐步精鍊成可以委托給 AI 去處理的任務，最終減少人類的介入。
有趣的是，回頭來看 Richard 的信件裡頭的行為其實和我恰恰是相反的路徑。
Richard 的 queen agent： Agent 在前，先由 agent 理解問題，再創建出 graph-based 的 workflow。
我： Agent 在後，先有 workflow，再針對 exception path 去建立 agent。
我認為兩者並不衝突，同樣是 workflow 和 agent 的搭配，只是看待角度不同，依賴的 AI model 成熟度也有所差異。Richard 期望的是由 AI 主導，來釐清抽象情境並產出可靠的 workflow。我則是在確定的 workflow 之外，僅針對 exceptions 去建立 agent 來處理那些非預期的抽象情境。
就難度而言，後者（也就是我的做法）相對容易許多，但也對 AI 的成熟度要求沒這麼高，比較好落地實行。
期待未來 AI 可以更成熟或是人類願意放手的更多，能夠直接跟上 Richard 的腳步，由 AI 來全權主導這一切。
作者：Tai