https://yennj12.js.org/yennj12_blog_V4/tags/ai-agent/Recent content in AI Agent on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSat, 04 Jul 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part1-strategy-zh/Thu, 30 Apr 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part1-strategy-zh/前言 想像你是一家小型 AI 顧問公司的創辦人。客戶問你：「我們公司要怎麼導入 AI？」 你不可能 24 小時隨時接電話，但 AI Bot 可以。 這個系列文章將帶你從零開始，用純 Bot 建立一支能夠： 接受客戶需求、提問、釐清問題 產出顧問報告草稿 自動分派任務給不同專業角色 追蹤執行狀況並彙整成果 的 AI 顧問團隊。 本篇（第一篇）專注在策略層面：應該選哪條技術路線？各自的優缺點和適用場景是什麼？ 商業背景：我們要解決什麼問題？ 根據 ai_consultant 這個商業計劃的核心理念，AI 顧問的工作可以拆成幾個主要環節： 客戶需求輸入 → 問題釐清與診斷 → 方案設計 → 報告產出 → 執行追蹤 傳統顧問公司靠人來完成每個環節。我們的目標是： 用一組協作的 AI Agent 取代或增強每個環節，讓少數人力就能服務更多客戶。 這不是「一個超級 AI 什麼都做」，而是多個專責 Agent 分工合作的概念。 三條技術路線 路線 A：Claude Code + Skills / AGENTS.md 核心概念： 利用 Claude Code CLI 的原生 multi-agent 機制，透過 AGENTS.md（或 CLAUDE.md）定義每個 Agent 的角色、工具權限與行為邊界，搭配 Skills（可重複呼叫的 slash command 腳本）讓 Agent 之間能互相協作。https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part2-implementation-zh/Thu, 30 Apr 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part2-implementation-zh/前言 上一篇 我們比較了三條技術路線的優缺點。本篇進入動手實作，每條路線都包含： 環境設定 角色（Agent）定義 實際執行範例 關鍵注意事項 路線 A：Claude Code + AGENTS.md + Skills 1. 環境設定 1# 安裝 Claude Code CLI 2npm install -g @anthropic-ai/claude-code 3 4# 確認版本 5claude --version 6 7# 登入（需要 Anthropic 帳號） 8claude auth login 建立專案目錄： 1mkdir ai-consultant-team && cd ai-consultant-team 2. 建立 AGENTS.md（團隊憲章） AGENTS.md 是整個 Agent 團隊的「組織架構圖」，定義各角色的職責與協作方式。 1# AI 顧問團隊 - 組織架構 2 3## 團隊宗旨 4協助中小企業做出明智的 AI 導入決策，提供從需求診斷到執行規劃的完整顧問服務。 5 6## 角色定義 7 8### Coordinator（協調員） 9- **職責**：接收初始需求，判斷複雜度，分派給對應 Agent 10- **不做**：不直接撰寫報告，不做技術分析 11- **輸出格式**：JSON，包含 task_id、assigned_agent、priority 12 13### Intake Agent（需求收集師） 14- **職責**：與客戶對話，收集結構化需求資訊 15- **問題清單**：產業、公司規模、現有系統、痛點、預算範圍、時程 16- **輸出格式**：Markdown 的需求摘要文件 17 18### Analyst Agent（問題分析師） 19- **職責**：根據需求摘要，診斷問題根源，評估 AI 導入可行性 20- **輸出格式**：包含 feasibility_score (1-10)、risks[]、opportunities[] 的分析報告 21 22### Strategist Agent（策略顧問） 23- **職責**：設計 AI 解決方案，評估 ROI，排列優先順序 24- **輸出格式**：方案比較表 + 建議路徑 25 26### Writer Agent（報告撰寫師） 27- **職責**：整合所有 Agent 的輸出，產出最終顧問報告 28- **格式**：Executive Summary + 詳細分析 + 行動計畫 3.https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part3-devops-zh/Thu, 30 Apr 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part3-devops-zh/前言 你已經建好了 AI 顧問 Agent 團隊（第一篇、第二篇），現在問題來了： 「這系統真的有在正常工作嗎？品質夠好嗎？出了問題怎麼辦？」 AI Agent 系統不像傳統軟體，你不能只看 HTTP 200。你需要評估輸出品質、追蹤推理過程、並且在 LLM 開始說廢話之前就發現它。 本篇從 DevOps/SRE 的角度，完整說明如何讓 AI 顧問團隊穩定、可觀測、持續進化。 一、系統效能評估：怎麼知道 Agent 表現好不好？ 1.1 評估的四個維度 品質（Quality） → 輸出內容是否正確、有用、符合顧問標準 速度（Latency） → 每個 Agent 節點的回應時間 成本（Cost） → 每次顧問對話的 Token 花費 可靠性（Reliability）→ 成功完成整個流程的比率 1.2 建立評估資料集（Golden Dataset） 這是最重要的第一步。準備 20-50 個有代表性的客戶案例： 1# evaluation/golden_dataset.py 2GOLDEN_CASES = [ 3 { 4 "id": "case-001", 5 "input": "我們是一家 50 人的電商公司，客服每天要處理 500 封郵件，想用 AI 減輕負擔。", 6 "expected_intake": { 7 "industry": "電商", 8 "size": "50人", 9 "pain_points": ["客服郵件量大"], 10 "ai_type": "自動化" 11 }, 12 "expected_strategy_keywords": ["聊天機器人", "郵件分類", "自動回覆"], 13 "quality_rubric": { 14 "relevance": "策略必須針對客服場景", 15 "feasibility": "建議的方案在 100 萬預算內可行", 16 "actionability": "至少有 3 個具體的下一步行動" 17 } 18 }, 19 # .https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part4-outsourcing-zh/Thu, 30 Apr 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part4-outsourcing-zh/情境設定 公司背景： TechBridge Studio，台灣台北，10 人軟體外包公司 主要業務： 承接中小企業的網站、APP、後台系統開發 每月詢問量： 約 40-60 個潛在客戶詢問 核心痛點： PM 每天要花 3-4 小時回覆詢問、估時、報價 需求不清楚的客戶佔 70%，常常來回溝通一週才能確定範圍 報價單格式不統一，常常漏掉風險評估 客戶問進度時 PM 要手動查詢 Jira，很耗時 目標： 用 AI Agent 團隊處理 80% 的初步詢問與報價流程，讓 PM 只需審核最終結果。 整體架構設計 客戶詢問（LINE / Email / 網頁表單） ↓ ① Intake Agent（需求釐清師） → 提問 10 個標準問題，整理結構化需求 ↓ ② Scope Agent（範圍評估師） → 拆解功能清單，標記模糊需求，評估風險 ↓ ③ Estimator Agent（報價估算師） → 根據功能清單估時、報價，套用公司價目表 ↓ ④ Proposal Agent（提案撰寫師） → 產出正式提案文件（含時程、里程碑、付款條件） ↓ ⑤ PM Review（人工審核） → PM 在 5 分鐘內審核並核可 ↓ ⑥ Follow-up Agent（追蹤師） → 3 天後自動詢問客戶是否有問題，追蹤成交 技術選型 本案例使用 Claude Code + AGENTS.https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part5-digital-marketing-zh/Thu, 30 Apr 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part5-digital-marketing-zh/情境設定 公司背景： PixelFlow Agency，台灣台中，8 人數位行銷公司 主要服務： 社群媒體管理、廣告投放（Meta / Google Ads）、SEO、內容行銷 服務客戶數： 同時服務 15-20 個品牌 核心痛點： 每個客戶每月需要 30-50 篇社群貼文，文案師產能跟不上 廣告成效報告每月要花 2 天手動彙整，格式各異 新客戶的「內容策略規劃」每次都要從頭寫，耗時 3-5 天 客戶問「我們這個月的廣告怎麼樣」時，帳號管理師要翻資料才能回答 目標： AI Agent 承擔 60% 的文案產出、100% 的報告彙整、80% 的策略草稿。 整體架構設計 定期觸發（每日/每週/每月）+ 客戶即時請求 ↓ ① Brand Agent（品牌守門員） → 載入品牌 DNA，確保所有輸出符合品牌調性 ↓ ┌────────────────────────────────┐ │ 並行執行（Parallel Execution） │ ├──────────────┬─────────────────┤ ② Content Agent ③ Ad Copy Agent （內容策略師） （廣告文案師） └──────────────┴─────────────────┘ ↓ ④ Analyst Agent（數據分析師） → 讀取廣告成效數據，產出洞察 ↓ ⑤ Report Agent（報告撰寫師） → 整合所有產出，製作月報/週報 ↓ ⑥ Presenter Agent（簡報師） → 把報告轉成客戶易讀的簡報格式 技術選型： 本案例使用 LangGraph + Claude API（路線 C）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/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/hermes-agent-intro-installation-zh/Sat, 11 Apr 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/hermes-agent-intro-installation-zh/詳細介紹 Hermes Agent，一個具有自我學習和改進能力的 AI 系統。涵蓋核心功能、安裝步驟、配置方式和實際應用，幫助你快速上手這個強大的自主 AI 系統。