从 1:1 Chat 到群聊:让人和多个 AI Agent 一起开会

Posted on 四 30 4月 2026 in Tech

Abstract 从 1:1 Chat 到群聊:让人和多个 AI Agent 一起开会
Authors Walter Fan
Category tech note
Status v1.0
Updated 2026-04-30
License CC-BY-NC-ND 4.0

从 1:1 Chat 到群聊:让人和多个 AI Agent 一起开会

我们已经习惯了 1:1 AI Chat:我问一句,AI 回一句。这个模式很像找一位聪明同事私聊,适合解释概念、写一段代码、改一封邮件。它简单、直接、低摩擦。

但工作里的真实问题通常不是一问一答。一个需求过来,产品要说目标,架构师要看边界,安全同学要挑风险,测试同学要问验收标准,最后还得有个人拍板。现实世界早就证明了:复杂问题靠单线程聊天很难收敛,哪怕对方很聪明。

所以我越来越觉得,AI Agent 的下一个常见形态,不是更花哨的 1:1 窗口,而是人和多个 Agent 在一个群聊里协同。你可以问一个 Agent,也可以同时问几个 Agent;Agent 可以互相追问、补充、反驳;人类不再负责把每个答案复制粘贴给另一个 Agent,而是像主持会议一样控制节奏。

一句话:

1:1 Chat 解决“我和 AI 怎么说话”,Group Chat 解决“人和一组 AI 怎么一起做事”。

先看一个场景

假设我想评审一个新的 API 设计。在 1:1 模式下,我可能这样干:

  1. 问 Coding Agent:“帮我看这个接口设计。”
  2. 复制回答,去问 Security Agent:“这里有什么安全问题?”
  3. 再复制一遍,问 Test Agent:“怎么写测试用例?”
  4. 最后自己开一个文档,把三份答案揉在一起。

这当然能用,但很像上世纪的人工消息队列。人类成了中间件,负责转发、去重、压缩和兜底。老程序员看到这里会本能地想加个 broker。

群聊模式应该是这样:

Human:
  @architect @security @tester 请一起评审这个 API 设计,
  重点看边界、鉴权、异常处理和测试策略。

Architect Agent:
  我先看资源模型和调用链……

Security Agent:
  我补充鉴权和敏感数据暴露风险……

Tester Agent:
  我基于你们的结论列验收测试……

Human:
  @architect 请根据 security 的意见改一下方案。

注意,这里不只是“把三个回答显示在同一个窗口”。真正的变化是:Agent 之间能看见彼此的观点,并在同一个任务上下文里继续推进。

从 1:1 到群聊,真正变复杂的是状态

1:1 Chat 的系统模型非常朴素:

User -> Conversation -> Agent -> Model -> Response

你只要维护一个 conversation history,再加一点 memory、tool call 和权限控制,就能做出一个可用系统。

群聊一来,事情马上变成这样:

Room
  ├── Human
  ├── Architect Agent
  ├── Security Agent
  ├── Tester Agent
  └── Bot / Tool / Workflow

复杂度不在 UI,而在几个问题:

  • 谁应该回复这条消息?
  • Agent 能不能主动发言?
  • Agent 能不能呼叫另一个 Agent?
  • 每个 Agent 能看到多少上下文?
  • 哪些消息是事实,哪些只是建议?
  • 工具调用由谁授权?
  • 多个 Agent 同时说话时,怎么防止群聊变成菜市场?

这就是从 Chatbot 到 Multi-Agent Collaboration 的分水岭。群聊不是把 N 个 1:1 窗口拼起来,而是要重新设计消息、路由、上下文和权限。

最小模型:把群聊看成一个可审计的消息总线

我建议先不要急着发明“群体智能”。第一版实现可以很工程化:把 group chat 当成一个可审计的 message bus。

核心对象只有四个。

对象 说明 关键字段
Room 一次协作空间 room_id, topic, participants, policy
Participant 人、Agent 或工具账号 id, type, role, capabilities
Message 群聊里的事件 sender, mentions, reply_to, content, visibility
Task 需要收敛的工作项 owner, status, deadline, artifacts

一个简化的消息结构可以这样设计:

{
  "message_id": "msg_123",
  "room_id": "room_api_review",
  "sender": {
    "id": "human_walter",
    "type": "human"
  },
  "mentions": ["agent_architect", "agent_security", "agent_tester"],
  "reply_to": null,
  "content": "请一起评审这个 API 设计,重点看鉴权、异常处理和测试策略。",
  "attachments": [
    {
      "type": "markdown",
      "name": "api_design.md",
      "uri": "artifact://api_design"
    }
  ],
  "visibility": "room",
  "created_at": "2026-04-30T22:10:00+08:00"
}

关键点是:消息不是一段裸文本,而是带有发送者、提及对象、回复关系、附件和可见性的事件。后面所有路由、权限、审计、压缩都靠这些字段活着。

第一步:从“单个 Agent 回复”改成“路由器决定谁回复”

1:1 Chat 里,用户发消息,唯一的 Agent 回复。群聊里,不能每条消息都让所有 Agent 回答。否则用户问一句“收到吗”,五个 Agent 一起写小作文,屏幕会立刻热闹得像线上事故群。

所以需要一个 Conversation Router

路由规则可以先从简单开始:

  1. 如果消息显式 @agent,只唤醒被提及的 Agent。
  2. 如果消息 @all-agents,唤醒房间内所有可响应 Agent。
  3. 如果消息是对某个 Agent 的 reply,优先唤醒原 Agent。
  4. 如果没有 mention,则只进入 room history,不触发 Agent。
  5. 如果 room policy 允许主动发言,再由 Agent 自己判断是否需要插话。

伪代码大概是这样:

def route_message(room, message):
    if message.sender.type == "agent" and not room.policy.allow_agent_to_agent:
        return []

    if message.mentions:
        return [
            p for p in room.participants
            if p.id in message.mentions and p.type == "agent"
        ]

    if message.reply_to:
        parent = load_message(message.reply_to)
        if parent.sender.type == "agent":
            return [find_participant(room, parent.sender.id)]

    if message.content.startswith("@all-agents"):
        return [p for p in room.participants if p.type == "agent"]

    return []

这里有一个产品取舍:默认静默,比默认热闹更好。 AI Agent 很容易过度积极,系统要给它一点会议礼仪。人类已经参加过太多低效会议,不必再让 AI 帮我们复刻一遍。

第二步:让 Agent 拥有自己的角色、记忆和工具

多个 Agent 的价值,来自“差异化视角”,不是来自“同一个模型换三个名字”。

一个可用的 Agent 定义至少要包括:

id: agent_security
display_name: Security Agent
role_prompt: |
  You are a security reviewer.
  Focus on authentication, authorization, data exposure,
  abuse prevention, logging safety, and threat modeling.
tools:
  - read_artifact
  - search_code
  - run_static_check
memory_scope: room
permission_level: reviewer
can_initiate_message: false

我会把 Agent 的配置分成四层:

层次 内容 例子
Persona 它是谁,关心什么 Architect / Security / Tester
Context 它能看到什么 当前 room、相关文档、历史决策
Tools 它能做什么 读文件、查代码、跑测试、搜索知识库
Policy 它不能做什么 不能直接部署、不能读密钥、不能私聊外部用户

这里最容易犯的错,是只写 Persona,不管 Tools 和 Policy。结果就是三个 Agent 都很会说,但谁也不能干活;或者更糟,谁都能干任何事。前者像顾问团,后者像权限事故预演。

第三步:Agent 可以互相说话,但要有边界

用户提到一个很关键的点:AI Agent 可以和另一个 AI Agent 对话。

这非常有用。比如 Security Agent 发现接口缺少租户隔离,可以直接问 Architect Agent:

Security Agent:
  @architect 当前设计里 tenant_id 是从 token claims 里取,
  还是从 request body 里取?如果两者都有,以哪个为准?

Architect Agent:
  应该只信任 token claims,request body 里的 tenant_id 只能作为过滤条件,
  不能作为授权依据。我会把这一点写进设计约束。

这类对话能减少人类转述成本,也能让结论更清楚。

但 Agent-to-Agent 如果不加控制,也很容易陷入两个问题:

  • 循环对话:A 问 B,B 问 A,最后生成一部中篇小说。
  • 权限绕过:低权限 Agent 通过高权限 Agent 间接调用工具。

所以需要几条硬规则:

  1. 每个 Agent-to-Agent 消息必须在 room 内公开可见,默认不允许私聊。
  2. 每个任务设置最大轮次,比如 max_agent_turns = 6
  3. Agent 不能替另一个 Agent 调用工具,只能请求对方发表意见。
  4. 高风险动作必须回到 human approval。
  5. Router 要检测重复问题和循环引用。

这不是保守,而是工程经验。任何能自动循环的系统,最后都会找到一种方式把账单跑高。

第四步:上下文不是越多越好,要按角色裁剪

群聊历史会很快变长。如果每个 Agent 每次都拿完整 room history 去问模型,成本、延迟和噪声都会上来。

更合理的做法是为每个 Agent 构造自己的 context window:

Agent Context =
  System Prompt
  + Agent Role
  + Room Objective
  + Relevant Messages
  + Mention Thread
  + Selected Artifacts
  + Tool Results
  + Constraints / Policies

比如 Security Agent 不一定需要看到 Tester Agent 每条测试用例草稿,但一定要看到:

  • 原始需求
  • API 设计
  • 鉴权相关讨论
  • Architect Agent 的边界说明
  • 最新决策和未解决问题

这需要一个 Context Builder,它的职责不是把所有内容塞给模型,而是做选择:

def build_context(room, agent, message):
    thread = load_thread(message)
    relevant = retrieve_relevant_messages(
        room_id=room.id,
        query=message.content,
        filters={"roles": agent.interested_roles}
    )
    artifacts = select_artifacts(room, agent, message)

    return [
        system_prompt(agent),
        room_objective(room),
        policy_block(room.policy, agent),
        summarize_room_state(room),
        *thread,
        *relevant,
        *artifacts,
    ]

这里有个反直觉点:群聊越复杂,越需要有选择地遗忘。 不是丢掉审计记录,而是不把每一句废话都塞进模型上下文。人开会也一样,做会议纪要的人如果把每声“嗯嗯”都写进去,那不是负责,是报复。

第五步:需要一个主持人,可以是人,也可以是 Moderator Agent

群聊式 Multi-Agent 最大的产品挑战,是收敛。

多个 Agent 都能提出意见,但最后谁来合并?谁来判断冲突?谁来宣布“这个问题先这样定”?如果没有主持人,系统很容易从“协作”滑向“各说各话”。

我建议保留一个明确的 Moderator 角色:

  • 默认由 human 担任。
  • 对低风险任务,可以由 Moderator Agent 协助整理。
  • 最终决策必须标记为 human-approved,除非房间策略明确允许自动决策。

Moderator Agent 的职责不是装领导,而是做脏活:

  • 汇总不同 Agent 的观点。
  • 标记冲突和未决问题。
  • 提醒需要人类决策的点。
  • 把结论写成 artifact,比如设计文档、测试清单、执行计划。

一个好的群聊系统,应该把人类从“复制粘贴和整理格式”里解放出来,但不要把人类从“判断和负责”里删除。前者是生产力,后者是甩锅。

一个参考架构

如果从工程实现看,我会把系统拆成这些组件:

            ┌────────────────────┐
            │  Chat UI / Channel │
            └─────────┬──────────┘
                      │
                      v
            ┌────────────────────┐
            │  Message Service   │
            └─────────┬──────────┘
                      │ append event
                      v
            ┌────────────────────┐
            │ Conversation Store │
            └─────────┬──────────┘
                      │
                      v
            ┌────────────────────┐
            │ Conversation Router│
            └─────────┬──────────┘
                      │ dispatch
        ┌─────────────┼─────────────┐
        v             v             v
 ┌────────────┐ ┌────────────┐ ┌────────────┐
 │ Architect  │ │ Security   │ │ Tester     │
 │ Agent      │ │ Agent      │ │ Agent      │
 └─────┬──────┘ └─────┬──────┘ └─────┬──────┘
       │              │              │
       v              v              v
 ┌──────────────────────────────────────────┐
 │ Context Builder + Policy + Tool Gateway  │
 └──────────────────────────────────────────┘

这里有几个关键边界:

  • Message Service 只负责接收和落库,不直接调用模型。
  • Conversation Store 是事实源,所有消息和 tool result 都可审计。
  • Router 负责决定唤醒谁,而不是 Agent 自己抢话筒。
  • Context Builder 负责按 Agent 裁剪上下文。
  • Tool Gateway 统一做鉴权、参数校验、审计和审批。

如果做企业内部系统,我会再加三样东西:

  1. Policy Engine:控制谁能进房间、Agent 能看什么、工具能不能调用。
  2. Artifact Store:存设计文档、代码片段、测试结果、决策记录。
  3. Evaluation Hook:记录每次 Agent 输出是否被采纳,用于后续改进。

关键流程:一条消息如何变成多 Agent 协作

可以把一次群聊处理拆成八步:

  1. 用户发送消息,带上 mentions、附件和 room id。
  2. Message Service 写入 Conversation Store。
  3. Router 根据 mention、reply、policy 决定要唤醒哪些 Agent。
  4. 对每个 Agent,Context Builder 构造独立上下文。
  5. Policy Engine 检查该 Agent 是否允许处理这条消息。
  6. Agent 调用模型,必要时通过 Tool Gateway 调工具。
  7. Agent 输出作为新消息写回 room。
  8. Moderator 汇总结论,或等待 human 继续追问。

用 sequence diagram 表示就是:

sequenceDiagram
    participant H as Human
    participant MS as Message Service
    participant R as Router
    participant A as Architect Agent
    participant S as Security Agent
    participant T as Tester Agent
    participant G as Tool Gateway

    H->>MS: @architect @security @tester review API design
    MS->>R: message_created
    R->>A: dispatch with scoped context
    R->>S: dispatch with scoped context
    R->>T: dispatch with scoped context
    A->>MS: architecture review message
    S->>G: read artifact / check policy
    G-->>S: tool result
    S->>MS: security findings
    T->>MS: test strategy
    H->>MS: approve decisions / ask follow-up

这个流程不神秘,难的是边界。只要边界清楚,第一版可以很小。

第一版 MVP 怎么做

如果让我从零开始做,我不会一上来就做“自主多 Agent 社会”。我会先做一个朴素但可用的 MVP。

MVP 目标

支持三件事:

  1. 人可以在一个 room 里 @一个 Agent 提问。
  2. 人可以 @多个 Agent 同时提问。
  3. Agent 可以在 room 内 @另一个 Agent 追问,但有轮次限制。

MVP 数据表

create table rooms (
  id text primary key,
  title text not null,
  created_by text not null,
  policy_json text not null,
  created_at timestamp not null
);

create table participants (
  room_id text not null,
  participant_id text not null,
  participant_type text not null, -- human | agent
  role text not null,
  config_json text not null,
  primary key (room_id, participant_id)
);

create table messages (
  id text primary key,
  room_id text not null,
  sender_id text not null,
  sender_type text not null,
  content text not null,
  mentions_json text not null,
  reply_to text,
  turn_index integer not null,
  created_at timestamp not null
);

注意,turn_index 很重要。它可以帮你限制一次任务里的 Agent 轮次,防止循环对话。

MVP 路由策略

MAX_AGENT_TURNS = 6

def handle_message(room_id, message):
    save_message(message)

    if count_agent_turns(room_id, root_message_id(message)) >= MAX_AGENT_TURNS:
        save_system_message(room_id, "Agent turn limit reached. Waiting for human input.")
        return

    agents = route_message(load_room(room_id), message)

    for agent in agents:
        context = build_context(room_id, agent, message)
        response = run_agent(agent, context)
        save_message(response)

第一版甚至可以不用复杂检索。先把 room objective、当前 thread、最近 N 条消息、被引用 artifact 放进去,就能跑起来。

几个容易踩的坑

1. 把群聊做成“自动回复风暴”

默认所有 Agent 都回复,是最常见也最烦人的错误。Agent 的积极性要被路由器管理,不能靠模型自觉。

2. Agent 角色写得太虚

“你是一个有帮助的 AI 助手”这种角色,在群聊里没有意义。Architect、Security、Tester、Product、SRE 这些角色要有清晰关注点、输出格式和停止条件。

3. 没有 artifact,只有聊天记录

聊天是过程,不是结果。每次协作最好沉淀一个 artifact:设计文档、决策记录、测试清单、风险列表、PR 描述。否则群聊越聊越长,价值越藏越深。

4. 没有权限边界

群聊里最危险的不是 Agent 会说错话,而是它能做错事。工具调用必须经过统一 gateway,尤其是发消息、改代码、部署、访问密钥、调用外部 API 这类动作。

5. 人类没有最后控制权

Multi-Agent 系统容易给人一种“它们自己会商量好”的错觉。可以让 Agent 提建议、整理冲突、生成方案,但关键决策最好由人确认。系统要明确标记哪些结论是 suggested,哪些是 approved

我的设计原则

如果只能带走几条,我会选这几条:

  • Room 是边界:每个群聊都有主题、成员、权限和生命周期。
  • Message 是事实源:所有输入、输出、工具结果都落成可审计事件。
  • Router 控制发言权:不要让 Agent 自由抢答。
  • Context 按角色裁剪:不同 Agent 看到不同重点。
  • Tool Gateway 管动作:模型不能直接碰高风险能力。
  • Moderator 负责收敛:群聊必须产出 artifact 或 decision。
  • Human owns accountability:AI 可以协作,人类负责拍板。

可以直接抄的 Prompt 模板

给每个 Agent 一个群聊专用系统提示,会比普通 1:1 prompt 稳定很多。

You are {agent_name}, a participant in a group chat.

Your role:
- {role_description}

Group chat rules:
- Respond only when you are mentioned, replied to, or explicitly asked by the moderator.
- Keep your response focused on your role.
- If another agent made a useful point, build on it instead of repeating it.
- If you disagree, explain the concrete reason and propose a fix.
- Do not call tools unless the current room policy allows it.
- Do not ask another agent to perform actions outside its role or permission.
- When a human decision is required, mark it clearly as "Needs human decision".

Output format:
- Findings
- Questions
- Recommendations
- Risks

这个模板不华丽,但有用。群聊里的 Agent 最重要的不是“聪明地发挥”,而是知道什么时候说、说多少、什么时候停。

结尾:把 AI 从“问答对象”变成“协作成员”

1:1 Chat 是 AI 产品的起点,因为它符合人的直觉:我问,你答。但工程协作从来不是单人单线。真实工作里,我们需要不同角色互相补位,也需要有人把分歧收敛成决定。

多 Agent 群聊的价值,正在于把这个过程产品化:

  • 人可以同时询问多个 Agent。
  • Agent 可以互相追问和补充。
  • 系统可以记录讨论、沉淀 artifact。
  • 工具调用和权限可以被统一治理。
  • 最后由人类把建议变成决策。

我的判断是:未来很多 Agent 应用不会只长得像聊天框,而会更像一个“可编排的工作群”。只是这个群里,有人类、有 Agent、有工具、有记忆,也有边界。

最后给一个小清单,方便明天开工。

Multi-Agent Group Chat 检查清单

  • [ ] 是否定义了 Room / Participant / Message / Task 四个核心对象?
  • [ ] 消息是否支持 mentionsreply_toattachmentsvisibility
  • [ ] 是否有 Router 控制哪些 Agent 被唤醒?
  • [ ] Agent-to-Agent 是否默认公开、可审计、有最大轮次?
  • [ ] 每个 Agent 是否有清晰 role、tools、memory scope 和 permission?
  • [ ] Context Builder 是否按角色裁剪上下文,而不是塞完整群聊历史?
  • [ ] 高风险工具是否统一经过 Tool Gateway?
  • [ ] 是否有 Moderator 汇总冲突、决策和 artifact?
  • [ ] 系统能否区分 suggested decision 和 human-approved decision?
  • [ ] 每次群聊是否最终沉淀一个可复用结果?

如果 1:1 Chat 像找一个聪明人喝咖啡,那么 Multi-Agent Group Chat 更像开一场小型设计评审。咖啡可以随便喝,评审最好有议程、有主持、有纪要、有结论。AI 也一样。