跳到主要內容

AG Day 45 系列總結與延伸路線

AG Day 45 系列總結與延伸路線

執行需求：CPU 可跑。今天是「AI Agent 工程實戰：LangGraph、MCP 與多代理系統」系列的第 45 篇，也是最後一篇。從 AG Day 1 系列導覽：AI Agent 工程的學習地圖（原文連結）到 AG Day 44 技術手冊：常見維運情境（原文連結），我們花了 45 天、每天一篇，把「會呼叫 LLM API」一路推到「能打造可觀測、可評估、可部署的多代理系統」。貫穿專案 research-agent 從零長成 v1.0：手刻代理迴圈 → LangGraph 框架 → 結構化輸出 → 串流輸出 → RAG 檢索 → 引用出處 → 搜尋工具 → MCP 整合 → 多代理架構 → 通訊協議 → 評估集 → LLM-as-judge → Langfuse 觀測 → FastAPI 服務 → Docker 容器 → CLI 與 Streamlit → 壓測 → README → 限制清單 → 維運手冊。今天的任務是把這一切收束起來：盤點 research-agent 的完整能力、列出每一篇的主題與產出、給未來的延伸路線，並把讀者從「學完整個系列」引導到「開始自己的專案」。這一篇完全在本機 CPU 上完成，不需要 API 金鑰、Docker 或外部服務，是整個系列最安靜卻也最具儀式感的一篇。

引言

寫系列文章最怕「收尾虎頭蛇尾」：前面 44 篇把專案從零蓋到 v1.0，最後一篇如果只是簡單重述，就辜負了前面的累積。今天我們不寫「謝謝大家讀到這裡」，而是把 45 篇的累積壓縮成一張「能力圖譜」與一張「學習路線圖」：前者告訴讀者「research-agent 現在能做什麼」，後者告訴讀者「如果想更深入，下一步該往哪個方向走」。這兩張圖的價值在於它們是「可驗證的」：每一個能力點都對應到 AG 系列的某一篇、每一個延伸方向都能從今天開始動手。

這個系列走到今天，最值得回顧的不是某一篇的細節，而是整條學習路徑：從「為什麼要框架」（AG Day 10）到「如何用框架」（AG Day 11-19）、從「單一代理的極限」（AG Day 10）到「多代理的分工」（AG Day 29-30）、從「程式能跑就好」（AG Day 6）到「程式能被評估」（AG Day 32-34）、從「程式能跑」（AG Day 38）到「程式能交給別人維運」（AG Day 42-44）。這條路徑呼應了軟體工程的核心節奏：寫程式 → 測試 → 觀測 → 改進 → 部署 → 維運。AG 系列把這個節奏完整地示範在 AI Agent 系統上。

原理／觀念

為什麼這 45 篇是一個整體而不是 45 個獨立主題

把 45 篇當作 45 個獨立主題來讀，每一篇都會顯得瑣碎；但把它們當作一條線性演進路徑，整個系列的設計就清楚了：每一篇都「站在前一篇的肩膀上」，同時「為下一篇鋪路」。AG Day 1 的環境準備、AG Day 2 的工具鏈，是 AG Day 3-9 對話與工具呼叫的基礎；AG Day 10 對框架的反思，是 AG Day 11-19 引入 LangGraph 的鋪墊；AG Day 18 的子圖、AG Day 23 的引用，是 AG Day 28 接上 MCP、AG Day 29 拆多代理的前置條件。理解這個層層遞進的設計，比起死記每一篇的內容更重要——因為日後讀者要解決自己的問題時，能依樣畫葫蘆地設計自己的演進路徑。

貫穿專案 research-agent 是這個設計的核心。它從 AG Day 6 的手刻迴圈開始，AG Day 14 換成 LangGraph ReAct，AG Day 18 拆出子圖，AG Day 23 加上引用，AG Day 28 接上 MCP，AG Day 29-30 變成多代理，AG Day 38 包成 FastAPI，AG Day 39 容器化，AG Day 40 加上 CLI 與前端，AG Day 41 壓測，AG Day 42-44 完成交付。每一篇都用同一個專案的延伸做示範，而不是每篇都開新專案，這讓學習者能「沿著程式碼的演進」理解每一個設計決策的脈絡。

為什麼要先做簡單版再升級

很多讀者會問：「為什麼不從 AG Day 14 直接開始講 LangGraph？為什麼要花 6 篇手刻迴圈？」答案是：手刻迴圈能讓你「看清楚模型在幹嘛」，這是後續用框架時除錯的基礎。AG Day 6-9 的手刻迴圈、AG Day 8 的 Pydantic 結構化輸出、AG Day 9 的觀測基礎，這些在 AG Day 11-19 換成 LangGraph 時全部派上用場：你的結構化輸出契約可以直接搬進 State 設計、你的觀測資料可以直接接上 Langfuse、你的錯誤處理可以直接整合進 ToolNode。沒有前 9 篇的地基，後面 36 篇會變成「跟著抄但不知道為什麼」。

同樣的道理，AG Day 28 接 MCP 之前要先有「工具呼叫」（AG Day 5）、「多步代理」（AG Day 6）、「錯誤處理」（AG Day 7）、「結構化輸出」（AG Day 8）的基礎；AG Day 29 拆多代理之前要先有「狀態設計」（AG Day 12）、「條件邊」（AG Day 13）、「ReAct」（AG Day 14）的基礎；AG Day 38 做 FastAPI 之前要先有「CLI」（AG Day 40 雖然是後做的，但概念在 AG Day 6 就有了）等的基礎。先做簡單版再升級，是這個系列一貫的教學節奏。

「評估」與「觀測」是品質篇的兩條腿

AG Day 32-37 的「品質」區塊把 Agent 系統的兩條腿補齊了：評估（evaluation）回答「這個 Agent 答得對不對」，觀測（observability）回答「這個 Agent 跑的過程長怎樣」。AG Day 33 的黃金問題是「離線評估」，AG Day 35 的 Langfuse 是「線上觀測」，AG Day 34 的 LLM-as-judge 是「自動化評估」。少了任何一條腿，系統就是跛腳的：只有觀測沒有評估，你看到 trace 卻不知道答案對不對；只有評估沒有觀測，你看到分數卻不知道哪一步出問題。AG Day 36-37 把成本、安全也補上，整個品質區塊才算完整。

完整實作

今天的實作不是「寫新程式」，而是「盤點現有產出」。我們會做四件事：(1) 列出 45 篇的主題與產出、(2) 畫出 research-agent 的能力圖譜、(3) 給出延伸學習的路線圖、(4) 提供一份 self-check 自我檢核表。

第一步：建立 45 篇的主題與產出總表（節錄核心 45 篇，完整對應 manifest）：

檔案：research-agent/series_map.md（45 篇主題與產出總表）

導論區（Day 1-2）

  • AG Day 1 系列導覽：AI Agent 工程的學習地圖（原文連結）
    產出：系列地圖、學習地圖分區。
  • AG Day 2 環境與工具鏈：uv、API key 與專案骨架（原文連結）
    產出：research-agent/ 專案骨架、uv 環境、config.py。

基礎區（Day 3-9）

  • AG Day 3 對話 API 深入：messages、roles 與 system prompt（原文連結）
    產出：llm.chat()、messages 結構、token 計算。
  • AG Day 4 Prompt 設計：角色、少樣本與輸出約束（原文連結）
    產出：prompt 樣板、few-shot 機制、輸出契約。
  • AG Day 5 Function calling：讓模型呼叫你的函式（原文連結）
    產出：tools.py、JSON Schema 工具定義。
  • AG Day 6 手刻 Agent 迴圈：工具執行與多輪對話（原文連結）
    產出：agent_loop.py、第一個可跑的代理。
  • AG Day 7 錯誤處理：逾時、重試與工具失敗（原文連結）
    產出：tenacity 重試、circuit breaker。
  • AG Day 8 結構化輸出：Pydantic 契約與 JSON Schema（原文連結）
    產出：schemas.py、output parser。
  • AG Day 9 觀測基礎：token、延遲與成本紀錄（原文連結）
    產出：storage.py、events 表、cost tracker。

LangGraph 區（Day 10-19）

  • AG Day 10 為什麼要框架：手刻 Agent 的極限（原文連結）
    產出：手刻 vs 框架的決策矩陣。
  • AG Day 11 LangGraph 起步：StateGraph、節點與邊（原文連結）
    產出：第一張 StateGraph。
  • AG Day 12 狀態設計：TypedDict、reducer 與訊息累積（原文連結）
    產出：進階狀態、Annotated reducer。
  • AG Day 13 條件邊：讓流程學會分岔（原文連結）
    產出：條件邊、recursion_limit。
  • AG Day 14 ReAct Agent：create_react_agent 實戰（原文連結）
    產出：ReAct 代理、create_react_agent 整合。
  • AG Day 15 ToolNode：工具節點與錯誤處理（原文連結）
    產出：ToolNode 設定、錯誤處理策略。
  • AG Day 16 記憶：checkpointer 與 thread（原文連結）
    產出：SqliteSaver、thread 隔離。
  • AG Day 17 Human-in-the-loop：interrupt 與人工核准（原文連結）
    產出：interrupt()、Command 物件。
  • AG Day 18 子圖：把研究流程模組化（原文連結）
    產出：subgraph、流程模組化。
  • AG Day 19 串流輸出：stream 與事件流（原文連結）
    產出：串流模式、event stream。

這份總表刻意只列「產出」一行，因為 45 篇的內容細節不該在這裡重複——讀者照表去讀對應的篇章就好。總表的價值在於讓你用 5 分鐘確認「我是不是漏了什麼」，而不是讓你用 5 小時從頭到尾讀一次。

第二步：列出 AG Day 20-37 的對應產出：

檢索區（Day 20-24）

  • AG Day 20 RAG 基礎：embedding 與向量檢索（原文連結）
    產出：embedding 流程、向量檢索基礎。
  • AG Day 21 文件擷取與分塊：從網頁到知識庫（原文連結）
    產出：trafilatura 整合、分塊策略。
  • AG Day 22 檢索品質：查詢改寫與 rerank（原文連結）
    產出：query rewriting、cross-encoder rerank。
  • AG Day 23 引用與出處：答案要能追溯（原文連結）
    產出：citations 機制、出處標註。
  • AG Day 24 搜尋工具：讓 Agent 查網路（原文連結）
    產出：Tavily 整合、web_search 工具。

MCP 區（Day 25-28）

  • AG Day 25 MCP 概念：Model Context Protocol 架構（原文連結）
    產出：MCP 概念理解。
  • AG Day 26 第一個 MCP server：用 FastMCP（原文連結）
    產出：第一個 FastMCP server。
  • AG Day 27 MCP 進階：resources、prompts 與多工具 server（原文連結）
    產出：resources、prompts、複合 server。
  • AG Day 28 MCP client：把研究助理接上 MCP 生態（原文連結）
    產出：MCP client 整合、生態接入。

多代理區（Day 29-31）

  • AG Day 29 多代理架構：supervisor 與 worker（原文連結）
    產出：supervisor-worker 拓樸。
  • AG Day 30 多代理通訊：狀態交接與訊息協議（原文連結）
    產出：HandoffPayload、TaskSpec。
  • AG Day 31 長任務：檢查點、恢復與背景執行（原文連結）
    產出：背景執行、checkpoint 恢復。

品質區（Day 32-37）

  • AG Day 32 評估基礎：Agent 為什麼難測（原文連結）
    產出：評估挑戰分析。
  • AG Day 33 建立評估集：黃金問題與評分標準（原文連結）
    產出：黃金問題集、評分 rubric。
  • AG Day 34 LLM-as-judge：用模型評模型（原文連結）
    產出：judge_prompt、自動化評估。
  • AG Day 35 追蹤平台：Langfuse 觀測實戰（原文連結）
    產出：Langfuse 整合、tracing。
  • AG Day 36 成本與延遲優化：快取與模型分級（原文連結）
    產出：cache、model cascading。
  • AG Day 37 安全：prompt injection 與工具防護（原文連結）
    產出：input 過濾、工具白名單。

這段把 AG Day 20-37 的產出也列出來。這 18 篇是 AG 系列的核心擴充區：從「單代理能跑」升級成「多代理可觀測」。讀者讀完這 18 篇應該已經有能力打造一個 production-grade 的多代理系統雛形。

第三步：列出 AG Day 38-45 的對應產出（含今天）：

交付區（Day 38-45）

  • AG Day 38 部署：FastAPI 包裝 Agent（原文連結）
    產出：FastAPI app、/research 端點。
  • AG Day 39 容器化：Docker 打包 Agent 服務（原文連結）
    產出：Dockerfile、image 推送流程。
  • AG Day 40 使用者介面：CLI 與 Streamlit 前端（原文連結）
    產出：CLI、Streamlit UI。
  • AG Day 41 效能總檢與壓測（原文連結）
    產出：locust 腳本、容量報告。
  • AG Day 42 文件與交接：README 與架構圖（原文連結）
    產出：README、architecture.mmd、smoke_test.sh。
  • AG Day 43 已知限制與除錯日誌（原文連結）
    產出：limitations.md、debug-log.md、ADR 範本。
  • AG Day 44 技術手冊：常見維運情境（原文連結）
    產出：runbook.md、maintenance.sh。
  • AG Day 45 系列總結與延伸路線（原文連結）
    產出：series_map、能力圖譜、學習路線圖。

AG Day 38-45 是「交付」區，把前 37 篇的能力包成可上線、可維運的系統。今天這篇則是整個系列的句點，但也是讀者開始自己專案的起點。

第四步：畫一張 research-agent 的能力圖譜。我們用 Mermaid 圖把整個系統的能力畫成一張心智圖，從輸入到輸出、從單機到多代理、從開發到維運：

# research-agent/docs/capability_map.mmd
flowchart TB
    subgraph 輸入層
        U[使用者問題]
    end

    subgraph 介面層
        CLI[CLI]
        API[FastAPI]
        UI[Streamlit]
    end

    subgraph 代理層
        SUP[supervisor]
        SW[search_worker]
        RW[retrieval_worker]
        WW[writer_worker]
    end

    subgraph 工具層
        TAV[Tavily]
        MCP[MCP Servers]
        LLM[LLM Provider]
    end

    subgraph 儲存層
        DB[(SQLite)]
        CH[(Chroma)]
    end

    subgraph 觀測層
        LF[Langfuse]
        LOG[logs/]
    end

    subgraph 品質層
        EVAL[評估集]
        JUDGE[LLM-as-judge]
    end

    subgraph 維運層
        DOC[README]
        LIM[limitations.md]
        DBG[debug-log.md]
        RB[runbook.md]
    end

    U --> CLI & API & UI
    CLI & API & UI --> SUP
    SUP --> SW & RW & WW
    SW --> TAV
    RW --> CH
    WW --> LLM
    SW & RW & WW --> LF
    SW & RW & WW --> DB
    EVAL --> JUDGE
    JUDGE --> LF
    DOC & LIM & DBG & RB -.參考.-> SW & RW & WW

這張圖把 AG 系列累積的 45 篇能力視覺化為七個分層：輸入層、介面層、代理層、工具層、儲存層、觀測層、品質層、維運層。每一層都對應 AG 系列的某些篇章；維運層（DOC、LIM、DBG、RB）與其他層用虛線連接，表示「參考關係」而不是「執行關係」——這呼應 AG Day 43「文件不是程式」的概念。

第五步：給出延伸學習的路線圖。AG 系列結束不代表學習結束，它只是「入門到中階」的完整地圖。讀者可以依需求選擇延伸方向：

# research-agent/docs/next_steps.md（延伸路線）

## 路線 A：效能與規模化
- 深入 AG Day 36 的快取與模型分級，套用到自己的 production 環境
- 學習分散式任務排隊（Celery、RQ）把 supervisor 拆出去
- 評估 Postgres 取代 SQLite（AG Day 43 L-03 已知限制）

## 路線 B：多模態與新工具
- AG Day 43 L-02「不支援圖片／音訊」的限制怎麼解除
- 整合 OCR、ASR、影像理解模型
- 串接更多 MCP servers（搜尋、計算、繪圖）

## 路線 C：評估與品質
- 擴充 AG Day 33 的黃金問題集，加入領域特定問題
- 嘗試不同的 LLM-as-judge 模型做交叉驗證
- 引入 human-in-the-loop 評估（AG Day 17 的擴充）

## 路線 D：產品化與商業化
- AG Day 40 的 Streamlit 改成正式前端（React / Next.js）
- 串接真實的計費 API（Billing）
- 加入帳號與權限管理（Auth）
- 部署到雲端（K8s、Cloud Run、Fly.io）

## 路線 E：研究與前沿
- 追蹤 LangGraph、FastMCP 的版本更新
- 實驗不同的多代理拓樸（hierarchical、mesh）
- 探索 self-reflection、self-improvement 模式

這五條路線是 AG 系列結束後最常見的延伸方向。讀者不必每一條都走，先選一條深入即可。建議依工作場景選：如果是內部工具，選 A 或 C；如果是對外產品，選 D；如果是研究目的，選 E。

第六步：提供一份 self-check 自我檢核表，幫讀者確認自己是否真的學會了 AG 系列：

# research-agent/docs/self_check.md

## 入門級（必會）
- [ ] 能說出 Agent 與純 LLM 應用的差別
- [ ] 能用 LangGraph 寫一張 StateGraph（含節點、邊、條件邊）
- [ ] 能設計 Pydantic 結構化輸出契約
- [ ] 能用 checkpointer 實作 thread 隔離的記憶

## 中階（建議會）
- [ ] 能把研究流程拆成 supervisor 與 worker
- [ ] 能用 HandoffPayload 設計 worker 回報格式
- [ ] 能寫一份黃金問題評估集並跑出 baseline
- [ ] 能用 Langfuse 看出一個 trace 的瓶頸
- [ ] 能把 Agent 包成 FastAPI 服務

## 進階（加分）
- [ ] 能自己設計 MCP server 並讓既有代理無縫接入
- [ ] 能用 LLM-as-judge 做自動化評估
- [ ] 能做 Docker 容器化並推到 registry
- [ ] 能寫 runbook 並對應到實際 incident
- [ ] 能用 ADR 紀錄關鍵設計決策

## 自評方式
- 入門：能獨立從零寫出一個簡單的研究代理
- 中階：能修改既有 research-agent 加上新 worker
- 進階：能設計自己的多代理系統並對外演講

這份清單刻意分成三個等級：入門級是「學完 AG 系列應該會的」，中階是「可以上手工作會的」，進階是「可以教別人或設計新系統的」。讀者依據自己的程度自我檢核，不必強求每項都達到 100%。

常見錯誤與踩雷

第一個常見錯誤是把 AG 系列當成「看完就會」的教材，而不是「動手做才會」的教材。45 篇的內容很多，但實際吸收率遠低於閱讀時間。建議讀者至少選 3 篇做完整實作（例如 AG Day 14 ReAct、AG Day 29 多代理、AG Day 38 FastAPI），照著程式碼一行一行敲一次，這樣的吸收率遠高於純閱讀。AG 系列的所有產出都設計成可獨立運行的片段，挑幾個做過一遍比讀完整 45 篇更有價值。

第二個常見錯誤是把 production-grade 的標準套到學習階段。AG Day 35 的 Langfuse 整合、AG Day 39 的 Docker 容器化、AG Day 44 的 runbook，都是 production 環境會用到的設計；學習階段不需要一次到位。建議的順序是：先做 AG Day 6 的手刻迴圈、AG Day 14 的 LangGraph ReAct、AG Day 29 的多代理，這三個是核心；其餘的依需求慢慢補。

第三個常見錯誤是跳過評估就直接上線。AG Day 32-34 的評估章節不是「可選」，而是「必讀」。沒有評估的 Agent 系統等於盲人開車：你不知道答案對不對、不知道哪裡需要改。建議至少做 AG Day 33 的黃金問題集，並把它納入 CI——只要改了 prompt 就跑評估，看到分數變化再決定是否上線。

第四個常見錯誤是只看當下能跑，不看未來會壞。AG Day 43 的限制清單與 AG Day 44 的 runbook 容易被當作「事後再說」的東西，但實際上這些是「事前預防」的設計。如果等到 production 出事才寫 runbook，你會在壓力下寫出更差的文件。AG Day 42-44 的設計都是趁系統還在掌握中時寫的，這時候對細節最熟、寫出來的東西最實用。

效能與實務提醒

AG 系列結束後，最重要的下一步是「選一個自己的小專案」。可以是工作上的一個小任務（例如「把客戶常見問題整理成可查詢的知識庫」）、可以是一個 side project（例如「為某個開源專案做貢獻整理」）、也可以是教學演示（例如「為學生準備一份教材大綱」）。選完之後，依 AG 系列的能力地圖規劃自己的實作路徑：先做哪幾篇、再做哪幾篇、最後做哪幾篇。

另一個重要觀念是「不要一次做太大」。AG 系列的 45 篇花了 45 天，每天一篇；你的小專案不該試圖在三天內做完所有功能。建議把專案拆成三到五個里程碑，每個里程碑一到兩週，里程碑結束就跑一次評估並做一次 review。這個節奏呼應 AG Day 36 的「成本與延遲最佳化」精神：分批做、分批驗證，不要一次推到 production 然後才發現問題。

學完 AG 系列後，讀者應該具備的能力是「能判斷什麼時候該用 Agent、什麼時候不該」。這個判斷力比任何單一技術都重要——很多場景其實只需要純 LLM 呼叫或純 RAG，不需要 Agent；硬上 Agent 只會增加複雜度與成本。AG Day 1 開頭就強調「AI Agent 是工具不是目的」，這條原則到今天仍然適用。

最後，AG 系列的程式碼會隨著 LangGraph、FastMCP、Langfuse 等工具的版本演進而需要更新。建議把 AG 系列的程式碼當作「學習範本」而不是「最終產品」：學習它的設計決策，但實際工作時依當下版本與需求做調整。AG Day 44 OP-04「套件升級造成相依性破壞」就是在提醒這件事。

小結

今天把 AG 系列 45 篇完整收束了。我們盤點了 research-agent 的能力圖譜（七個分層：輸入、介面、代理、工具、儲存、觀測、品質、維運），列出了每一篇的產出（45 篇對應到 research-agent 的具體檔案與設計決策），給出了五條延伸路線（規模化、多模態、評估、產品化、研究前沿），並提供了一份 self-check 自我檢核表（入門、中階、進階三個等級）。這個收束不是句號，而是逗號——讀者從這裡開始自己的專案，才是 AG 系列真正的價值實現。

新增的術語：能力圖譜（capability map，視覺化展示系統能力的分層架構）、延伸路線（next steps，依學習者需求選擇的後續方向）、自我檢核（self-check，依明確標準確認學習成果的過程）。

結語

45 天的旅程在今天結束，但 AI Agent 工程的世界才剛開始。這 45 篇能給你的是「地基」——一個能跑、可觀測、可評估、可部署、可維運的多代理系統雛形；但這個世界還有很多地基之上可以蓋的東西：更複雜的多代理拓樸、更精密的評估方法、更深的工具整合、更穩的 production 部署。每一個方向都可以再延伸出幾十篇深度內容，但那些就是後續系列的事了。

AG 系列想帶給你的最終價值，不只是「你現在會寫 Agent」，而是「你未來碰到任何 AI Agent 相關問題時，有一套清楚的思考框架」。這個框架的核心是「分層思考」：把問題拆成輸入、介面、代理、工具、儲存、觀測、品質、維運等層次，每一層有每一層的設計原則與常見問題。這套思考框架可以套用到任何 AI Agent 專案，不限於 research-agent 這個具體實作。

謝謝你讀完這 45 篇。從 AG Day 1 的「系列導覽」走到 AG Day 45 的「系列總結」，我們一起完成了一段完整的學習旅程。接下來就換你開始自己的故事了——選一個小專案，照著 AG 系列的能力地圖規劃路徑，然後動手做。過程中會碰到 AG 系列沒涵蓋的問題，那時你會發現「原來還有這麼多要學」——這就是學習的真實樣貌，也是這個系列最想傳達的精神。

延伸資源

  • LangGraph 官方文件：https://langchain-ai.github.io/langgraph/。AG 系列核心框架的權威參考，所有 API 與版本差異以官方文件為準。
  • Model Context Protocol 規格：https://modelcontextprotocol.io/。MCP 區塊（AG Day 25-28）的協議基礎；規格 2025-06-18 版與後續修訂請以官方網站為準。
  • Langfuse 官方文件：https://langfuse.com/docs。AG Day 35 的觀測整合細節，以及 LLM 評估與 cost tracking 的最新功能。
  • Pydantic v2 官方文件：https://docs.pydantic.dev/latest/。AG Day 8、AG Day 30 等篇章的結構化輸出與資料契約以此為準。
  • FastMCP 官方說明：FastMCP 2.x 的安裝、resources、prompts 章節涵蓋了 AG Day 26-27 的內容。
  • Chroma 官方文件：https://docs.trychroma.com/。AG Day 20-23 的向量檢索與條件過濾以此為準。
  • Google SRE Book：https://sre.google/sre-book/。AG Day 44 維運手冊的「症狀／診斷／處理／預防」框架源自 SRE 文化。
  • Architecture Decision Records 範本：https://github.com/joelparkerhenderson/architecture-decision-records。AG Day 43 的 ADR 範本參考來源。
標籤：

留言

張貼留言

這個網誌中的熱門文章

Day 2 變數與資料型別

Day 2 變數與資料型別 引言 寫程式的過程中，變數與資料型別是處理資料的基礎。變數是存放資料的容器，資料型別則決定這筆資料有哪些特性、可以進行哪些操作。學會定義變數、認識各種資料型別，是學好 Python 的關鍵一步。 這篇文章會帶你了解 Python 中變數的觀念、如何定義變數，以及常見的資料型別，包括整數、浮點數、字串、布林值，還有串列、元組、字典與集合等容器型別。我們也會介紹變數的命名規則與撰寫風格建議，以及如何用 type() 檢查資料型別。 什麼是變數？如何在 Python 中定義變數 變數是在程式執行時用來存放資料的名稱。透過定義變數，我們可以給一筆資料一個名字，並在程式的其他地方用這個名字取用該筆資料。在 Python 中，變數不需要事先宣告型別，因為 Python 是動態型別語言，變數的型別由指定給它的值決定。 定義變數的基本語法 在 Python 中定義變數非常簡單，只要用賦值符號 = 把值指定給變數即可。例如： x = 5 # 定義變數 x，並把整數 5 賦值給它 name = "Alice" # 定義變數 name，並把字串 "Alice" 賦值給它 在這裡，x 是一個變數，被賦予整數 5；name 是另一個變數，被賦予字串 "Alice"。 變數的更新與覆寫 變數的值可以修改，也就是說，我們可以在程式的不同地方給同一個變數新的值。例如： x = 10 # x 最初被賦予 10 x = 15 # x 的值現在被更新為 15 這樣就能依照需求，在程式執行過程中靈活調整變數的值。 Python 的動態型別系統 Python 和某些靜態型別語言不同，定義變數時不需要宣告型別。賦值時，Python 會根據值自動判斷變數的型別。例如： x = 5 # x 是整數 x = 3.14 # x 變成浮點數 x = "Hi" # x 變成字串 同一個變數在程式執行過程中可以存放不同型別的值，這是 Python 的彈性之一。 常見資料型別 在 Python 中，資料型別決定我們可以對變數進行哪些操作...
張貼留言
閱讀完整內容

Day 1 Python 簡介與環境設定

Day 1 Python 簡介與環境設定 引言 在現在的科技環境裡，程式設計已經是一項重要技能。無論你是對資料科學有興趣、想成為開發者，或是想踏入人工智慧（AI）領域，學會寫程式都能明顯提升你的競爭力。在眾多程式語言中，Python 因為語法簡單、功能強大、應用範圍廣泛，成為許多人進入程式世界的第一選擇。這篇文章會帶你認識 Python 的背景與優勢，並一步步教你在不同系統上安裝與設定 Python 開發環境，最後寫出第一支 Python 程式。 為什麼選擇 Python？ Python 是一種高階程式語言，由 Guido van Rossum 在 1991 年發布。Python 的設計哲學強調程式碼的可讀性，並用縮排來定義程式區塊，這點和許多使用大括號的語言不同。簡潔的語法讓它成為初學者的理想選擇；就算是經驗豐富的開發者，也能用它完成複雜的專案。 Python 的優勢如下： 簡單易學 ：Python 的語法清楚、結構簡潔，初學者很快就能上手。和其他語言相比，學習曲線相對平緩，不需要先弄懂一堆複雜觀念，就能開始寫程式。 應用範圍廣泛 ：從資料科學、網頁開發、人工智慧、機器學習、自動化測試到網路爬蟲，Python 都有大量開源函式庫與工具支援，而且在這些領域都扮演關鍵角色。 豐富的函式庫與框架 ：Python 的函式庫生態系非常龐大。做資料分析有 NumPy、Pandas；開發網站有 Django、Flask；做深度學習有 TensorFlow、PyTorch。各種需求幾乎都能找到對應的套件，讓開發更有效率。 跨平台支援 ：Python 支援 Windows、macOS、Linux 等作業系統，程式通常不需要太多修改就能跨平台執行，讓開發與部署更有彈性。 活躍的社群 ：Python 擁有龐大的開發者社群。學習或開發上遇到問題，幾乎都能在社群與論壇（例如 Stack Overflow）找到答案，對初學者來說是很強的後盾，也能減少卡關時的挫折感。 Python 的應用領域 Python 的流行與強大功能，讓許多領域都開始大量使用它。以下是幾個常見的應用方向： 資料科學 ：隨著大數據與人工智慧興起，資料科學大量使用 Python。NumPy、Pandas 與 Matplotlib 等工具能處理和分析龐...
張貼留言
閱讀完整內容

Python 從入門到 PyTorch 深度學習：開啟 AI 世界的大門

Python 從入門到 PyTorch 深度學習：開啟 AI 世界的大門 隨著人工智慧（AI）與深度學習（Deep Learning）快速發展，越來越多人對這些技術產生興趣。不論你是想踏入 AI 領域的初學者，還是已經有程式基礎的開發者，學好 Python 與深度學習框架（例如 PyTorch），都能為你打開更多可能。 為什麼選擇 Python？ Python 已經是資料科學與人工智慧領域的首選語言。它的語法簡潔、容易上手，而且擁有龐大的生態系與大量開源函式庫。無論是資料處理、資料視覺化，還是建立機器學習與深度學習模型，Python 都能勝任。對想進入 AI 或資料科學領域的人來說，它幾乎是必備工具。 PyTorch 是什麼？ PyTorch 是由 Meta（原 Facebook）AI 研究團隊開發的開源深度學習框架，以易用、靈活和動態計算圖著稱，是許多 AI 研究人員與開發者的首選。相較於其他框架，PyTorch 的寫法更貼近原生 Python，對初學者相對友善。無論是簡單的實驗，還是複雜的深度學習模型，PyTorch 都能提供強大的支援。 這個系列能帶給你什麼？ 這個系列會從 Python 的基礎開始，帶你一步一步學習，最後能自己用 PyTorch 建立深度學習模型。即使你完全沒有寫過程式，也能跟著文章的節奏累積技能，理解 AI 與深度學習的核心觀念。 本系列涵蓋的主題 Python 基礎：從變數、條件判斷到函式與模組。 資料處理工具：用 NumPy 與 Pandas 有效率地操作資料。 資料視覺化：用 Matplotlib 與 Seaborn 把資料畫成圖表。 深度學習的數學基礎：線性代數、微積分與機率。 PyTorch 入門：理解張量、模型建構與 GPU 加速。 基礎深度學習模型：CNN 與 RNN 的實作應用。 深度學習專案實戰：從資料前處理到模型部署的端到端流程。 誰適合這個系列？ 程式初學者 ：如果你對 AI 充滿好奇，卻還沒寫過程式，系列的第一部分會帶你快速上手 Python，並幫助你理解深度學習的基本觀念。 資料科學愛好者 ：如果你已經熟悉一些資料處理方法，進階部分會教你如何用 PyTorch 建構深度學習模型。 開發者與研究人員 ：想更深入了...
張貼留言
閱讀完整內容