Trinity：AI Agent 真要上线，脏活还是得有人接

我看 Trinity，第一眼没被“多 Agent 协作”这种词打动，反倒是停在那条安装命令上：

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

啧，AI Agent 现在最大的问题，不是 Demo 能不能跑，是你第二天想让它继续跑、定时跑、出错能查、别把数据扔到别人 SaaS 里。Trinity 的思路很直接：把 Agent 当基础设施跑，每个 Agent 单独塞进 Docker 容器，配实时监控、调度、互相委派，还有审计日志。它明确支持自托管，也能跑在你自己控制的云上。

这就很现实。

老鬼以前看这种工具，最怕它只管“创建 Agent”，不管后面的限流、日志、权限、成本。README 里有个控制台截图说明挺扎眼：拓扑图能看整个 Agent fleet 的状态、成本和成功率，还能看执行时间线；这玩意儿不花哨，但真到生产环境，老板问“昨晚是谁跑爆了 token”，你就知道它值不值了。

还有一个点：它把 Claude Code 工作流接进来了。不是写完代码再切到别的平台部署，而是在 Claude Code 里通过插件连接 Trinity、创建 Agent、onboard、sync，甚至直接拉日志、看 fleet health。对写 Agent 的人来说，少切一次上下文，就少一次“我刚才配到哪了”的痛苦。

当然，先别急着吹。生产部署不是一条命令就万事大吉，.env、API key、Docker Compose、服务器权限，这些坑还是在。README 里也写了需要 Docker / Compose v2，以及 Anthropic 或 Google API key。能不能稳，最后还得看你自己的机器、网络和日志习惯。

多 Agent 这块，它支持用一个 YAML manifest 定义一组 Agent，比如 orchestrator、writer、权限和 cron 调度，然后通过 MCP 或 REST API 部署整套系统。这个方向挺适合内容流水线、销售线索处理、知识库维护这种“不是一个 Agent 干完”的活。

我会把 Trinity 放在“Agent 从玩具变工具”的那一层看：不负责让你的 Agent 更聪明，但负责让它别裸奔。

GitHub 地址：GitHub - Abilityai/trinity。