Chidori：把每个副作用都变成可重放记录的 TypeScript Agent 运行时
The agent framework where every run is durable, replayable, and resumable by default.
秒懂
- 它是什么？
- Chidori 用一条 host call 边界把 LLM 调用、工具调用和 HTTP 请求全部收进调用日志，于是重放、断点续跑和挂起等待人类审批都成了默认行为。它适合把 Agent 当作长期运行的生产流程来写的人，不适合只想快速拼一个 demo 的人。
- 适合谁用？
- 如果你的 Agent 需要跨进程存活、需要在崩溃后从断点继续、需要把一次真实运行提交进 git 当作零成本集成测试，Chidori 的 host call 模型值得评估；如果你只是要在一个已有 Node 服务里加几个 LLM 调用，引入一个独立的 Rust 二进制和 HTTP SDK 只会增加部署面。上手前先确认三件事：目标平台在 install.sh 覆盖的 macOS（Apple Silicon / Intel）与 Linux（x86_64 / arm64）之列；你的 Agent 副作用确实都走 chidori.* 而不是绕过运行时直接发请求，否则调用日志不完整、重放会失真；以及从源码构建时 Rust 工具链版本满足 README 写明的 1.95 或更高。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 6 天前。
- 用什么语言写的？
- 主要是 Rust（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
Chidori 要解决的是 Agent 的不可复现，而不是编排本身
README 把痛点列得很直接：bug 出现在第三次运行之后，复现不了；每轮调试都要重新付一遍 token；多步运行中途崩溃，前面全丢；等人类审批意味着进程要挂几个小时。这四个问题里，只有第二个是钱的问题，其余三个都是状态问题。多数框架的做法是在这套混乱之上再叠一层编排，Chidori 的选择是把混乱从源头切掉。
它的目标用户是写长期运行、带真实副作用的 Agent 的工程师。判断标准很简单：如果你的 Agent 只跑几秒、失败了重跑一遍也不心疼，Chidori 提供的保证你基本用不上。反过来，如果你的 Agent 要跑几十分钟、要调付费模型、要在某个节点停下来等人点确认，那么 README 描述的那套默认行为就开始产生实际价值。
host call 是唯一的边界，也是全部机制的来源
按 README 的说法，Agent 从不直接接触外部世界。每一次 LLM 调用、工具调用和 HTTP 请求都作为一次被记录的 host call 流经运行时。这个设计的关键不在记录本身，而在于运行时因此看见了全部副作用，于是同一份调用日志可以同时支撑四种能力：日志、缓存、重放、暂停与恢复。
重放是这里最值得注意的推论。README 称调用日志是一份确定性记录，用同一份代码对着它重跑，每个 prompt、工具和 HTTP 调用都立刻返回当时记录的结果，零 token 消耗、输出逐字节一致。确定性不是靠祈祷，而是靠运行时策略强制的：固定时钟、有种子可复现的随机性。这一点区分了 Chidori 和那些把重放当作近似模拟的方案，README 明确说重放不是近似，是同一次运行。
另一个机制是结构化 prompt 缓存。README 说稳定前缀会被自动标记给 provider 缓存，在 Anthropic 上约为基础输入价格的 10%，而重放本身完全不付费。这个数字来自 README 的陈述，我没有验证过实际账单。
需要说清楚的是，这套机制成立的前提是副作用确实经过运行时。README 没有描述绕过 host call 直接发起网络请求时会发生什么，从设计上推断调用日志会缺失那部分记录，重放的一致性也就无从谈起。
安装的是一个 Rust 二进制，SDK 是可选的外壳
README 在安装一节里特意澄清了包的区分，这一点容易踩坑。你安装的 chidori 二进制是运行时；npm 上的 @1kbirds/chidori 和 PyPI 上的 chidori 是 SDK，是可选客户端，通过 HTTP 驱动运行时，不含原生绑定。换句话说，运行时不需要 Node、不需要 Deno、不需要 V8、不需要 Python，也不需要 Rust 工具链。
最快的安装路径是脚本：
curl -fsSL https://raw.githubusercontent.com/ThousandBirdsInc/chidori/main/scripts/install.sh | sh
README 说这个脚本会从最新 GitHub release 下载对应平台的二进制，放到 ~/.chidori/bin，必要时打印一行 PATH 修改提示，覆盖 macOS（Apple Silicon 与 Intel）和 Linux（x86_64 与 arm64）。装完用 chidori --version 检查。不想跑脚本的话，每个 release 页面按平台提供 tarball。
另外两条路径是 cargo install chidori（需要 1.95 或更新的稳定 Rust 工具链，二进制落在 ~/.cargo/bin）和从源码 checkout 后 cargo build --release（二进制在 ./target/release/chidori，仓库通过 rust-toolchain.toml 固定工具链，cargo 会自动读取）。从源码构建还会附带 examples/ 目录，README 的第四步会用到。
chidori.input() 与命名信号：把等待人类变成磁盘上的状态
README 里最具体的一个 API 是 chidori.input()。它和命名信号一起，把一次运行挂起到磁盘，而不是让进程挂着等。人类或者另一个 Agent 在几分钟甚至几天之后给出答复，运行从停下的位置继续。
这个设计解决的是「等审批」这类场景里的资源占用问题。常见的替代做法是轮询、是常驻 worker、是把状态塞进外部数据库再自己写恢复逻辑。Chidori 的做法是把挂起作为运行时的一等状态，恢复时先重放调用日志到暂停点，然后转入实时执行。README 说恢复可以在一个全新的进程里完成，崩溃后也一样：杀掉进程，从断点继续。
这里有一个值得留意的取舍。恢复靠的是先重放再继续，那么重放的代价就和暂停点之前的运行长度成正比。如果一次运行在暂停前已经做了大量 host call，恢复时的重放虽然不花 token，但仍然要重新执行一遍代码路径并读取日志。README 没有给出重放速度的数据，所以这一点只能在上手后自己量。
把一次真实运行提交进 git 当测试
README 提到一个用法：把记录下来的检查点提交进 git，断言 Agent 行为没有漂移。按它的说法，这是一个完整的集成测试，成本为零，运行时间是毫秒级。
这个用法之所以可行，正是因为上面那条边界。测试跑的不是 mock，是真实运行留下的调用日志，所以它检验的是代码路径是否改变，而不是某个手写桩函数是否还匹配。对于 prompt 频繁调整的 Agent 项目，这类回归测试的价值比单元测试高，因为 Agent 的行为漂移通常来自控制流或者 prompt 结构的变化，而不是某个函数的输入输出。
代价在于检查点文件本身。README 没有说明调用日志的体积、是否包含敏感内容、以及提交进 git 时该如何裁剪。把真实运行的记录放进版本库，意味着里面的 prompt 和工具返回都会长期留存，这一点在采用前需要自己确认。
它不适合的场景，以及和 Temporal、LangGraph 的差别
Chidori 的定位有一个明确的代价：你必须接受一套运行时。Agent 是普通 async TypeScript，不用图、不用 DSL，这一点听起来是自由度，但所有副作用必须走 chidori.* 才能被记录。如果你的代码库里已经有大量直接调用 SDK 的业务逻辑，把它们改造成 host call 是一项实打实的迁移工作。
和 Temporal 的差别在抽象层次。Temporal 的持久化执行建立在 workflow 与 activity 的划分上，你需要把副作用显式放进 activity，用注解和确定性约束来换取重放能力。Chidori 按 README 的说法取消了这一步：没有步骤注解，没有 activity 定义，每个 await chidori.* 本身就是一个可重放的安全点。代价是 Chidori 的持久化边界完全绑定在它自己的运行时上，而 Temporal 的 worker 可以用多种语言实现，且已经有一套成熟的运维体系。
和 LangGraph 的差别在形态。LangGraph 用图来组织 Agent 的控制流，节点和边是显式的，可视化与状态检查点围绕这张图展开。Chidori 走的是相反方向：控制流就是 TypeScript 的 if、for、try，运行时不去理解你的图，只记录你碰过的世界。对于控制流本身很复杂、分支很多的 Agent，写普通代码通常比维护一张图更省事；但如果你的团队需要从图结构里获得可读性和协作上的共识，LangGraph 的表达方式更直接。
还有一种情况 Chidori 是错的工具：你只想在现有 Node 服务里加几个 LLM 调用，没有跨进程恢复的需求。这时引入一个独立的二进制、一套 HTTP SDK 和一层 host call 约定，换来的保证你一条都用不上。
维护成本与 Apache-2.0 带来的边界
从仓库材料能确认的维护信号有限。最近一次 push 是 2026-09-10，最近的三个 release 是 v3.8.1（2026-08-30）、v3.7.0（2026-07-29）、v3.6.0（2026-07-07），大约每月一个 minor 版本。这个节奏意味着升级不是可以完全放着不管的事，尤其是在 3.x 系列内部，minor 版本之间通常会有行为调整。README 没有提供兼容性承诺或者弃用策略，所以升级前需要自己读 release notes。
许可证是 Apache-2.0。这个许可证包含专利授权条款，通常对商业使用友好，但具体到你的场景，比如是否要修改后闭源分发、是否涉及商标使用，需要你自己或法务判断，这里不给法律意见。
一个实际的部署考量：运行时是单个自包含二进制，SDK 通过 HTTP 与它通信。这简化了运行时侧的依赖，但把部署形态从「一个进程」变成了「一个进程加一个运行时服务」，网络边界、端口、进程生命周期都需要纳入你的部署配置。README 没有描述运行时的并发模型、资源上限或者多租户隔离，这些在把它放进共享环境之前需要自己验证。
上手前应该先验证什么
第一件事是平台。install.sh 覆盖 macOS（Apple Silicon 与 Intel）和 Linux（x86_64 与 arm64），README 没有提到 Windows 的原生支持。如果你的部署目标是 Windows 或者别的架构，需要先确认 release 页面是否有对应产物。
第二件事是副作用覆盖率。Chidori 的全部保证都建立在「运行时看见每一个副作用」这个前提上。拿一个你现有的 Agent，把它的 LLM 调用、工具调用和 HTTP 请求逐条对照，看有多少能落进 chidori.*。落不进去的部分就是重放会失真的地方。
第三件事是调用日志的实际形态。README 说检查点可以提交进 git，但没有说明文件大小、格式和敏感信息处理。跑一次真实的、包含外部 API 调用的运行，看看日志长什么样，再决定它能不能进版本库。
第四件事是恢复路径的实测。README 承诺可以在新进程里从崩溃点恢复，这个承诺值得亲手验一遍：起一个带 chidori.input() 的运行，杀掉进程，在新终端里恢复，确认它确实从暂停点继续而不是从头重跑。这三步做完，你对 Chidori 是否适合自己就有了答案，而不需要先读完整个文档站。
编辑结论
如果你的 Agent 需要跨进程存活、需要在崩溃后从断点继续、需要把一次真实运行提交进 git 当作零成本集成测试，Chidori 的 host call 模型值得评估；如果你只是要在一个已有 Node 服务里加几个 LLM 调用，引入一个独立的 Rust 二进制和 HTTP SDK 只会增加部署面。上手前先确认三件事：目标平台在 install.sh 覆盖的 macOS（Apple Silicon / Intel）与 Linux（x86_64 / arm64）之列；你的 Agent 副作用确实都走 chidori.* 而不是绕过运行时直接发请求，否则调用日志不完整、重放会失真；以及从源码构建时 Rust 工具链版本满足 README 写明的 1.95 或更高。
社区笔记