#一个 agentic backend 在 iii 上长什么样
Mike Piccolo（iii.dev 团队）写了一段关于如何把 agentic backend 做成 production ready 的简短文章。核心论点是：在 iii 上构建 agentic backend，等于在引擎上组合一小撮 worker。每个都 production ready，每个都可替换，组合才是你的 backend。
四个 worker 分工：
- harness ——编排 agent 的 turn loop
- context-manager ——把原始历史转换成 model-ready 的上下文
- session-manager ——类型化对话条目的持久化、响应式、可分支的存储
- llm-router ——所有 LLM provider 的统一前门
每个都是独立的，可以单独用：
- 只装 llm-router，你有了一个 provider 无关的 completion 服务
- 只装 session-manager，你有了一个响应式的对话存储
- harness 只负责串联其他三个加工具调用分发
#"加一个新服务再跟所有人集成"的范式要结束
任何真正长大的逻辑——审批门控、花费预算、多 Agent 交接——都会变成同级的 sibling worker，而不是让 harness 变复杂。
从外面看像四层，里面没有任何集成代码。harness 用 iii.trigger("context::sync") 调 context-manager，context-manager 返回后 harness 再调 llm-router，llm-router 通过 channel 流式输出。没有编排框架要配置，没有层间契约要维护，没有 service mesh 要运维。
这四个 worker 跟 queue worker、state worker、pubsub worker、observability worker、HTTP worker、sandbox worker、schedule/cron worker 跑在同一个引擎上。每个 worker 都能继承其他所有 worker 的能力，零集成成本。iii worker add <worker-name>，直接拿到完整系统面。
#范式抽象跳跃
Mike 引用了 React 的类比：React 把 UI 还原成了 Component，iii 把后端还原成了 Worker、Trigger、Function。复杂度最终都会要求抽象，这是 backend 工程的客观规律，React 当年在 UI 领域发现过同样的事。
任何你会作为一个独立服务加进去的能力，在 iii 上都可以是一个 worker。能力以 function 和 trigger 的形式暴露。
这是 iii.dev 团队观察到的模式。系统因此变得：
- Composable
- Extensible
- Discoverable
- Observable
每多一个 worker，系统的能力就上一层。
#资源
- iii 开源：iii.dev/docs
- harness workers：github.com/iii-hq/workers
- 引擎：github.com/iii-hq/iii
- 社区：discord.gg/iiidev