18,790 颗星背后：iii 想把”每加一个服务就多一层集成地狱”这件事彻底终结

18,790 颗星背后：iii 想把”每加一个服务就多一层集成地狱”这件事彻底终结

做后端服务的同学大概都懂这种感觉：系统里接了一个消息队列，要配一套消费者；接了一个定时任务框架，要再配一套重试逻辑；接了一个 AI Agent，又要配一套独立 tracing。等到服务多了，十个八个各自为政的孤岛就立在那儿，每个新来的能力都带着自己的接口、自己的配置、自己的坑。

iii（读作”eye-eye-eye”）想解决的就是这个。它目前的 Stars 是 18,790，近半年增速明显——有趋势追踪工具已经把它列进了 Rust 项目里值得关注的仓库。

它到底是什么

iii 是一个 Rust 写的运行时引擎，核心思想非常简单：用三个概念统一一切后端能力——Worker（谁提供能力）、Trigger（什么触发它）、Function（它做什么）。

Workers 是注册到 iii engine 的进程，可以是 TypeScript API、Python 数据管道、Rust 微服务，或者一个 AI Agent。Workers 一注册就进入实时目录，其他所有 Worker 立即收到通知并可以直接调用它们。

Trigger 是任何导致函数运行的外部事件——可以是直接的函数调用、HTTP 端点、Cron 定时、队列订阅、状态变更、或者流事件。Trigger 是声明式的，Worker 定义”这个函数在什么条件下运行”，iii 处理路由、序列化和投递。

Function 则是带稳定标识符的工作单元，比如 content::classify 或 orders::validate，接收输入、执行工作、返回输出。

为什么这个思路有意思

传统模式里，加一个新服务意味着手动处理与现有系统的 N 个集成点。iii 的文档里画了一张经典的图：四个服务有六条集成边，二十个服务就有一百九十条。这不是线性增长，是二次方。

iii 把这个二次方变成了常数——加两个 Worker 和加两百个 Worker 是同一个操作。

关键在于”运行时目录”这个设计。Worker 不再是独立部署的孤岛，而是向整个系统广播自己的能力。当你在 worker-compose.yaml 里声明 worker=queue 并运行 iii compose --up 之后，队列能力立刻出现在全局目录里，每个其他 Worker 都可以发现并调用它，不需要任何额外配置。

iii 官方把 compose::add 称为”系统层面的 npm 时刻”——不是安装一个库，而是添加一个完整运行的服务，立即对整个系统可用。

什么让它值得注意

多语言 SDK 完整。不是只支持一种语言，Node.js、Python、Rust、Go 都有独立 SDK，都发布在各自的主流包管理平台上。Docker 镜像也有，pull 次数已经相当可观。这意味着团队里用不同语言的开发者都能参与进来。

AI Agent 和人用同一套接口。iii 文档里有一段话值得单独摘出来：

“iii gives agents the same runtime the whole system already runs on. An agent is a worker and can, with permission, act on every part of the system through the shared system runtime. The runtime is the rest of the system.”

换句话说，Agent 不再是”调用外部工具然后拿结果”，而是和系统里其他 Worker 完全平等的存在——能注册新能力、能发现现有函数、能通过同一个 trace 链路看到所有调用记录。这个设计让 Agent 和人类的协作有了真正的共享上下文，而不是各说各话。

面向 AI 编程 Agent 的 Skills 包。iii 提供了独立的 Agent Skills（用于 Claude Code 等第三方 harness），覆盖 HTTP 端点、队列、Cron、状态、流等每一种原语。这意味着即使不用 iii 作为主引擎，也可以用它的 Skill 包让 Agent 具备与 iii 生态交互的能力。

架构上有清晰的分层。Engine（Rust，ELv2 许可证）、SDK（Node.js/Python/Rust/Go，Apache 2.0）、Console（React+Rust）、文档都是独立仓库。Engine 是闭源许可证（ELv2），但所有 SDK、工具链、文档是 Apache 2.0——这个许可结构本身值得研究。

适合谁用

平台工程团队。如果你在公司里负责维护内部基础设施，让各业务团队能快速接入共享能力，iii 的 Worker 发布模式可以直接减少你在 SDK 分发和接口维护上的工作量。

多语言后端系统。Python 数据 pipeline、Node.js API 服务、Rust 高性能模块需要互相调用，iii 提供的统一路由层比写一堆适配代码更干净。

AI Agent 集成场景。想让 Agent 能在运行时发现并调用系统能力，而不是硬编码几个工具名，iii 的设计天然适配这个需求。

不适合谁

个人小项目。iii 的核心价值在于消除集成复杂度，如果你只有两三个服务，手写适配代码更快。iii 是一个需要认真学的框架，小规模场景下收益有限。

对许可证敏感的企业。Engine 本身是 Elastic License v2（类似 SSPL），不是严格意义的开源许可证。如果你要在商业产品里用 Engine，需要确认 ELv2 的条款是否合规。SDK 和工具链是 Apache 2.0，没问题，但 Engine 本身要注意。

强依赖云厂商托管服务。iii 目前主要还是本地/私有部署风格，虽然可以跑在 Kubernetes 上，但如果你强依赖 AWS Lambda 或 Azure Functions 这样的平台，iii 的模型不一定匹配。

实际开始

安装引擎只需要一条命令：

curl -fsSL https://install.iii.dev/iii/main/install.sh | sh

然后跑 Quickstart，跟着做一个真实案例（官方有一个叫 Linkly 的实战教程）。

如果你已经在用 Claude Code 或类似的 AI 编程工具，可以试试：

npx skills add iii-hq/iii/spills

看看 Agent 能从 iii 的 Worker 目录里发现什么、调用什么——这个过程本身就能让你理解 iii 的设计意图。

项目地址：https://github.com/iii-hq/iii
Workers 目录：https://workers.iii.dev
官方文档：https://iii.dev/docs
Discord 社区：https://discord.gg/iiidev

一句话：iii 不是又一个消息队列或任务调度框架，它是这些能力的统一运行时——如果你受够了每加一个服务就要写一整套适配代码， iii 值得认真看。