MCP

Archestra 企业 AI 平台：适合谁与第一次 Docker 启动指南

想在自托管环境统一承接 MCP 接入的团队，适合先用 Archestra 的 Docker quickstart 试一次；但启动命令会挂载宿主机 /var/run/docker.sock 并写入本地数据卷，archestra/platform:latest 通常运行 release candidate，试之前先接受这两点。

官方来源 · Archestra

安装

docker pull archestra/platform:latest

docker run \
  -p 127.0.0.1:9000:9000 -p 127.0.0.1:3000:3000 \
  -e ARCHESTRA_QUICKSTART=true \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v archestra-postgres-data:/var/lib/postgresql/data \
  -v archestra-app-data:/app/data \
  archestra/platform:latest

适合谁

  • 官方定位是「一体化开源企业 AI 平台」：同时承担 MCP registry、gateway 与 orchestrator，而不是单一用途的 MCP server。适合的形态是：团队在自己机器上自托管一套平台，把用户、agent 以及 Claude / Codex / Cursor 客户端统一指向同一个 URL，工具调用由平台统一承接，客户端只认一个入口。
  • 它的 MCP gateway 采用 OAuth + On-Behalf-Of，让工具以用户本人身份执行，而不是共享服务账号；在意每次调用归属到人的团队是明确受益者。
  • 判断口径：如果你的问题只是「某个客户端缺一个工具」，先去找单个 MCP server 就够了；要统一管理多个服务、多个客户端、多种身份时，才轮到平台层。
  • 适合的环境：本机或内网可跑 Docker，且愿意评估套接字挂载代价的团队；quickstart 把端口绑在回环地址，适合先在单机试，确认能接受副作用后再长期跑。
  • 运行前提：本机要有 Docker。证据没有给出最低资源配置、支持的操作系统范围，也没有提 Docker 以外的运行方式，这些尚未确认。

3 分钟完成第一次尝试

  • 动作前先确认你接受两个官方明示的副作用：其一，命令会挂载宿主机的 /var/run/docker.sock，容器因此可以操控宿主机的 Docker 守护进程；其二，镜像的 latest 标签指向最新的 release，通常运行的是 release candidate。这两点写在官方说明里，评估时就要算进去，不是部署后才处理的细节。
  • 首次启动也不是只读操作：命名卷 archestra-postgres-data 与 archestra-app-data 会把数据库数据和应用数据写进本机 Docker 卷；官方没有给出对应的清理或撤销命令，重复实验之间旧数据是否影响新启动，证据也未说明，别在存有重要数据的宿主机上随手试。
  • 接受后再执行官方快速启动命令：
docker pull archestra/platform:latest

docker run \
  -p 127.0.0.1:9000:9000 -p 127.0.0.1:3000:3000 \
  -e ARCHESTRA_QUICKSTART=true \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v archestra-postgres-data:/var/lib/postgresql/data \
  -v archestra-app-data:/app/data \
  archestra/platform:latest
  • 成功信号能确认到这一层：容器保持运行，两个端口只绑定在 127.0.0.1 的本机回环地址；quickstart 明确要求的配置就是 ARCHESTRA_QUICKSTART=true 加这组端口与挂载。端口只绑在回环地址，默认只有本机能访问；远程接入要怎么配，证据未提及。
  • 下一步是把 Claude / Codex / Cursor 指向这一个 URL；URL 的具体取值命令里没有包含，要等平台启动后从平台侧确认。首次登录怎么完成，同样证据未提及。

使用案例

  • 案例一：多客户端统一入口。场景：团队里同时有人用 Claude、Codex 与 Cursor，不想为每个客户端分别接入 MCP。做法：按上文快速启动平台，把客户端指向 Archestra 的同一个 URL。可期待：工具调用经 MCP gateway 按用户本人身份执行，同一套工具在三个客户端走同一个入口。边界：平台侧具体能接哪些服务，证据没有给出清单，接入前先确认你要用的服务在其中。
  • 案例二：不落共享服务账号。场景：团队不接受所有工具调用都记在一个共享服务账号名下。用的是 gateway 的同一套身份机制。做法：接入后核对工具是否以用户本人身份运行；如果现在用共享账号跑自动化，可以先后对比。能确认到的：官方口径即如此；账号配置界面与调用日志长什么样，证据没有提到，不要预设它们存在。
  • 两个案例的差别：案例一验证入口统一，案例二验证身份归属，可以先后各试一次。

使用边界

  • 读写性质：首次启动即写入本地状态（两个命名卷）；套接字挂载让容器具备操控宿主机容器的能力，这是最重的副作用，评估时要单独考虑。
  • 凭证与身份：gateway 依赖 OAuth，提供方如何配置、是否必须先接入身份源，证据未说明，尚未确认。
  • 客户端与平台的关系：官方口径是让用户、agent 或客户端指向一个 URL，其余由平台承接；各客户端需要什么版本或插件，证据未提及。
  • 版本边界：官方口径是生产部署应固定确切版本标签，latest 通常对应 release candidate，不要拿它直接承担正式负载。
  • 动作顺序：先接受套接字挂载与版本两件事，再执行命令；首试优先在本机回环环境完成，不要直接对公网开放。
  • 尚未确认的关键信息：资源占用、升级与回滚步骤、数据备份方式、平台内各 MCP 工具的读写声明、初始凭证策略，证据均未覆盖；首试环境不要放入真实数据。没有找到说明不等于没有风险，结论以官方文档为准。