Rust on KnightLi的博客

RTK：給 AI 編程代理省 token 的命令列代理工具

Wed, 27 May 2026 13:52:01 +0800

rtk-ai/rtk 是一個面向 AI 編程代理的命令列代理工具。它的思路很直接：很多 agent 在開發過程中會頻繁呼叫 ls、cat、grep、git status、git diff、測試命令和建置命令，而這些命令的原始輸出經常又長又重複。RTK 會在命令輸出進入 LLM 上下文之前先做過濾和壓縮，讓模型看到更短、更有用的結果。

專案地址：rtk-ai/rtk

它解決的是什麼問題

AI 編程工具真正貴的不只是模型呼叫次數，還有上下文裡被塞進去的無效資訊。

例如：

ls -la 可能輸出大量權限、時間和無關檔案。
git diff 可能夾雜很多重複上下文。
pytest、cargo test、npm test 失敗時，最重要的是失敗用例和錯誤堆疊，而不是所有通過項。
docker ps、kubectl pods、aws 命令往往欄位很多，但 agent 只需要少數關鍵資訊。

這些輸出如果原樣進入模型上下文，會快速消耗 token。RTK 的目標不是替代這些命令，而是在它們和 AI 編程代理之間加一層「壓縮代理」。

RTK 的基本工作方式

RTK README 裡給出的定位是：它會在命令輸出到達 LLM context 之前，對結果做過濾和壓縮。它是一個 Rust 單檔二進位程式，支援大量常見開發命令，並強調低額外開銷。

它主要做四類處理：

Smart Filtering：去掉註解、空白、樣板內容和低價值雜訊。
Grouping：把相似項目聚合起來，例如按目錄、錯誤類型或狀態分組。
Truncation：保留關鍵上下文，截斷重複或不重要的部分。
Deduplication：把重複日誌折疊成更短的計數表達。

從 agent 的角度看，命令仍然是熟悉的開發命令；變化在於返回給模型的結果更短。

支援哪些命令

RTK 覆蓋的命令範圍比較偏「日常開發現場」：

檔案查看：rtk ls、rtk read、rtk find、rtk grep
Git：rtk git status、rtk git log、rtk git diff
GitHub CLI：rtk gh pr list、rtk gh pr view、rtk gh issue list
測試命令：rtk pytest、rtk go test、rtk cargo test、rtk vitest、rtk playwright test
建置和 lint：rtk lint、rtk tsc、rtk next build、rtk cargo clippy
容器和雲命令：rtk docker ps、rtk docker logs、rtk kubectl pods、rtk aws sts get-caller-identity
資料和日誌：rtk json、rtk deps、rtk env、rtk log

這類工具最適合 agent 高頻讀命令輸出的場景。它不負責替你寫程式碼，而是讓 agent 少讀雜訊。

安裝和接入方式

README 給了幾種安裝方式。

Homebrew：

`1`	`brew install rtk`

Linux/macOS 快速安裝：

`1`	`curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh \| sh`

Cargo：

`1`	`cargo install --git https://github.com/rtk-ai/rtk`

安裝後可以先檢查版本和統計資訊：

1
2

rtk --version
rtk gain

接入 AI 編程工具時，可以用初始化命令：

rtk init -g
rtk init -g --gemini
rtk init -g --codex
rtk init -g --agent cursor
rtk init --agent windsurf
rtk init --agent cline

初始化後需要重啟對應的 AI 工具。對於支援 hook 的 agent，Bash 命令會在執行前被重寫，例如把 git status 變成 rtk git status，讓 agent 收到壓縮後的輸出。

使用時要注意什麼

RTK 的收益取決於 agent 是否真的透過 shell 命令讀取資訊。

README 裡特別提醒：像 Claude Code 的內建 Read、Grep、Glob 這類工具不經過 Bash hook，因此不會自動被 RTK 改寫。要讓 RTK 介入，需要使用 shell 命令，例如 cat、head、tail、rg、grep、find，或者直接呼叫 rtk read、rtk grep、rtk find。

這點很關鍵。RTK 不是全域透明地壓縮所有 agent I/O，它更像是 shell 命令層面的代理。

Windows 使用者也要注意，README 建議不要直接雙擊 rtk.exe，而是把它放到 PATH 裡，透過 Command Prompt、PowerShell 或 Windows Terminal 使用。它也提到，如果想獲得完整 hook 體驗，WSL 會更自然。

適合誰用

RTK 適合三類人：

重度 AI 編程使用者：每天讓 agent 跑很多 git、rg、測試和建置命令。
大倉庫使用者：命令輸出動輒幾百行，agent 經常被無關上下文淹沒。
關心 token 成本和上下文窗口的人：希望模型把注意力放在失敗、變更和關鍵檔案上。

如果你的專案很小，或者 agent 主要透過 IDE 內建工具讀取檔案，RTK 的體感收益可能沒那麼明顯。它真正發力的地方，是命令列輸出又長又頻繁的開發流。

我的判斷

RTK 的方向很實用。現在很多 AI 編程工作流都在強調更強的模型、更大的上下文、更長的任務，但開發現場還有一個樸素問題：agent 經常讀了太多沒必要讀的東西。

把命令輸出先壓縮，再交給模型，能減少 token 消耗，也能降低模型被雜訊帶偏的機率。

不過它不是魔法開關。要用好 RTK，需要把 agent 的工作方式往 shell 命令靠一靠，並確認目前工具的 hook 是否真的生效。對 Codex、Claude Code、Gemini CLI、Cursor、Windsurf 這類場景來說，它更像一個值得測試的「上下文節流器」：不改變開發命令本身，但讓 agent 讀到更乾淨的結果。

wx-cli 專案解讀：用命令列查詢本機微信聊天記錄

Mon, 18 May 2026 21:02:21 +0800

wx-cli 是一個用 Rust 編寫的本機微信資料命令列工具，目標是在命令列裡查詢自己的微信會話、聊天記錄、聯絡人、群成員、收藏、朋友圈、公眾號文章、附件和統計資訊。

它不是雲端微信同步服務，也不是聊天機器人。它更像是一個本機唯讀資料檢索層：微信仍然在本機執行，資料仍然留在本機，wx-cli 負責按需解密、快取和查詢本機資料庫，再把結果以 YAML 或 JSON 形式輸出給人或 Agent 使用。

這個專案有兩個值得關注的點：一是它把微信本機資料查詢做成了跨平台 CLI；二是它專門考慮了 Claude Code、Cursor、Codex 這類 AI Agent 的使用場景，提供了 SKILL.md 和帶 meta 的結構化輸出。

wx-cli 能做什麼

按專案 README 的描述，wx-cli 覆蓋的功能很完整：

查看最近會話和未讀會話。
查詢某個聯絡人或群的聊天歷史。
全庫搜尋關鍵字。
查看新增訊息。
查詢聯絡人、群成員和群暱稱。
查詢收藏。
查詢朋友圈通知、朋友圈時間線和朋友圈正文。
查詢公眾號文章推送。
列出和提取聊天圖片附件。
做聊天統計。
匯出聊天記錄為 Markdown 或 JSON。

這些能力讓它不只是「查聊天記錄」，而是把微信本機資料變成了可搜尋、可統計、可匯出的本機資料庫。

為什麼適合 AI Agent

很多命令列工具只是給人看的，輸出是一段文字。wx-cli 則明顯考慮了 Agent 讀取。

README 提到，history、search、sessions、unread、new-messages、stats、attachments 等命令會附帶 meta 資訊。meta 裡包含結果狀態、未知分片、命中資料的最新時間、session 記錄的最新時間等資訊。

這對 Agent 很有用。因為 AI 不只需要「查到了什麼」，還需要知道「結果新不新」「有沒有可能漏訊息」「是不是需要重新 init」。例如：

status 可以提示結果是否 ok 或 possibly_stale。
unknown_shards 可以提示是否存在 daemon 目前沒有 key 的資料庫分片。
chat_latest_timestamp 可以告訴 Agent 目前命中資料裡的最新訊息時間。
session_last_timestamp 可以幫助判斷本機 session 記錄是否明顯領先於查詢結果。

這類元資訊可以減少 AI 誤判，讓 Claude Code、Cursor、Codex 這類工具在處理微信資料時更穩。

安裝方式

專案推薦透過 npm 全平台安裝：

`1`	`npm install -g @jackwener/wx-cli`

也支援 macOS / Linux 的 curl 安裝：

`1`	`curl -fsSL https://raw.githubusercontent.com/jackwener/wx-cli/main/install.sh \| bash`

Windows 可以在系統管理員 PowerShell 中執行：

`1`	`irm https://raw.githubusercontent.com/jackwener/wx-cli/main/install.ps1 \| iex`

如果要從原始碼建置，也可以直接用 Rust：

1
2

git clone git@github.com:jackwener/wx-cli.git && cd wx-cli
cargo build --release

建置產物是 target/release/wx，Windows 下是 wx.exe。

和 Agent Skill 的關係

wx-cli 還提供了面向 AI Agent 的 Skill。可以透過 skills CLI 一鍵安裝到 Claude Code、Cursor、Codex 等支援 Skills 的環境：

`1`	`npx skills add jackwener/wx-cli`

全域安裝：

`1`	`npx skills add jackwener/wx-cli -g`

安裝後，Agent 會讀取倉庫裡的 SKILL.md，知道如何安裝、初始化和呼叫 wx-cli。

這意味著你可以讓 Agent 幫你做一些本機資訊整理任務，例如：

找某段時間某個群聊裡討論過的關鍵字。
彙總最近未讀訊息。
從某個會話裡匯出最近聊天記錄。
搜尋公眾號文章推送連結。
分析某個群聊裡的發言統計。

前提仍然是：這些資料必須是你本機、你自己的微信資料。

基本使用方式

初始化前需要保持微信正在執行。不同平台要求不同。

Linux 上可以執行：

`1`	`sudo wx init`

Windows 上需要用系統管理員 PowerShell：

wx init

macOS 上更複雜。README 說明，預設路徑需要先對 WeChat 做 ad-hoc 簽名，才能掃描程序記憶體；重新簽名後還要清理舊 TCC 授權記錄，否則截圖、視訊通話、麥克風等權限可能出現「看起來已開啟但實際拒絕」的問題。專案文件也提醒，重新簽名會帶來 macOS 頻繁彈出存取其他 App 資料提示的副作用。

初始化後，可以用下面的命令驗證：

`1`	`wx sessions`

能看到最近會話，說明基本鏈路已經可用。daemon 會在首次呼叫時自動啟動。

常用命令示例

查看最近會話：

`1`	`wx sessions`

查看未讀會話：

`1`	`wx unread`

只看真人未讀，過濾公眾號和摺疊入口：

`1`	`wx unread --filter private,group`

查看某個會話最近聊天記錄：

`1`	`wx history "張三"`

拉取更多歷史訊息：

`1`	`wx history "張三" -n 2000`

按時間範圍查詢群聊：

`1`	`wx history "AI群" --since 2026-04-01 --until 2026-04-15`

全庫搜尋：

`1`	`wx search "關鍵詞"`

搜尋某個群中的關鍵字：

`1`	`wx search "會議" --in "工作群" --since 2026-01-01`

匯出聊天記錄：

1
2

wx export "張三" --format markdown -o chat.md
wx export "AI群" --since 2026-01-01 --format json

這些命令都比較適合被腳本或 Agent 呼叫，尤其是加上 --json 後。

朋友圈和公眾號文章

wx-cli 不只查聊天。

朋友圈相關命令分成通知和貼文：

1
2
3

wx sns-notifications
wx sns-feed
wx sns-search "關鍵詞"

需要注意，朋友圈資料只覆蓋你本機刷到過的內容。微信客戶端按需下載，沒在本機出現過的資料，工具也不會憑空拿到。

公眾號文章則透過獨立命令查詢：

wx biz-articles
wx biz-articles --account "返朴"
wx biz-articles --since 2026-05-01 --until 2026-05-10
wx biz-articles --json | jq '.[].url'

它會回傳公眾號名稱、標題、URL、摘要、封面、時間等欄位。對做資料整理、文章收集和本機知識庫的人來說，這個功能很實用。

附件提取

微信聊天裡的圖片附件通常不是直接可讀的普通圖片檔，而是存在 xwechat_files/<wxid>/msg/attach/... 下的 .dat 檔案。

wx-cli 提供了兩步流程：

1
2

wx attachments "張三"
wx attachments "AI群" --kind image -n 100

先拿到 attachment_id 後，再提取：

`1`	`wx extract <attachment_id> -o ~/Desktop/photo.jpg`

輸出報告裡會帶 md5、dat_path、dat_size、output、format、decoder 等資訊。README 中說明它支援 legacy XOR、V1 fixed-AES、V2 AES + XOR 等解碼檔位，不同平台的 image key 提取方式也不同。

這部分能力很強，但也更需要謹慎使用：只處理自己的資料，不要把它用於未經授權的資料存取。

daemon 架構為什麼重要

wx-cli 的效能點在 daemon。

README 中給出的結構大致是：

wx (CLI) ──Unix socket──▶ wx-daemon (背景程序)
                              │
                    ┌─────────┴──────────┐
               DBCache               聯絡人快取
           (mtime 感知複用)

daemon 首次解密後，會把資料庫和 mtime 資訊持久化到 ~/.wx-cli/cache/。如果資料庫檔案 mtime 沒變，後續呼叫就可以複用快取，不需要每次重新解密。

這對命令列查詢和 Agent 循環都很關鍵。Agent 可能會連續查詢多個會話、搜尋多個關鍵字、再做統計和匯出。如果每次都重新掃描和解密，體驗會很差；daemon 快取讓它更接近一個本機查詢服務。

原理簡述

專案 README 對原理有直接說明：微信 4.x 使用 SQLCipher 4 加密本機資料庫，WCDB 會在程序記憶體中快取派生後的 raw key。

wx-cli 會根據平台使用不同方式掃描微信程序記憶體，匹配 key 模式後提取密鑰，再由 daemon 按需解密和快取資料庫。

不同平台的底層機制不同：

macOS 使用 Mach VM API。
Linux 使用 /proc/<pid>/mem。
Windows 使用 VirtualQueryEx 和 ReadProcessMemory。

這些能力解釋了為什麼初始化通常需要較高權限，也解釋了為什麼 macOS 上會涉及簽名和隱私授權。

使用邊界和風險

這類工具必須先講邊界。

wx-cli README 的免責聲明寫得很明確：工具僅用於學習和研究目的，用於解密自己的微信資料，並要求遵守相關法律法規，不得用於未經授權的資料存取。

實際使用時也建議注意：

只在自己的電腦、自己的微信帳號上使用。
不要把匯出的聊天記錄隨意上傳到雲端模型。
用 Agent 分析聊天記錄時，先確認 API 供應商和資料跨境風險。
匯出 Markdown / JSON 後要注意檔案權限和備份位置。
公司或多人裝置上使用前，先確認合規和授權。

本機工具不等於沒有隱私風險。它減少了資料離開本機的預設路徑，但如果你把輸出交給雲端模型、網盤或第三方腳本，風險又會回來。

適合誰使用

wx-cli 適合這些場景：

想在本機快速搜尋自己的微信歷史訊息。
需要把某個會話匯出為 Markdown 或 JSON。
想統計某個群聊在一段時間內的發言情況。
想讓 Claude Code、Cursor、Codex 等 Agent 幫忙整理本機微信資料。
想把公眾號文章推送連結整理進本機知識庫。
想研究微信本機資料庫結構和解密流程。

不太適合這些場景：

想做雲端微信同步。
想繞過他人裝置或帳號權限。
想無腦圖形介面操作，不接觸命令列。
不願意處理 macOS 權限、Windows 系統管理員權限或 Linux sudo 的使用者。

小結

wx-cli 的價值，不只是「命令列查微信聊天記錄」。更準確地說，它把本機微信資料變成了一個可查詢、可匯出、可被 Agent 消費的本機資料源。

它的 daemon 架構解決了反覆解密和查詢效能問題；meta wrapper 讓 AI Agent 更容易判斷結果是否新鮮；SKILL.md 則把安裝和使用方式交給 Claude Code、Cursor、Codex 這類工具理解。

如果你經常需要從微信裡找資訊、整理群聊、匯出記錄或建構個人資料庫，wx-cli 很值得關注。但使用它時也要始終記住一條底線：只處理自己的資料，並且謹慎管理匯出結果。

參考資料

jackwener/wx-cli GitHub 倉庫

DeepSeek-TUI：在終端裡執行 DeepSeek 編程 Agent

Fri, 08 May 2026 13:41:15 +0800

DeepSeek-TUI 是一個執行在終端裡的 AI 編程 Agent。它圍繞 DeepSeek V4 模型設計，透過 deepseek 命令啟動，可以在 TUI 介面裡讀寫檔案、執行 shell 命令、搜尋網頁、管理 git、呼叫 MCP server，並支援子 Agent 協作。

它比普通聊天 CLI 更像一個終端工作台。它不只是把問題發給模型，而是把看程式碼、改檔案、跑命令、檢查診斷、保存會話、恢復狀態整合在一起。

專案主要使用 Rust 編寫，授權為 MIT。GitHub 描述是「Coding agent for DeepSeek models that runs in your terminal」。

適合誰

DeepSeek-TUI 適合喜歡終端工作流，並想用 DeepSeek 模型處理本地開發任務的開發者。

用 DeepSeek 做程式碼修改和專案分析。
不想打開完整 IDE。
希望 AI 工具能讀寫本地 workspace。
需要 Plan、Agent、YOLO 模式。
想保存會話、恢復長任務、回滾改動。
想接入 MCP、LSP 診斷、HTTP/SSE runtime API 和 skills。

如果只是簡單問答，Web 端或輕量 CLI 已足夠。DeepSeek-TUI 更適合把模型放進本地開發流程。

安裝方式

npm：

1
2
3

npm install -g deepseek-tui
deepseek --version
deepseek --model auto

npm 包是安裝器和 wrapper，會下載預編譯 Rust 二進位，要求 Node.js >=18。

Cargo：

1
2

cargo install deepseek-tui-cli --locked
cargo install deepseek-tui --locked

Homebrew：

1
2

brew tap Hmbown/deepseek-tui
brew install deepseek-tui

也可以從 GitHub Releases 下載 Linux x64/ARM64、macOS x64/ARM64、Windows x64 的預編譯版本。

Docker：

docker run --rm -it \
  -e DEEPSEEK_API_KEY \
  -v "$PWD:/workspace" \
  ghcr.io/hmbown/deepseek-tui:latest

配置 API Key

首次啟動會提示輸入 DeepSeek API key，並保存到：

`1`	`~/.deepseek/config.toml`

也可以手動配置：

1
2

deepseek auth set --provider deepseek
deepseek auth status

或使用環境變數：

1
2

export DEEPSEEK_API_KEY="YOUR_KEY"
deepseek

檢查環境：

`1`	`deepseek doctor`

清除已保存的 key：

`1`	`deepseek auth clear --provider deepseek`

Auto mode

`1`	`deepseek --model auto`

TUI 中也可使用：

`1`	`/model auto`

Auto mode 同時選擇模型和 thinking：

模型：deepseek-v4-flash 或 deepseek-v4-pro
Thinking：off、high 或 max

真正請求前，TUI 會做一次小型路由呼叫，分析最新請求和上下文，再決定本輪模型和思考級別。auto 是本地功能，上游 API 收到的是具體模型和設定。

需要基準測試、成本上限或固定行為時，建議直接指定模型。

三種模式

模式	用途
Plan	只讀探索和計畫
Agent	預設互動模式，工具呼叫有 approval gate
YOLO	在可信 workspace 中自動批准工具

Plan 適合分析，Agent 適合日常編程，YOLO 風險最高，只適合可信分支或測試目錄。

工具能力

DeepSeek-TUI 支援檔案讀寫、apply patch、shell、git、web search/browse、子 Agent、MCP、LSP 診斷、會話恢復、工作區回滾、持久化任務隊列、HTTP/SSE runtime API 和 skills。

LSP 診斷可把 rust-analyzer、pyright、typescript-language-server、gopls、clangd 等錯誤回饋給模型。工作區回滾使用 side-git 快照，提供 /restore 和 revert_turn，但正常 git 提交習慣仍然重要。

常用命令

deepseek
deepseek "explain this function"
deepseek --model deepseek-v4-flash "summarize"
deepseek --model auto "fix this bug"
deepseek --yolo
deepseek auth set --provider deepseek
deepseek doctor
deepseek doctor --json
deepseek models
deepseek sessions
deepseek resume --last
deepseek resume <SESSION_ID>
deepseek fork <SESSION_ID>
deepseek serve --http
deepseek serve --acp
deepseek pr <N>
deepseek mcp list
deepseek mcp validate
deepseek update

Zed 和 ACP

{
  "agent_servers": {
    "DeepSeek": {
      "type": "custom",
      "command": "deepseek",
      "args": ["serve", "--acp"],
      "env": {}
    }
  }
}

目前 ACP 支援新會話和 prompt response，但工具驅動編輯和 checkpoint replay 尚未透過 ACP 暴露。

配置和 provider

使用者配置：

`1`	`~/.deepseek/config.toml`

專案 overlay：

`1`	`<workspace>/.deepseek/config.toml`

api_key、base_url、provider、mcp_config_path 等敏感欄位不能放入專案 overlay。

OpenAI-compatible 示例：

1
2

deepseek auth set --provider openai --api-key "YOUR_OPENAI_COMPATIBLE_API_KEY"
OPENAI_BASE_URL="https://openai-compatible.example/v4" deepseek --provider openai --model glm-5

Ollama：

1
2

ollama pull deepseek-coder:1.3b
deepseek --provider ollama --model deepseek-coder:1.3b

小結

DeepSeek-TUI 是一個完整的終端 AI 編程 Agent，把 DeepSeek V4、TUI、工具呼叫、LSP 診斷、會話恢復、回滾、MCP 和 skills 放進同一套 Rust 工具鏈。它不一定最輕，但適合把 AI 從聊天推進到可執行的本地開發流程。

參考資料

sudo 和 sudo-rs 有什麼差異：Rust 版本 sudo 會改變什麼

Fri, 01 May 2026 19:27:08 +0800

sudo 是 Linux 使用者最熟悉的命令之一。它讓普通使用者在授權範圍內臨時以更高權限執行命令，例如安裝軟體、修改系統設定或重啟服務。

最近 sudo-rs 受到更多關注，原因是 Ubuntu 25.10 開始預設使用 Rust 實現的 sudo-rs 來替代傳統 sudo。對普通使用者來說，表面上仍然輸入 sudo。真正變化在系統底層：執行的可能已經是 Rust 版本的 sudo。

這件事容易引發兩個問題：

傳統 sudo 出什麼問題了嗎？
sudo-rs 會不會影響日常使用和伺服器設定？

簡單結論是：普通桌面使用者基本不用擔心；如果你維護伺服器、寫過複雜 sudoers 規則，或者依賴特殊 sudo 行為，就需要認真測試。

sudo-rs 是什麼

sudo-rs 是用 Rust 編寫的 sudo / su 實現。它的目標不是創造一個完全不同的新命令，而是重新實現傳統 sudo 的主要功能，同時利用 Rust 的記憶體安全特性降低常見安全風險。

傳統 sudo 主要由 C 語言編寫，歷史很長，功能也很完整。這種成熟度帶來穩定性，也帶來維護負擔。很多程式碼來自很早的 Unix/Linux 使用場景，後來又疊加了大量相容邏輯、擴充和邊界處理。

sudo-rs 選擇重新實現，是為了獲得幾個好處：

借助 Rust 減少記憶體安全問題；
用更現代的程式碼結構降低維護難度；
去掉部分歷史功能和高風險預設行為；
吸引熟悉 Rust 的新貢獻者參與維護；
為未來權限提升工具提供更容易稽核的基礎。

不過，sudo-rs 不是傳統 sudo 的 100% 相容替代品。它仍在發展中，一些傳統功能暫時沒有實現，另一些功能可能不會再實現。

普通使用者會感覺到什麼變化

對普通使用者來說，變化很少。

你仍然這樣使用：

`1`	`sudo apt update`

或者：

`1`	`sudo systemctl restart nginx`

在 Ubuntu 25.10 中，sudo 會指向 sudo-rs。使用者輸入的命令不需要改成 sudo-rs，腳本裡常見的 sudo 也不會因為命令名變化而立刻失效。

比較容易看到的變化是密碼輸入回饋。 sudo-rs 預設會在輸入密碼時顯示星號。傳統 sudo 也可以透過設定實現類似效果，但很多發行版預設是不顯示任何字元。

另外，部分錯誤資訊和警告資訊的文字可能不同。例如密碼錯誤、權限不足、設定不相容時，提示內容可能和以前不完全一樣。這對人類使用者影響不大，但如果某些腳本依賴解析 sudo 的錯誤輸出，就需要檢查。

管理員需要關注哪些差異

真正需要注意的是系統管理員和進階使用者。

傳統 sudo 的生態很大，不少伺服器會有複雜的 sudoers 設定。這些設定可能包含命令參數匹配、環境變數控制、日誌、郵件通知、PAM 行為和不同主機組策略。

sudo-rs 目前和傳統 sudo 存在一些差異。例如，原文提到 sudo-rs 不包含傳統 sudo 的 sendmail 支援。過去有些環境會透過 sendmail 發送 sudo 使用通知，這類設定遷移時就需要換方案。

認證方面，sudo-rs 使用 PAM。這意味著資源限制、umask 等行為應更多透過 PAM 設定，而不是完全依賴 sudoers 文件。如果你過去在 sudoers 裡處理了很多細節，切換前要確認這些規則是否仍然生效。

還有一個重要變化是命令參數位置的萬用字元支援。 sudo-rs 不支援在命令參數位置使用萬用字元，以避免 sudoers 文件中常見的設定錯誤。這對安全是好事，但可能影響已有規則。

Ubuntu 裡怎麼處理 sudo 和 sudo-rs

從 Ubuntu 25.10 開始，系統預設使用 sudo-rs。使用者繼續輸入 sudo，底層會執行 Rust 實現。

傳統 sudo 並沒有馬上消失。在 Ubuntu 的過渡設計中，經典 sudo 仍然以 sudo-ws 的形式保留。如果確實需要傳統實現，可以使用 sudo-ws，或者透過 alternatives 機制切換預設 sudo。

切換命令類似這樣：

`1`	`sudo update-alternatives --config sudo`

不過，不建議普通使用者主動切回傳統 sudo。如果你沒有自訂 sudoers，也沒有依賴特殊行為，繼續使用發行版預設選擇更省心。

如果你想在舊版本 Ubuntu 上測試，sudo-rs 從 Ubuntu 24.04 開始已經可以從 universe 倉庫獲得。其他發行版也可能提供對應套件，但命令名稱和整合方式不一定相同。

sudo-rs 為什麼選擇 Rust

sudo 是高權限工具。一旦這類工具出現漏洞，後果可能比普通命令嚴重得多。歷史上，sudo 也出現過多個權限提升漏洞。

Rust 的優勢在於記憶體安全。它透過所有權、借用檢查和型別系統，減少懸空指標、越界存取、use-after-free 等常見問題。這不能保證程式絕對安全，但可以減少 C/C++ 專案裡很常見的一類漏洞。

對 sudo 這種長期執行在安全敏感位置的工具來說，用更安全的語言重寫有現實意義。它不只是「為了 Rust 而 Rust」，而是試圖降低維護和稽核成本。

當然，語言不能解決全部安全問題。權限檢查邏輯、設定解析、PAM 互動、環境變數處理、日誌和使用者體驗，仍然需要嚴謹設計和長期測試。

sudo-rs 不是唯一選擇

sudo 生態裡本來就有其他替代品。

比較常見的是 doas。它來自 OpenBSD，設計更簡單，設定也更小。一些使用者喜歡它，是因為它沒有 sudo 那麼複雜。

還有一些 Rust 或 systemd 相關的替代方案，例如 RootAsRole、systemd 的 run0 等。不過這些工具的目標和適用場景並不完全相同。

對大多數 Linux 發行版來說，sudo 仍然是預設選擇。 sudo-rs 的意義在於，它嘗試在保持使用者習慣的同時，把底層實現換成更現代的程式碼基礎。

遷移前應該檢查什麼

如果你只是個人桌面使用者，可以跟隨發行版預設設定。

如果你維護伺服器或工作站，建議檢查這些內容：

是否有複雜的 /etc/sudoers 或 /etc/sudoers.d/ 規則；
是否使用了命令參數萬用字元；
是否依賴 sudo 的郵件通知；
是否有腳本解析 sudo 的錯誤輸出；
是否透過 sudoers 控制 umask、資源限制或環境變數；
是否有 LDAP、PAM、SSSD 等認證整合；
是否有自動化部署腳本預設假設傳統 sudo 行為。

可以先在測試機上驗證：

sudo -l

再執行關鍵維護命令，確認權限、環境變數和日誌行為都符合預期。

是否應該主動切換到 sudo-rs

如果發行版已經預設切換，普通使用者可以直接接受。如果你使用的是伺服器或生產環境，不建議只為了嘗鮮手動替換。

更穩妥的做法是：

在測試環境安裝 sudo-rs；
對照現有 sudoers 設定逐項驗證；
檢查 PAM、日誌、稽核和自動化腳本；
確認回滾方式；
等發行版給出穩定整合後再遷移。

這類工具處在權限鏈路上，不適合用「能執行幾個命令」來判斷是否安全。真正要驗證的是邊界條件和異常情況。

小結

sudo-rs 是傳統 sudo 的 Rust 實現，目標是用更現代、更安全的程式碼基礎承接 sudo 的核心功能。 Ubuntu 25.10 預設啟用它，說明主流發行版已經開始認真推動這條路線。

對普通使用者來說，變化很小。你仍然輸入 sudo，只是底層實現可能變成了 sudo-rs。最多會注意到密碼輸入顯示星號，或者錯誤提示文字略有變化。

對系統管理員來說，重點是相容性。如果系統裡有複雜 sudoers 規則、sendmail 通知、PAM 整合、參數萬用字元或依賴 sudo 輸出的腳本，就應該在升級前測試。

Rust 重寫不是萬靈丹，但對 sudo 這種安全敏感工具來說，減少記憶體安全風險、降低維護複雜度，是值得認真考慮的方向。

參考來源：