OctoBus 本地智能体网关

这个 Agent 能做什么，适合哪些场景？

OctoBus 是长亭科技开源的一个本地运行的单二进制网关（Go 编写的 `octobus` 程序），用于管理可插拔的 Node.js 服务包，并按 capset（能力集）将包内 gRPC 能力暴露给客户端或智能体。守护进程默认监听 `127.0.0.1:9000`，同一端口分发本地管理 API、gRPC、Connect RPC、MCP 流式 HTTP 与 gRPC reflection。核心模型由四层组成：service（含 service.、proto 和 gRPC 实现的 Node.js 服务包）、instance（带独立配置与工作目录的运行实例）、capset（面向智能体或场景的确定性能力集合）、method binding（capset 内实际暴露的 gRPC 方法）。服务包默认以 long-running 模式由守护进程托管为常驻 Node.js gRPC 子进程，也可声明 on-demand 模式按请求启动一次性 `invoke` 子进程。状态存储在 SQLite 中，访问日志以 NDJSON 写入 data 目录下 0600 权限的 access.log，且不记录请求体、密钥或业务元数据。项目以 GPL-3.0 许可发布，可通过 npm、Docker 或源码构建部署。

OctoBus 的守护进程启动本地控制面与数据面，并通过 octobus CLI 管理服务、实例和 capset。导入服务包（octobus service import calculator ./examples/calculator-js）时，它获取并解包 npm/本地目录/Git/HTTP 归档来源，用 protoc 编译 proto 描述符，准备运行目录；service. 支持多种来源并可用 //service-dir 选择包内服务根，--recursive 可批量导入多服务包。创建实例（instance create）后，long-running 模式启动常驻 Node.js gRPC 子进程并做健康检查，on-demand 模式则每请求启动一个 invoke 子进程，通过 stdin/stdout 传递 protobuf 线格式。创建 capset 并 capset add-instance 后，方法可通过三种协议调用：gRPC（保留原方法路径，用 x-octobus-capset/x-octobus-instance 元数据路由，支持四种流式）、Connect RPC（POST /capsets/{id}/connect/{instance}/{service}/{method}，仅 unary）、MCP 流式 HTTP（POST /capsets/{capset_id}/mcp，工具名默认为 {service}__{instance}__{method}）。capset 可通过 add-token 管理访问令牌（仅存哈希，不存明文），未配置令牌时端点默认公开。配套 SDK @chaitin-ai/octobus-sdk 的 runServiceMain 处理 --runtime serve/invoke/dev 等运行时协议，OpenAPI 端点输出方法级 schema，octobus logs 按 capset/实例/服务过滤查看访问日志。

1. 企业平台工程师需要让内部 AI 智能体调用 GitLab 等内部 API，但不希望智能体直接持有系统凭证——可用 capset + 令牌按智能体粒度授权方法子集
2. 团队已有一批 Node.js 实现的内部工具脚本，想通过统一 gRPC/Connect/MCP 接口暴露给不同客户端——可将其封装为 OctoBus 服务包导入
3. 开发者在本地为 Claude 等 MCP 客户端提供受控工具集——通过 POST /capsets/{id}/mcp 流式 HTTP 端点接入
4. 安全团队要求所有智能体工具调用有审计记录——access.log 以 NDJSON 记录协议、capset、方法、状态码、耗时等且不含敏感数据
5. 运维希望低频工具不占用常驻资源——将服务包声明为 on-demand 模式，按请求启动一次性进程
6. 需要多套不同权限的工具目录给不同智能体场景——为每个 capset 用 select-method 精确控制暴露的方法集合

这个 Agent 有哪些优点和局限？

如何安装或部署这个 Agent？

三种方式：

1. npm 安装（主包通过平台特定的可选依赖拉取对应的原生 Go 二进制）：

bash

npm install -g @chaitin-ai/octobus
octobus serve

或免全局安装：npx @chaitin-ai/octobus serve

1. Docker：

bash

docker run --rm \
-p 9000:9000 \
-v octobus-data:/var/lib/octobus \
ghcr.io/chaitin/octobus:latest

容器默认监听 0.0.0.0:9000，状态存储于 /var/lib/octobus。

1. 源码构建（需要 Go 1.26.1 与 Task）：

bash

task build
./bin/octobus serve --data-dir .octobus --addr 127.0.0.1:9000

正常运行服务导入与实例启动还需在 PATH 中备有 node、npm、protoc 和 git。可用环境变量 OCTOBUS_DATA_DIR、OCTOBUS_ADDR 覆盖默认配置。

如何使用这个 Agent？

1. 启动守护进程后确认 CLI 可连接：./bin/octobus status。
2. 导入示例服务包：./bin/octobus service import calculator ./examples/calculator-js（来源支持本地目录、tgz/tar.gz/zip 归档、npm:、HTTPS Git，可加 //service-dir 选择服务根）。
3. 创建并启动实例：

bash

./bin/octobus instance create calculator-test \
--service calculator \
--config- '{"label":"primary"}' \
--secret- '{"apiToken":"dev-token"}'

1. 创建 capset 并挂载实例：

bash

./bin/octobus capset create dev --name DevAgent
./bin/octobus capset add-instance dev calculator-test
./bin/octobus catalog dev --all --

1. 调用（Connect RPC 示例）：

bash

curl -X POST \
http://127.0.0.1:9000/capsets/dev/connect/calculator-test/calculator.v1.CalculatorService/Add \
-H 'Content-Type: application/' \
-d '{"left":20,"right":22}'

MCP 调用：POST /capsets/dev/mcp，JSON-RPC 方法为 tools/list / tools/call。gRPC 调用通过 grpcurl 加 x-octobus-capset/x-octobus-instance 元数据路由。可选：capset add-token dev local --token-stdin 启用 Bearer 令牌鉴权（gRPC/reflection 用同名 metadata）；octobus logs --follow 实时查看访问日志。

这个 Agent 与同类方案有什么区别？

常见问题