<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>LangSmith on YennJ12 Engineering Blog</title><link>https://yennj12.js.org/yennj12_blog_V4/tags/langsmith/</link><description>Recent content in LangSmith on YennJ12 Engineering Blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Thu, 04 Jun 2026 12:00:00 +0800</lastBuildDate><atom:link href="https://yennj12.js.org/yennj12_blog_V4/tags/langsmith/feed.xml" rel="self" type="application/rss+xml"/><item><title>用 AI Bot 打造顧問團隊（三）：評估、維運與優化計畫</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part3-devops-zh/</link><pubDate>Thu, 30 Apr 2026 11:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/ai-agent-team-for-consultant-part3-devops-zh/</guid><description>前言 你已經建好了 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 &amp;#34;id&amp;#34;: &amp;#34;case-001&amp;#34;, 5 &amp;#34;input&amp;#34;: &amp;#34;我們是一家 50 人的電商公司，客服每天要處理 500 封郵件，想用 AI 減輕負擔。&amp;#34;, 6 &amp;#34;expected_intake&amp;#34;: { 7 &amp;#34;industry&amp;#34;: &amp;#34;電商&amp;#34;, 8 &amp;#34;size&amp;#34;: &amp;#34;50人&amp;#34;, 9 &amp;#34;pain_points&amp;#34;: [&amp;#34;客服郵件量大&amp;#34;], 10 &amp;#34;ai_type&amp;#34;: &amp;#34;自動化&amp;#34; 11 }, 12 &amp;#34;expected_strategy_keywords&amp;#34;: [&amp;#34;聊天機器人&amp;#34;, &amp;#34;郵件分類&amp;#34;, &amp;#34;自動回覆&amp;#34;], 13 &amp;#34;quality_rubric&amp;#34;: { 14 &amp;#34;relevance&amp;#34;: &amp;#34;策略必須針對客服場景&amp;#34;, 15 &amp;#34;feasibility&amp;#34;: &amp;#34;建議的方案在 100 萬預算內可行&amp;#34;, 16 &amp;#34;actionability&amp;#34;: &amp;#34;至少有 3 個具體的下一步行動&amp;#34; 17 } 18 }, 19 # .</description></item><item><title>FDE 面試準備指南（十九）：RKK 實戰——Multi-Agent 系統的統計評估與細粒度追蹤</title><link>https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part19-multiagent-eval-tracing-zh/</link><pubDate>Thu, 04 Jun 2026 12:00:00 +0800</pubDate><guid>https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part19-multiagent-eval-tracing-zh/</guid><description>評估 RAG 系統：一個問題進去，一個答案出來，量化兩者的關係。
評估 Multi-Agent 系統：一個問題進去，4 個 Agent 跑了 10 次工具，最後出來一個答案。
中間任何一個環節出了問題，你都看不到——除非你事先設計好追蹤架構。
面試情境 面試官： 「這是一個由 4 個 Agent 組成、包含 10 次 Tool-calling 的複雜工作流。客戶說最終答案正確率很低。你如何建立統計評估管線？如何進行 Granular Tracing 抓出是哪個 Agent 或哪次 Tool-calling 出問題？」
一、核心問題：Multi-Agent 的評估為什麼比 RAG 難一個量級 RAG 評估的輸入/輸出模型： Input: Query ↓ [Single Pipeline] ↓ Output: Answer 評估點：3 個指標（Context Relevance, Faithfulness, Answer Relevance） 定位問題：要麼是 Retrieval，要麼是 Generation Multi-Agent 評估的現實： Input: User Request ↓ Router Agent → 分派 ├── Agent A → Tool 1 → Tool 2 → Output A ├── Agent B → Tool 3 → Tool 4 → Tool 5 → Output B └── Agent C → Tool 6 → Output C ↓ Synthesis Agent → 整合 A + B + C → Final Answer 評估點： ├── Router 的分派決策對不對？（Routing Accuracy） ├── Agent A 的工具呼叫成功率？（Tool Success Rate） ├── Agent B 是不是最慢的瓶頸？（Latency by Agent） ├── Agent C 的輸出品質？（Output Quality by Agent） └── Synthesis Agent 整合時有沒有幻覺？（Faithfulness） 問題可能在 10 個地方的任何一個 二、可觀測性架構：三層追蹤設計 ┌──────────────────────────────────────────────────────────────┐ │ User Request 進入 │ │ 分配唯一的 trace_id（e.</description></item></channel></rss>