Chidori：把 agent 的每一次副作用都變成可重播的 host call
The agent framework where every run is durable, replayable, and resumable by default.
秒懂
- 它是什麼？
- Chidori 用一個 Rust 執行檔與內嵌的純 Rust JavaScript 引擎，把 LLM 呼叫、工具呼叫與 HTTP 請求全部收攏成一條 host call 邊界，換來可重播、可續跑、可暫停的 agent 執行。它的代價是：你的 agent 必須活在這個 runtime 裡。
- 適合誰用？
- 如果你要的是長時間執行、需要人工中途放行、而且除錯時不想重複付 token 的 agent，Chidori 的 host call 邊界正好對上這個需求，值得先用官方 install.sh 裝好 runtime，再照 examples/ 跑一次含 chidori.input() 的流程，確認暫停後能在新 process 續跑。如果你的 agent 只是一次性問答、或你已經把工作流綁在既有的圖形化編排器上，導入 Chidori 等於要重寫控制流，並不划算。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 6 天前。
- 用什麼語言寫的？
- 主要是 Rust（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
Chidori 想解的是「跑三次才出現的 bug」
README 開頭把問題列得很直接：agent 是不確定、昂貴、長時間執行的。三者疊在一起，就變成一個 bug 要跑到第三次才浮現，而你重現不了；每次除錯都重新付一次同樣的 token；多步流程跑到一半 crash 就全部歸零；還有一個「等人類核准」的步驟，逼你為了幾小時的等待而把 process 開著。
Chidori 的目標讀者因此很清楚：寫 TypeScript、已經在用 LLM 與外部工具、而且流程長到會被打斷的人。它不是給寫單次問答腳本的人用的。README 的說法是「Most frameworks layer orchestration on top of this chaos」，Chidori 選擇在副作用發生的那一點上處理，而不是在上面再疊一層編排。
這裡有一個值得先講清楚的判斷：durability 不是免費的。你換到的是可重播與可續跑，付出去的是「agent 不能直接碰外面的世界」。這個交換是否值得，取決於你的流程有多長、失敗有多貴。
host call 是唯一邊界，也是整個設計的支點
README 描述的核心機制只有一句：agent 做的每一個副作用，包括每一次 LLM 呼叫、工具呼叫與 HTTP 請求，都以 host call 的形式流經 runtime 並被記錄下來。agent 從不直接接觸世界，所以 runtime 看得到、也記得到全部的東西。
一旦 runtime 掌握了所有副作用，同一份紀錄就能被拿去做四件事：記錄、快取、重播、暫停與續跑。README 把這四件事對應回開頭的四個痛點：重播時 call log 是確定性的紀錄，同一段程式碼對著它重跑，每個 prompt、工具與 HTTP 呼叫都立刻回傳當時記錄的結果，不花 token 且輸出相同；執行中的 run 在每個 host safepoint 被 checkpoint，process 被中途殺掉後可以在全新的 process 裡從 call log 重播到暫停點再繼續；chidori.input() 與具名 signals 會把 run 暫停到磁碟，人類或其他 agent 幾分鐘或幾天後回答，run 從停止處接上；一份錄下來的 run 可以 commit 進 git，當成零成本、毫秒級的整合測試。
確定性不是靠運氣。README 說 replay 的 byte-identical 是由 runtime policy 強制，包含固定時鐘與種子化隨機。這一點值得注意，因為它同時是一個限制：如果你的 agent 依賴真實時間或真實亂數，那部分行為在 replay 時不會重現。
另外，host call 邊界也解釋了為什麼 SDK 可以這麼薄。npm 與 PyPI 上的套件只是透過 HTTP 驅動 runtime 的客戶端，沒有 native binding。runtime 本身是一個 Rust binary，內嵌純 Rust 的 JavaScript 引擎，不需要 Node、Deno 或 V8。
安裝與啟動：一顆 binary，加上可選的 SDK
官方最快的安裝路徑是 install.sh：
curl -fsSL https://raw.githubusercontent.com/ThousandBirdsInc/chidori/main/scripts/install.sh | sh
README 說這個腳本會從最新 GitHub release 下載對應平台的 binary，放進 ~/.chidori/bin，並在需要時印出一行 PATH 調整提示。支援的平台是 macOS（Apple Silicon 與 Intel）與 Linux（x86_64 與 arm64）。裝完用 chidori --version 確認。
不想用腳本的話，release 頁面每個平台各有一個 tarball。也可以從 crates.io 安裝，但這條路會從原始碼建置，需要 stable Rust toolchain 1.95 或更新：
cargo install chidori
binary 會落在 ~/.cargo/bin。從 checkout 建置則多拿到 examples/，repo 用 rust-toolchain.toml 固定工具鏈，cargo 會自動採用：
git clone https://github.com/ThousandBirdsInc/chidori cd chidori cargo build --release
這裡有個容易搞混的地方，README 特別用一段提醒：你裝的 chidori binary 是 runtime，npm 上的 @1kbirds/chidori 與 PyPI 上的 chidori 是 SDK，也就是從 TypeScript 或 Python 應用透過 HTTP 驅動 runtime 的薄客戶端。兩者角色不同，別把 SDK 當成執行環境。
可用的 API 名稱在 README 中出現的有 chidori.input() 與 chidori.* 形式的 await 呼叫，具名訊號的細節指向 docs/signals.md。除此之外的函式簽章，這份材料沒有給出，需要查官方文件。
寫普通 async TypeScript，而不是畫一張圖
Chidori 對控制流的立場很明確：agent 就是普通的 async TypeScript，用原生 if、for、try，有型別化的輸入、真正的 import 與完整的編輯器工具。README 的說法是「If you can write a function, you can write an agent.」
對照組是圖或 DSL 形式的編排。差別不只是語法偏好。圖形化編排把控制流外化成資料，好處是靜態可視化，代價是迴圈、例外處理與條件分支往往要靠框架提供的節點來拼；Chidori 反過來，控制流留在語言裡，durability 由 runtime 在 host call 上處理。README 強調「You don't annotate steps or define activities」，也就是不需要標註步驟或定義 activity，每一個 await chidori.* 本身就是一個 durable、可重播的 safepoint。
這個選擇有一個實際後果：靜態分析工具看不到你的 agent 形狀，因為它就是程式碼。你換到的是撰寫時的順手，失去的是「一眼看完整條流程」的能力。對流程複雜到需要跟非工程師溝通拓撲的團隊，這是一個真實的取捨。
另一個 README 提到的設計是結構化 prompt 快取：穩定的前綴會被自動標記給 provider 的快取使用，並舉例說在 Anthropic 上約為基礎輸入費率的 10%，而 replay 完全不付費。這個數字來自 README，我沒有實測，實際費率仍以 provider 當下公告為準。
重播很強，但重播不是萬能
最需要說清楚的限制是：replay 重現的是被記錄下來的 host call，不是外部世界。當你對著 call log 重跑，LLM、工具與 HTTP 都回傳當時的結果，所以輸出相同、零 token。但這也意味著 replay 不會告訴你「如果當時模型回了別的東西會怎樣」。想測這條路徑，你得換一份 call log 或改寫紀錄。
第二個限制來自確定性 policy 本身。固定時鐘與種子化隨機是讓 replay 成立的前提，如果你的 agent 邏輯依賴真實時間戳或真實亂數去做決策，這部分在 replay 環境下的行為與實際執行不同。這不是 bug，是設計上的必然，但要在寫程式時就意識到。
第三個限制是適用範圍。README 的敘事圍繞長時間、多步、可能中斷的流程。如果一個 agent 只是一次問答、幾秒結束、失敗了直接重跑也不痛，那 host call 邊界帶來的約束（不能直接碰世界，所有副作用都要走 runtime）換不到什麼東西。
最後，README 這一版沒有交代 checkpoint 的儲存格式、大小上限、清理策略，也沒有談多個 run 並行時的資源行為。這些是評估長期使用時必須自己去文件或原始碼確認的部分，材料裡沒有答案，我不會替它補。
和一般 agent 框架的差別在哪一條線上
多數 agent 框架把 durability 當成外掛：你要嘛在節點上標註哪些步驟需要持久化，要嘛另外定義 activity，要嘛接受「crash 就重跑整條鏈」的預設行為。Chidori 的差別在於它不提供這個選項，durability 是預設，因為所有副作用都必須經過 host call。
拿 Temporal 這類 durable execution 系統來比會更清楚，雖然 README 沒有直接點名。這一類系統的核心也是把副作用記錄下來以便重播，概念上同源；差別在於 Chidori 把 LLM 與工具呼叫當成第一級的原語，內建結構化 prompt 快取，並且用一個內嵌 JavaScript 引擎的 Rust binary 執行你的 TypeScript，不需要額外的 worker 或 service 部署。反過來說，Temporal 那一側累積的營運經驗、多語言 SDK 廣度與既有生態，是 Chidori 這份材料看不出來的部分。
如果你要的只是把 LLM 呼叫包一層 retry 與 logging，市面上更輕的工具就夠了。Chidori 的價值出現在「這個流程不能重跑」的時候，例如已經送出外部訂單、已經寄出通知、已經改動了第三方系統的狀態。那時你能從 checkpoint 續跑，而不是從頭再來一次。
授權、維護與升級成本
授權是 Apache-2.0。這是一個寬鬆授權，允許商業使用與修改，通常也包含專利授權條款，但我不提供法律意見，實際條文與你所在組織的合規要求仍需自行確認。README 沒有提到任何額外的商業授權或 enterprise 版本。
維護面可以觀察到的訊號：repo 未封存，預設分支為 main，最近一次 push 是 2026-09-10，最近三個版本是 v3.8.1（2026-08-30）、v3.7.0（2026-07-29）、v3.6.0（2026-07-07）。從版本節奏來看，大約每月一個 minor，屬於還在演進的階段。這對升級成本有直接影響：minor 版本之間 API 是否穩定，這份材料沒有給出任何相容性承諾或 deprecation policy，導入前應該先看 CHANGELOG 或 release notes 的實際內容。
安裝層面的維護成本相對低。runtime 是一顆自帶 JavaScript 引擎的 binary，沒有 Node 或 Python 執行環境要跟著升級；從 crates.io 安裝則需要 stable Rust 1.95 以上。SDK 是 npm 與 PyPI 上的薄客戶端，版本要與 runtime 對齊，這是升級時要多注意一處的地方。
至於長期維運，checkpoint 會落磁碟、call log 會累積，README 沒有說明保留策略或清理方式。這部分在正式上線前必須自己量測與規劃，不能從這份材料推論。
編輯結論
如果你要的是長時間執行、需要人工中途放行、而且除錯時不想重複付 token 的 agent，Chidori 的 host call 邊界正好對上這個需求，值得先用官方 install.sh 裝好 runtime，再照 examples/ 跑一次含 chidori.input() 的流程，確認暫停後能在新 process 續跑。如果你的 agent 只是一次性問答、或你已經把工作流綁在既有的圖形化編排器上，導入 Chidori 等於要重寫控制流，並不划算。動手前先確認三件事：你的 LLM provider 是否支援其結構化 prompt 快取所要的穩定前綴、你需要的訊號名稱在 docs/signals.md 中是否已有定義、以及 replay 時固定時鐘與種子隨機性會不會與你依賴外部時間的程式碼衝突。
社群筆記