40分钟上手Trinity：构建4个协作AI Agent的实战指南

在AI原生公司成为热词的当下，如何让多个智能体真正协同工作，而非各自为政，是许多团队面临的现实挑战。B站上的一场40分钟工作坊实录，展示了用开源编排工具Trinity构建四个互相协作的AI Agent的完整过程。这场演示没有停留在概念层面，而是从实例部署、模板创建、权限配置到跨框架迁移，一步步搭建出一个名为Keymaker的迷你机构。

Trinity是什么：智能体的组织操作系统

Trinity本质上是一个编排和运行智能体的平台，目标不是做一堆自动化脚本，而是让智能体像公司员工一样长期共存、积累经验。每个智能体对应一个GitHub仓库，在Docker容器中拥有独立的沙盒环境，被设计成有状态、可协作的实体。

演示中的实例展示了清晰的层级架构：顶部的幕僚长（Chief of Staff）负责编排其他智能体，第二大脑智能体基于Cornelius技术提供持续更新的决策视角，下方则分布着销售、产品经理、插画师等职能角色。它们通过消息传递和执行任务协同，而非孤立运行。有意思的是，Trinity对底层模型框架保持中立，当前实例全部使用Claude Code，但也支持Codex、Gemini等，降低了团队被单一技术栈锁定的风险。

从库到实例：三步创建智能体

工作坊的核心操作集中在Keymaker这个全新实例上。创建智能体的路径非常直观：进入库（Library）的智能体模板选项卡，选择Keymaker销售、交付或营销模板，点击“使用模板”并命名即可。由于模板是公开的，初始阶段无需配置GitHub个人访问令牌，降低了上手门槛。

一个值得借鉴的实践是，主讲人为Keymaker创建了独立的GitHub组织，并为该组织生成通用访问令牌。这样做的好处是权限边界清晰，智能体在组织内创建仓库、提交代码时不会越界。随后，通过技能库为每个智能体分配标准作业程序，比如让销售智能体具备创建剧本、使用图片生成器或项目管理的能力。这种“模板+技能”的组合，让智能体在保持轻量的同时具备可扩展性。

GitHub 个人访问令牌（Personal Access Token, PAT）与组织级令牌 的差异值得说明。PAT 绑定在具体用户账号下，权限范围通常覆盖该用户可访问的所有仓库，一旦泄露影响面较大；而组织级令牌（如 Fine-grained PAT 授予组织）可以将权限严格限定在某个组织内的仓库，并可细化到读写、提交、创建等具体操作。文中为 Keymaker 单独创建 GitHub 组织并生成通用访问令牌，实质是在智能体与人类账号之间划出一道隔离带：智能体只能在 Keymaker 组织内活动，既避免了误操作波及个人或其他项目仓库，也让权限审计有据可查。对于多智能体系统，这种“一组织一令牌”的做法是成本最低的权限边界实践。

权限配置：让孤岛变成团队

刚创建的三个智能体彼此并不知道对方的存在。演示中，交付智能体被问及产品发布计划时直接回答“那不在我负责的生命周期里”。解决方式是在每个智能体的权限设置中，勾选允许通信的其他智能体。几秒钟的操作后，交付智能体就能在收到问题时主动调用营销智能体获取信息，并把结果带回对话。

这一设计揭示了一个关键理念：多智能体协作不是靠一个中央大脑强行调度，而是通过点对点的权限授权形成网络。主讲人后续还演示了工作区中的多智能体对话功能，选中交付和销售智能体并@它们，两者便开始协同规划下一季度产能。对于希望引入AI原生工作流的团队，这种渐进式授权比一次性全自动更可控。

点对点授权与中央调度的区别 是多智能体架构中的关键分野。中央调度模式由一个主控 Agent 统一分配任务，所有通信经过中枢，优点是全局可控，缺点是主控成为单点瓶颈，且新增角色需要修改主控逻辑。点对点模式则让每个 Agent 在权限表中声明“我可以和谁说话”，通信直接在成员之间发生，网络拓扑随授权动态生长。Trinity 采用的是后者：交付智能体被授权访问营销智能体后，便能在对话中自行发起请求并整合结果，无需幕僚长中转。这种方式更接近真实组织的运作方式，扩展新成员时只需增补授权关系，而不必重构整个编排逻辑，代价则是需要更谨慎地设计权限矩阵以避免通信混乱。

跨框架迁移：把现有Agent接入Trinity

工作坊最具实操价值的部分，是如何将非Trinity体系的智能体迁移进来。演示者打开一个普通桌面版Claude Code项目，其中包含会议记录、发票提醒和潜在客户评分三个Agent。通过安装“agent集群分析”和“agent集群迁移”插件，系统自动识别出三个Agent的用途和结构。

执行迁移命令后，系统创建副本而非破坏原文件，并生成Trinity兼容格式。主讲人强调，基于Claude的Agent通常只需少量修改，主要是补充Agent定义和辅助技能。迁移完成后，通过Trinity入住插件，直接从GitHub仓库部署到实例，整个过程在MCP连接下完成，无需手动搬运配置。最终，原本孤立的会议记录机器人获得了访问销售、营销和交付智能体的权限，成为第四个协作成员。

MCP（Model Context Protocol） 是 Anthropic 于 2024 年底提出的开放协议，用于标准化大语言模型与外部工具、数据源之间的连接方式。它定义了一套客户端-服务器架构：模型作为客户端，通过统一的接口调用封装好的工具服务器，从而访问文件系统、数据库、代码仓库等资源。MCP 的核心价值在于解耦——工具开发者只需实现一次 MCP 服务器，即可被任何支持该协议的模型或 Agent 框架调用。文中迁移完成后通过 MCP 连接直接部署到实例，正是利用了这一协议：Trinity 将 GitHub 仓库、部署流程等封装为 MCP 工具，智能体无需了解底层实现细节即可完成操作，这也是跨框架迁移能够做到“无需手动搬运配置”的技术基础。

开源与企业版的边界

问答环节透露了产品的分层逻辑：独立开发者或小团队使用开源版即可，核心功能相当完整；当公司需要合规性、多用户角色管理或几十人协作时，才需要企业版许可。这种划分对预算有限的初创团队较为友好。此外，主讲人提到画布目前定位是可视化协作界面，而非BI工具，但Trinity层级已开始存储业务指标，未来会与Power BI等工具集成。

实践启示

这场工作坊的价值在于把“AI原生公司”从口号拆解为可执行步骤：先有编排平台和沙盒环境，再用模板和技能快速构建角色，接着通过权限让角色互相感知，最后把已有Agent迁移进来扩充团队。整个过程中，人类始终保留审批门禁和凭据管控，比如通过1Password服务账号集中管理密钥。对于想动手尝试的开发者，可以从Docker本地部署Trinity开始，用公开模板练手，再逐步接入真实CRM和营销数据源。多智能体协作的门槛，正在从架构设计降到配置操作。