iii 调研：把队列、定时任务、HTTP、状态、Agent 统一到同一套实时运行时

如果你的后端服务是由“新需求就加一个新集成”堆出来的—— observability 一套 SDK、队列一套 client、定时任务一套 scheduler、状态管理一套 store——那你应该看看 iii。

它的目标不是再给你一个更好的消息队列，也不是再做一个新的 Agent 框架，而是把 服务发现、函数调用、触发路由、实时可观测 全部收束到同一个 live system surface 里。用 README 里的原话讲：

iii is the easiest way to compose, extend, and observe every service in your stack in real time.

1. 它解决什么问题

现代后端最常见的结构性债务，是 每一类能力都自带一套集成协议：

每加一种能力，就多一套“接入故事”。平台团队累，应用团队也累。

iii 的做法是引入一个 共享运行时，所有能力都以 Worker 的形式接入，统一用 Function + Trigger 描述，统一由 engine 路由、序列化和追踪。

结果是：iii worker add queue 和 iii worker add observability 之后，它就已经在系统里、可追踪、可调用了。

2. 项目画像

3. 核心架构：三个原语，一套系统

iii 的 mental model 极小，只有三样东西：

Worker

进程级实体，向 iii engine 注册自己。
一个 TypeScript API service 是 worker，一个 Python 数据管道是 worker，一个 Rust microservice 也是 worker。Worker 还能在运行时创建其他 worker，所以 Agent 可以动态扩展系统。

Function

稳定的工作单元，有唯一标识，例如 content::classify、orders::validate。接收输入、执行逻辑、可选返回输出。Function 存在于 Worker 里。

Trigger

任何能让 Function 运行的东西：直接调用、HTTP endpoint、cron schedule、queue subscription、state change、stream event……Trigger 是声明式的：Worker 说“这个 function 在这个事件发生时运行”，iii 负责路由、序列化和投递。

把服务能做的所有事情映射成 Worker / Function / Trigger 之后，系统就同时做到了两件事： effortlessly composable + completely observable。

4. 四语言 SDK：不只是 Rust 玩具

iii 不是只有 Rust 可用。官方 SDK 覆盖四语言：

这意味着你可以在同一个 iii 系统里混合部署 TS API service + Python 数据管道 + Rust 微服务，它们共享同一个 catalog、同一套 function calling、同一份 trace。

5. Agent 故事：不是“调用工具”，是“扩展系统”

很多 Agent 框架里的 tool calling 是静态的：你在 config 里声明一组 tool，Agent 只能调用这些。

iii 的思路不同：当任务需要系统里没有的能力时，Agent 可以 add a worker，然后 discover 它的 functions，调用它们，并查看 trace。跟开发者用的接口完全一致。

这意味着 Agent 不只是“调用现有服务”，而是 运行时动态扩展系统。你的 Agent 可以根据当前任务，现场拉入一个 queue worker、一个 sandbox worker、一个 database worker，然后立刻使用。

README 里也明确把这套能力叫做 Agent Skills：

npx skills add iii-hq/iii/skills
npx skills add iii-hq/workers --list
npx skills add iii-hq/workers --skill database

6. Console：实时看见整个系统

iii 自带一个 iii-console（React + Rust），可以实时 inspect：

• Workers 状态
• Functions / Triggers
• Queues
• Traces
• Logs
• Real-time state

对飞熊这种技术品牌定位的人，iii-console 是一个很好的 演示资产：你可以现场展示“加一个 worker 之后，系统实时可见、可追踪、可调用”，比 PPT 有说服力得多。

7. 与同类项目的定位差异

关键区别：iii 不把自己定位成“又一个 workflow engine”或“又一个 Agent framework”。它是一个 让所有服务共享同一份实时视图的可组合运行时。Agent 只是其中一个接入层，不是唯一目标。

8. 适用场景与边界

最适合

• 多服务团队：TS API + Python pipeline + Rust worker 混跑，希望统一观测和调用
• Agent 系统搭建：希望 Agent 能按需动态扩展能力，而不是依赖静态 tool config
• 平台工程：想给应用团队提供“开箱即用”的 queue / cron / state / observability
• 技术演示：需要直观展示“服务实时可组合、可追踪”的场景

需要留意的边界

1. License 分层：engine 是 Elastic License 2.0，不是宽松 Apache/MIT。如果你要基于 engine 做二次分发或 SaaS，需要仔细看 ELv2 限制
2. 学习曲线：Worker / Function / Trigger 三原语虽小，但背后是完整 runtime 概念，需要理解“共享引擎”的模型
3. 生态早期：workers 市场还在增长（workers.iii.dev 已有多类 worker），但成熟度不及 Temporal / Dapr
4. 国内资料稀缺：目前主要是英文生态，中文社区刚刚起步

9. 为什么它值得飞熊关注

iii 背后有一个更适合技术品牌讲清楚的故事：AI 工程化的下一站不是“更大的模型”，而是“更好的运行时”。

飞熊的核心能力是技术咨询和重点项目。如果客户已经在用 Claude Code / OpenClaw / Cursor，你需要的不是又一个“记忆层”或又一个“Agent 框架”，而是一个 能让所有服务、所有 Agent、所有工具共享同一份实时视图的运行时。iii 刚好在这个交叉点上。

再加上它的四语言 SDK、Agent Skills、实时 Console、Docker 一键部署，足够支撑一场 30 分钟的技术演示，也足够写成一篇文章。

10. 总结

如果你受够了“每加一种能力就多一套集成”，iii 值得认真看一次。它不是银弹，但它是目前 服务实时可组合 + Agent 可扩展 这条路上最干净的原语设计之一。

项目地址：https://github.com/iii-hq/iii

官网：https://iii.dev

Worker 市场：https://workers.iii.dev