每当你想给后端加一个新能力，就要交一次"集成税"。
想要队列？选供应商、写适配器、配重试。想要可观测性？又一个 SDK、又一个配置、又是一套和其他系统毫不关联的 traces。Agent 需要单独的重试模型、单独的超时配置、一个和现有服务毫无关系的部署流程。
一个中型后端有了队列、cron、HTTP 层、状态存储和 Agent 之后，每一项都是和其他系统手动对接的。它们不共享 trace 格式、不共享重试语义、无法直接互调函数。整个栈靠定制胶水粘在一起。
iii 的赌注是：这是架构问题，不是运维问题。答案不是更好的集成，而是让集成从一开始就不需要。
点对点集成的平方复杂度
传统后端架构是星型辐射：Service A 通过专用 HTTP Client 调用 Service B，Service B 发布到队列，Service C 订阅这个队列，Service D 写指标到一个其他服务都读不了的可观测性平台。
每新增一个服务，就要和所有现有服务都新建一套集成。复杂度不是线性增长，是服务数量的平方。五服务栈可能有十个集成，二十服务栈就快两百个了。
大多数团队不会在某一天集中感受到这个危机。它表现为持续的摩擦：一个新工具接上来要好几周，Agent 需要单独的编排 harness，某个依赖改了接口测试就挂了，没人能端到端追踪一个请求因为 traces 分散在五个不同系统里。
iii 的主张是：集成面本身就是问题所在，不是任何一个具体的集成。
共享运行时：让所有服务都变成同一种东西
iii 引入了一个单一引擎，每个服务通过 WebSocket 连接上来。一旦连接，任何服务都可以调用任何其他连接的命名函数，不管它用什么语言、部署在哪里、跑在什么环境里。
新增一个服务不产生 N 个新集成，只产生一个新的 WebSocket 连接，所有已经连接的服务立刻可以触达它。路由、序列化、交付全部由引擎处理。
效果对比：
不用 iii：供应商评估 → 采购 → 每个需要发布/消费的服务写适配器代码 → 各自配重试 → 各自配超时 → traces 无法关联 → 几周过去了。
用 iii：
iii worker add queue
队列 worker 加入引擎的实时目录，所有其他 worker 立刻可以调用它的函数。Traces 自动关联。没有任何现有服务需要写新的集成代码。
同样的模式适用于可观测性、HTTP 路由、状态管理、cron。
三个原语：Workers、Functions、Triggers
Workers：任何向引擎注册自己的进程。TypeScript API 服务是 worker，Python ML 管道是 worker，Rust 微服务是 worker，AI Agent 也是 worker。Worker 跑在哪里都可以——本地机器、Docker、Kubernetes Pod、远程服务器，引擎只关心它是否连接着。
Functions：带稳定命名空间标识符的工作单元：math::add、orders::validate、content::classify。一个函数接收 payload，执行工作，可选地返回输出。任何其他 worker 通过这个标识符调用它，不管实际实现用的是哪种语言。TypeScript worker 调用 math::add，不需要知道这个函数跑在一个 Python worker 里——它通过引擎调用名字，拿回结果。
Triggers：触发函数运行的任何东西。Trigger 类型包括直接函数调用、HTTP 端点、cron 定时、队列订阅、状态变更、流事件。Trigger 是声明式的：拥有函数的 worker 说"这个函数在这个事情发生时运行"，引擎处理路由和交付。同一个 handler 可以同时挂在多个 trigger 类型上，handler 逻辑无需任何改动。
Agent 不再是旁观者
这是 iii 对 AI 工程师最值得关注的点：在 iii 里，Agent 只是另一个 worker。
在大多数 AI 产品架构里，Agent 是客户端。它通过一个单独的 tool-call 接口调用外部工具，用单独的格式生成 traces，通过一个单独的流程部署。它坐在系统旁边，不是系统里面。
在 iii 里，Agent 向引擎注册，发现函数目录，用和 TypeScript 服务完全一样的方式调用函数。它生成的 trace 和其他所有 trace 是同一格式。没有单独的 Agent 运行时，没有单独的编排层。
当 Agent 需要一个还不存在的功能时，它可以在运行时添加：
iii worker add sandbox
新 worker 加入实时目录。Agent 下一行就能调用它的函数。不需要部署周期，不需要停机，不需要人工干预。
repo 自带 AGENTS.md 和 skills/ 目录，LLM Agent 可以原生消费 iii 的参考文档。安装只需 npx skills add iii-hq/iii/skills，Agent 就能在没有单独 onboarding 的情况下开始组合 workers。
这就是 iii 打破的那堵墙："Agent"和"Agent 操作的系统"之间的边界。
技术细节
Engine 74.8% Rust，按语言统计是绝对主力。SDK 是薄连接器，不是框架——所有路由、序列化、状态、可观测性逻辑都在 engine 里，SDK 只负责注册 worker 和触发事件。
现状：
- ✅ 1694 次 commits，225 个 releases，v0.16.1（2026 年 5 月 29 日），生产级别活跃度
- ✅ 架构简洁有力，三个原语覆盖了原本需要一整套中间件才能解决的所有场景
- ⚠️ Worker 注册表是主要开放问题：共享运行时模型在有大量预建 workers 可用时价值最大。Catalog 在增长但仍然早期，框架架构领先于生态系统
- ⚠️ 失败语义文档缺失：Worker 断连时正在执行中的函数调用会发生什么？Trigger 的投递保证是什么？跨 worker 调用的重试语义？原语干净，失败模式文档需要补上才能支撑严肃的生产级采用
- ⚠️ 规模特性未公开：引擎在数千 workers 下的扩展性、跨 worker 调用的延迟特性、多区域部署、状态一致性——这些问题在生产级采纳前需要直接测试
许可证：SDK、console、docs 是 Apache 2.0，完全开源无限制。Engine runtime 是 Elastic License 2.0——可以自由用于构建产品，但不能把 iii 的引擎作为托管服务提供给他人。如果你在这上面做基础设施，这层要注意。
iii 的核心命题：把服务、基础设施和 Agent 都当成同一个运行时里的对等节点。这不是优化，是范式转移。框架架构已经到位，挑战在于建立一个足够大的生态，让这个模型难以被忽视。