uv 教學｜AI Agent 時代的 Python 套件管理，Claude Code、Codex 裝了什麼
Kyle 5,690 字 · 約 18 分鐘

整理上百個檔案、合併多份 CSV、把文件轉成方便分析的格式，都是 Agent 可以透過寫程式協助處理的工作。Claude Code、Codex 這類 Agent 擅長把需求轉成程式，再透過終端機執行。把 Agent 想成人類請來的助手，就容易理解環境的重要性：交代任務之外，還要讓助手取得所需資料、可用工具與合適的工作空間。

Python 是 Agent 處理檔案、資料與自動化任務時很常用的工具，uv 則把 Python 版本、套件與專案環境管理整合在一起。理解 Python 環境，能減少 Agent 反覆處理缺少套件、版本不合或找錯執行檔的時間，讓委派工作更有效率。本文從 pip、venv 到 uv 的演進談起，接著說明 Claude Code、Codex 執行安裝指令後留下什麼，並提供 uv 與 Python 安裝、專案建立及環境盤點教學。

uv 是什麼

uv 是 Astral 開發的 Python 套件與專案管理工具，以 Rust 撰寫。它在 2024 年先從套件安裝與版本解析切入，後來加入 Python 版本管理、虛擬環境、專案鎖檔和命令列工具管理。寫 Python 程式、執行文件轉換工具，或讓 Agent 準備專案環境，都可以用到它。

Python 是程式語言；要讓 Agent 寫出的 Python 程式真正執行，環境裡需要 Python 解譯器，使用額外功能時還需要對應套件。以合併每月報表為例，Agent 可以撰寫讀取檔案、統一欄位與加總資料的程式；準備好相容的 Python、所需套件與專案目錄，下次便能沿用同一套環境處理新資料。這也是學習套件管理的實際價值：減少重複準備工具，把時間留給需求與結果確認。

人交代需求，Agent 撰寫 Python 程式，在具備 Python 與套件的環境執行，再由人檢查成果；uv 管理版本與套件
以 Python 任務為例，環境可沿用，成果仍需檢查。

例如請 Agent 處理 PDF 時，可能需要安裝 Docling 或 MarkItDown 。這時 uv 可以下載所需套件、安排相容版本，並放進指定環境。不過，要理解裝完留下什麼，需要先分清楚 Python、套件與專案設定各自的用途。

Python 解譯器、套件、虛擬環境與專案設定的用途圖解
安裝位置與執行方式，要從這四項資料一起判斷。
項目用途
Python 解譯器執行 Python 程式的軟體，例如 Python 3.12、3.13。不同專案可能要求不同版本。
Python 套件額外功能，例如 HTTP 請求用的 httpx。套件也可能依賴其他套件，安裝一個名稱未必只增加一項。
虛擬環境給專案獨立的套件安裝位置，常取名 .venv。預設隔開第三方套件，降低專案之間的版本衝突。
專案設定與鎖檔pyproject.toml 記錄需求；uv.lock 記錄解析出的版本與來源，供後續同步環境。

虛擬環境會使用某個 Python 解譯器，但不是一台虛擬機，也不是限制程式讀寫檔案的安全沙盒。套件進入 .venv，能減少依賴互相干擾；程式執行時可以存取哪些檔案，仍由作業系統、Agent 權限和其他隔離機制決定。


Sponsored Links

Python 套件管理的發展史

Python 套件管理逐步處理了發佈、安裝、環境隔離與版本重現等問題。這些需求出現的時間不同，因此形成多種工具；讀舊教學時看到 setup.py、pip install 或 python -m venv，通常是文章採用了不同時期、不同職責的工具。

以 pip、venv 與 uv 說明套件安裝、環境隔離及專案管理的職責
圖中整理管理範圍的擴充，完整年代與工具沿革見正文。

從 distutils、PyPI 到 pip

2000 年，distutils 隨 Python 1.6 納入標準函式庫，提供套件建置與安裝功能。2003 年 PyPI 開始運作，讓 Python 套件有集中查找的索引；2004 年出現 setuptools，加入依賴宣告與自動安裝能力。setuptools 內附的 easy_install，也是早期教學常見的指令。

2008 年 Ian Bicking 推出 pip，作為 easy_install 的替代工具。這段演進建立了「從套件索引取得套件，再交給安裝工具處理」的使用方式。PyPI 是套件索引與檔案服務，pip 是安裝工具，兩者不是同一個產品。年代可回查 PyPA 的套件管理歷史 。

virtualenv 與 venv 解決環境隔離

套件容易安裝後，接著會遇到版本衝突：專案 A 需要某套件的舊版，專案 B 需要新版，若共用同一個安裝位置，升級可能影響另一邊。2007 年推出的 virtualenv 用獨立環境處理這個問題；Python 3.3 在 2012 年加入標準函式庫 venv，對應 PEP 405 。

2013 年 pip 加入 wheel 建置與安裝支援。wheel 是套件的建置完成格式，安裝相容的 wheel 通常不必在本機重新編譯。Python 3.4 則透過 PEP 453 引入 ensurepip，讓 Python 安裝更容易取得 pip。發行商仍可能拆分套件，因此不能看到 Python 就假設一定附有可用的 pip。

pyproject.toml 與專案管理工具

環境隔開後，還有另一個問題：換台電腦，如何知道原本裝了什麼？requirements.txt 可以列出安裝需求，也能固定版本，但檔名本身不保證內容已鎖定，更不會自動交代哪些是直接需求、哪些是附帶依賴。

2016 年接受的 PEP 518 定義 pyproject.toml，最初處理建置工具需要哪些依賴；2017 年接受的 PEP 517 將建置工具之間的呼叫介面標準化。後來 PEP 621 再規範 [project] 裡的名稱、版本與依賴等專案資料。今天常用的檔案，是逐步擴充而來。

Poetry、Pipenv 等工具把依賴宣告、虛擬環境與鎖檔納入專案工作流程。它們回答的是「如何管理整個專案」，而 pip 主要處理「如何把套件安裝進環境」。既有專案已經有穩定的管理方式，就應沿用其設定，避免 Agent 為了執行一次任務又引入另一份鎖檔。

uv 整合 Python、套件與工具管理

Astral 在 2024 年 2 月 15 日發表 uv ，先提供套件安裝與依賴解析；同年 8 月 20 日擴充為完整的專案管理工具 ，涵蓋 Python 版本、命令列工具與單檔腳本。uv 沿用 Python 生態的套件與標準，將多種日常操作放進同一套指令。

工具主要管理範圍
pip安裝、移除及查看特定 Python 環境裡的套件。
venv／virtualenv建立隔離的 Python 環境；套件通常再由安裝工具處理。
pyenv安裝與選擇 Python 版本，不等同專案依賴鎖檔。
pipx為 Python 命令列工具建立獨立環境，提供可呼叫的工具入口。
Poetry／Pipenv以專案為單位整合依賴、環境與鎖檔。
Conda管理環境及 Python／非 Python 套件，常見於科學運算工作流程。
uv整合 Python 版本、專案、套件、工具執行與快取管理。

這不是必須逐一淘汰舊工具的順序。尤其 Conda 還處理許多非 Python 的二進位依賴，不能把 conda install 一律換成 uv add。新專案可以採用 uv；既有 Conda 或 Poetry 專案，先遵循原本流程通常更省事。

Claude Code、Codex 把 Python 套件裝在哪裡

本機終端機中的 Claude Code 和 Codex CLI 可以呼叫套件管理指令。安裝位置取決於執行環境、當前目錄、所選的 Python 與指令參數，沒有一份固定的「Claude Code 安裝套件清單」或「Codex 安裝目錄」適用所有任務。

安裝 Agent 程式本體，與 Agent 替任務安裝 Python 套件，是兩件事。若任務在雲端、遠端主機或容器執行，套件會依那個環境的設定安裝；不能因為從桌面視窗下指令，就認定改到了本機 Python。開始盤點時要先確認指令實際在哪裡執行。

一般設定下 uv add、未持久安裝工具的 uvx 與 uv tool install 對應環境位置
uvx 也可能重用已持久安裝的工具；實際位置應查設定。

常見指令的影響範圍

看到的指令通常代表什麼
python -m pip install httpx安裝到這個 Python 所對應的環境；要查 Python 路徑才能知道範圍。
uv pip install httpx依環境發現規則選擇虛擬環境；不會替專案更新依賴宣告與 uv.lock。
uv add httpx更新專案依賴、鎖檔並同步環境；預設專案環境是 .venv。
uv run main.py在專案環境執行，預設會先確認環境已同步，必要時安裝套件。
uvx ruff check執行獨立工具；未持久安裝時通常使用快取中的隔離環境。
uv tool install ruff建立持久的獨立工具環境，並提供工具入口。
uv python install 3.12下載並安裝 Python 解譯器，不是只安裝一個 Python 套件。

uvx 是 uv tool run 的別名。官方所說的臨時執行仍可能下載套件並保留快取環境，供下次重用；若工具已經由 uv tool install 安裝，uvx 預設也可能直接使用該版本。因此「沒有裝進專案」不等於「電腦沒有留下檔案」。

另一個容易誤判的是 uv run。即使後面只是查版本的短指令，uv 仍可能先同步專案。只想看現況時，應使用 list、show 類查詢，或明確呼叫已存在的 Python 執行檔。

專案、工具與快取的預設位置

以下整理未自訂儲存路徑時的常見位置。~ 代表使用者家目錄；Windows 的 %APPDATA% 與 %LOCALAPPDATA% 是環境變數表示法。它們用來辨識路徑，不是可以直接原樣貼進 PowerShell 的指令。

資料macOS／Linux 預設位置
專案虛擬環境專案或 workspace 根目錄的 .venv
uv 管理的 Python~/.local/share/uv/python
uv 持久工具環境~/.local/share/uv/tools
uv 快取~/.cache/uv
獨立安裝器的 uv 與工具入口通常是 ~/.local/bin；Homebrew 安裝 uv 則依 Homebrew 的位置。

Windows 常見的 Python 與工具環境位於 %APPDATA%\uv\data 下的 python、tools 子目錄，快取位於 %LOCALAPPDATA%\uv\cache。實際位置應以 uv 儲存位置文件 和查詢指令為準：XDG、UV_CACHE_DIR、UV_PYTHON_INSTALL_DIR、UV_TOOL_DIR 等設定都可能覆寫預設值。

專案也可能設定 UV_PROJECT_ENVIRONMENT，或啟用 centralized-project-envs 預覽功能，把環境放到快取並嘗試在 .venv 建立連結。不能只看到目錄名稱就決定刪除；需要檢查實際路徑及設定。本文教學採一般的專案內 .venv。

Python 環境的唯讀盤點

已經使用 Agent 一段時間、想知道目前留下什麼，可以先做這一章。所有查詢都以工具已安裝、環境已存在，且 Python 來源可信為前提；找不到工具時記錄缺口，不必為了盤點再安裝。套件清單只代表查到的環境，不等於整台電腦的完整清單。

確認命令列選到哪個 Python

macOS、Linux 可用以下指令找出目前 shell 的命令解析結果。PATH 是尋找執行檔的目錄清單；同名指令出現多份時，目錄順序會影響選到哪一份。

# 列出目前可找到的同名指令
type -a python python3 pip pip3 uv

# 查實際執行檔、目前環境與基礎 Python
# python3 必須已存在
python3 -c 'import sys; print(sys.executable)'
python3 -c 'import sys; print(sys.prefix, sys.base_prefix)'

# pip 屬於哪個 Python、裝在哪裡
python3 -m pip --version

Windows PowerShell 可改用 Get-Command python,pip,uv -All 查命令，並以 python 取代範例中的 python3。如果得到 No module named pip，只代表這個 Python 沒有 pip；uv 建立的環境不一定內附 pip，無須為此立即補裝。

標準的 venv 環境裡，sys.prefix 與 sys.base_prefix 通常不同。這是判斷 venv 的線索，不適合拿來涵蓋所有 Conda 或自訂環境；已使用 Conda 時，可另用 conda env list 查看其環境。

查看專案套件與 uv 儲存目錄

以下範例在專案根目錄執行，且 .venv/bin/python 已存在。明確指定執行檔，能避免查到另一個剛好啟用的環境。Windows 將該路徑換成 .venv\Scripts\python.exe。

# 只查已存在的 .venv，不建立或同步
uv pip list --python .venv/bin/python
uv pip show --python .venv/bin/python httpx
uv pip tree --python .venv/bin/python

# 不把「可下載版本」混入已安裝清單
uv python list --only-installed

# 工具清單與各類實際目錄
uv tool list
uv python dir
uv tool dir
uv tool dir --bin
uv cache dir

list 列出目前套件，show 可看到版本、Location 與依賴資訊，tree 顯示已安裝套件之間的依賴關係。沒有 uv 時，可使用該環境已存在的 python -m pip list、python -m pip show httpx；沒有 pip 就保留為未能確認，不必執行 uvx 來補查。

環境裡有十幾個套件，不代表 Agent 主動選了十幾個工具。直接依賴是專案明確要求的套件，間接依賴則是它們還需要的套件。用 pyproject.toml 對照依賴樹，比只看數量更能理解安裝原因。

要確認是不是某次 Claude Code 或 Codex 任務安裝，還需要對照該任務留下的指令與輸出。檔案存在、修改時間接近，只能提供線索；沒有直接紀錄就應保留「安裝者未確認」。uv.lock 也描述預期依賴，不能單獨證明目前環境已經同步完成。

uv 教學：建立可重建的 Python 專案

以下適合準備新專案的讀者，會實際下載 uv、Python 與套件，和前面的唯讀盤點不同。範例依官方文件編排，以 Python 3.12 和小型文字輸出程式示範；Python 3.12 是示範選擇，不代表最新版本或所有 AI 工具的必要版本。

安裝 uv

macOS 已經使用 Homebrew 的話，可直接透過它管理 uv。Homebrew 的用途與設定方式可參考 Homebrew 教學 。以下方式擇一，避免同時裝出多份 uv。

# macOS：已有 Homebrew 時使用
brew install uv

# 確認安裝結果
uv --version

沒有 Homebrew 的 macOS 或 Linux，可使用 uv 官方安裝方式 。安裝腳本會執行下載的程式碼，也可能調整 shell 設定以加入 PATH；需要先確認來源。這裡拆成下載與執行兩步，便於先檢視內容。

# 下載到目前目錄；先用編輯器檢視檔案
curl -LsSf https://astral.sh/uv/install.sh -o uv-install.sh

# 確認來源及內容後才執行
sh uv-install.sh

# 重新開啟終端機後確認
uv --version

Windows 可在 PowerShell 使用相同的兩步方式。受公司裝置政策管理時，應沿用組織核准的安裝流程。

# 下載官方安裝腳本，先用編輯器檢視
Invoke-WebRequest `
  -Uri https://astral.sh/uv/install.ps1 `
  -OutFile uv-install.ps1

# 確認後執行；Bypass 僅指定這次啟動的程序
powershell -ExecutionPolicy Bypass -File .\uv-install.ps1

# 重新開啟終端機後確認
uv --version

如果出現找不到 uv，先重新開啟終端機並檢查安裝器提示的 PATH。uv tool update-shell 可協助把工具入口目錄加入 shell 設定，但它會修改設定檔，屬於環境設定操作。

安裝 Python 並確認版本

使用前述獨立安裝器或 Homebrew 安裝 uv，不必先準備 Python。確認 uv --version 能顯示版本後，便可由 uv 安裝 Python；macOS、Linux 與 Windows PowerShell 都可使用下面兩個指令。依 uv 官方 Python 安裝說明 ，指定 3.12 即可取得該系列的適用版本。

# 安裝 Python 3.12 的適用修補版本
uv python install 3.12

# 只列出已安裝的 Python，確認版本與路徑
uv python list --only-installed

清單中應能找到 Python 3.12 及其執行檔路徑。單獨執行 uv python list 還會列出可下載的版本，因此這裡加上 --only-installed，避免把尚未安裝的版本也算進去。完成這一步是取得 Python；接著還要為工作建立專案環境，並安裝需要的套件。

建立專案與指定 Python 版本

在準備存放專案的位置執行下列指令。範例目錄 agent-python-demo 應尚未存在；既有專案不要直接照抄初始化步驟。uv init 建立專案資料，再以 uv add 加入工作需要的套件。

# 建立新專案，再進入目錄
uv init --no-package --python 3.12 agent-python-demo
cd agent-python-demo

# 明確記錄專案偏好的 Python 版本
uv python pin 3.12

# 加入文字輸出套件
uv add rich

此例使用 --no-package，建立頂層 main.py 的簡單腳本專案。新版 uv 預設會建立可打包的 src 結構，明確指定範本可讓後續步驟一致。設定方式可參考 官方專案建立說明 。

uv add rich 會宣告這個專案需要 Rich，解析其依賴、更新鎖檔並準備環境。專案生成的 .python-version 用來選擇 Python；pyproject.toml 中的 requires-python 表達專案支援範圍，兩者用途不同。若要連修補版也固定，可指定完整的 3.12.x 實際版本號。

.venv 通常到需要環境的操作才建立，不要因為剛執行 uv init 還沒看到它，就認定初始化失敗。

agent-python-demo/
├── .python-version   # Python 版本偏好
├── pyproject.toml    # 專案與直接依賴
├── uv.lock           # 解析後的依賴版本
├── main.py           # 程式
└── .venv/            # 本機執行環境

執行程式並確認套件位置

把生成的 main.py 換成以下內容。Rich 提供終端機文字顯示功能，這個範例只輸出 Python 路徑、套件位置和訊息，不呼叫 AI API，也不下載模型。

import sys
import rich
from rich.console import Console

console = Console()
console.print("Python:", sys.executable)
console.print("Rich:", rich.__file__)
console.print("[green]Python 環境已準備完成[/green]")
# 透過專案環境執行；必要時先同步
uv run main.py

一般設定下，輸出的 Python 路徑會指向此專案的 .venv，Rich 路徑也會落在該環境的套件目錄。實際路徑隨作業系統、專案位置及設定而變，不需要和別台電腦逐字一致。

使用 uv run 時不必先啟用虛擬環境。若要直接打 python，macOS／Linux 可用 source .venv/bin/activate，Windows PowerShell 則用 .venv\Scripts\Activate.ps1；完成後用 deactivate 離開。啟用主要改變目前 shell 的命令選擇，並不會搬移套件。

鎖檔、同步與依賴調整

要讓另一台電腦或下一次 Agent 任務重建環境，應保留程式碼、pyproject.toml、uv.lock 與 .python-version，放進版本控制。.venv 是可依設定重建的本機產物，通常不提交，也不直接複製到另一個作業系統。

# 在已取得上述專案檔案的目錄中執行
# 核對鎖檔仍符合宣告，再安裝所需依賴
uv sync --locked

# 在同步後的專案環境執行
uv run --locked main.py

--locked 的意思是鎖檔若需要更新就報錯，並不是禁止安裝；uv sync 預設還會移除環境中未被鎖檔納入的套件。不要把它當成唯讀檢查，也不宜拿來整理尚未釐清用途的共用環境。鎖檔提高依賴重現性，但不同作業系統可能選到不同相容檔案，系統函式庫與外部服務也不會因此一起固定。

新增與移除依賴可使用 uv add 套件名稱、uv remove 套件名稱。需要升級時，明確指定目標，避免把整個專案一起更新。

# 只升級 Rich 及解析時必要的相關依賴
uv lock --upgrade-package rich

# 按更新後的鎖檔同步
uv sync --locked

在 uv 專案裡臨時使用 uv pip install 雖然可能讓程式立刻執行，卻沒有把需求寫回 pyproject.toml。下次重建環境可能缺少它。長期需要的套件應透過 uv add 宣告，Agent 交付時也應說明改動了哪些設定檔。

命令列工具與既有 requirements.txt

只需要執行命令列工具時，可選 uvx。例如 Ruff 是檢查 Python 程式碼的工具；下列指令可能下載 Ruff 並建立快取環境，適合主動要做程式檢查時使用，不適合唯讀安裝盤點。

# 執行工具；可能下載並建立快取環境
uvx ruff check main.py

# 長期需要直接呼叫 ruff 時，改採持久工具安裝
# 這是另一種選擇，不必兩種都執行
uv tool install ruff

工具名稱相同，也不代表程式裡 import 得到：uv tool install 的套件在獨立環境中。自己的程式要匯入某個套件時，應把它加入專案。

既有專案只有 requirements.txt，可以先保留原本的依賴來源，明確建立隔離環境後安裝。以下是另一個專案情境，不要接著在前面的 uv 專案裡混用。

# 在既有專案中建立虛擬環境
# 先確認原專案沒有需要保留的 .venv
uv venv --python 3.12

# 明確指定目標環境
uv pip install --python .venv/bin/python \
  -r requirements.txt

Windows 的 Python 路徑同樣換成 .venv\Scripts\python.exe，且 PowerShell 的續行符號是反引號，不是反斜線。這種做法沒有自動建立 uv.lock。確定要遷移成 uv 專案時，再依 官方遷移流程 整理直接依賴；把 pip freeze 的全部結果直接當成主要需求，會把間接依賴也一起固定。

環境整理與 Agent 盤點提示詞

清理前先區分要移除的是專案依賴、獨立工具、Python 解譯器，還是快取。這些資料可能分散在不同目錄，刪除 uv 本身也不等於它管理的資料全部消失。

整理目標做法與影響
專案不再需要某套件在正確專案執行 uv remove 套件名稱，一起更新宣告、鎖檔與環境。
不再使用某獨立工具先用 uv tool list 確認，再用 uv tool uninstall 工具名稱 移除。
快取占用空間uv cache prune 清理不再需要的快取；uv cache clean 清空快取，之後可能重新下載及建置。
不再需要某個 Python 版本先確認哪些 .venv 與工具引用它，再考慮 uv python uninstall 版本；移除可能讓既有環境失效。
不再使用整個專案環境確認程式與依賴設定已保留、沒有執行中的工作，再針對已確認的環境路徑整理。

在本文採用的一般設定下，清除快取不會移除持久的工具環境或專案內的 .venv，但會清掉快取中的 uvx 環境。若啟用了前述集中式專案環境預覽功能，清快取也可能移除那類專案環境，之後使用時再重建。需要依設定判斷，不能把「快取可以重建」當成「清除完全不影響下次執行」。

使用具備檔案讀寫與終端機執行權限的 Agent（例如 Claude Code、Codex）時，可把下列文字貼進對話，要求盤點目前專案與相關 Python 環境。這個提示詞將任務限定為唯讀，讓缺少工具、安裝者無法確認等情況也能被如實記錄。

請盤點目前工作環境的 Python 套件管理狀態。
這次只做唯讀盤點，不安裝、升級、移除或同步任何環境。

先確認指令實際執行在本機、容器、遠端主機或雲端，
並列出作業系統與目前專案的絕對路徑。
不要把雲端或容器的結果當成本機電腦的狀態。

檢查目前專案的 pyproject.toml、uv.lock、
.python-version、requirements*.txt 與 .venv/pyvenv.cfg。
只讀取相關欄位；不要輸出 .env、憑證、完整環境變數，
私有套件來源若含帳密或 token，必須遮蔽。

找出命令列實際選到的 Python、pip 與 uv 路徑。
有 uv 才使用既有 uv 的 list、show、dir 類查詢。
用 uv python list --only-installed 排除可下載但未安裝的版本。
盤點套件時明確指定已存在的 Python 執行檔路徑，
不要為了查詢先建立虛擬環境或安裝 pip。
缺少工具或權限時，記錄缺口並繼續可完成的唯讀項目。

不要執行 uv run、uvx、uv add、uv sync、
uv lock、uv venv、安裝腳本或專案內未知程式。
不要匯入第三方套件來猜版本，改讀套件 metadata。
不要遞迴掃描整顆磁碟，也不要啟動模型或下載模型檔。

請在回覆中用表格整理：
- Python 版本、執行檔與環境的絕對路徑
- 專案直接依賴、已安裝的依賴套件及判斷依據
- uv 管理的 Python、獨立工具、工具入口與快取位置
- 專案宣告、鎖檔與已安裝狀態是否有可見差異
- 哪些安裝可由目前可見的 Agent 指令紀錄確認

檔案存在或修改時間不能單獨證明由哪個 Agent 安裝。
沒有直接紀錄的項目標成「安裝者未確認」。
找不到套件也要限定為「此環境未找到」，不要推論整台未安裝。
最後提出必要整理建議、影響範圍與待確認事項，
但這次不要執行整理，也不要寫入任何報告檔。

後續要讓 Agent 建立新環境時，則應在任務中指定專案目錄、Python 版本及需要的套件，要求使用專案隔離環境，並在完成後列出新增檔案、安裝位置與重建指令。能回答這幾件事，才知道這次操作留下了哪些可維護的成果。

常見問答

以下整理 uv、pip 與 Agent 工作流程中容易混淆的情況。

用了 uv，還需要先安裝 Python 嗎？

使用 uv 的獨立安裝器不需要先有 Python，uv 可以再下載及管理 Python，也能使用既有的相容解譯器。若採用 pip install uv，則需要先有可用的 Python 和 pip。安裝 uv 的方式不同，前置需求也不同。

uv 可以直接取代所有 pip 指令嗎？

uv 提供 pip 相容介面，但不是逐項完全相同。尤其環境選擇、設定檔與部分選項有差異；uv pip install 也不等於 uv add。既有腳本遷移前應對照 官方相容性文件 ，確認要保留的是原本安裝流程，還是改成專案管理。

出現 externally-managed-environment 怎麼辦？

這通常表示基礎 Python 環境由作業系統或另一個套件管理器管理，對應 PEP 668 的保護機制。一般專案應建立 venv 後安裝；命令列工具可使用 uv tool install 或 pipx。不要把 sudo pip install 或略過系統保護當成一般修復步驟。

刪掉 .venv 就能還原 Agent 做過的所有變更嗎？

不能。Python 安裝、工具環境、快取、shell 設定與專案原始碼可能在不同位置；若程式另外下載模型或寫入資料，也不一定在 .venv 裡。還原需要依當次指令與變更紀錄逐項處理，Git 的程式碼回復也不會自動移除版本控制之外的安裝資料。

每次使用 Agent 都應該改成 uv 嗎？

新建一般 Python 專案時，uv 能提供一致的依賴與環境流程。已有 Poetry、Conda 或團隊指定方式的專案，則應優先沿用。讓 Agent 看懂既有設定、在正確環境工作，通常比同一個專案多放一套管理工具更有幫助。

參考來源

Post Views: 41
Tags:
Sponsored Links

發佈留言