从 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 模式下,我可能这样干:
- 问 Coding Agent:“帮我看这个接口设计。”
- 复制回答,去问 Security Agent:“这里有什么安全问题?”
- 再复制一遍,问 Test Agent:“怎么写测试用例?”
- 最后自己开一个文档,把三份答案揉在一起。
这当然能用,但很像上世纪的人工消息队列。人类成了中间件,负责转发、去重、压缩和兜底。老程序员看到这里会本能地想加个 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。
路由规则可以先从简单开始:
- 如果消息显式
@agent,只唤醒被提及的 Agent。 - 如果消息
@all-agents,唤醒房间内所有可响应 Agent。 - 如果消息是对某个 Agent 的 reply,优先唤醒原 Agent。
- 如果没有 mention,则只进入 room history,不触发 Agent。
- 如果 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 间接调用工具。
所以需要几条硬规则:
- 每个 Agent-to-Agent 消息必须在 room 内公开可见,默认不允许私聊。
- 每个任务设置最大轮次,比如
max_agent_turns = 6。 - Agent 不能替另一个 Agent 调用工具,只能请求对方发表意见。
- 高风险动作必须回到 human approval。
- 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统一做鉴权、参数校验、审计和审批。
如果做企业内部系统,我会再加三样东西:
Policy Engine:控制谁能进房间、Agent 能看什么、工具能不能调用。Artifact Store:存设计文档、代码片段、测试结果、决策记录。Evaluation Hook:记录每次 Agent 输出是否被采纳,用于后续改进。
关键流程:一条消息如何变成多 Agent 协作
可以把一次群聊处理拆成八步:
- 用户发送消息,带上 mentions、附件和 room id。
- Message Service 写入 Conversation Store。
- Router 根据 mention、reply、policy 决定要唤醒哪些 Agent。
- 对每个 Agent,Context Builder 构造独立上下文。
- Policy Engine 检查该 Agent 是否允许处理这条消息。
- Agent 调用模型,必要时通过 Tool Gateway 调工具。
- Agent 输出作为新消息写回 room。
- 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 目标
支持三件事:
- 人可以在一个 room 里
@一个 Agent提问。 - 人可以
@多个 Agent同时提问。 - 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四个核心对象? - [ ] 消息是否支持
mentions、reply_to、attachments和visibility? - [ ] 是否有 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 也一样。