本文介绍一种轻量级的多角色 AI Agent 协作架构，通过群聊式的 @mention 交互，在单一会话中实现多个专家角色的按需切换与能力隔离，取代传统多智能体框架的实例化路由方案。
问题背景：当一个 Agent 被迫扮演所有角色
在构建 AI Agent 平台的过程中，我们遇到了一个典型的"全能陷阱"：
一个 Agent 需要同时具备业务处理、创意构思、技术讨论、经验总结等截然不同的能力。为了支撑这些能力，System Prompt 被迫塞入所有角色的规则、所有工具的描述、所有工作流的列表。结果是：
- Prompt 膨胀：单次请求的 System Prompt 长达 6000+ 字符，其中大量内容与当前任务无关
- 角色混乱：模型在"严谨的业务分析师"和"轻松的创意伙伴"之间频繁人格分裂
- 工具滥用：模型拥有 20+ 工具的调用权限，容易在不必要的场景调用不相关的工具，甚至编造工具返回值
- Token 浪费：大量 token 消耗在模型永远不会用到的上下文上
主流的多智能体框架（CrewAI、AG2/AutoGen）通过实例化多个独立 Agent 对象来解决这个问题，但引入了新的复杂性：上下文共享需要专门的记忆系统、Agent 间的 handoff 有信息丢失风险、架构依赖重。
我们选择了一条不同的路——不要多个 Agent，要多个角色。
核心设计：群聊隐喻
一句话定义
在单一对话会话中，用户通过 @角色名 按需召唤不同的专家角色，每个角色拥有独立的 Prompt 和能力边界，但共享完整的对话上下文——就像在一个群聊里 @ 不同的人。
与传统多智能体架构的本质区别
| 传统多智能体（多实例） | 我们的方案（多角色） | |
|---|---|---|
| Agent 数量 | N 个独立 Agent 对象 | 1 个模型，N 套角色配置 |
| 上下文共享 | 需要外部记忆系统（如 LanceDB） | 天然共享——同一个对话历史 |
| 切换机制 | Handoff 协议 / 路由器 / 编排器 | 用户 @mention / 粘性回退 |
| 信息丢失 | Handoff 时可能丢失上下文 | 零丢失——历史消息完整保留 |
| 架构依赖 | 框架级依赖（CrewAI / AG2 / LangGraph） | 零依赖——YAML 配置 + Prompt 切换 |
| 用户认知 | 需理解 Agent 编排概念 | 像群聊一样 @ 某人 |
架构实现
角色定义：一个 YAML + Markdown 文件
每个角色由一个 role.md 文件定义，包含 YAML frontmatter（元数据）和 Markdown body（角色规则）：
---
id: creative
name: 创意伙伴
description: 视频脚本、漫画分镜、故事创作
tools: # 工具白名单
- GET_WORKFLOW_LIST
- SAVE_EXPERIENCE
- WEB_SEARCH
workflows: # 工作流白名单
- wf_1773715937154 # 漫画创意实现-发布
skillRules: # 工具级使用约束
GET_WORKFLOW_LIST: |
推荐工作流前必须先调用获取可用列表，禁止编造。
dynamicSections:
- bestPractices
---
# 核心职责
协助构思创意内容，通过工作流完成生成和发布。
# 风格
轻松、有创造力、鼓励发散思维。
# 规则
- 禁止输出 :::task-complete
- 当需求涉及生成内容时，必须先调用 GET_WORKFLOW_LIST
这个文件同时控制了三层隔离：
- Prompt 隔离：每个角色加载独立的 System Prompt，包含角色特有的身份、规则和语气
- 工具隔离：
tools白名单决定了模型可调用的 function calling 工具集 - 工作流隔离：
workflows白名单决定了通过工具查询或 Prompt 注入时可见的工作流范围
角色切换：@mention + 粘性回退
用户在对话中输入 @创意伙伴 帮我想两个漫画创意，后端处理流程：
用户输入: "@创意伙伴 帮我想两个漫画创意"
│
┌──────────▼──────────┐
│ 正则匹配 @角色名 │
│ findRoleByName() │
└──────────┬──────────┘
│ matched: creative
┌──────────▼──────────┐
│ 写入 session.roleId │ ← 粘性：后续消息自动沿用
└──────────┬──────────┘
│
┌──────────▼──────────┐
│ 剥离 @前缀 │
│ effectiveText = │
│ "帮我想两个漫画创意" │
└──────────┬──────────┘
│
┌───────────────▼───────────────┐
│ 加载 creative 角色配置 │
│ • System Prompt (3596 字) │
│ • Tools: 10 个 │
│ • Workflows: 1 个 │
└───────────────────────────────┘
角色解析的优先级链：
- @mention（最高）：用户当前消息中的
@角色名 - Settings.roleId：用户在设置面板中预选的默认角色
- Session.roleId（粘性）：会话中上一次使用的角色 ID
- 自动路由（兜底）：根据消息特征自动分配
"粘性"设计是关键——用户 @ 了一个角色后，后续消息不需要再 @，系统会自动沿用。只有当用户 @ 了一个不同的角色，才会切换。这让交互变得极其自然。
上下文共享：零成本的"群聊记忆"
传统多智能体框架需要专门的共享记忆机制。而在我们的架构中，所有角色共享同一个 chat_messages 表——因为它们本来就在同一个会话里。
关键细节：用户消息以原始文本（含 @前缀）保存到数据库，但发给 LLM 时用剥离后的纯文本。这意味着，当角色 B 接手后，它在历史消息中能看到：
历史消息[1] user: "@创意伙伴 帮我想两个漫画创意"
历史消息[2] assistant: "《Bug转生到异世界》..."
当前消息 user: "你觉得哪个更好？" (发给角色 B)
角色 B 可以从 @创意伙伴 前缀推断出消息[2]的发言者是创意伙伴，从而理解上下文关系。无需额外的归属标记系统，@ 前缀自然成为了发言者标识。
双白名单：工具 + 工作流的能力边界
每个角色拥有两层白名单控制：
工具白名单（tools） 控制模型的 function calling 能力：
delegate（委托处理）: 13 个工具 — 全业务能力
business（业务助理）: 22 个工具 — 含代码分析和文件操作
creative（创意伙伴）: 10 个工具 — 创作 + 工作流执行
talker （创意总监）: 1 个工具 — 仅联网搜索
socrates（苏格拉底）: 1 个工具 — 仅联网搜索
exp-master（经验大师）: 3 个工具 — 经验读写
工作流白名单（workflows） 控制可发现和可执行的工作流范围：
delegate: null（不限制）— 可访问全部 6 个 agentReady 工作流
creative: ["wf_xxx"] — 仅可见"漫画创意实现"这一个工作流
talker: 未配置 — 无工作流访问权限
白名单在两条链路上同时生效：
- Prompt 注入链路：
buildSystemPrompt构建时，工作流列表按白名单过滤后注入 - 技能调用链路：
GET_WORKFLOW_LIST执行时，返回结果按白名单过滤；RUN_WORKFLOW执行前校验workflowId是否在白名单内
这确保了角色无论通过"看到"还是"调用"，都无法突破自己的能力边界。
实践验证
验证场景：群聊式创意协作
以下是一次真实的多角色协作会话（同一 session）：
第一轮：@创意伙伴 构思创意
用户: @创意伙伴 晚上睡不着，起来写代码，想两个漫画创意
创意伙伴: [输出了两个完整的漫画创意方案 + 工作流推荐]
- 角色路由：
@角色指派 | name=创意伙伴 → role=creative - Session.roleId 更新：
null → creative - Prompt 长度：3596 字符，工具数：10
第二轮：@创意总监 评审创意
用户: @创意总监 你选哪个？
创意总监: [从原创性、受众吸引力等维度分析，给出了选择建议]
- 角色路由：
@角色指派 | name=创意总监 → role=talker - Session.roleId 更新：
creative → talker - Prompt 长度：1197 字符，工具数：1
关键观察：
- 同一会话、无缝切换：两个角色在同一 session 中工作，创意总监能看到创意伙伴之前的完整输出，并基于此给出评审意见
- 角色行为一致性：创意伙伴活泼发散，输出了创意方案和工作流推荐；创意总监专业直率，从多维度做了结构化评估——两者风格完全不同，符合各自的角色定义
- 工具使用精准：创意伙伴拥有 10 个工具但本轮未使用（构思阶段不需要）；创意总监只有 1 个工具（WEB_SEARCH），不会出现误调用工作流的情况
量化效果
基于实际运行数据的对比：
| 指标 | 重构前（单一全能 Prompt） | 重构后（角色化） | 变化 |
|---|---|---|---|
| System Prompt 长度（创意场景） | ~6000 字符 | 3596 字符 | -40% |
| System Prompt 长度（讨论场景） | ~6000 字符 | 1197 字符 | -80% |
| 可调用工具数（创意场景） | 26 个 | 10 个 | -62% |
| 可调用工具数（讨论场景） | 26 个 | 1 个 | -96% |
| 可见工作流数（创意场景） | 6 个 | 1 个 | -83% |
| 工具幻觉（编造工具返回值） | 偶发 | 未观察到 | 消除 |
| 工作流名称幻觉 | 偶发 | 未观察到 | 消除 |
注：以上数据来自内部测试环境的实际运行日志，非大规模 benchmark。幻觉消除的结论基于重构后的多轮手动验证，主观判断能力未下降。
Prompt 长度和工具数的减少直接带来两个好处：
- Token 成本降低：每次请求的 prompt_tokens 显著减少，按量计费场景下成本可观
- 模型专注度提升：更少的工具选项意味着更少的"选择困难"，模型更容易做出正确的工具调用决策
行业对比：与主流方案的定位
AG2（AutoGen 继任）— 最接近的工业级方案
AG2 提供了 5 种编排模式（DefaultPattern、AutoPattern、RoundRobinPattern、RandomPattern、ManualPattern），其中 ManualPattern 允许用户手动选择下一个 speaker。但核心区别在于：
- AG2 的每个 Agent 是独立实例，需要 context variables 实现上下文共享
- AG2 的切换是回合制的强制选择，每一轮都要指定
- AG2 需要框架级依赖和编排器
我们的方案：单实例 + @mention 按需切换 + 粘性回退，在交互自然度和实现简洁性上有明显优势。
CrewAI — 任务导向的多智能体协作
CrewAI 通过 Agent-to-Agent 委托（delegation）实现协作，配合 Cognitive Memory 做知识共享。但：
- CrewAI 面向的是Agent 自主协作（Agent A 委托 Agent B），不是用户驱动
- 记忆系统依赖 LanceDB，是独立于对话历史的外部存储
- 适合自动化 pipeline，不适合交互式对话
我们的方案面向人机协作，用户是指挥者，角色是专家团队。
cursor-agent-team — 理念最接近的学术方案
cursor-agent-team（2026 年 2 月发表）同样提出了"单会话多角色"的概念，使用 AOP 原则管理 persona 一致性。但其侧重于 Spec-Script 循环的形式化方法，而非面向终端用户的交互设计。
我们的方案在用户体验层做了更多工作：@mention 的群聊隐喻、粘性角色、工具/工作流双白名单、会话列表中的角色标签等。
定位总结
| 方案 | 适用场景 | 架构复杂度 | 用户可控度 |
|---|---|---|---|
| AG2 | 复杂的自动化多 Agent 编排 | 高 | 中（可手动，但主打自动） |
| CrewAI | 任务 Pipeline 自动化 | 高 | 低（Agent 自主协作） |
| cursor-agent-team | 开发辅助的角色切换 | 中 | 中 |
| 本方案 | 交互式人机协作 | 低 | 高（用户 @mention 驱动） |
适用边界与局限
这个架构不是银弹，有其明确的适用范围：
适合的场景：
- 用户是唯一指挥者，需要不同专家视角的交互式协作
- 角色数量有限（5-10 个），角色定义相对稳定
- 需要在角色间共享完整的对话上下文
- 追求轻量实现，不希望引入重型框架
不适合的场景：
- Agent 需要自主发起协作（如 Agent A 主动调用 Agent B）
- 需要多个 Agent 并行处理不同任务
- 角色数量极多（50+），需要复杂的语义路由
- 需要跨会话的长期记忆协作（本方案的记忆限于单会话）
已知局限：
- 超长对话被压缩为摘要后，@ 前缀信息可能丢失，影响角色归属的推断
- 单模型的能力上限决定了所有角色的能力天花板
- 粘性角色在某些场景下可能不符合预期（用户可能忘记当前是哪个角色在"值班"）
总结
我们提出的"单会话多角色群聊协作"架构，核心贡献不在于任何单点技术突破，而在于用一个极度简洁的交互隐喻（群聊 @mention）解决了一个被过度工程化的问题（多智能体协作）。
关键设计决策：
- 不要多个 Agent 实例，要多个角色配置文件 — 消除了上下文共享的复杂性
- 不要路由器，要 @mention — 将控制权交给用户，用最低认知成本实现角色调度
- 不要框架，要约定 — YAML 白名单 + Prompt 切换 + 工具过滤，零外部依赖
- 工具 + 工作流双白名单 — 确保能力隔离的同时保持配置的简洁性
在实践中，这套架构将创意场景的 Prompt 体积降低了 40%-80%，将工具选择空间压缩了 62%-96%，消除了工具和工作流的幻觉问题，且主观评估模型能力未下降。
对于正在构建 AI Agent 平台、且核心场景是人机交互式协作（而非 Agent 自主编排）的团队，这套架构值得作为一种轻量替代方案来考虑。
本文基于内部实践总结，代码不开源，但架构理念和设计模式可自由参考和讨论。欢迎在评论区分享你的多智能体协作实践经验。
