Agent 调通了却上不了线？Trinity 用一容器一实例把生产运行时补齐

笔记本上把 Agent 聊通很容易，真正卡住的是下一公里：谁能触发它、它半夜干了什么、花了多少 Token、会不会把隔壁 Agent 的文件删掉、出事之后有没有可查的审计。这些问题跟「模型聪不聪明」无关，却决定 demo 能不能进生产。

Abilityai/Trinity（github.com/Abilityai/trinity，Apache-2.0）的定位很干脆：Claude Code 负责写 Agent，Trinity 负责在你自己的边界里把它跑起来。每个 Agent 独占一个 Docker 容器，带调度、可观测、委派协作与只追加审计。本文基于官方 README、docs/DEPLOYMENT.md、安装脚本与社区拆解深度改写；源微信页若抓取失败，以仓库与文档为准，不臆造能力。

一、它解决的不是「再写一个 Agent」，而是框架下面那一层

市面上的 Agent 框架、本地 harness、托管团队服务各管一段：框架帮你拼工具调用，Claude Code 帮你在本机迭代，SaaS 帮你「开箱即用」但数据出边界。Trinity 抢的是框架之下的控制面——多用户、定时触发、舰队健康、成本与审计。官方对照表写得很清楚：

这一定位决定了它的「重量」：需要 Docker 与 Docker Compose v2+，起来的是一整套栈——Vue 前端（80）、FastAPI 后端（8000）、MCP Server（8080）、Scheduler（8001）、Redis、数据库，以及日志收集（Vector，8686）。可选 OpenTelemetry Collector 做指标导出。它不是「一个二进制跑起来」的路线，更接近小型 Kubernetes + 审计系统，只是调度单位是 Agent 容器而不是 Pod。

v0.9.0（2026-08-17）把 Workspace 客户端面、远程模板注册表、多源 Skills 库、双向 A2A、自动库备份等推进了一步；版本仍在 0.x，功能长但成熟度需要你自己压测。README 声明项目通过了 UnderDefense 独立渗透测试（Grade A）——开源 Agent 平台里主动做第三方渗透的并不多。

二、硬设计：一个 Agent 一个容器，护栏写在运行时而不是提示词里

Trinity 最硬的一条承诺是：每个 Agent 跑在独立 Docker 容器里，带独立资源配额。某个 Agent 抽风，不至于把整套控制面一起拖下水；出了问题能看容器日志与执行记录，而不是只剩一句「模型好像没回」。

围着这个粒度，运行时控制项也排得很齐：

• 多 Runtime：每个 Agent 可选 Claude Code（Anthropic）、OpenAI Codex 或 Gemini CLI
• 模型可选：任务或调度可指定 Opus / Sonnet / Haiku 等
• 只读模式：保护源码不被改，只允许往指定目录写输出
• 完整能力模式：需要 apt-get、sudo 的 Agent 可单独提权
• 失控预防：max_turns 限制执行深度
• 护栏（Guardrails）：确定性安全强制，可按 Agent 覆盖
• 持久异步积压：超出并行容量的任务进 SQLite 支撑的 FIFO 队列，重启不丢

注意后几条的性格——它默认假设 Agent 会失控，然后用架构拦住。max_turns 和护栏不是提示词里写一句「请不要」，而是运行时硬限制。容器协作走三条通路：层级委派（细粒度权限）、Docker volume 共享目录、无状态并行任务（orchestrator-worker）。

控制面侧还有四层 RBAC（user < operator < creator < admin）、只追加平台审计日志（生命周期 / 认证 / MCP，管理员 API）、Operator Queue（人在环审批）、统一邮箱白名单（Web / Slack / Telegram），以及可导出到 Grafana / Datadog 的 OpenTelemetry。生产治理要的是「事后可查、不可乱改」——Trinity 至少把这条设计意图写进了产品面。

三、把实例拉起来：一键安装、无人值守与 Agent 自装

先决条件很简单：Docker + Compose v2+，外加 Anthropic 或 Google 的 API Key（看你跑哪系 Agent）。官方提供三条路径。

路径 A：一键安装脚本

curl -fsSL https://raw.githubusercontent.com/abilityai/trinity/main/install.sh | bash

脚本会 clone 仓库（默认 ~/trinity）、准备 .env、构建 Agent 基础镜像，再 docker compose up。真上服务器时务必盯一眼密钥与权限边界——「一键」省的是步骤，不是运维责任。

路径 B：手动克隆（更可控）

git clone https://github.com/abilityai/trinity.git
cd trinity
cp .env.example .env
# 交互模式：至少改 ADMIN_PASSWORD（12 位以上）
# SECRET_KEY、加密密钥、Redis 密码由 start.sh 首次生成

./scripts/deploy/build-base-image.sh
./scripts/deploy/start.sh

完全无人值守可用 ./scripts/deploy/start.sh --unattended，或设置 TRINITY_UNATTENDED=1——管理员密码会自动生成并打印在摘要末尾。

路径 C：让编码 Agent 按 runbook 装

README 提供面向 Agent 的确定性循环（docs/AGENT_INSTALL_GUIDE.md：验证 → 安装 → 确认 → 报告下一步）。你可以直接对 Claude 说：按该 runbook 在本机安装 Trinity。装完入口大致是：Web UI http://localhost，API 文档 http://localhost:8000/docs，MCP http://localhost:8080/mcp。

数据库策略很克制：默认 SQLite（/data/trinity.db），适合本地评估；生产推荐 PostgreSQL，设一个 DATABASE_URL，后端与调度器一起切换。选择非黏性：注释掉 DATABASE_URL 重启即回 SQLite。已有实例迁移可由 trinity-ops-public 的 /migrate-to-postgres skill 做校验后切流，SQLite 文件不被覆盖，回滚成本低。

远程服务器还可走 abilities 市场的 /trinity:deploy-new-instance，顺带脚手架 Ops Agent（健康检查、日志、更新、回滚、库迁移）。

四、实例起来之后：插件、CLI 与 YAML 舰队怎么部署 Agent

站起来只是 Phase A。Phase B 是把本机写好的 Agent 部署进舰队。官方主推 abilities 插件市场（与 Claude Code 深度绑定）：

/plugin marketplace add abilityai/abilities
/plugin install trinity@abilityai
/trinity:connect
/trinity:create-agent my-agent
/trinity:onboard

onboard 会做兼容性检查、生成 Trinity 相关文件、部署并启动容器。连上后，MCP 工具（list_agents、chat_with_agent、调度与执行查询等）可直接在编辑器里用，少在网页、终端、配置文件之间来回切。

Trinity CLI 是终端优先替代路径：

pip install trinity-cli   # 或 brew install abilityai/tap/trinity-cli
trinity init              # 实例 URL + 邮箱验证码 → JWT + MCP key
cd my-agent/ && trinity deploy .
trinity agents list
trinity chat my-agent "Hello, what can you do?"
trinity logs my-agent
trinity health fleet

多 Agent 系统可用一份 YAML 声明整套协同，再经 MCP deploy_system 或 REST POST /api/systems/deploy 部署。示意：

name: content-production
description: Autonomous content pipeline

agents:
  orchestrator:
    template: github:abilityai/agent-corbin
    resources: {cpu: "2", memory: "4g"}
    folders: {expose: true, consume: true}
    schedules:
      - name: daily-review
        cron: "0 9 * * *"
        message: "Review today's content pipeline"

  writer:
    template: github:abilityai/agent-ruby
    folders: {expose: true, consume: true}

permissions:
  preset: full-mesh

调度侧是 cron + 独立 scheduler + Redis 分布式锁（防多实例重复触发）；另有带 HMAC-SHA256 与限流的公开 webhook。模板可来自内置库、远程注册表或 github:org/repo@branch（私有仓需 GITHUB_PAT）。

五、边界、排坑与什么人该上这套栈

先说代价，避免「一键部署」滤镜过强：

1. 很重：七个服务起步，磁盘与内存占用明显高于「单进程管家」类运行时；树莓派级环境不现实。

2. 工作流绑定 Claude Code：完整 scaffold → develop → deploy → iterate 在 abilities 市场；不用 Claude Code 也能用 CLI / Web UI，但体验会缺一块。

3. 私有子模块可选：克隆会自动跳过、不需凭据，但说明存在你看不到的企业能力面；Apache-2.0 覆盖你能 clone 到的部分。

4. 商业双生：ability.ai 提供托管与咨询；开源可完整自托管，但要清楚这是「开源 + 商业」模型。

5. 0.x 成熟度：Issue 活跃、功能列表长，生产前务必做渗透回归、备份演练与成本告警。

排坑清单（按官方文档常见路径整理）：

适合谁：已经把 Agent 写通、但卡在「定时 + 多用户 + 留痕 + 隔离」的团队；以及不想自造控制面、又拒绝数据出边界的自托管场景。不适合谁：只想本机玩一轮对话的人——栈太重，收益不对等。

一句话验证路径：先 --unattended 起本地实例，把一个真实定时任务包成 Agent，打开只追加审计日志与成本面板，看信息量是否够你半夜排障。够，再谈上云与 Postgres。

仓库与文档入口：Abilityai/trinity、官方文档部署页、trinity-ops-public。装之前先读 AGENTS.md 与 docs/AGENT_INSTALL_GUIDE.md，比盲目抄命令省半宿。