最近整理了一下我平常在龍蝦上設計 Skill 與 Workflow 的做法，也順手把 Agent、Skill、Workflow 這三層的差別寫下來，覺得蠻值得分享。
先講兩個極端的例子： 去年 n8n 之類的工作流工具很紅，把任務拆成節點、連好線，讓 AI 按流程跑。這種方式省錢、穩定、可預期，但它只能做你預先定義好的事，條件一變流程就得重來。
光譜的另一端，則是完全放手讓 Agent 自由探索，什麼都讓 LLM 自己想辦法。它可能最終摸索出跟你手動定義一樣的方案，但可能花了好幾倍的 Token，而且下次做同樣的事還是得重新摸索。
兩種方式各有優缺點，固定流程無法適應變化，自由探索雖然彈性高，但如果沒有後續整理與固化，經驗就很難真正沉澱成可重用資產。
所以實際上比較合理的做法是分層。
Agent：全部讓 LLM 自己來
你給它目標，它自己思考、規劃、執行、反思，每一步都是 LLM 在跑。彈性最大，適合你還不確定流程的時候讓它先跑一遍。但因為每一步都靠 LLM 探索跟決策，Token 用量自然比較高。
Skill：把做過的流程整理起來
在我的工作流裡，Skill 比較像是從 Agent 探索過程中萃取出來的可重用模組。只是你把探索的結果固定下來了，讓 Agent 不用每次重新摸索，所以 Skill 相比純 Agent，通常會更省 token、也更穩定，但本質上仍然是 agentic 的做法。
Workflow：腳本為主，LLM 為輔
Workflow 的重點是把流程的控制權從 LLM 拿回來。簡單的情況可以直接用 Script 線性跑，Step 1 → Step 2 → Step 3 按順序執行完就結束；複雜一點的會用 Dispatcher 做調度，根據條件分流或平行處理。不管哪種，核心都是腳本在主導，只有真正需要語言理解的地方才 call LLM。Token 通常最省、速度通常最快、穩定性也通常最高；代價是它對預設邊界外的變化適應力較弱，如果沒有做好容錯設計，某一步失敗就可能連帶影響後續流程，不像 Agent 可以自己繞路。
三種類型就是一個光譜，左邊是最大靈活性，右邊是最大穩定性跟效率。
我自己的做法是先手把手帶 Agent 跑一遍看流程可不可行，確認可行就寫成 Skill 固定下來，如果這個 Skill 每天都在用，而且有些過程不需要 LLM 判斷，就再推成 Workflow，把不需要判斷的部分用腳本跑，節省 token。
但有個很重要的原則是不要急著升級，一個好用的 Skill 比一個寫壞的 Workflow 有價值得多。我自己也是用了一陣子 Skill，確定流程真的穩定了才去轉 Workflow，而不是一開始就急著把所有東西自動化。流程要自然成熟，不是硬推的。
其實 Anthropic 在他們的文件裡也提到類似的概念：先從最簡單的架構開始，只在必要的時候才增加複雜度。Cursor 的設計也是這個邏輯，Skill 是動態載入的知識包，Workflow 則是把不需要 LLM 的步驟用腳本自動化。
我個人覺得這個分層的意識蠻重要的，不是說每件事都要推到 Workflow，而是知道自己手上的任務目前在光譜的哪個位置，需不需要往右邊移，還是現在這樣就夠了，這也是一個需要自己衡量的地方。
有在用 AI Coding Agent 或養龍蝦的朋友，你們平常會做這種分層嗎？歡迎留言聊聊 🦞