Github連結
Setting Up the Lab Before We Break Things
在 Day 1，我們會建立第一條 AI Workflow Trace：
Client
↓
FastAPI
↓
Prompt
↓
Gemini
↓
Response
然後用 LangSmith 把這條 request 打開來看。
但在開始之前，我們得先處理所有技術教學最容易被一句話帶過的東西：
「請先自行準備開發環境與 API Key。」
這句話通常代表：
恭喜，你的第一個 Bug 已經開始了。
所以 Day 0 不談 Reliability、不談 SLO，也不談 Observability。
今天先把一件事做好：
把後續 30 天需要的最小開發環境準備好，而且確認它真的可以呼叫 Gemini。
完成後，環境裡會有：
uv 套件管理工具.env Secret ManagementDay 1 就可以直接開始 tracing。
整個環境先保持很簡單：
Local Machine
│
├── Python
├── uv
│
└── Python Project
│
├── FastAPI
├── google-genai
├── LangSmith
└── .env
我們需要兩個外部服務：
Google AI Studio
↓
GEMINI_API_KEY
↓
Gemini API
以及：
LangSmith
↓
LANGSMITH_API_KEY
↓
Trace Storage / Visualization
最終 .env 大概會是：
GEMINI_API_KEY=your_gemini_api_key
LANGSMITH_API_KEY=your_langsmith_api_key
LANGSMITH_TRACING=true
LANGSMITH_PROJECT=learning-sre-ai-era-day01
MODEL_NAME=gemini-3.7-flash
先不要把 Key 貼進任何 Python 程式碼。
我們等等會處理。
這個系列第一階段先使用 Google Gemini API，目的是降低學習門檻，不比較哪一家 LLM 最強。
我們真正想學的是：
SRE
Observability
Tracing
SLI / SLO
Failure Handling
AI Reliability
而不是第一天就先處理一筆 LLM API 帳單。
這裡選擇：
Google AI Studio
↓
Gemini API Key
↓
Google Gen AI SDK
主要有幾個考量。
對教學與個人 Lab 來說，最大的優點就是可以先用較低成本開始實驗。
Day 1 的 Request 數量很少，我們只會：
Send Request
↓
Observe Trace
↓
Break Something
↓
Send Again
不需要為了學一條 Trace，先處理付費設定。
不過要注意：
免費額度不是「無限免費」。
實際 Rate Limit、可用 Model 與 Quota 仍會依 Google 當下政策與帳戶設定而異。
所以未來進入 Load Testing、大量 Evaluation 或 Production Experiment 時，成本仍然會是我們需要觀察的一項 Reliability 指標。
Google 提供：
google-genai
所以最小的 LLM Call 可以非常直接：
from google import genai
client = genai.Client()
response = client.models.generate_content(
model="gemini-2.5-flash",
contents="What is an SLO?",
)
這對 Day 0 / Day 1 很重要。
因為我們希望把注意力放在：
Request
↓
Workflow
↓
Trace
而不是先花大量篇幅解釋 SDK abstraction。
這裡特別要強調：
我們選 Gemini，不代表後面的 Reliability 架構會綁死 Gemini。
今天可能是：
FastAPI
↓
Gemini
未來可能變成：
Application
↓
Model Router
↓
├── Gemini
├── OpenAI
├── Anthropic
└── Local Model
到了後面的：
我們反而會刻意把 LLM Provider 當成：
External Dependency
來處理。
所以 Day 0 選 Gemini 的真正原因很單純：
便宜、容易開始，而且足夠讓我們先把 Reliability 問題做出來。
工具之後可以換。
但：
Build
↓
Trace
↓
Break
↓
Measure
↓
Recover
這套思考方式不會因為 Model Provider 改變。
這個系列的 Python 環境統一使用：
pyproject.toml
+
uv
不使用傳統的：
requirements.txt
pip install
python -m venv
不是因為 pip 不能用。
我希望整個 Lab 的環境能做到：
uv 剛好可以把這些事情整合在一起。
官方支援 macOS、Linux 與 Windows。
如果你有 Homebrew：
brew install uv
或者直接使用官方 installer：
curl -LsSf https://astral.sh/uv/install.sh | sh
安裝後確認：
uv --version
只要看到類似：
uv 0.x.x
就代表成功。
使用官方 installer：
curl -LsSf https://astral.sh/uv/install.sh | sh
如果沒有 curl：
wget -qO- https://astral.sh/uv/install.sh | sh
重新開啟 Terminal 後：
uv --version
Astral 官方目前就是建議透過 standalone installer 安裝。
PowerShell：
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
或者使用：
winget install --id=astral-sh.uv -e
然後：
uv --version
能看到版本就完成。
你可以先確認目前 Python：
python --version
但如果沒有安裝 Python，也不用急著去 Python 官網找 installer。
uv 本身可以管理 Python。
我們這個系列先使用：
Python 3.14
安裝：
uv python install 3.14
確認：
uv python list
這也是我偏好 uv 的原因之一。
之後進到 CI、Docker 或不同電腦時：
Python Environment
會少很多：
「可是我這台可以跑啊。」
這種經典 Production 前傳。
建立：
mkdir sre-for-ai-era
cd sre-for-ai-era
初始化：
uv init --python 3.14
這時會得到類似：
sre-for-ai-era/
├── .python-version
├── README.md
├── main.py
└── pyproject.toml
打開：
pyproject.toml
大概會看到：
[project]
name = "sre-for-ai-era"
version = "0.1.0"
description = "Learning SRE for the AI Era"
requires-python = ">=3.14"
dependencies = []
之後 Python 專案的 dependency 都由這個檔案管理。
執行：
uv add \
fastapi \
"uvicorn[standard]" \
google-genai \
langsmith \
pydantic-settings
完成後：
pyproject.toml
會自動出現 dependencies。
同時通常還會產生：
uv.lock
所以 Repository 會慢慢變成：
sre-for-ai-era/
├── .python-version
├── pyproject.toml
├── uv.lock
├── README.md
└── main.py
uv.lock 建議 Commit。
因為：
pyproject.toml說我們需要什麼。
而：
uv.lock更接近告訴我們實際解析出了什麼版本。
這對後續建立可重現環境很重要。
接著來處理第一把 Key。
我們要使用：
Google AI Studio 是 Google 提供的 Gemini 開發入口，可以：
Google 官方目前的新專案可以直接從 AI Studio 建立 Gemini API Key。
前往 Google AI Studio。
登入 Google Account。
進入 Dashboard 後找到：
API Keys
如果是第一次使用，Google 可能會要求你：
新使用者在接受條款後，AI Studio 可以自動建立預設 Project；如果你本身已有 Google Cloud 帳戶，也可以 Import 已存在的 Project。
點：
Create API key
選擇要使用的 Project。
建立後會拿到一串 Key。
例如：
xxxxxxxxxxxxxxxxxxxxxxxx
不要把真正的 Key 截圖貼在文章、Discord、Slack、GitHub Issue 或 README。
這不是：
Project ID
這是真正可以呼叫 API 的 Credential。
如果你以前建立過 Gemini Key，請先確認它的類型。
Google 正在把 Gemini API 從舊的 Standard API Key 遷移至新的 Authorization Key。
目前：
在 Google AI Studio 新建立的 API Key，預設已經是新的 Auth Key。
Google 官方也表示，2026 年 9 月開始 Gemini API 將拒絕 Standard Key。
所以現在重新跟著系列建立環境的話：
直接建立新的 AI Studio Key，不要拿幾年前的舊 Key 硬撐。
下面這種寫法：
from google import genai
client = genai.Client(
api_key="YOUR_REAL_KEY"
)
Technically：
可以跑。
Engineering：
不要。
因為你的下一個動作很可能是：
git add .
git commit -m "day 0 done"
git push
然後：
Day 0 就順便學 Credential Incident Response。
Google 官方建議可以設定：
GEMINI_API_KEY
Google Gen AI SDK 會自動讀取它。
但我們不把 Secret 永久寫進 shell profile。
對這個 Lab，我比較推薦：
.env
.envProject Root 建立：
.env
加入：
GEMINI_API_KEY=你的_Gemini_API_Key
例如：
GEMINI_API_KEY=xxxxxxxxxxxxxxxxxxxxxxxx
接著建立：
.env.example
內容只放 Placeholder：
GEMINI_API_KEY=your_gemini_api_key
差別：
.env
是：
你自己的 Secret。
而：
.env.example
是：
告訴其他 Developer 這個 Application 需要哪些環境變數。
.gitignore如果這一步忘記，前面講的 Security 全部當作沒講。
建立：
.gitignore
內容至少：
.env
.venv/
__pycache__/
*.pyc
.pytest_cache/
確認：
git status
你應該：
看不到 .env。
如果看到：
.env
準備被 Git Commit：
先不要 Commit。
.env.example 要 Commit正確情況是：
.env ❌ Git ignored
.env.example ✅ Git tracked
例如：
# .env.example
GEMINI_API_KEY=your_gemini_api_key
這是很普通的習慣。
但普通的習慣往往就是 Reliability Engineering 的開始。
在正式碰 FastAPI 之前，我們先做：
先確認：
Local Python
↓
Google SDK
↓
Authentication
↓
Gemini API
這條路徑可以工作。
建立：
scripts/test_gemini.py
截至 2026 年，Google 已經將：
作為新專案的預設 Gemini Interface。
Google 官方說明，從 2026 年 6 月開始，Interactions API 已經成為推薦的新介面，而早期常見的：
generateContent
仍然支援，但已被視為 legacy。
Day 0 的 Gemini Smoke Test 直接使用新的 Interactions API。
from google import genai
client = genai.Client()
interaction = client.interactions.create(
model="gemini-3.7-flash",
input="Reply with exactly: Gemini connection OK",
)
print(interaction.outputs[-1].text)
注意這裡：
genai.Client()
沒有傳：
api_key=
因為 SDK 可以直接讀：
GEMINI_API_KEY
Google 官方 Quickstart 現在也是以 client.interactions.create() 示範新的 Interactions API。
.env 怎麼載入？剛剛的 SDK 會讀 OS Environment Variable。
但我們目前把 Key 放在：
.env
Day 0 先用 pydantic-settings 載入設定。
建立：
app/config.py
from functools import lru_cache
from pydantic_settings import BaseSettings, SettingsConfigDict
class Settings(BaseSettings):
gemini_api_key: str
model_config = SettingsConfigDict(
env_file=".env",
extra="ignore",
)
@lru_cache
def get_settings() -> Settings:
return Settings()
Smoke Test 改成：
from google import genai
from app.config import get_settings
settings = get_settings()
client = genai.Client(
api_key=settings.gemini_api_key,
)
interaction = client.interactions.create(
model="gemini-3.7-flash",
input="Reply with exactly: Gemini connection OK",
)
print(interaction.outputs[-1].text)
執行：
uv run python scripts/test_gemini.py
如果看到：
Gemini connection OK
代表這整條：
Python
↓
.env
↓
Google Gen AI SDK
↓
Authentication
↓
Gemini
已經成功。
先不要開始：
重裝 Python
重裝 VS Code
重開電腦
懷疑人生
先縮小問題。
檢查：
.env
是否真的存在：
ls -la
確認：
GEMINI_API_KEY=...
變數名稱有沒有拼錯。
最常見的是：
GEMINI_KEY=
但程式找的是：
GEMINI_API_KEY
這兩個不是同一個東西。
可以暫時：
print(bool(settings.gemini_api_key))
期待：
True
不要：
print(settings.gemini_api_key)
Debug Secret 的最佳方式不是：
先把 Secret 印到所有 Log。
Gemini 已經能跑。
接下來準備 Day 1 的第二把 Key：
Day 1 我們會使用 LangSmith 儲存與視覺化：
ask_workflow
├── build_prompt
└── Gemini
所以需要讓 Application 有權限把 Trace 傳給 LangSmith。
進入 LangSmith：
官方目前支援：
登入。
進入：
Settings
↓
API Keys
選：
Create API Key
LangSmith 目前主要有兩種：
適合：
Developer
Local development
Personal scripts
適合：
Application
Production service
Automation
官方也是這樣區分用途。
我們現在只是：
Local Lab
所以建立：
Personal Access Token
就足夠。
Production 之後再用：
Service Key
不要第一天就把：
Local Developer Credential
和：
Production Workload Identity
搞成同一件事。
給它一個名稱，例如：
sre-for-ai-era-local
建立後，LangSmith 只會完整顯示 API Key 一次。請當場安全保存。
你會得到類似：
lsv2_...
.env現在：
GEMINI_API_KEY=your_gemini_api_key
LANGSMITH_API_KEY=your_langsmith_api_key
LANGSMITH_TRACING=true
LANGSMITH_PROJECT=learning-sre-ai-era-day01
LangSmith 官方 tracing 需要至少：
LANGSMITH_API_KEY=...
LANGSMITH_TRACING=true
而：
LANGSMITH_PROJECT
讓我們可以把 Trace 放進指定 Project。
之後才不會得到：
default
裡面有 8,000 條不知道誰是誰的 Trace。
.env.example我們真正 Commit 的檔案：
GEMINI_API_KEY=your_gemini_api_key
LANGSMITH_API_KEY=your_langsmith_api_key
LANGSMITH_TRACING=true
LANGSMITH_PROJECT=learning-sre-ai-era-day01
MODEL_NAME=gemini-3.7-flash
真正的 .env：
GEMINI_API_KEY=你的真正_Key
LANGSMITH_API_KEY=你的真正_Key
LANGSMITH_TRACING=true
LANGSMITH_PROJECT=learning-sre-ai-era-day01
MODEL_NAME=gemini-3.7-flash
兩者最大的差異：
.env.example
永遠不應該包含真正 Credential。
Day 0 完成後，大概會是：
sre-for-ai-era/
├── app/
│ ├── __init__.py
│ └── config.py
├── scripts/
│ └── test_gemini.py
├── .env
├── .env.example
├── .gitignore
├── .python-version
├── pyproject.toml
├── uv.lock
└── README.md
我們還沒有：
FastAPI Endpoint
LangSmith Trace
Prometheus
Grafana
PostgreSQL
Redis
OpenTelemetry
都正常。
今天是：
不是：
依序執行：
uv --version
再來：
uv run python --version
應該是：
Python 3.14.x
確認 dependency：
uv sync
最後：
uv run python scripts/test_gemini.py
如果成功得到：
Gemini connection OK
今天就完成了。
uv
sre-for-ai-era
pyproject.toml
google-genai
.env
.env.example
.gitignore 排除 .env
只要全部打勾：
Day 1 可以開工。
今天還沒正式講 SRE。
不過，我們已經碰到第一個 Production Reliability 問題：
一個被 GitHub 公開的 API Key 可能造成：
所以：
API Key management
不是單純：
「不要把密碼貼出去。」
它本身就是 Reliability 與 Security 的一部分。
如果 Key 不小心 Commit：
不要只有：
git rm .env
因為 Credential 很可能已經進入 Git History。
正確第一步通常是：
Rotate / Revoke Credential。
Google 官方對洩漏 Key 的處理也是先建立 replacement、更新 Application，再停用或刪除 compromised key，並檢查 usage。
不要賭：
「應該沒人看到吧。」
Internet 在這方面通常比你想像中勤勞。
表面上今天只做了：
Install uv
Get API Keys
Run Gemini
同時也建立了幾個後面會反覆用到的工程習慣：
Reproducible Environment
Secret Separation
Dependency Management
Configuration Management
Smoke Testing
這些看起來沒有 LLM Agent 那麼酷。
但 Production 系統真正容易把人叫起床的，通常也不是：
Transformer Architecture
而是：
Environment 不一致
Credential 過期
Configuration 寫錯
Dependency 壞掉
Service 根本連不到 Provider
所以在開始研究：
「AI 時代的 SRE 有什麼不同？」
之前，我們先確保最基本的軟體工程沒有消失。
環境準備好了。
下一篇我們會真正建立：
Client
↓
FastAPI
↓
Prompt Construction
↓
Gemini
↓
Response
然後加上 LangSmith。
讓原本只能看到：
HTTP 200
的 Request，第一次變成：
ask_workflow
│
├── build_prompt
│
└── Gemini
├── Model
├── Prompt
├── Latency
├── Tokens
└── Output
我們會開始回答這個系列的第一個 Reliability 問題：
當 API 成功，但 AI 回答錯了，我們到底應該觀察什麼？
這篇是 Learning SRE for the AI Era 系列的環境準備篇。
從 Day 1 開始，我們會從一條最小 LLM Trace 出發，再逐步建立 SRE Lab、SLI/SLO、Observability、Incident Response、Resilience，以及最後延伸到 LLM、RAG、Agent 與 GPU Infrastructure。
Build → Trace → Break → Measure → Evaluate → Recover → Improve.
iThome鐵人賽
看影片追技術