https://yennj12.js.org/yennj12_blog_V4/tags/ai-engineering/Recent content in AI Engineering on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSat, 04 Jul 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part5-frontend-pipeline-zh/Sat, 04 Jul 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part5-frontend-pipeline-zh/後端做得再精巧,使用者感受到的只有兩件事: 「我按下去之後,看得到它在動嗎?」以及「這些任務能不能串起來自動接力?」 前者是即時進度串流,後者是 pipeline 編排。 這一篇——系列最終回——談的就是這條「從按鈕到體驗」的最後一哩路。 四篇走下來:架構(Part 1)、可靠性引擎(Part 2)、實戰任務(Part 3)、生產化(Part 4)。這些都是使用者看不見的底層。最後這一篇,我們談使用者唯一真正碰得到的東西:前端體驗,以及把任務串起來的 Pipeline。 一、即時進度串流:AI 任務為什麼非有它不可 先講「為什麼」。一個 AI 任務可能跑 30 秒到好幾分鐘。如果使用者按下「執行」後盯著一個沒有任何反應的畫面…… 沒有即時進度 ───────────────────────────── [執行] → (轉圈圈…30 秒…) → 使用者以為當機 → 重新整理 → 更慘 有即時進度 ───────────────────────────── [執行] → 「登入中…」→「掃描案件…」→「撰寫第 3 篇提案…」 → 「送出中…」→「完成 ✅」 使用者全程知道它活著、在做什麼、還要多久 對 AI 任務來說,即時進度不是體驗加分,是信任的基礎。因為任務久、又是黑箱,不給回饋,使用者就會焦慮、就會亂按。 這個系統用 SSE(Server-Sent Events) 解決,Part 1 提過機制,這裡完整拆開。 二、SSE 串流的完整運作:四個零件 ┌───────────────────────────────────────────────────────────┐ │ ① 背景任務寫 log │ │ Flow 執行中,每完成一小步就 append 一條 log 到 DB │ │ progress.https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part4-production-zh/Sat, 04 Jul 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part4-production-zh/「在我電腦上跑得起來」和「能給一群人用」之間,隔著四道牆: 你看得到它在做什麼嗎(可觀測性)?它打包起來多大、部署多快(image)? 它能自動擴縮、掛了會自己重啟嗎(部署)?誰能用、能用什麼由誰決定(權限)? 這一篇,就是 agent_auto_system 翻過這四道牆的過程。 前三篇我們把系統的「能力」講完了:架構(Part 1)、可靠性引擎(Part 2)、實戰任務(Part 3)。這一篇談的是另一個維度——生產化(productionization):讓這套系統能被真實地、多人地、可維運地跑起來。四個主題,對應四個 merged PR。 一、Langfuse 可觀測性:在唯一的漏斗上掛 trace 對應 PR #19:feat(harness): add Langfuse LLM-observability integration Part 2 我們反覆強調:LLM 的「錯」不是當機,而是品質退化——HTTP 200,但答案是編的。你需要一種能看見「品質」的監控,這就是 LLM 可觀測性,而 Langfuse 是這個領域的代表工具。 這個 PR 最漂亮的地方,是它的 PR 描述本身就是一堂架構課: 「CrewAI 1.x 直接呼叫各家原生 provider SDK(不走 litellm),所以要把 Langfuse 掛在 executor——這個已經知道 model、tokens、cost、eval score、status 的唯一漏斗。」 拆解這句話為什麼重要: 很多人以為的 Langfuse 接法: 在「LLM 呼叫的那一行」自動攔截(靠 litellm 之類的中介層) 但 CrewAI 1.x 直接打原生 SDK,沒有那個中介層可攔 │ ▼ 聰明的做法:不在「呼叫點」攔,而在「執行點」記 │ ▼ executor 是所有任務的必經之路,而且它手上早就有: model + tokens + cost + eval score + status → 在這裡發一條 trace,一次到位、還帶品質分數 ┌─────────────────────────────────────────────────┐ │ executor.https://yennj12.js.org/yennj12_blog_V4/posts/anthropic-financial-services-intro-part3-example-zh/Sat, 04 Jul 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/anthropic-financial-services-intro-part3-example-zh/講概念很容易流於空泛,所以這篇只做一件事:挑一個 Agent,走一次真實流程。 GL Reconciler 是 fund-admin 這條線裡最具代表性的 Agent——輸入是總帳(GL)和對帳來源, 輸出是「哪裡斷了、為什麼斷、該找誰簽核」,而不是一個自動幫你改帳的黑盒子。 一、核心問題:對帳為什麼還需要人做 GL 對帳的痛點不是「不會算」,是斷點的根因五花八門——可能是時間差(trade date vs settlement date)、可能是手續費分類錯誤、也可能真的是資料輸入錯誤。傳統做法是資淺 Analyst 一筆一筆比對兩份表,慢且容易漏看模式。 傳統對帳流程 ───────────────────────────── GL 匯出 ──┐ ├─ 人工逐筆比對 ──▶ 找到斷點 ──▶ 憑經驗猜根因 ──▶ 簽核 對帳來源 ──┘ │ 耗時、容易漏看跨期模式 GL Reconciler 要解決的,不是取代這個判斷,而是把「找斷點」和「聚類根因」這兩步自動化,把人力集中在真正需要判斷力的「這筆該怎麼調整」上。 二、三個演進階段 Phase 1(POC / 單一基金,< 10K 筆交易月對帳量) ┌─────────────────────────────────────┐ │ Claude Code + gl-reconciler plugin │ │ 手動貼上 GL 匯出 + 對帳來源 CSV │ └──────────────┬────────────────────────┘ ▼ Claude 讀兩份表,找斷點,輸出 markdown 報告 新增元件:僅 financial-analysis 核心 + gl-reconciler plugin,無連接器 成本/複雜度:幾乎零,一個 Analyst 手動貼資料跑 解決的問題:比人工逐筆比對快,能聚類出「同一根因造成的一批斷點」 未解決的問題:資料要手動匯出貼進去,無法排程,無歷史對照 Phase 2(MVP / 多基金,10K–200K 筆/月) ┌───────────────┐ ┌───────────────┐ │ Fund Admin │────▶│ Egnyte/Box │ │ 系統匯出 │ │ (GP 報告來源) │ └───────────────┘ └───────┬────────┘ ▼ ┌─────────────────────┐ │ gl-reconciler Agent │ │ (Cowork,人在迴圈) │ └───────┬─────────────┘ ▼ 斷點清單 + 根因分類 + 待簽核佇列 新增元件:接上 Egnyte/Box 連接器自動抓 GP 報告,Cowork dispatch 讓多個基金的對帳可以並行跑 成本/複雜度:需要文件儲存連接器的訂閱/權限設定,人力成本從「逐筆比對」降到「審核聚類結果」 解決的問題:多基金並行處理,斷點根因有分類而非逐筆羅列 未解決的問題:仍然是互動觸發,沒有排程,月底集中跑時人力仍是瓶頸 Phase 3(Scale / 機構級,200K–1M+ 筆/月,多基金多幣別) ┌──────────────┐ │ 排程觸發 │ (每日/每週跑增量對帳,而非月底一次性) └──────┬────────┘ ▼ ┌─────────────────────────────┐ ┌──────────────────┐ │ Managed Agent │─────▶│ callable_agents │ │ (agent.https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part3-automations-zh/Sat, 04 Jul 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part3-automations-zh/有人問: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。https://yennj12.js.org/yennj12_blog_V4/posts/anthropic-financial-services-intro-part2-concepts-zh/Sat, 04 Jul 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/anthropic-financial-services-intro-part2-concepts-zh/大部分「AI Agent 框架」的第一個問題是:互動模式(chat)和自動化模式(headless)得寫兩套邏輯。 financial-services 的做法是:同一份 system prompt、同一組 skill,兩邊共用,只是包裝層不同。 這篇講清楚它是怎麼切出 Agent / Skill / Command / Connector 四層,讓這件事成立的。 一、核心問題:一份系統提示,兩種跑法 Claude Cowork 是互動式的,人全程在迴圈裡,隨時可以插話。Claude Managed Agents API 是 headless 的,接到你自己的批次工作流引擎裡跑,沒有人盯著。 如果這兩種模式各寫一套 prompt 和邏輯,維護成本會隨 Agent 數量線性爆炸——改一個 skill,要同步改兩個地方,遲早會漂移。 錯誤做法(兩套維護) ───────────────────────────── Cowork prompt.md ──╮ ├─ 各自維護,容易漂移 Managed prompt.md ──╯ financial-services 做法(一份來源) ───────────────────────────── agents/<slug>.md + skills/ │ ├──▶ Cowork 直接讀這個目錄 └──▶ managed-agent-cookbooks/<slug>/ 引用同一份檔案 scripts/sync-agent-skills.py 和 scripts/check.py 的存在就是為了守住這個「單一事實來源」——後者會在 CI 檢查任何 Agent 綁定的 skill 有沒有跟 vertical 裡的原始版本「漂移」。 二、五層架構總覽 ┌───────────────────────────────────────────────────────────┐ │ Agents(命名的端到端工作流,如 Pitch Agent、GL Reconciler)│ │ plugins/agent-plugins/<slug>/ │ │ ── 自包含:把它用到的 skill 都打包進來 │ └───────────────────┬───────────────────────────────────────┘ │ 綁定/呼叫 ▼ ┌───────────────────────────────────────────────────────────┐ │ Skills(領域知識與步驟方法,Claude 自動判斷何時使用) │ │ plugins/vertical-plugins/<vertical>/skills/ ← 原始來源 │ │ plugins/agent-plugins/<slug>/skills/ ← 同步副本 │ └───────────────────┬───────────────────────────────────────┘ │ 部分 skill 對應 ▼ ┌───────────────────────────────────────────────────────────┐ │ Commands(手動觸發的 slash action,如 /comps、/dcf) │ │ plugins/vertical-plugins/<vertical>/commands/ │ └───────────────────┬───────────────────────────────────────┘ │ 讀寫外部資料 ▼ ┌───────────────────────────────────────────────────────────┐ │ Connectors(MCP Server,接資料商:FactSet、Moody's.https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part2-harness-engine-zh/Sat, 04 Jul 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part2-harness-engine-zh/Demo 版的 AI:json.loads(resp.content)——今天能跑。 上線版的 AI:模型回了 ```json {...} ```、或回 429、或一本正經編造欄位——明天就炸。 差別不在模型多強,而在你有沒有一層「挽具」接住這些意外。 這一篇就是拆解 agent_auto_system 的 Harness 引擎——它如何把不可靠的 LLM,變成可預測的服務。 Part 1 我們鳥瞰了整個系統,並指出 executor.py 和 harness/ 是心臟。這一篇我們把它剖開,順著這個專案的 merged PR 歷史,看它是如何一步步長出「可靠性」的。 Harness 層有五個元件: src/automation/harness/ ├── provider.py 選模型、算 fallback 順序 ├── validator.py 每個任務的結果驗證規則 ├── evaluator.py 獨立的 LLM 評審,0–100 打分 ├── costs.py token 用量與美元成本估算 └── langfuse_tracer.py 可觀測性(Part 4 深入) 我們一個一個看,並穿插它們背後的 PR。 一、最不起眼卻最致命的第一個坑:被 markdown 包住的 JSON 對應 PR #1:fix: parse markdown-fenced JSON from LLM flow output 任何做過 LLM 結構化輸出的人都遇過這件事。你在 prompt 裡明明白白寫「只回 JSON」,結果模型很貼心地回你:https://yennj12.js.org/yennj12_blog_V4/posts/anthropic-financial-services-intro-part1-usage-zh/Sat, 04 Jul 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/anthropic-financial-services-intro-part1-usage-zh/大部分團隊想用 LLM 做財務分析,第一步是自己從零寫 prompt、兜資料源、堆流程。 正確的起手式是:先看有沒有人已經把這套流程做成可重複使用的 Agent。 anthropics/financial-services 就是 Anthropic 官方把「投銀、研究、私募、財管」最常見工作流程包好的參考實作。 裝上去、調參數,比從空白 prompt 開始快得多。 一、這個套件解決什麼問題 金融業的分析工作有一個共通結構:輸入一堆非結構化資料(財報、CIM、GP 報告、KYC 文件),經過固定的分析步驟,產出一份要給人審核的工作成果(模型、備忘錄、對帳表)。 典型金融分析工作流程 ───────────────────────────────────────── 財報 / 文件 / 資料源 │ ▼ 固定分析步驟(comps、DCF、對帳、KYC 規則) │ ▼ 工作成果草稿(memo / model / deck) │ ▼ 人工審核與簽核 ← 必要,不可跳過 這個流程本身重複性很高,但每個環節都需要領域知識(怎麼抓可比公司、怎麼算 WACC、怎麼追帳目斷點)。financial-services 這個 repo 就是把這些領域知識寫成 Claude 的 Skill 和 Slash Command,再包成 Agent。 [!IMPORTANT] 這些 Agent 產出的是分析師工作草稿——模型、備忘錄、對帳結果——供合格專業人員審核。它們不做投資建議、不執行交易、不核准開戶,每一份輸出都停在「待人工簽核」這一步。 二、兩種部署方式,同一套系統 這是這個 repo 最重要的設計決定:同一份 system prompt、同一組 skill,可以用兩種方式跑。 ┌─────────────────────────┐ ┌─────────────────────────┐ │ Claude Cowork │ │ Claude Managed Agents │ │ (互動式,人在迴圈中) │ │ API(headless,接你自己 │ │ │ │ 的工作流引擎) │ └────────────┬─────────────┘ └────────────┬─────────────┘ │ │ └──────────────┬───────────────────────┘ ▼ plugins/agent-plugins/<slug>/ 同一份 agents/<slug>.https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part1-overview-zh/Sat, 04 Jul 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/auto-agent-system-part1-overview-zh/大部分人寫 AI Agent:把 prompt 丟給 OpenAI SDK,拿到字串,json.loads(),能跑就好。 出事了才發現:模型偶爾回 markdown 包住的 JSON、偶爾 429、偶爾一本正經地亂編——每個任務都要各自處理一次。 這個專案的答案是:把「跟 LLM 打交道的所有髒活」抽成一層 Harness,讓業務邏輯乾乾淨淨。 這一系列會帶你從架構總覽,一路讀到它每一個 merged PR 背後的工程決策。 本系列以 yennanliu/agent_auto_system 這個開源專案為主角,一共五篇: Part 1(本篇):系統總覽、架構、資料流 Part 2:Harness 引擎——多模型容錯、自我修正、LLM 評審、成本追蹤 Part 3:自動化任務實戰——Shopee 爬蟲、Google Maps 名單、Tasker 自動提案 Part 4:生產化之路——Langfuse 可觀測性、Docker 瘦身、AWS 部署、權限系統 Part 5:前端體驗與 Pipeline 編排——SSE 即時串流、多步驟任務鏈 一、這個系統到底在做什麼 一句話:它是一個「AI 自動化任務的執行平台」。你在網頁上選一個任務(例如「爬 Shopee 賣家」「從 Google Maps 收集潛在客戶名單」「自動幫我在 tasker.com.tw 投標」),填幾個欄位,選一個 LLM 供應商與模型,按下執行——系統就會在背景跑一整個 AI 代理流程,並把進度即時串流回你的畫面。 它不是一個聊天機器人,而是一個把「重複性的知識工作」變成一鍵可執行任務的平台。目前內建 11 種任務類型: 任務類型 做什麼 ────────────────────────────────────────────────────────────── google_form_fill AI 檢視並自動填寫/提交 Google 表單 web_scraper 抓取網址,回傳結構化摘要 google_sheet_reader 讀取公開 Google Sheet,做欄位/統計分析 shopee_seller_scraper 從熱門商品收集賣家清單(最多 100 筆) profit_health_check 四個 agent 協作,分析 Shopee CSV,輸出 PDF 報告 x_scraper 抓取公開 X(Twitter)帳號的近期貼文 hacker_news_digest 把 HN 熱門文章整理成摘要 email_collect Google Maps 漏斗:找商家 → 抓 email → 驗證 → 分級 tasker_apply 自動在 tasker.https://yennj12.js.org/yennj12_blog_V4/posts/langfuse-intro-part4-monitoring-prompt-management-zh/Tue, 30 Jun 2026 14:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/langfuse-intro-part4-monitoring-prompt-management-zh/很多團隊把 prompt 當成「寫死在程式裡的字串」,改一個字就要改程式、跑 CI、重新部署。 也有很多團隊上線後從不看成本,直到月底收到一張嚇人的 API 帳單。 這篇講的就是讓 LLM 應用「可營運」的最後兩塊拼圖:看得見的監控,與管得動的 prompt。 一、從「會用」到「營運得起來」 Part 2 讓資料進來、Part 3 讓品質可評,這最後一篇處理的是長期營運:當你的 LLM 應用每天服務真實使用者,你需要兩件事—— ┌─────────────────────────────────────────────┐ │ 監控(Monitoring) │ │ 「現在花多少錢?多慢?品質有沒有退化?」 │ ├─────────────────────────────────────────────┤ │ Prompt 管理(Prompt Management) │ │ 「改 prompt 不必改程式、不必重新部署」 │ └─────────────────────────────────────────────┘ 二、監控:LLM 應用要盯的三個維度 傳統服務盯 error rate、latency、throughput。LLM 應用在這之上,多了一個你絕不能忽略的維度:成本。Langfuse 的儀表板原生圍繞三個維度: ┌──────────┬──────────────────────────────────────┐ │ 維度 │ 為什麼要盯 │ ├──────────┼──────────────────────────────────────┤ │ 成本 Cost │ token 用量直接換算成 $$;一個爛 prompt│ │ │ 可能讓成本翻數倍而你毫無感覺 │ │ 延遲 Lat. │ LLM 呼叫是秒級的;哪一步拖慢、p95 多少│ │ 品質 Qual.https://yennj12.js.org/yennj12_blog_V4/posts/langfuse-intro-part3-evaluation-zh/Tue, 30 Jun 2026 14:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/langfuse-intro-part3-evaluation-zh/寫傳統程式,你有單元測試:斷言 add(2,3) == 5,綠燈就是對。 寫 LLM 應用,「正確答案」往往沒有唯一解——同一個問題有一百種好的回答方式。 那你怎麼測?怎麼知道改了 prompt 之後是變好還是變壞?這就是 LLM 評估要解的問題,也是 Langfuse 最核心的價值。 一、為什麼 LLM 評估這麼難 Part 1 說過,LLM 的「錯」是品質退化而非當機。這帶來一個根本困難:品質很難測。 傳統測試 LLM 評估 ─────────────── ─────────────── assert f(x) == 預期值 「這個回答好不好?」 ✅ 確定、二元、自動 ❓ 主觀、連續、難自動 困難來自三點: 沒有唯一正解:「解釋一下這份財報」可以有無數種好答案。 品質是多維的:正確性、忠實度(有沒有編造)、完整性、語氣、格式……每個維度都要分開看。 改一處動全身:調了 prompt 修好了 A 問題,可能默默弄壞了 B 問題——你需要回歸測試。 Langfuse 的評估體系,就是把這三個困難逐一拆解。核心是一個概念:Score(評分)。 二、Score:把「好不好」變成一個數字 Part 1 提過,Score 是 Langfuse 評估的基石。它把主觀品質,變成可記錄、可追蹤、可比較的值,附加在 trace 或 observation 上。 最直接的用法是用 SDK 寫入。比如收到使用者按了「👍 / 👎」: 1from langfuse import get_client 2langfuse = get_client() 3 4# 把使用者回饋寫成一個 score 5langfuse.https://yennj12.js.org/yennj12_blog_V4/posts/langfuse-intro-part1-concepts-zh/Tue, 30 Jun 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/langfuse-intro-part1-concepts-zh/傳統後端壞掉:噴 500、log 一條 stack trace、監控告警響——你馬上知道。 LLM 應用壞掉:回了一段「看起來很合理但其實是編的」答案,HTTP 200,沒有任何錯誤。 你的使用者知道它錯了,但你的系統不知道。這就是為什麼 LLM 需要一種全新的可觀測性。 一、傳統監控為什麼救不了 LLM 應用 先想一個問題:一個傳統 API 壞掉,你怎麼發現? 傳統後端 ───────────────────────────── 輸入 → 確定性邏輯 → 輸出 │ ├─ 壞了 → throw Exception → 500 → 告警響 └─ 對了 → 200 錯誤是二元的、確定的:不是對就是錯,壞了會噴例外。你的 APM(Datadog、Sentry)抓得到。 但 LLM 應用不是這樣: LLM 應用 ───────────────────────────── 輸入 → Prompt → LLM(機率性) → 輸出 │ ├─ 幻覺(編造事實) → HTTP 200 ✅ ├─ 答非所問 → HTTP 200 ✅ ├─ 語氣不對/拒答 → HTTP 200 ✅ └─ 完美回答 → HTTP 200 ✅ 所有情況都是 HTTP 200。 沒有例外、沒有 stack trace、沒有錯誤碼。LLM 的「錯」不是當機,而是輸出品質的退化——而品質是連續的、主觀的、機率性的。傳統監控的整套工具(看 error rate、看 5xx)在這裡完全失效。