Astrid：把代理权限交给可撤销的 WASM 能力模型
Astrid 是一個用於可組合軟體的便攜式、功能安全的作業系統。
秒懂
- 它是什麼？
- Astrid 是 Rust 實作的可组合執行時，以 capsule、能力令牌、IPC ACL、Wasmtime 沙箱和审计链構成安全边界。
- 適合誰用？
- Astrid 适合希望執行不可信代理或可组合软件，並愿意采用 WebAssembly、能力授权和显式發行版的安全团队。不适合需要成熟產品發行版、简单插件安裝或不愿维护 capability manifest 的專案。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Rust（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
儲存庫入口 · astrid-runtime-astrid-deep-analysis
astrid-runtime/astrid 的儲存庫描述是：一個可移植、能力安全的操作係統，面向可组合软件。README 開篇说：Astrid 把元件当作操作係統對待進程一樣。每個能力都是一個密封的 WebAssembly 胶囊，可以與其他胶囊组合、只被授予明确的权限，並且可以在不擴大其影响范围的情况下被替換。Astrid 不依赖任何特定的產品、模型提供商、代理循环、使用者界面或分發方式。
Astrid 的閱讀重點還包括錯誤處理與撤銷時機：權限模型若只在初始化時檢查，長時間執行的代理可能保留過期能力；若每次呼叫都驗證，則會增加執行成本。README 沒有提供完整效能數據，因此只能把這個問題列為部署設計中的待驗證項，並用實際 capability 呼叫結果判斷。
设计出發点 · astrid-runtime-astrid-deep-analysis
README 的"為什么 Astrid 存在"一节说：代理框架把信任放在提示词中，而 Astrid 把信任放在執行時。代理被視為不可信代码，執行在使用者的机器上，可以访问檔案、網路和凭證。仅靠提示词约束不算安全边界。Astrid 的立场是：需要的是操作係統級别的边界。該节列出了几個机制：加密能力模型，每個檔案路径、網路主机和工具都是签名过的 ed25519 授权，范围限定到资源模式，绑定主體，检查过期時间，並且可以全局撤销。WASM 沙箱没有环境权限。內核被描述為"笨"，只负责路由事件、执行能力、執行沙箱、記錄审计轨迹，不持有模型、工具架構或業务逻辑。
元件如何交互 · astrid-runtime-astrid-deep-analysis
README 將前端（CLI、HTTP 网關、Discord 等）称為"上行链路"：透過 Unix 域套接字连接到守护進程，並以 IPC 事件進行通信。没有"Frontend"特性；上行链路像任何总線参與者一樣發布事件並接收响應。胶囊只透過总線通信，每個胶囊在 Capsule.toml 清单中声明它需要什么和提供什么，带有類型化的 imports/exports 表。內核透過拓扑排序解析依赖图，並按顺序启动胶囊。工具被描述為一種 IPC 约定，而不是內核概念：工具胶囊拦截 tool.v1.execute.<name>，內核從不看到工具架構。
安全模型 · astrid-runtime-astrid-deep-analysis
README 说 Astrid 的安全是分解的，没有一個单一的闸门讓所有操作都透過。一個胶囊没有环境权限，授权由独立的、按区域的机制强制执行，每個机制都預設關闭，並且在效果实际發生的地方强制执行。它列出的机制包括：WASM 沙箱（無係統调用、無檔案描述符、無主机內存）；清单门（声明的檔案、網路、進程允许列表，空列表即全部拒绝，並有路径遍历和 SSRF 防御）；IPC ACL（只能声明發布/订阅主题，按主體路由）；能力令牌（ed25519、绑定主體、有范围、有过期時间、可撤销）；审批门（一次、会话、总是、拒绝）；操作係統沙箱（Linux 上 bwrap，macOS 上 seatbelt，用於原生子進程）；审计链（签名、哈希連結的 JSONL 决策和调用）。README 说這些机制是真实且独立測試的，並指向了《The Astrid Book》的"五層门"章节。
安裝與初始设置 · astrid-runtime-astrid-deep-analysis
README 给出了三種安裝路径：透過 Homebrew（macOS 和 Linux）使用 brew tap astrid-runtime/tap 和 brew install astrid；透過 crates.io 使用 cargo install astrid（需要 Rust 1.95+）；或從源码構建：git clone 然後 cargo build --release。安裝後会有四個二進制檔案：astrid（CLI 上行链路）、astrid-daemon（內核進程）、astrid-build（胶囊編譯器和打包器）、astrid-emit（stdio 到总線的桥接）。初始设置使用 astrid init --distro <source> 獲取一個分發版（一個策划的胶囊集合），它可能呈現選擇组並提示設定。秘密按主體存储在秘密存储中，绝不透過指令行传递。init 寫入 Distro.lock，用 BLAKE3 哈希固定每個胶囊。README 還说 Astrid 執行時不選擇或捆绑一個產品分發版，操作员必須显式传递名称、儲存庫、本地 Distro.toml 或签名的 .shuttle 归档。
寫胶囊 · astrid-runtime-astrid-deep-analysis
README 描述了一個胶囊是一個由清单描述的 WASM 進程。astrid capsule new my-capsule 生成一個针對 wasm32-unknown-unknown 的首次編譯專案，加上 AUTHORING.md 指南。astrid capsule build 編譯並打包，astrid capsule install . 热加载到執行中的守护進程，無需重启。胶囊作者依赖 astrid-sdk，它镜像 std 模块布局（fs、net、process、env、time、log）並添加 Astrid 模块（ipc、kv、http、hooks、uplink、identity、approval）。#[capsule] 过程宏生成 WASM ABI 樣板：导出、序列化、工具、指令、钩子和生命周期入口的分發。
文档與開發流程 · astrid-runtime-astrid-deep-analysis
README 指向《The Astrid Book》作為权威参考，涵盖內核、胶囊模型、主机 ABI、总線和安全模型，带有檔案和行锚点。還列出了 docs/ 中的操作指南：統一設定架構、LLM 模型選擇、分發签名、网關部署執行手册、网關客户端生成。開發指令為 cargo build --workspace、cargo test --workspace -- --quiet、cargo clippy --workspace --all-features -- -D warnings、cargo fmt --all -- --check。所有 crate 强制执行 #![deny(unsafe_code)]，但 astrid-sys 和 astrid-sdk 例外，因為 WASM FFI 需要。README 说發布二進制檔案在标签推送時構建，使用無密钥 Sigstore 签名，自管理更新在提取任何字节之前驗證归档和身份。
在 Astrid 的能力邊界上，WASM 模組與宿主之間的權限不是抽象標籤，而是執行時要檢查的契約。閱讀 README 時，應把 capability 名稱、模組載入入口與撤銷流程逐項對照；任何未列出的檔案存取、網路呼叫或程序操作，都不能自行推定為可用。這個分界適合拿來審核代理工作是否超出原本授權。
若要評估 Astrid 是否能放進既有代理流程，先從倉庫的範例設定與 WASM runtime 啟動方式開始，記下模組版本和宿主參數，再觀察權限被拒絕時的錯誤訊息。重點不是看介面是否漂亮，而是撤銷 capability 後，代理是否真的無法繼續使用那項資源。這個結果會直接影響隔離策略與故障處理。
驗證 Astrid 時，先以 astrid init --distro 指定一個可追溯的 distro，再執行 astrid start、astrid status 與 astrid capsule list，確認守護程序和膠囊清單狀態。接著檢查 Distro.lock 是否固定每個膠囊的 BLAKE3 雜湊，並觀察 audit chain 是否留下簽名、雜湊連結的 JSONL 記錄。若要測試能力邊界，建立只宣告單一 fs 或 net import 的 Capsule.toml，分別執行允許與未宣告的 host call；預期後者在能力閘門拒絕，而不是靠提示文字阻止。開發者還可執行 cargo test --workspace -- --quiet 和 cargo clippy --workspace --all-features -- -D warnings，將編譯、測試與 lint 結果和 Rust 1.95+ 環境一併保存。這樣測到的是 Astrid 自己承諾的事件路由、WASM 沙箱和權限拒絕行為。
目前，Astrid 的採用者要把 uplink 和 capsule 分開審查：CLI、HTTP gateway 或 Discord 只透過 Unix socket 發 IPC event，並不因此取得檔案或網路權限。測試時讓一個 capsule 嘗試訂閱未寫入 Capsule.toml 的 topic，再讓另一個 principal 讀取對方的 KV、secret 或 home namespace，逐項確認 fail-closed。對原生子程序則檢查 Linux bwrap 或 macOS seatbelt 的限制，並以簽名、過期和撤銷的 ed25519 grant 驗證 capability token。這些觀察能區分核心 ACL、WASM host call、作業系統沙箱和 audit chain 的責任，避免把所有安全結果錯誤歸因給模型。
編輯結論
Astrid 适合希望執行不可信代理或可组合软件，並愿意采用 WebAssembly、能力授权和显式發行版的安全团队。不适合需要成熟產品發行版、简单插件安裝或不愿维护 capability manifest 的專案。先用 cargo 或 Homebrew 安裝，执行 astrid init --distro 與 astrid status，检查一個 capsule 的 imports、exports、授权拒绝、审计链和升級回滚行為。
社群筆記