pydantic / pydantic-ai

平台 metadata 記錄的主要語言是 Python，有 34,234,401 個 Python 位元組，Makefile、PLpgSQL 和 Shell 的數量則小得多。它採用 MIT 授權；記錄到的最新 release 是 v2.54.0，發布於 2026-10-03，當時 repository 有 20385 個 stargazer。GitHub topics 包括 agent-framework、genai、harness、harness-engineering、llm、pydantic 和 python。

Repository 的描述「How Python does AI. Agents, realtime voice, image generation, embeddings. Every model, every interface, typed end to end.」（大意是：用 Python 做 AI；agent、即時語音、影像生成、embedding；每個模型、每個介面都從頭到尾有型別）和首頁 https://pydantic.dev/pydantic-ai 都是作者提供的 metadata，不是分析器的觀察。

在結構上，分析器統計了 4082 個分析過的檔案。

可執行的啟動點以 Python __main__ 守衛的形式，分散在 pydantic_ai_slim 和 clai 套件、.github/scripts、examples 和 tests 裡。有兩個套件帶有 __main__ 守衛：pydantic_ai_slim/pydantic_ai/__main__.py 呼叫 cli_exit()，clai/clai/__main__.py 呼叫 _cli.cli_exit('clai')。.github/scripts/ 底下還有更多經驗證的守衛，包括 agent_provider_health.py、agent_spend_report.py 和 check_api_compatibility.py。

範例展示了使用方式：pydantic_model.py 執行 agent.run_sync('The windy city in the US of A.')，並印出 result.output 和 result.usage；data_analyst.py 以一段提示和一個 deps 物件呼叫 analyst_agent.run_sync。chat_app.py 為 pydantic_ai_examples.chat_app:app 啟動一個 uvicorn 伺服器，tests/ 底下也有一個模組呼叫 mcp.run()。

唯一被詳細追蹤的有界靜態流程從 .claude/skills/testing-skill/parse_cassette.py 開始，經過 main() 和 parse_cassette()，在 argparse.ArgumentParser 和 args.cassette.exists 這類未解析的外部邊界結束；分析器把它們標為 unresolved_boundary，所以在那之後的事都沒有確立。摘要裡的「偵測到的起點」examples/pydantic_ai_examples/slack_lead_qualifier/app.py 只是依檔名推測，並沒有確立為主要進入點。

分析器把 docs、src 和 tests 指定為頂層子系統。依賴記錄引用的來源路徑有 pydantic_evals/pyproject.toml 和 pydantic_graph/pyproject.toml，以及根目錄的 pyproject.toml。

依靜態呼叫次數推得的角色（分析器的推論）勾勒出函式庫的樣貌：messages.py 有 403 個呼入、70 個呼出，exceptions.py 有 421 個呼入、沒有呼出，兩者看起來都是被廣泛共用的層。agent/__init__.py 的輪廓正好相反，4 個呼入、203 個呼出，被標為 service/core 候選。models/__init__.py（113 入、52 出）和 models/openai.py（8 入、151 出）位在兩者之間。

分析器總共記錄了 150000 條關係，其中 124623 條是呼叫、25377 條是 import；這些關係裡有 125702 條仍是外部或未解析的，24298 條解析到本地目標。

根目錄的 pyproject.toml 宣告了一個龐大的 dev 群組：pytest、anyio、trio、coverage、dirty-equals、inline-snapshot、hypothesis、pytest-mock、pytest-xdist、pytest-split、mypy、pyright 和 ruff。子套件各有自己的清單檔：pydantic_graph 把 anyio、logfire-api、pydantic 和 typing-inspection 列為 runtime 依賴，pydantic_evals 則把 logfire 列為 optional。清單的涵蓋並不完整：解析器會讀 requirements 檔案和 pyproject.toml（PEP 621/735、Poetry 表格），但不讀 setup.py、setup.cfg、Pipfile 或 lock 檔，而且版本限制照原樣記錄。

這個 repository 有 2514 個類測試檔案和 8 個建置／依賴清單檔。tests/conftest.py 定義了 pytest_configure（第 101-113 行）和一個 anyio_backend 函式（第 367-370 行）。

涵蓋上有兩個缺口：有界分析讓超過 400 kB 的檔案、minified bundle 和 vendored 目錄不被解析；分析資料回報有五個檔案處於這種狀態，但沒有確立少了它們對這次分析的影響。

• 先看 README.md：分析器把它歸為專案層級的重要檔案。
• 接著看 pyproject.toml 和 LICENSE，它們也是專案層級的重要檔案。
• 再看函式庫的核心：pydantic_ai_slim/pydantic_ai/agent/__init__.py，抽取出的 Agent 類別橫跨第 476-4290 行；接著看 messages.py 和 exceptions.py（例如 SystemPromptPart、ModelRetry）。
• 然後看一個可執行的範例 examples/pydantic_ai_examples/pydantic_model.py，在脈絡中觀察 run_sync 的用法和結果物件。
• 分析器建議的路徑也一致：先從清單檔和重要符號開始，追蹤有界執行路徑，並在修改程式之前檢查未解析的邊界。

這份概覽只建立在靜態分析上：反射、執行期依賴注入、動態 import、monkey-patching、產生的程式碼、框架的執行期接線和動態分派都沒有解析。這裡沒有任何內容確立執行時的行為：安裝／執行／建置的推論並不完整，安裝指令也沒有驗證。來自 README 的敘述即使被引用，也仍然只是作者的說法，因為抽取是逐行進行的，會略過標題、fenced code、HTML、徽章、表格和 shell 提示。

關係的涵蓋並不完整：記錄的 150000 條關係中有 125702 條仍是外部或未解析的，而記錄的總數正好等於文件寫明的每個 repository 150000 條上限。分析資料也回報有三條進入點路徑沒有靜態偵測到的呼叫步驟；那些進入點做什麼並沒有確立。

分析沒有解析任何外掛或擴充套件如何載入的接線；動態 import 和框架的執行期接線都受同樣的靜態限制。

• models/__init__.py 定義了 known_model_names（第 120-127 行）、Model 類別（第 454-1149 行）、StreamedResponse（第 1153-1417 行）和 parse_model_id（第 1645-1660 行）。
• pydantic_ai_slim/pydantic_ai/exceptions.py 定義了 ModelRetry（59-99）、ToolFailed（102-149）、CallDeferred（152-167）、ApprovalRequired（170-185）和 RunCancelled（270-449）。
• pydantic_ai_slim/pydantic_ai/messages.py 定義了 SystemPromptPart、FileUrl、VideoUrl、AudioUrl、ImageUrl、DocumentUrl 和 BinaryContent。