在 AI Agent 越来越普及的今天，很多人都已经不满足于只拥有一个万能助手。我们希望 AI 能像一个真正的团队一样，有人擅长写作，有人专攻代码，有人负责陪伴聊天，还有人统筹全局。但理想很丰满，现实往往很骨感，多开几个 Bot 简单，真正搭建一套稳定、不串台、不打架、各司其职的多 Agent 系统，却藏着无数工程细节和深坑。

我是字节的一名 AI 工程师，也是一个重度多 Agent 玩家。在折腾了无数个凌晨之后，我终于把五只风格、功能、模型完全不同的 AI，稳定跑在了同一台服务器、同一个 Gateway 进程上，它们在 Discord 里分工协作，互不干扰，却又能高效配合。今天这篇文章，就是我踩坑无数后，沉淀下来的完整架构拆解，不讲虚的理论，全部是可直接复用的实战经验。

在正式开始之前，我必须先给大家一个非常实在的建议，如无必要，千万别强行做多 Agent。很多人遇到的问题，其实只是简单的上下文串台，用单 Agent 加线程隔离就完全足够解决。为了追求所谓的多角色，把系统搞得无比复杂，最后设计了一大堆功能，真正能用得上的寥寥无几，纯粹是给自己增加维护成本。

但这篇内容，是写给那些真正被痛点逼到死角的人。比如上下文严重污染、人设反复横跳、Token 消耗爆炸、单 Agent 无法兼顾专业性与多样性的重度使用者。我接下来要讲的，不是某个框架的简单使用教程，而是一套通用的多 Agent 协作架构。我使用的是 OpenClaw 加 Discord 的组合，但这套架构思路，包括角色拆分、消息路由、身份隔离、记忆分层、双轨治理，放到任何支持多 Agent 的框架上，都具备极高的参考价值。

整篇内容很长，干货极多。如果你懒得逐字阅读，其实可以直接把这篇文章丢给你的 AI 助手，让它帮你对比现有架构的差异，并给出落地改进方案。但如果你想真正吃透这套系统，建议耐心看完，每一个踩坑经验，都能帮你省下数小时的排错时间。

一、为什么一只 AI 不够用？从痛点出发的架构起源

在搭建五只 AI 团队之前，我和绝大多数人一样，只使用一个全能 Agent。写文章、查资料、写代码、算数据、做规划、聊生活，所有事情全部丢给它。一开始觉得很方便，但随着使用频率越来越高，致命问题开始集中爆发。

第一个问题，上下文污染严重。我正在让 AI 写一篇风格轻松、口语化的文章，中途突然插入一个技术问题，让它帮忙调试一段代码。等它回答完技术问题，我再让它继续写文章时，文风直接跑偏。原本流畅的叙事，突然混入了代码逻辑和专业术语，写作状态被彻底打断，之前的铺垫全部作废。

第二个问题，人设彻底混乱。我给写作场景设定的人设是接地气、像朋友聊天，结果它在调试代码时，也用同样的语气吐槽 bug 离谱，专业感荡然无存。反过来，调试完代码再去写文章，文字又变得生硬刻板，跟技术文档一样，完全失去了写作该有的温度。

第三个问题，记忆爆炸带来的成本飙升。一个 Agent 承担所有任务，对话历史会无限堆积，Token 消耗直线上升。就算是 200K 的上下文窗口，一篇长文加上几次技术讨论，就能直接占满。更麻烦的是，旧的对话记忆会持续干扰新任务，我让它做一份生活规划，它可能突然联想到之前的 API 调用逻辑，给出完全不相关的回答，体验极其糟糕。

正是这三个无法回避的痛点，让我下定决心拆分 Agent。写作归写作，技术归技术，生活归生活，思考归思考，再用一个统筹角色管理全局。让专业的 AI 干专业的事，从根源上杜绝上下文污染、人设混乱和记忆冗余。

我的五只 AI 团队就此成型，它们分别是负责全局统筹的大蔡，专注写作的蔡笔，主攻代码的蔡农，提供生活情绪价值的小杜，以及负责深度思考碰撞的蔡思。五只 AI 同住一台服务器，共用一个 Gateway，却能做到各司其职，互不干扰。

二、5 只 AI 团队分工清晰，专业的事交给专业的角色

很多人以为，多 Agent 就是多开几个 Bot，挂几个不同的账号。这种理解完全错误。多开 Bot 只是简单的复制，相当于五个人各自在家远程办公，互相没有关联，没有协作，更没有统一管理。而我搭建的系统，是给五只 AI 租了一间统一的办公室，有明确的工位分配、沟通规则、权限管理、独立存储空间，同时共用一套基础设施。

先给大家详细介绍我的五位 AI 成员，每一个角色的定位、模型选择和核心职责，都经过了反复打磨。

大蔡，作为全局统筹的核心，是默认 Agent。它的职责最综合，日常问答、任务拆解、派工分配、系统状态监控，全部由它负责。模型选择上，我使用 Claude Sonnet 4.6，兼顾智能程度与成本控制，足够应对日常统筹工作，又不会过度消耗 Token。同时，大蔡还承担心跳巡检任务，每 30 分钟自动唤醒，检查其他 Agent 运行状态，扫描待办事项，排查异常。心跳环节使用成本极低的 DeepSeek V3.2，几乎没有额外开销。

蔡笔，是专属写作机器人，也是我内容产出的核心助手。它拥有完整的写作工作流，包括风格指南、去 AI 化规则、三轮审校流程、素材消化规范等，工作区的配置文件比其他 Agent 多出一倍。为了保证写作质量，蔡笔使用的是 Claude Opus 4.6，对语言表达、逻辑结构、风格把控的能力更强，能写出更自然、更有温度、更像真人创作的内容。

蔡农，定位是技术编码专家，专门负责代码编写、系统调试、运维相关工作。模型选择 GPT-5.3-codex，代码生成能力、工具调用稳定性、多步骤逻辑执行都非常可靠。我也尝试过用 Claude 写代码，效果确实不错，但在工具链集成和复杂工程任务上，codex 的表现更稳定。所以我的策略很明确，写作用 Claude，代码用 GPT，各取所长。

小杜，负责生活陪伴与情绪价值。它的 ID 沿用了之前的健身助手 ID，这里给大家一个实用经验，Agent 的 ID 一旦确定，尽量不要修改，否则会导致历史会话、绑定关系、授权配置全部失效，重新配置成本极高。我只修改了它的人设和功能，保留原有 ID，保证系统稳定衔接。

蔡思，是整个团队里最特殊的角色，不承担具体执行任务，专注于深度思考、观点碰撞、决策推演。它更像一面思想镜子，把我的想法反射出来，帮我发现思维盲区，完善逻辑链条。思考类任务对模型能力要求最高，所以蔡思同样使用 Claude Opus 4.6，保证思考深度。

五只角色，五种定位，覆盖了我工作、学习、生活、思考的全部场景，真正实现了 AI 团队化协作。

三、单 Gateway 多 Agent 架构，高效稳定的底层设计

五只 AI，却只运行一个 Gateway 进程，而不是五套独立服务。很多人会担心，一个进程承载多个 Agent，会不会出现互相干扰的情况。答案是不会，因为 OpenClaw 的原生架构，就支持单进程、多隔离工作空间。

Gateway 承担的是公共基础设施的角色，负责消息接入、路由分发、会话管理，就像一栋写字楼的物业管理，负责门禁、电梯、公共服务。而每一个 Agent，都拥有独立的工作空间，人格设定、记忆文件、规则配置、工具权限，全部在各自的空间内独立管理，互不影响。

我放弃多进程、多服务架构，主要有三个核心原因。

第一，运维成本极低。一个进程，一份日志，一个配置文件，出现问题时，只需要集中排查一处，不用在多个服务之间来回切换对比，排错效率大幅提升。

第二，配置统一管理。全局策略，比如模型目录、安全规则、通道配置，只需要在一个地方修改，就能同步生效到所有 Agent，不会出现不同角色配置冲突、不一致的问题。

第三，协作基础牢固。Agent 之间想要高效配合，必须在同一个运行时环境中。跨进程通信会带来延迟、数据同步、调用复杂等一系列问题，严重影响协作体验。单 Gateway 架构，从底层为多 Agent 协作扫清了障碍。

四、Discord 双模式设计，专属频道与统筹大厅完美配合

我选择 Discord 作为交互入口，是因为它的频道结构，天生适配多角色分工体系。经过多次优化，我把 Discord 打造成了专属频道加统筹频道的双模式系统。

第一种模式，专属频道，主打私聊级体验。我为每一个 Agent 都创建了独立频道，写作频道对应蔡笔，编程频道对应蔡农，小杜频道对应生活陪伴，沉思频道对应蔡思，琐事频道对应大蔡。

重点在于，专属频道不只是简单的消息路由，而是实现了完整的身份对应。每个频道里会存在对应角色的 Bot 和默认 Bot，默认 Bot 开启 requireMention 配置，只有被 @ 时才会响应，不会抢占普通消息。同时开启自动线程功能，每一条消息都会自动生成子线程，主频道保留清晰的任务目录，点进线程即可查看详细内容。频道实现职能分层，线程实现任务分层，双重隔离，干净整洁，完全不会出现消息混乱。

第二种模式，统筹频道，实现群聊式协作。我创建了一个统筹频道，将所有 Bot 都加入其中。大蔡不需要 @ 即可自动响应，其他四位角色必须被 @ 才会回复，避免抢话。这样一来，我在同一个频道里，就可以随时召集 AI 团队协作，日常沟通找统筹大蔡，需要专业能力时，再点名对应专家，使用体验极其流畅。

五、路由绑定机制，消息精准送达不迷路

整个多 Agent 系统的入口逻辑，依靠 bindings 路由绑定机制。简单来说，就是告诉系统，哪一个聊天窗口对应哪一个 AI。但这里有一个关键认知，路由正确，不代表身份正确，消息能发给对应的 AI 生成内容，不代表能以正确的身份发出。

我的路由绑定主要分为两类，分别适配专属频道和统筹频道。

第一类是 peer binding，按频道 ID 精确路由，用于专属频道。配置规则明确指定，某个服务器的某个频道，消息只路由给对应 Agent。这种方式精准直接，稳定性极高。

第二类是 accountId binding，按 Bot 身份路由，用于统筹频道。规则逻辑很简单，哪一个 Bot 账号收到消息，就交给对应的 Agent 处理。没有匹配到绑定规则的消息，统一交给默认 Agent 大蔡处理。

路由配置看似简单，却藏着极易出错的细节。我曾经因为复制频道 ID 时多输入一位数字，导致蔡笔的所有消息全部错误路由给大蔡，排查了半个多小时才找到问题根源。对于多 Agent 系统来说，路由是基础中的基础，一步配置错误，整个协作体系都会陷入混乱。

六、身份隔离，路由对了不代表说话的嘴对了

这是我在整个搭建过程中，踩到的最大、最荒诞的坑。内容明明是蔡笔生成的文章，在 Discord 里显示的却是大蔡的头像和名称，语气也完全跑偏。

一开始我以为，只要做好频道路由就足够了，后来才彻底明白，在 Discord 中，消息由哪个 Bot 账号发出，取决于消息由哪个 Bot 账号接收。如果所有频道都只使用一个默认 Bot，那么消息流程就会变成，默认 Bot 接收消息，路由给对应 Agent 生成内容，最后依然通过默认 Bot 发出。内容是专业角色的，身份却是统筹角色，彻底错位。

解决这个问题的方法只有一个，一个 Agent 对应一个独立 Bot Token。我将 Discord 配置从单 Token，修改为多账号模式，为蔡笔、蔡农、小杜、蔡思、大蔡分别配置独立 Token，再配合 accountId 路由绑定，实现消息接收、处理、发出的身份完全统一。

同时配合专属频道的权限配置，默认 Bot 只处理斜杠命令，不抢占普通消息，彻底解决身份错位问题，让每一个 AI 都能用自己的身份说话。

七、会话调用规则，sessions_spawn 与 sessions_send 别乱用

在实现 Agent 之间协作调用时，我还踩了一个关于会话调用的坑。一开始我习惯使用 sessions_spawn，让大蔡创建后台任务，派发给蔡笔写作，完成后将结果返回频道。但结果依然出现身份错位，内容是蔡笔写的，发出身份却是大蔡。

原因在于，子 Agent 通过 spawn 创建的任务，会继承主 Agent 的会话上下文，发出消息时依然使用主 Agent 的身份。经过多次测试，我总结出了稳定可靠的使用规则。

需要以指定角色身份对外发言的任务，必须使用 sessions_send，将任务发送到对应角色的独立会话中处理，保证身份正确。纯后台执行、不需要对外发出消息的任务，才使用 sessions_send。

如果使用 sessions_send 时出现上下文长度限制，不要切换为 spawn，正确做法是在目标频道创建新线程，全新的线程对应全新的会话，上下文干净无冗余。

八、Discord 斜杠命令的架构限制，接受并合理规避

在使用过程中，我还发现了 Discord 斜杠命令的一个固有坑点。在任意频道使用斜杠命令，处理消息的 Bot 并不是由频道路由决定，而是由注册命令的 Bot 决定。

如果只有默认大蔡 Bot 注册了斜杠命令，那么在任何频道使用斜杠命令，都会交给大蔡处理。我曾经在小杜的专属频道使用推理命令，结果大蔡回复频道不允许，就是因为这个机制。

最后的解决方案是，将大蔡 Bot 加回所有频道，专属频道开启 requireMention 配置。普通消息不会触发大蔡，斜杠命令则由大蔡统一接收处理，同时配合文本命令使用，文本命令的路由可控性更高，能更好地适配多 Agent 架构。

九、灵魂工程，文件即规则，给 AI 注入持久人格

整个架构中，最有价值、最有温度的部分，就是基于文件的规则管理体系。我把 AI 的人格、行为、记忆、规范，全部写在独立文件中，而不是临时的提示词里。每一个 Agent 的工作区，都有一套标准化文件。

SOUL.md 是灵魂文件，也就是 AI 的人格说明书。里面清晰定义它是谁、说话风格、职责边界、质量底线、不可妥协的原则。以蔡笔为例，文件里明确规定了代笔定位、口语化风格、固定开头、禁用词汇、九步写作流程、真实性原则。同一个底层模型，挂载不同的灵魂文件，就会呈现出完全不同的人格，这就是提示词无法比拟的灵魂工程。

AGENTS.md 是运行手册，是 Agent 启动后第一个读取的文件。启动流程、记忆规范、安全规则、群聊行为、长任务汇报逻辑，全部写在其中，保证 AI 运行行为稳定可控。

IDENTITY.md 是身份卡片，简短清晰地记录名称、定位、表情符号、说话特点，相当于 AI 的名片。

USER.md 是用户画像，记录用户偏好、时区、表达习惯，让每一个 AI 都能精准适配用户需求。

MEMORY.md 是长期记忆，沉淀经过验证的稳定信息、可复用经验、重要决策，不是流水账式的对话记录。

每日记忆文件，记录当天的任务过程、上下文碎片、临时决策，时效性强，便于回溯复盘。

HEARTBEAT.md 是心跳检查清单，定义 Agent 定期唤醒需要检查的事项。

这套体系的核心思想是，规则写在文件里，而不是提示词里。提示词是临时口头指令，说完即忘，文件是持久化规则，每次启动都会加载，还可以通过 Git 做版本管理，随时修改、回溯、迭代。

十、会话隔离与群聊规范，让 AI 不打架、不抢话、不无限互聊

多 Agent 系统最容易出现的乱象，就是上下文串台、群聊抢话、AI 之间无限客套。这些问题，依靠工程配置和行为规范双重保障，完全可以避免。

OpenClaw 的会话机制，会为每一个聊天窗口生成独立会话，上下文完全隔离。再配合 Discord 频道隔离、多 Bot 身份隔离，三重保障下，上下文串台的概率基本为零。

针对 AI 之间自动互聊、无限客套的问题，只需要在配置中设置 maxPingPongTurns 等于 0，禁止 Agent 之间自动互相回复。所有协作任务，都由大蔡显式派工，或者用户手动 @ 触发，从根源上杜绝无效对话，避免浪费 Token。

群聊规范同样重要，我在每一个 Agent 的运行手册中，都明确规定了群聊行为准则。被直接 @ 或被提问时才回复，能提供有效价值才回复，纯闲聊、重复回答保持沉默，复杂工作流引导至专属频道。核心原则就是，让 AI 像真人一样参与群聊，不做消息复读机。

十一、记忆分层与模型混搭，把成本花在刀刃上

记忆管理和模型选择，是多 Agent 系统性价比的关键。很多人误以为记忆就是对话记录，无限堆积只会导致成本飙升、推理变慢。我的记忆体系分为三层。

第一层是每日流水记忆，记录当天任务细节，量大、细碎、时效性强，过期后价值极低。

第二层是长期记忆，沉淀稳定、可复用、高价值的信息，经过筛选和整理，不占用多余资源。

第三层是语义检索记忆，需要调用记忆时，不全部加载，而是通过语义搜索召回相关片段，按需读取，极大节省上下文空间。

模型选择上，我不追求统一高配，而是按需搭配。统筹日常用性价比高的 Claude Sonnet，写作思考用高质量 Claude Opus，代码用专业 GPT codex，心跳巡检用低成本 DeepSeek。同时配置 fallback 兜底机制，主模型故障时自动切换备用模型，保证系统不间断运行。

十二、双轨治理，配置硬约束加规则软引导，稳定不翻车

我的整个系统，采用配置层加规则层的双轨治理模式。

配置层是硬约束，写在核心配置文件中，包括群聊策略、路由绑定、响应权限、ping pong 上限等，是无法绕过的底层规则。

规则层是软引导，写在工作区文件中，包括人格设定、行为规范、工作流程、质量标准，通过持久化文件引导 AI 行为。

两层治理相互配合，配置层先做好限流和隔离，规则层再细化行为和质量，双重保险，保证系统长期稳定运行。

十三、真实踩坑复盘，这些错误别再重复

最后，给大家总结我真实遇到的高频坑点，帮大家少走弯路。

Bot 在线不回复，大概率是 Discord 开发者平台的消息内容权限未开启。

路由正确但身份错误，必须配置多独立 Token，配合 accountId 路由。

斜杠命令不受频道路由控制，统一由默认 Bot 处理，专属频道开启防抢话配置。

sessions_spawn 不适合需要对外发言的任务，容易导致身份错位。

部分全局配置不支持单 Agent 覆盖，修改前务必确认配置规则。

配置非法会被自动回滚，修改后一定要检查日志确认生效。

不要用脚本整体读写配置文件，容易引发副作用，精准修改目标字段即可。

绝对不要让多个 Agent 共用工作区，会导致记忆、配置互相覆盖，系统崩溃。

十四、架构反思：多 Agent 的核心不是多开，而是协同

折腾完整套架构，我最深的感悟是，多 Agent 从来不是简单的多开 Bot。从单 AI 到多 AI 团队，中间隔着的是路由设计、身份隔离、会话管理、记忆分层、协作规则、双轨治理一整套工程体系。

搭建完成后，体验的提升是颠覆性的。写作时，蔡笔的上下文纯净无干扰，文风稳定自然；编码时，蔡农专注技术，专业度拉满；生活陪伴时，小杜温柔贴心；思考时，蔡思深度碰撞；全局事务，大蔡统一统筹。五只 AI 同住一台服务器，却像一个训练有素的团队，高效、稳定、各司其职、互相配合。

OpenClaw 提供了优秀的底层底座，原生支持多 Agent、多工作区、路由绑定、会话隔离等核心能力，但从能跑到跑对，从可用好用，中间全是容易被忽略的细节。尤其是路由对了不等于身份对了这个关键教训，是无数次试错换来的核心经验。