OctoBus：给 AI Agent 用的企业 API 内部总线

一句话场景

安全团队想让 AI 助手能查 WAF 日志、查资产、提工单——但 Agent 直接拿到 30 个内部系统的 API 凭证，等于把整个内网交出去。OctoBus 的解法是：所有内部 API 收进一个本地网关，Agent 只能看到"按场景授权的能力集"（capset），而不是原始接口。

项目背景

OctoBus 来自长亭科技（chaitin），2025 年 12 月建仓，目前 210 星、94 fork，采用 GPL-3.0。项目定位是"本地运行的单二进制网关"，管理可插拔的 Node.js 服务包，并把这些服务里的 gRPC 能力按 capset 暴露给客户端或 Agent。

star 数不算最高，但 fork 数（94）接近 star 的一半，services/ 目录下堆了 170+ 个真实企业服务适配——奇安信、腾讯云、火绒、阿里云、Fortinet、F5、深信服、腾讯云安全、阿里云 WAF……这个密度说明它不是 demo，是有人在真用的东西。

类比理解

把它想成"Agent 时代的 API 网关 + PAM"。传统 API 网关管的是流量；OctoBus 管的是"哪个 Agent、在什么场景下、能调哪个服务的哪个方法"。传统堡垒机管的是"谁能登录这台机器"；OctoBus 管的是"这个 Agent 能拿到哪几把 API 钥匙"。

核心模型

项目定义了四层概念，理解了就理解了全部：

• service：可导入 Node.js 包里的一个服务根目录，含 service.json、proto 文件和 gRPC 实现。一个发行包可通过 //service-dir 暴露多个服务根。
• instance：服务的一个运行时实例，独立配置与工作目录，常驻实例还有日志和本地监听端口。
• capset：给某个 Agent 或场景用的确定性能力集，由 capset → service → instance → method 绑定组成。
• method binding：capset 里实际暴露的 gRPC 方法。

关键设计是协议三合一：同一个 unary 方法可以通过 gRPC、Connect RPC、MCP streamable HTTP 三种方式调用；streaming 方法只支持 gRPC。默认所有端口都收在 127.0.0.1:9000——admin API、gRPC、Connect RPC、MCP、reflection 全在一个端口上。

运行时模式

• long-running（默认）：实例启动后常驻一个 Node.js gRPC 子进程。
• on-demand：不预启动，每个请求起一个短命 invoke 子进程。
• scale-to-zero：保留一个温热的 serve 子进程，首次请求启动（并发首次请求共享一次启动），空闲超过 OCTOBUS_SCALE_TO_ZERO_IDLE_TTL（默认 15 分钟）后停放，温池上限 OCTOBUS_SCALE_TO_ZERO_MAX_INSTANCES（默认 32，淘汰最久未用）。这是为云上场景省成本设计的。

daemon 每 5 分钟（OCTOBUS_RECONCILE_INTERVAL）对账真实进程与存储状态：Linux 上通过读 /proc 归因并杀掉泄漏的 serve 进程，其他平台修复陈旧行并重启意外死亡的常驻实例。

安全加固

这是 OctoBus 最有分量的部分。--runtime-hardening=node 开启后，每个服务运行时：

• 只拿到环境变量白名单（PATH、LANG、LC_ALL、TZ、代理与 CA 设置，Windows 另有 SystemRoot/PATHEXT/COMSPEC）加 OCTOBUS_* 上下文，其他变量和已有的 NODE_OPTIONS 全部丢弃；
• HOME、USERPROFILE、临时目录变量指向实例自己的目录；
• 在 Node.js 权限模型下运行——能读自己的服务产物、读写自己的实例目录，但读不到 octobus.db 和别的实例，不能起子进程、不能用 worker thread、不能加载原生插件；
• 拒绝拨向 loopback、link-local、unspecified、云元数据地址、本机地址和 unix socket 路径；它 patch 了 dns.lookup、fetch、net.connect、net.Socket.prototype.connect，每次重定向都重新判定；
• V8 老生代堆上限 512MB，独立进程组（停实例连带停它起的进程）。

限制也很直白：Node 权限模型是 Node 自己执行的而非操作系统强制，且 Node 会跟随指向授权目录外的符号链接——只防误操作，不防恶意代码。而且 service import 仍会以 daemon 环境运行 npm（含生命周期脚本）。

上手门槛

有三条路径，最快的是 npm：npm install -g @chaitin-ai/octobus && octobus serve --dev，npm 包通过平台相关的可选依赖（@chaitin-ai/octobus-linux-x64 等）拉取对应原生 Go 二进制。也可以 npx @chaitin-ai/octobus serve --dev。Docker 镜像 ghcr.io/chaitin/octobus:latest 基于 ubuntu:26.04，非 root 用户 octobus，默认监听 0.0.0.0:9000，状态存 /var/lib/octobus。源码构建用 task build。

依赖硬性要求：node、npm、protoc、git 必须在 PATH 上——node 跑服务、npm 装依赖、protoc 编译 proto 描述符、git 拉取 HTTPS Git 源服务包。--runtime-hardening=node 还要求 Node.js 22.13+/23.5+/24+，且版本管理器 shim（Volta、asdf）会因需要白名单外变量而启动失败。

争议与局限

GPL-3.0 是企业采用的最大障碍——内部工具网关上动静态链接，公有云厂商多半需要走法务。默认监听 loopback 是安全的，但 README 直说"远程暴露 OctoBus 时网络访问控制由你自己负责"——它把边界划得很清楚，可也意味着裸暴露风险由用户承担。

--runtime-hardening=node 的限制条件苛刻：需要子进程、worker thread 或原生插件的服务在这一层直接跑不起来。scale-to-zero 的温池机制在多实例场景下资源占用需要自己调参。170+ 个服务适配的维护成本也随时间线性上升。

行业意义

OctoBus 代表了 MCP 生态里一条务实但少人走的路：不把 Agent 直接连到企业系统，而是在中间加一层受控的、确定性的、可审计的能力授予层。MCP 解决的是"Agent 怎么调工具"，OctoBus 解决的是"企业凭什么让 Agent 调这个工具"。随着 Agent 从 demo 走向企业生产，这道门槛迟早要被跨过——长亭用 170+ 个真实服务适配给出了自己的答案。