有人問:AI Agent 到底能做什麼有用的事? 答案不是「聊天」,而是「把你每天重複做、又懶得做的知識勞動,一鍵跑完」。 爬賣家、收名單、寫投標文案、分析報表——這些都是人做很煩、AI 做剛好的事。 這一篇拆解 agent_auto_system 的四個實戰任務,每一個都是一種 agent 設計模式的縮影。
Part 2 我們把 Harness 這層地基打穩了——重試、驗證、評分、記帳都由它包辦。這一篇回到真正產生價值的地方:任務本身。我們挑四個最有代表性的,順著它們的 PR 歷史看設計是怎麼演化的。
本篇四個任務,四種模式
─────────────────────────────────────────────
① Shopee 賣家爬蟲 → HTTP + DOM fallback + 分頁(容錯爬蟲模式)
② Google Maps 名單漏斗 → 確定性 funnel + LLM 只做最後分級(混合模式)
③ Tasker 自動投標 → Playwright 真登入 + 每案客製文案(瀏覽器代理模式)
④ 利潤健檢報告 → 四 agent 協作 + PDF 產出(多代理協作模式)
一、Shopee 賣家爬蟲:一個爬蟲的「三次進化」
對應 PR #2(新增)、PR #4、PR #5(兩次修正)
shopee_seller_scraper 的目標很單純:給定一個關鍵字或分類,從熱門商品裡收集賣家清單。但它的 PR 歷史,完美示範了「爬蟲上線後才會遇到的現實問題」。
進化 1:先能跑(PR #2)
第一版把基本能力做出來:抓熱門商品 → 解析出賣家。這是 MVP。
進化 2:數量對不上(PR #4)
fix: Shopee scraper now returns the requested seller count (up to 100)
上線後發現:使用者要 100 筆,結果只回了 20、30 筆。原因是爬蟲只抓了「第一批載入的商品」就停了。這個 PR 修正了「回傳數量」的邏輯,確保能回滿使用者要求的數量(上限 100)。
進化 3:分頁才是根本解(PR #5)
fix: Shopee DOM fallback now paginates to reach requested seller count
進一步發現,光是修數量還不夠——當走 DOM fallback 路徑時(HTTP 抓不到就退回解析頁面),必須真的翻頁才能湊到足夠的賣家。這個 PR 讓 DOM fallback 會持續翻頁,直到收集到要求的數量。
把三次進化畫成一張圖:
請求:100 個賣家
│
▼
┌─────────────────┐ 成功且夠 100
│ 路徑 A:HTTP API │──────────────▶ 回傳 ✅
└────────┬────────┘
│ 失敗 / 不夠
▼
┌─────────────────┐
│ 路徑 B:DOM fallback │
│ 抓第 1 頁 → 40 筆 │
│ 還不夠? → 翻第 2 頁 → +40 (PR #5 的修正)│
│ 還不夠? → 翻第 3 頁 → +20 │
│ 湊滿 100 → 停 │
└─────────────────┬───────────────────────┘
▼
Validator 檢查:真的有 100 筆嗎?(Part 2 §四)
│
├─ 不夠 → 觸發自我修正重跑
└─ 夠 → ✅
這裡的工程教訓:爬蟲的難點從來不是「抓到第一筆」,而是「穩定地抓到你要的那麼多筆,還要能在主路徑失效時優雅退場」。這個任務示範了「主路徑(HTTP)+ 備援路徑(DOM)+ 分頁湊量 + Validator 把關」的完整容錯爬蟲模式。而且注意——Validator 的把關(Part 2)在這裡直接派上用場,爬不夠時會自動觸發重試。
二、Google Maps 潛在客戶名單漏斗:LLM 該少做,不是多做
對應 PR #20:
feat(lead_collect): add Google Maps lead-collection funnel job type
email_collect 是我最喜歡的一個任務,因為它示範了一個反直覺但極重要的原則:在一個 AI 系統裡,讓 LLM 做越少越好,能用確定性程式碼做的就別交給 LLM。
它的目標:自動收集中小企業(SMB)的聯絡 email,並判斷是不是你的理想客戶(ICP, Ideal Customer Profile)。整個流程是一條確定性的漏斗,LLM 只在最後一關出場:
關鍵字 + 地區(例:「台北 牙醫診所」)
│
▼
┌────────────────────────┐
│ ① 探索:Google Maps 搜尋 │ ← 確定性,不用 LLM
│ 找出一批商家 │
└───────────┬────────────┘
▼
┌────────────────────────┐
│ ② 抽取:進每個商家網站 │ ← 確定性,爬蟲
│ 抓出 email │
└───────────┬────────────┘
▼
┌────────────────────────┐
│ ③ 驗證:MX 記錄 + 盡力 │ ← 確定性,不花錢用付費 DB
│ SMTP 探測、去重 │
└───────────┬────────────┘
▼
┌────────────────────────┐
│ ④ 分級:LLM 判斷是否符合 │ ← 唯一用 LLM 的一步!
│ ICP,並寫一句個人化開場 │
└───────────┬────────────┘
▼
乾淨、已驗證、已分級、附個人化 hook 的名單
為什麼 email 驗證「不用付費資料庫」?
這是一個很漂亮的成本取捨。市面上有很多付費的 email 驗證 API,但這個任務選擇用免費的技術手段:
選擇 這樣做的理由 不這樣做的理由
──────────────────────────────────────────────────────────────
MX 記錄 + 盡力 零成本、無外部依賴、 付費 DB:每筆 $0.01–0.1,
SMTP 探測 夠好地過濾掉明顯無效的 量大時很貴;還多一個
email 外部服務要維護
「盡力 SMTP 探測(best-effort)」這個詞很誠實——它不保證 100% 準,但能便宜地擋掉大部分死信箱。什麼時候該升級到付費驗證? 當你的寄信量大到「寄給死信箱會傷害你的寄件者信譽(sender reputation)」時。在那之前,免費方案的性價比完勝。
為什麼 LLM 只放在最後一步?
因為前三步都是有標準答案的工作:搜尋、抓 email、驗 MX——這些用程式碼做又快又準又便宜,交給 LLM 只會更慢、更貴、更不穩。
只有第四步「這家診所符合我們的 ICP 嗎?幫我寫一句打動他的開場白」是需要判斷與生成的——這才是 LLM 的主場。
確定性程式碼擅長:搜尋、抽取、驗證、去重(有標準答案)
LLM 擅長:判斷、歸類、生成文案(需要理解與創造)
好的 AI 系統 = 把每一步交給對的工具
這條原則,是很多 AI 產品做壞掉的分水嶺:把什麼都塞給 LLM,結果又慢又貴又不可靠。這個任務刻意把 LLM 的職責縮到最小,是很成熟的設計。這個 PR 還附了 18 個單元測試,對一個爬蟲/漏斗型任務來說相當扎實。
三、Tasker 自動投標:當 Agent 要「真的登入、真的點擊」
對應 PR #14(新增)、PR #16(註冊進目錄)、PR #18(真送出修正)
tasker_apply 是複雜度最高的任務,因為它要操作一個需要登入、有互動 UI 的真實網站(tasker.com.tw,台灣的接案平台)。這已經不是「爬個網頁」,而是「像一個真人一樣操作瀏覽器」。
它的流程:
① 登入 tasker.com.tw(用持久化的 session,避免每次重登)
│
▼
② 掃描某分類下的公開案件
│
▼
③ 對每一個案件:
│ ├─ 點「我要提案」
│ ├─ 填「初次估價」的最低/最高金額
│ └─ 寫一段「提案說明」 ← 每個案子一個 crew,AI 客製文案
│ (繁中,有 template fallback)
▼
④ 送出
PR 歷史揭露的三個真實坑
PR #14——先做出來。 用 Playwright 做瀏覽器自動化、持久化 session 登入、每個案件一個 crew 生成文案,附 8 個單元測試。
PR #16——「做好了卻沒人看得到」。
fix: register tasker_apply in ALL_AUTOMATIONS so admins can see/run it
這個 PR 修的問題很有教育意義:任務程式碼都寫好了,但忘了把它註冊進 settings_store.ALL_AUTOMATIONS——那是所有可執行任務的權威目錄(Part 1 提過 admin 從這裡指派權限)。結果 admin 在後台根本看不到、也開不了這個任務。
任務程式碼寫好 ≠ 任務可以被使用
還要:註冊進 ALL_AUTOMATIONS(權威目錄)
│
▼
admin 才看得到 → 才能指派給 user → user 才能跑
這提醒我們:一個功能「完成」的定義,包含「讓它被系統的其他部分知道它存在」。在一個有權限系統的平台裡,「寫好邏輯」只是第一步,「接進目錄與權限流」才算真的上線。
PR #18——「假裝送出」變「真的送出」。
Fix/tasker apply real submit
這是瀏覽器自動化最經典的坑:流程跑完了、文案填好了,但最後那個「送出」按鈕其實沒真的按下去(可能是 selector 沒對上、或按鈕還沒 enable、或是被 confirm 對話框擋住)。這個 PR 修正了「真正送出」的邏輯。
教訓:在瀏覽器自動化裡,「看起來跑完了」和「真的完成了」中間差了十萬八千里。你必須驗證最終的副作用真的發生了(這裡是提案真的送出),而不是只看「程式沒報錯」。這也是 Part 2 的 Validator 哲學在瀏覽器場景的延伸。
為什麼用 Playwright,而不是 HTTP 直接打 API?
選擇 這樣做的理由 不這樣做的理由
──────────────────────────────────────────────────────────────
Playwright 對方沒有公開 API;有登入、 HTTP 直打:要逆向工程私有
(真瀏覽器) 有動態 JS 渲染、有反爬蟲。 API、破解 token/簽章,又脆
模擬真人操作最穩、最不易被擋 又違反服務條款風險更高
持久化 session 只登一次,之後重用 cookie, 每次重登:慢、易觸發驗證碼
省時且降低被風控的機率
什麼時候該改用 HTTP? 當對方提供官方 API 時——那永遠比操作 UI 快且穩。Playwright 是「沒有 API 時的最後手段」,不是首選。
四、利潤健檢報告:四個 Agent 的一場接力
對應 PR #7(設計)、PR #8(多檔上傳 + PDF)
前三個任務基本上是「一個主流程 + 少量 LLM 呼叫」。profit_health_check 則展示了 CrewAI 最招牌的能力:多個 agent 分工協作。
你上傳一份(或多份)Shopee 銷售 CSV,系統跑一個四人 crew:
CSV(s) 上傳
│
▼
┌──────────────┐ 把關:欄位對嗎?數字合理嗎?髒資料清掉
│ Agent 1 驗證 │ → 產出:一份「乾淨、可信」的資料
└──────┬───────┘
▼
┌──────────────┐ 分析:毛利率?哪些品項在虧?趨勢如何?
│ Agent 2 分析 │ → 產出:量化的財務洞察
└──────┬───────┘
▼
┌──────────────┐ 建議:根據分析,該漲價?該砍品項?該衝量?
│ Agent 3 建議 │ → 產出:可執行的行動建議
└──────┬───────┘
▼
┌──────────────┐ 彙整:把上面全部組成一份好讀的報告
│ Agent 4 彙整 │ → JSON → HTML → PDF
└──────┬───────┘
▼
PDF 報告下載
為什麼要拆成四個 agent,而不是一個大 prompt?
這是多代理設計的核心問題。你當然可以寫一個超長 prompt 叫 LLM「驗證+分析+建議+排版一次搞定」,但拆開有實質好處:
選擇 拆成四個 agent 的理由 一個大 prompt 的問題
────────────────────────────────────────────────────────────────
職責單一 每個 agent 只做一件事, 一個 prompt 塞太多任務,
prompt 短、專注、好調 模型容易顧此失彼、漏步驟
可驗證中繼 「驗證」的產出可以先檢查再 全部混在一次輸出,錯了
往下傳,錯誤不會擴散 很難定位是哪一步壞
可替換 想升級「分析」的邏輯,只改 牽一髮動全身
Agent 2,不動其他
代價是:四個 agent = 四次(以上)LLM 呼叫,比單一 prompt 貴、慢一些。什麼時候該用單一 prompt? 當任務夠簡單、步驟間沒有明顯的「中繼產物需要把關」時。利潤健檢每一步都有清楚的交付物(乾淨資料 → 洞察 → 建議 → 報告),正是多代理的好場景。
PR #7 → #8:從設計到「多檔上傳 + PDF」
PR #7 是設計文件先行——先把「利潤健檢 Copilot」的架構和實作計畫寫清楚。PR #8 才實作:支援單次上傳多個檔案,並打通 JSON → HTML → PDF 的報告產出鏈。
這個 JSON → HTML → PDF 的產出策略也值得一提:
Agent 產出結構化 JSON
│
▼ 套 HTML 模板(排版、樣式、圖表)
完整的 HTML 報告
│
▼ WeasyPrint 渲染
PDF(可下載、可寄送)
為什麼中間要繞經 HTML? 因為 HTML/CSS 是最成熟的排版語言——調樣式、加表格、放圖表都容易,還能在瀏覽器裡先預覽。JSON 保留結構化資料(可另作他用),HTML 負責「長得好看」,PDF 是最終交付。這個「資料與呈現分離」的鏈路,比直接叫 LLM「生一個 PDF」可控太多。(PDF 引擎為什麼是 WeasyPrint 而不是 Chromium?這是 Part 4 一個關於 Docker 瘦身的精彩取捨,先賣個關子。)
五、四個任務,四種模式:一張總表
| 任務 | 核心模式 | LLM 的角色 | 最難的坑 |
|---|---|---|---|
| Shopee 爬蟲 | HTTP 主路徑 + DOM 備援 + 分頁 | 幾乎不用,主要靠爬蟲 | 穩定湊到要求的數量 |
| Maps 名單漏斗 | 確定性 funnel,LLM 收尾 | 只做最後的分級與文案 | 克制——別讓 LLM 做太多 |
| Tasker 投標 | Playwright 真操作瀏覽器 | 每案客製提案文案 | 確認「真的送出」了 |
| 利潤健檢 | 四 agent 協作 + PDF | 貫穿驗證/分析/建議/彙整 | 拆對職責、中繼把關 |
這張表想傳達的重點是:「用 AI 做自動化」不是只有一種寫法。有時 LLM 是主角,有時它只是漏斗末端的一個判斷器;有時你需要多個 agent 接力,有時一個就夠。判斷「這個任務該用哪種模式」,比會用 CrewAI 本身更重要。
六、貫穿四個任務的三條共同線索
儘管模式各異,四個任務都靠 Part 1、Part 2 建立的基礎設施吃到免費的好處:
- Validator 把關:爬不夠、送不出、欄位缺——都由 Validator 抓出來並觸發自我修正。任務作者不用自己寫這套。
- Harness 記帳與評分:每個任務跑完,token、成本、品質分數都自動記錄——作者一行相關程式碼都不用寫。
- 統一的 SSE 進度串流:四個任務不管內部多不同,對前端都是「一條 SSE 串流的即時 log」——這是 Part 5 的主題。
這正呼應 Part 2 的結論:把可靠性抽成一層之後,每個新任務都自動繼承它。任務作者能專心想「這個任務該長什麼樣」,而不是重複造重試、記帳、串流的輪子。
系列導覽
- Part 1:系統總覽、架構、資料流
- Part 2:Harness 引擎——多模型容錯、自我修正、LLM 評審、成本追蹤
- Part 3(本篇):自動化任務實戰——Shopee、Google Maps、Tasker、利潤健檢
- Part 4:生產化之路——Langfuse、Docker、AWS、權限
- Part 5:前端體驗與 Pipeline 編排
對應的 PR:#2/#4/#5 Shopee、#20 Maps 名單、#14/#16/#18 Tasker、#7/#8 利潤健檢 專案原始碼:github.com/yennanliu/agent_auto_system
