从 Motia 到 iii：把 API、事件、后台任务与 AI Agent 统一成一套原语
阅读时间: 大约 11 分钟
从 Motia 到 iii：把 API、事件、后台任务与 AI Agent 统一成一套原语
Koala 科技周报里曾介绍过一个叫 Motia 的后端框架：用「Step」作为核心概念，把 API、后台任务、事件和 AI Agent 揉进同一个事件驱动工作流。但当我们按项目库给出的地址 github.com/MotiaDev/motia 回访时，发现它已经重定向到了 github.com/iii-hq/iii——也就是说，这个项目已经从 Motia 演进 / 更名为 iii。本文以当前线上仓库的一手 README 为准，分析它今天到底是什么，以及相对当初的「Step」叙事有哪些变化。
一、它想消灭的东西：每个 concerns 一套集成
iii 的自我概括是一个缩写 CODER：实时地 compose（编排）、observe（观测）、discover（发现）、extend（扩展）、react（响应）你技术栈里的每一个服务。它点出的痛点很真实：每个后端在写第一行业务逻辑之前，往往就要先解决队列、定时任务（cron）、HTTP、状态、可观测、Agent、沙箱——而这些东西过去每一样都带来一套独立的集成故事。
iii 给出的范式是「一个 live system surface（实时系统界面）」：用 iii compose --namespace dev --up 启动，再用 iii trigger -n dev compose::add worker=queue（或 worker=agent、任意 worker）动态把 worker 加进来。每个 worker 加入一个「实时目录（live catalog）」，其他 worker 立刻被通知并可以直接调用它；可用 worker 还能在 workers.iii.dev 浏览。Agent 的故事也是同一套：当某个任务需要系统尚不具备的能力时，Agent 可以自己加一个 worker、发现它的函数、调用它、并追踪全过程——用的是和开发者完全相同的接口。
二、三个原语：Workers、Triggers、Functions
iii 把一切服务能力映射到三个原语上：
- Worker（工作者）：向 iii 引擎注册、并随后注册 trigger 与 function 的进程。一个 TypeScript API 服务是 worker，一个 Python 数据管道是 worker，一个 Rust 微服务也是 worker——用几行代码就能把任意功能变成 worker。Compose 还能在运行时新增 worker，因此 Agent 与应用可以在系统运行中持续扩展它。
- Trigger（触发器）：任何能让 function 跑起来的东西——直接函数调用、HTTP 端点、cron 调度、队列订阅、状态变更、流事件……它是声明式的：由 Worker 声明「这个函数在这个事件发生时运行」，iii 负责路由、序列化与投递。
- Function（函数）：带稳定标识（如
content::classify、orders::validate）的工作单元，接收输入、干活、可选地返回输出。Function 存在于 Worker 内部。
这套「Worker / Trigger / Function」与旧 Motia 宣传的「Step」在思想上一脉相承（都是把后端逻辑拆成可组合、可观测的小单元），但表达更贴近「服务目录 + 声明式触发」，并且不再局限于 JS/TS/Python，而是以多语言 worker 的方式组织。
三、多语言 SDK、Agent Skills 与控制台
iii 提供四种语言的 SDK：Node.js（iii-sdk）、Python（iii-sdk）、Rust（Cargo.toml）、Go（go get .../iii）。引擎本身用 Rust 编写（engine/ 目录），控制台（console/）是 React + Rust。
值得注意的是它把「Agent 可读」做成了一等公民：
- 对第三方 harness，可以用
npx skills add iii-hq/iii/skills安装覆盖所有原语（HTTP 端点、队列、cron、状态、流、自定义 trigger）的技能包； iii-hq/workers仓库里每个 worker 自带一个 skill，可按库安装（--skill database）或全量安装（--all）；- 引擎自带 worker（configuration、iii-worker-manager、iii-http-functions、iii-stream、iii-sandbox）与引擎函数、遥测、可观测 worker 都在主仓库里；而 HTTP、cron、queue、state、pubsub、bridge 是独立的 Compose worker。
iii-console 则是一个面向开发与运维的控制台，用来查看 worker、function、trigger、队列、trace、日志与实时状态——这正好补上了「可观测」这块拼图。
四、许可：引擎不是 OSI 开源，要特别注意
README 的许可证表格是落地前必须看清楚的：
| 目录 | 许可证 |
|---|---|
| engine/（引擎运行时） | Elastic License 2.0（ELv2） |
| sdk/、CLI、console/、docs/、website/ | Apache License 2.0 |
也就是说，SDK 与工具链是宽松的 Apache-2.0，但核心引擎采用 ELv2——这是一种「源码可见（source-available）」而非 OSI 认证开源的许可证，其典型约束是禁止把引擎本身作为对外托管服务（hosted offering）转售。对自部署、内部使用没有影响；但如果你想基于 iii 引擎做一个商业化的「后端即服务」，需要先读懂 ELv2 的限制。这一点和 Koala 当初把它描述为通用开源框架时没有强调，选型时不能忽略。
五、口径与局限
- 项目非常年轻、变动快：仓库提交活跃到「数小时前」，同时有 35 个 open Issue、52 个 open PR，说明它仍在快速迭代，API 与原语语义可能未稳定；
- Motia → iii 的更名：意味着网上关于「Motia」的旧文档、博客、教程可能描述的是「Step」旧概念，与当前 Workers/Triggers/Functions 模型对不上，引用旧资料时要留心版本；
- 「统一一切」是雄心也是风险：把 HTTP、队列、cron、状态、流、沙箱全收进一个引擎，能力大但学习曲线与排障复杂度也随之上升，简单服务用它可能是杀鸡用牛刀；
- 可核对数字有限：README 没有给出吞吐、延迟、规模等实测基准，「real-time」「effortlessly」属于营销措辞，不宜当作性能结论。
六、适用与不适用
适合：
- 想在一个系统里同时跑 HTTP 服务、定时任务、队列消费、事件流、AI Agent，且希望它们天然可观测、可互相调用的团队；
- 多语言技术栈（TS / Python / Rust / Go 混合）、希望用统一原语而非为每种 concern 各搭一套基础设施的平台团队；
- 想让 Agent 在运行时动态接入新能力、并全程留 trace 的场景。
不适合：
- 只需要一个简单 Web 框架 / 一个队列的小项目——引入整套引擎是过度设计；
- 想把引擎本身做成商业托管服务的团队——ELv2 有约束；
- 追求生产成熟度、要求 API 长期稳定的关键系统——目前它更像快速演进的早期项目。
七、它意味着什么
从 Motia 到 iii 的演变，代表了后端框架一个清晰的方向：不再区分「这是 API、那是队列、那是定时任务、那是 Agent」，而是把它们统一成「注册到同一目录、由声明式 trigger 触发、彼此可发现可调用、全程可观测」的函数单元。这与 Agent 时代「能力要能被动态组合、被 Agent 调用」的需求高度吻合。对开发者而言，它是一个理念先进、值得关注的新范式；但在押注生产之前，务必确认它的 ELv2 引擎许可与早期 API 稳定性是否匹配你的场景。