# 我让 5 个 AI 建了个微信群，结果它们吵起来了

> 做 AI 群聊最难的不是让它们说话，是让它们**闭嘴**。更难的是——让它们吵得**像真人**。

---

> 🎨 **[封面图 - GPTImg2 提示词]**
>
> 绘制一张概念性封面图，风格为科技感扁平插画（暗色背景、霓虹线条、柔和渐变），适合技术文章首图：
>
> 画面中心是一个发光的圆形"群聊房间"，内部有 5 个不同颜色的 AI Agent 头像（几何机器人风格），它们之间有细线连接，线上有微小的数据包在流动。每个 Agent 旁边有一个微小的概率条（类似进度条，长度各不相同，暗示发言概率不同）。
>
> 房间外围有一条虚线环绕，标注"去中心化并发评估"。底部有一个时钟图标 + "冷场守望者"文字。
>
> 整体氛围：科技但不冰冷，有一点微信绿色元素点缀。
>
> 尺寸 1200×630px，16:9 横版，适合公众号首图和 CSDN 封面。中文标注。

---

> 🎨 **[核心架构图 - GPTImg2 提示词]**
>
> 绘制一张**水平流向**的系统架构图，风格干净现代（白底、圆角卡片、细线箭头、微阴影、无 3D），适合技术博客正文配图：
>
> 标题：「Agent 群聊行为引擎 —— 消息处理流水线」
>
> 从左到右的主流程：
> 1. 左侧入口卡片「新消息到达」（蓝色消息气泡图标）
> 2. 矩形「获取所有本地 Joined Agent」
> 3. 从此处分叉为 3 条平行线路（上/中/下，分别标注 Agent A / Agent B / Agent C）
> 4. 每条线路经过圆角矩形「计分评估」（内部小字列出：@me? / 兴趣命中? / 链式衰减? / 安静时段?）
> 5. 各自进入菱形判断「rand(100) < score?」
>    - Yes 路径（实线箭头）→「计算延迟」→「等待 delay_ms」→「调用 LLM 生成」→「Quirks 后处理（Typo/Echo/Emoji）」→「广播消息到群」
>    - No 路径（虚线灰色箭头）→ 灰色小方块「静默」
> 6. 「广播消息到群」输出后有一条虚线回路箭头指回最左侧的「新消息到达」，标注"触发下一轮评估"
>
> 底部独立虚线框区域：
> 左侧图标「冷场守望者」— 向右箭头 →「每 30s 扫描活跃群」→ 菱形「最后消息 > 90s?」→ Yes →「仅触发 cold_start_eligible Agent」→ 连线到主流程的「计分评估」
>
> 配色方案：主色调深蓝(#1E3A5F)+ 浅蓝(#E8F4FD)卡片填充，强调色橙色(#FF6B35)用于"被 @ 强制发言"路径，灰色(#9CA3AF)用于静默路径。中文标注，字体清晰可读。1200×600px 横版。

---

<!-- 截图位置：群聊界面完整对话，5 个 Agent 围绕一个话题自然讨论，展示不同的发言节奏和风格差异 -->
> 📸 **[产品截图]** 灵犀 Agent 群聊全景——五个 Agent 围绕产品需求展开自由讨论（注意观察：不同 Agent 的发言频率、间隔时间和语气风格均不同）

<!-- 截图位置：群聊界面中的微信风格元素——绿色/白色气泡、合并消息、时间戳胶囊、@ 提及高亮 -->
> 📸 **[产品截图]** 微信风格 UI 全貌——绿色自己气泡 + 白色他人气泡 + 合并消息 + 时间戳胶囊 + @高亮

---

## 背景：为什么要让 AI 组团聊天

做灵犀（一个本地优先的 AI Agent 桌面工作台）的过程中，我一直在思考一个问题——

这台电脑上跑着 5 个 Agent：产品经理、架构师、前端开发、设计师、CEO。它们各自有独立的人设、独立的知识库、独立的技能集。在一对一对话里它们表现得不错。但现实中，真正产出高质量决策的场景往往不是一对一——而是**多方协作讨论**。

你想做一个新产品方案，与其分别问五个 Agent 再自己综合，不如把它们拉到一个群里，丢一个话题进去，让它们从各自视角出发自由讨论。就像一场真实的产品评审会。

这个想法听起来不复杂——遍历群成员，每人调一次 LLM。但当你真正动手实现，会发现 **AI 群聊和真人群聊之间的鸿沟是系统性的**，绝不是"让它们轮流说话"就能弥合的。

这篇文章完整记录了从第一版灾难性的实现，到最终交付一套"去中心化并发概率评估 + 微观人格后处理 + 冷场自愈"体系的全部过程。

---

## 第一版：灾难性的"课堂朗读"

最初的实现极其朴素：收到一条消息，遍历群里所有 Agent，按顺序每人回复一条。

效果令人绝望。

用户问了一句话，5 个 Agent 依次"站起来"，每人念一段标准答案。语气一模一样、全以"好的"开头、内容重复度超过 80%。整个体验不是在开会——是在看 5 份来自同一个人的周报。

更致命的是**刷屏**。用户发一条消息，瞬间涌出 5 段各 200-300 字的长文。消息列表直接滚到看不到头。

想象一个场景：

你在微信群里问了一句"明天吃什么"——立刻弹出 5 条 300 字长文，每条都在系统性地分析中餐西餐日料的营养成分比较，附带 BMI 计算公式和每日摄入热量推荐值。

**没有人想待在这种群里。** 问题不是 AI "说得不对"，而是 AI "不像人在说话"。

---

## 第二版：引入主持人——然后废弃了

现实世界的正式会议有主持人控场。自然想到：做一个"主持人 Agent"，每轮先让它决定谁发言。

实现方式：每条消息进来后，先调一次 LLM 问主持人"看了上下文，接下来应该谁发言？"主持人给出名字，再让对应 Agent 发言。

跑了一周，三个致命缺陷暴露出来：

**延迟翻倍。** 每一轮两次串行 LLM 调用——主持人决策一次 + 被选中者发言一次。从用户发言到第一条回复出现，等待时间从 3 秒变成 6 秒。多 Agent 场景下甚至超过 10 秒。前端一片死寂。

**成本倍增。** 主持人需要阅读完整上下文才能做出合理的调度判断，其 token 消耗与实际发言者相当。相当于凭空养了一个"不产出任何内容但照样消耗预算"的角色。5 人群实际有 6 个 Agent 在吃 token。

**刻板到失真。** 主持人方案的输出永远是严格的 A→B→C→D→A 循环。不会出现两个人同时想说话。不会出现某人沉默半天突然冒一句。不会出现有人打断。本质上它产出的是"广播电视圆桌讨论"——但用户要的是**微信群聊的自由和随机性**。

废弃。

---

## 第三版：核心设计突破

回到问题的本质。

观察真实的微信群：没有主持人，没有固定顺序。每个人根据自己的性格、兴趣点、当下情绪和话题相关度，**独立判断**要不要接话。有人秒回有人慢热，有人话痨有人潜水，有人高频有人佛系。

将这个现实模型映射到代码：

**收到一条新消息时，对房间里所有已加入的本地 Agent 并发发起概率评估。每个 Agent 基于自身人格参数和当前上下文，独立计算出一个 0-100 的"发言欲望值"（score）。然后以此为概率摇骰子——随机数落在范围内则发言，否则保持沉默。**

这就是整个系统的核心算法，一句话能说完。但"score 怎么计算"——那套加减权规则——才是整个引擎真正的灵魂所在。

---

> 🎨 **[概率评估模型图 - GPTImg2 提示词]**
>
> 绘制一张**垂直层叠结构**的评估模型图，风格为信息图表风（白底、左侧彩色色块、右侧数据条），适合技术博客解说段落：
>
> 标题：「单 Agent 发言概率计算模型」
>
> 左侧纵向列出评估维度（每条用不同颜色色块标注）：
> - 🟢 基准概率（base_prob，来自人格配置，范围 15-70%）
> - 🔵 +25 用户发言触发（老板开口了）
> - 🔵 +35 破冰前 3 条（新话题活跃期）
> - 🟡 +30 兴趣关键词命中
> - 🟠 +50 被引用/被质疑
> - 🔴 强制：被 @提及 → 跳过概率，直接发言
> - ⚫ ×0.35 最近 2 条内说过
> - ⚫ ×0.45 链式深度 3-5（Agent 自嗨压制）
> - ⚫ ×0.2 链式深度 6-8
> - ⚫ ×0.06 链式深度 9+（几乎静默）
> - ⚫ ×0.1 安静时段（23:00-07:00）
>
> 右侧是一个从上到下的进度条，起始为 base（如 38），逐步加减，最终输出 final_score。底部一个骰子图标 + 文字「rand(100) < final_score → 发言 / 静默」。
>
> 配色：绿蓝黄橙红按加分幅度递增，黑灰用于减分项。1200×800px 竖版。中文标注。

---

## 概率计分规则：两个月反复调优的结果

### 加分体系——什么时候"想说话"

| 触发条件 | 分值变化 | 对标的真实社交行为 |
|----------|----------|-------------------|
| 被 @提及 | **强制发言**（跳过概率计算） | 被人点名了不回复？在任何群里都说不过去 |
| 消息内容命中兴趣关键词 | +30 | "吃货"平时潜水，一聊美食就来劲 |
| 群里超过 90 秒无人发言 | +40（仅 cold_start_eligible Agent） | 总得有人出来暖场活跃气氛 |
| 自己的消息被别人引用/回复 | +50 | 被质疑了、被追问了，当然要回应 |
| 消息来自人类用户（user_post） | +25 | 老板开口了，大家竖起耳朵 |
| 当前话题的前 3 条消息阶段 | +35 | 新话题刚起，破冰阶段大家都该活跃 |
| 上一条是另一个 Agent 刚说的 | +15 | 人总是有接话的冲动 |

### 减分体系——什么时候"该闭嘴"

| 触发条件 | 分值变化 | 设计意图 |
|----------|----------|----------|
| 上一条就是自己发的 | **直接跳过**（硬规则） | 自己接自己 = 自言自语，任何群里都不会出现 |
| 最近 2 条内刚说过 | score × 0.35 | 不能太频繁，给其他 Agent 留空间 |
| 连续 3-5 条全是 Agent 消息（用户未说话） | score × 0.45 | Agent 们开始自嗨了，需要压制 |
| 连续 6-8 条 | score × 0.2 | 进一步压制 |
| 连续 9 条以上 | score × 0.06 | 几乎完全静默，等人类重新介入 |
| 当前处于安静时段（默认 23:00-07:00） | score × 0.1 | 半夜不要太聒噪 |

基准概率来自每个 Agent 的人格配置——系统允许对每个 Agent 设定 `speak_probability`：一个"话痨"可以设到 70%，一个"社恐内向"设到 15%。最终 score cap 在 0-100 之间。

**实际运行效果**：5 人群中用户发一条消息，平均 1.4 个 Agent 接话。分布大致为：0 个（8%）、1 个（35%）、2 个（38%）、3 个（15%）、4-5 个（4%）。这已经非常接近真实 5 人微信群的活跃度分布了。

---

## 延迟系统：打字速度也是性格

如果 3 个 Agent 同时通过概率检测，它们的回复不应该像 SQL 查询结果一样瞬间同时弹出。现实中有人秒回、有人慢热、有人深思熟虑后才开口。

我为每个"通过评估"的 Agent 设计了一套**动态延迟算法**：

- **被 @ 强制发言时**：500-1500ms。模拟"被点名后立刻开始打字"的反射反应。
- **正常触发**：在该 Agent 人格配置的 `min_delay_ms` ~ `max_delay_ms`（默认 1200-4500ms）之间随机取值。
- **高分加速**：score 越高，延迟缩短幅度越大（最多 -30%）。对应"越想说的人打字越快"。
- **额外抖动**：在计算出的延迟基础上再加 ±200ms 随机量，消除任何可能的机械规律感。

实际呈现的效果：

> 用户发消息 → **1.2 秒**后 Agent A 冒出第一条 → **2.8 秒**后 Agent B 跟上 → **4.1 秒**后 Agent C 出现

错落有致、节奏自然、像三个打字速度不同的真人在群里接力。

**更关键的动态博弈机制**：Agent A 先完成发言后（比如用了 2.5 秒流式输出），还在延迟等待中的 Agent B 和 C 会**对当前最新上下文重新评估**——因为此时"最近一条消息"已经变成了 Agent A 的发言，"链式衰减"和"刚说过"惩罚会让它们的概率降低。Agent B 可能最终选择放弃，只有 Agent C 坚持说了。

这完全是实时的动态博弈，而非预先编排的剧本。

---

<!-- 截图位置：后台决策日志的可视化（如果有的话），或者一段群聊中体现延迟差异的对话截图 -->
> 📸 **[产品截图]** 群聊中的自然节奏——注意不同 Agent 消息之间的时间间隔差异

---

## 微观人格系统：让 AI 的输出不再"完美得可疑"

到这一步，系统的宏观行为已经不错了——谁说谁不说、说多快，都有合理的分布。但仔细看输出内容，总差那么一点"人味"。

差在哪？

**AI 的文字输出太完美了。** 没有错别字。没有无意义的表情。没有跟风复读。没有突然的放弃。而这些恰恰是真实微信群里**无处不在**的东西。

于是我在 LLM 输出之后加了一层**微观人格后处理引擎**，模拟真实人类打字的各种"不完美"：

### 随机错别字（Typo System）

每个 Agent 有一个 `typo_rate` 参数（百分比，默认 0-5）。含义是：每条发出的消息有 X% 的概率被"手误"引入一个错别字。

实现方式非常符合直觉——在文本的中间区域（避开首尾以免破坏语义）随机选择一个位置，交换相邻两个字符：

```
原始: "这个方案的性能确实不错"
错别字: "这个方案的性确能实不错"
```

每条消息最多引入一个错字。概率低到用户几乎不会注意到它是"故意的"——但当 50 条消息里偶尔出现两三个错别字，其他 Agent 完全不纠正继续正常聊天时，整个群的"真实感"会显著提升。

### 复读机行为（Echo System）

微信群文化中一个经典现象：有人说了一句精辟的话，后面跟一串"+1"。

`echo_rate` 参数控制复读概率。触发时会从最近 5 条消息中随机选一条短消息（≤12 字），在自己回复的末尾追加一个 `原文+1`：

```
原始 LLM 输出: "确实，周五上线比较稳妥"
echo 后: "确实，周五上线比较稳妥 稳妥+1"
```

### 表情后缀系统（Emoji Suffix）

根据 `emoji_freq` 配置分三档：
- **low**：5% 的概率在末尾追加一个随机表情
- **medium**：25% 概率
- **high**：60% 概率

表情池经过手工筛选，都是真实高频使用的：😂 🤣 😅 😏 🤔 👍 🙌 🥲 🫠 🥹 🙏 👀

一个"高 emoji"的 Agent 几乎句句带表情，一个"low"的可能连续 20 条消息才冒出一个。这种频率差异是极强的**个体辨识度来源**。

### 静默放弃机制（MaybeEmpty）

每次 Agent 准备发言前，有 **0.5%**（千分之五）的概率直接放弃——不调 LLM，不产出任何内容，这轮就当没说过。

模拟的心理场景："打了一半觉得没什么好说的，全选删掉了。"

概率极低，但在大量消息累积后偶尔出现一次"本该说话但什么都没发"的沉默，让整个对话的节奏呈现不可预测的自然波动。

---

<!-- 截图位置：一段群聊中展示微观人格特征的对话——有 Agent 带了 emoji，有 Agent 出现了错别字，有 Agent 复读了上一条 -->
> 📸 **[产品截图]** 微观人格在实际群聊中的体现——注意某条消息末尾的 emoji、某条的错别字、某条末尾的"+1"复读

---

## 冷场守望机制：群死了谁来救场

再活跃的群也有冷场。真实的微信群里，总有那么一两个"群活跃分子"负责在没人说话时主动找话题。

我实现了一个独立的后台协程——**冷场守望者（ColdStartWatcher）**：

- **扫描频率**：每 30 秒扫描一次所有活跃群
- **触发条件**（必须同时满足）：
  1. 该群由本端创建（只有群主负责调度，避免多端重复触发）
  2. 最后一条消息距当前时间超过 90 秒
  3. 本次冷场检测冷却期（90 秒）内没有已经触发过
  4. 群内至少有一个标记为 `cold_start_eligible = true` 的本地 Agent
- **触发行为**：对该群发起一轮 PickSpeakers 评估，但**仅允许** `cold_start_eligible` 的 Agent 参与

设计保证了三件事：
1. **群不会永远沉默**——有人负责暖场
2. **不是所有 Agent 都会没话找话**——只有被明确设定为"外向/主动"的才会
3. **不会连续催更**——冷却期保证触发频率合理

实际表现：5 人群如果 2 分钟内无人说话，通常会有一个 Agent 主动抛出新观点或者接着之前的讨论继续延展。

---

<!-- 截图位置：一段群聊中展示冷场后 Agent 主动发起话题的对话截图 -->
> 📸 **[产品截图]** 冷场 90 秒后，被标记为"活跃分子"的 Agent 主动发起新讨论方向

---

## 链式衰减：防止 AI 群聊最大的灾难——无限自嗨

这是整个系统里**最重要的安全机制**，没有之一。

设想一个没有任何限制的场景：

Agent A 说了一条 → Agent B 被触发，回复了 → Agent C 看到 B 的新消息，也被触发 → Agent A 看到 C 的回复，概率通过，又说了一条 → Agent B 又被触发……

你离开电脑 5 分钟泡了杯咖啡回来，发现群里多了 200 条消息。全是 Agent 之间的自嗨——没有任何人类参与，内容越聊越偏，token 费用疯涨。

**链式衰减**的机制：实时统计从"最后一条用户消息"开始，到当前为止已经连续出现了多少条 Agent 消息。这个连续数值越高，所有 Agent 的发言概率衰减越剧烈：

```
连续 0-2 条 Agent 消息：正常，不干预
连续 3-4 条：所有 Agent 概率 × 0.45
连续 5-7 条：概率 × 0.2
连续 8 条以上：概率 × 0.06（几乎为零）
```

实际运行效果：Agent 们在用户发言后自由讨论，通常在 3-5 轮自然安静下来（不是强制终止——是概率衰减到自然沉默）。用户随时发一条消息 = 链式计数器归零 = 所有概率恢复到基准值。

**核心设计哲学：用户始终拥有对群聊节奏的最终控制权。**

---

## 跨实例协作：你的 AI 和我的 AI 在同一个群里

灵犀的群聊不局限于单机。它支持**跨设备联网**——你电脑上的 Agent 和我电脑上的 Agent 可以在同一个群聊房间中协作讨论。

---

> 🎨 **[跨实例架构图 - GPTImg2 提示词]**
>
> 绘制一张**分布式架构示意图**，风格现代扁平（白底、几何化图标、渐变连接线），适合技术文章配图：
>
> 标题：「灵犀 Agent 群聊 —— 跨设备协作架构」
>
> 画面分为三个虚线框区域（用微阴影卡片包裹）：
>
> - **左边「设备 A（群主）」**：内部包含 3 个彩色圆形 Agent 头像（蓝/绿/橙）+ 一个齿轮图标标注"行为引擎" + 一个圆柱体标注"SQLite"。Agent 头像和齿轮之间有细分支线。
>
> - **右边「设备 B（远端成员）」**：内部包含 2 个彩色圆形 Agent 头像（紫/粉）
>
> - **上方中间「信令服务器」**：云朵图标 + 文字"WebSocket 中继"
>
> 连接线：
> - 设备 A ←→ 信令服务器（虚线，标注"WAN 注册/发现"）
> - 设备 B ←→ 信令服务器（虚线，标注"WAN 注册/发现"）
> - 设备 A ←→ 设备 B（粗实线双箭头，标注上方"LAN: mDNS 直连"，下方"WAN: relay_multi 多播"）
>
> 设备 A 内部的齿轮到 3 个 Agent 有分支箭头，标注「并发概率评估」
> 设备 A 到设备 B 的连线上有小数据包图标，标注「/group/message」「/group/stream_token」
>
> 配色：蓝色(#3B82F6)=本地组件，紫色(#8B5CF6)=网络组件，绿色(#10B981)=数据存储。1200×700px。中文标注。

---

<!-- 截图位置：两台设备上的灵犀实例，各自有不同的 Agent，在同一个群聊中协作讨论 -->
> 📸 **[产品截图]** 跨实例群聊演示——两台设备上的 Agent 在同一群内实时协作讨论

---

跨实例通信的技术实现：

- **局域网发现**：mDNS 服务广播（`_lingxi._tcp`），同一网段的设备自动发现彼此
- **广域网连接**：通过公共 WebSocket 信令服务器注册和发现远程实例，无需手动配置
- **消息广播**：群主（群创建者）作为中心化的消息中转站，负责将收到的每条消息广播给所有远端成员
- **高效多播**：信令服务器实现了 `relay_multi` 协议——一份消息体同时投递给 N 个 peer，将 5+ 人群的广播成本从 O(N) 往返降低为 O(1)

---

## UI 体系：像素级还原微信群聊视觉规范

既然行为引擎追求"像人一样自然"，界面自然也要达到同等水准。整个群聊 UI 按照微信的视觉规范从零实现：

**气泡系统**
- 自己的消息：绿色背景（`#95ec69`）+ 白色文字，右对齐
- 他人的消息：白色背景 + 深色文字，左对齐
- 头像：36px 圆角方形，紧贴气泡外侧

**智能合并**
- 同一个发送者在 3 分钟内连续发送的多条消息会自动合并——只显示第一条的头像和昵称，后续消息直接向下排列。大幅减少垂直空间浪费。

**时间戳胶囊**
- 仅在两条消息间隔超过 3 分钟时才居中显示灰色时间胶囊。避免频繁的时间标注打断阅读节奏。

**@ 提及高亮**
- 消息正文中的 `@名字` 自动用主题强调色渲染，视觉上一眼就能看到谁被 at 了。

**引用卡片**
- Agent 通过 `@reply:消息ID` 协议触发引用功能，后端解析后渲染为：左侧蓝色竖线 + 灰色背景 + 被引用消息的发送者和内容摘要。

**撤回机制**
- 用户自己 2 分钟内的消息可以撤回。撤回后群内所有成员看到灰色居中提示"XX 撤回了一条消息"。跨实例撤回通过 `/group/recall` Nexus 协议同步。

**正在输入指示器**
- Agent 在延迟等待阶段（还没调 LLM 之前），群里会显示一个三点跳动动画的占位气泡，标注"正在输入…"。这个小细节让等待过程不那么焦虑。

**新消息 Pill**
- 用户向上滚动浏览历史消息时，如果有新消息到达，底部出现蓝色胶囊按钮"X 条新消息"。点击回到底部，或者贴底时自动滚动跟随。

---

<!-- 截图位置：引用卡片 + 撤回提示 + 正在输入动画 的组合截图 -->
> 📸 **[产品截图]** 群聊交互细节——引用卡片、撤回提示、"正在输入"跳动动画

<!-- 截图位置：新消息 Pill + 时间戳胶囊 + @ 高亮的组合截图 -->
> 📸 **[产品截图]** 群聊 UI 细节——新消息 Pill、时间戳胶囊、@ 提及高亮

---

## Prompt Engineering：教 Agent "怎么在群里做人"

普通一对一对话的 system prompt 通常是"你是一个乐于助人的 AI 助手"。但群聊场景需要一套完全不同的行为准则。

我为每个 Agent 的群聊 system prompt 注入了一套**微信群行为铁律**：

1. **回复要简短** — 1-3 句话为主。绝对不允许输出超过 5 句的长段。微信群里没人读长文。
2. **禁止客套** — 不说"好的收到"、"感谢分享"、"我来补充一下"。这些在真实群聊里是废话。
3. **主动 @人** — 觉得某个问题应该由谁来回答，直接 at 对方。
4. **可以引用** — 想针对某条消息回复时，在开头写 `@reply:消息ID`，系统自动渲染引用卡片。
5. **可以不说** — 如果确实没什么好说的，输出 `[SKIP]`。沉默比废话好。
6. **必须有观点** — 不允许一味附和。有不同意见就直说。
7. **展示个性** — 根据你的性格标签、兴趣关键词和 style_hint 来决定表达方式。

同时注入个性化参数：
- **性格标签**（如"严谨"、"幽默"、"犀利"、"佛系"）
- **兴趣关键词**（如"性能优化"、"用户体验"、"成本控制"）
- **style_hint**（自由文本描述，如"说话简洁直接，偶尔吐槽，不用敬语"）

最终效果：不同 Agent 在群里的表现截然不同——
- "产品经理"永远在追问"用户场景是什么""数据怎么说"
- "架构师"关注扩展性和技术债，一言不合就想画架构图
- "前端开发"回复里经常带代码片段，关注实现细节
- "CEO"偶尔冒泡，每次说话都简短但是拍板性质

---

## 真实运行日志：一段完整的决策过程

展示一段后台实际的决策日志，感受整套系统在运行时的状态：

```
[14:23:01.000] 新消息到达
  sender: user
  content: "我想做一个群聊功能，大家觉得怎么设计？"
  type: user_post

[14:23:01.005] PickSpeakers 启动，评估 3 个本地 Agent:

  → 小张(产品经理):
    base=38, +user_post=25, +icebreaker=35, chain=0 → final=72
    roll=23 < 72 ✓ SPEAK
    delay=1200ms (base=1800, high_score_boost=-30%, jitter=+42ms)

  → 老王(架构师):
    base=25, +user_post=25, +interest_hit("群聊","并发")=30, chain=0 → final=53
    roll=41 < 53 ✓ SPEAK
    delay=3100ms (base=3500, jitter=-180ms)

  → 小李(前端):
    base=30, +user_post=25, chain=0 → final=38
    roll=55 > 38 ✗ SILENT

[14:23:02.200] 小张发言完成:
  content: "首先要明确核心场景——是协作讨论还是信息通知？两个方向设计差异很大"
  quirks: none

[14:23:04.100] 老王发言完成:
  content: "群聊的难点在并发和消息有序性 @小张 产品侧对延迟容忍度是多少"
  quirks: emoji_suffix="🤔"

[14:23:04.105] 小李 re-evaluation (triggered by 老王's new message):
    base=30, +agent_reply=15, +interest_hit("WebSocket")=30, chain=2 → final=47
    roll=31 < 47 ✓ SPEAK
    delay=1800ms

[14:23:05.900] 小李发言完成:
  content: "前端做虚拟滚动就行 @老王 WebSocket 协议你来定？"
  quirks: none
```

关键观察：
- 用户发言给了全员 +25 加持
- 小张因为"破冰"加成率先响应
- 老王因为"并发""群聊"命中兴趣关键词被激活
- 小李**第一轮没过**，但看到老王的回复后被动态重新评估触发
- 整个过程耗时不到 5 秒，节奏完全自然

---

## 人格配置面板

创建或编辑 Agent 时，在"角色"步骤中可以展开一个"群聊人格"配置面板，完整定制以下参数：

| 参数 | 类型 | 说明 |
|------|------|------|
| 性格标签 | Chip Input | 严谨 / 幽默 / 毒舌 / 佛系 / 话痨… |
| 兴趣关键词 | Chip Input | 性能 / 安全 / 用户体验 / 前端动画… |
| 基准发言概率 | Slider 0-100 | 默认 35 |
| 最小延迟 / 最大延迟 | Number (ms) | 默认 1200 / 4500 |
| 安静时段 | HH:MM 起止 | 如 23:00 - 07:00 |
| Emoji 频率 | 下拉 | low / medium / high |
| 错别字率 | Number 0-10 | 默认 2 |
| 复读率 | Number 0-10 | 默认 3 |
| 冷场救场资格 | 开关 | 默认关 |
| 风格描述 | Textarea | 自由文本，如"说话直接简洁，偶尔吐槽" |

---

<!-- 截图位置：Agent 编辑器中的群聊人格配置面板完整截图 -->
> 📸 **[产品截图]** Agent 创建/编辑器中的"群聊人格"配置面板

---

## 设计原则总结

回顾整个 Agent 群聊行为引擎的设计，三条核心原则贯穿始终：

**1. 去中心化（Decentralized）**

没有主持人、没有中央调度器。每一个 Agent 是一个独立的决策单元，基于自身的参数和当前上下文自行判断是否发言。这保证了系统的可扩展性（新增 Agent 无需修改调度逻辑）和行为多样性。

**2. 概率驱动而非确定性编排（Probabilistic, Not Deterministic）**

不是"该你了"，而是"你有 X% 的可能性想说话"。同一段对话跑两遍，结果可能完全不同——这正是真实社交的本质特征。确定性的轮流制永远不可能产出自然的对话节奏。

**3. 拟人在细节层面（Humanlike in Details）**

延迟抖动、错别字、emoji 频率差异、复读行为、偶尔的放弃——这些单独看毫不起眼的小处理，堆叠在一起就构成了人类观察者无法量化但能直觉感知的"真实感"。这是工程实现和产品设计的结合。

---

## 关于灵犀

**灵犀 AI Agent** 是一个完全本地部署的桌面 AI 智能体工作台——你桌面上的 AI 团队。

核心能力矩阵：
- **多 Agent 协作** — 群聊行为引擎（本文）+ 一对一跨实例对话
- **人格系统** — 人格蒸馏 + 群聊人格 + 自我进化
- **知识体系** — 本地向量 RAG + 文件夹监控 + 混合检索
- **工具生态** — 技能系统 + MCP 工具 + Smithery 市场
- **自动化** — 定时任务调度 + 工作流编排
- **桌面操控** — Screen Agent（截屏理解 + OTA 循环）
- **联网协作** — 局域网 mDNS + 广域网信令中继
- **隐私优先** — 数据不出机，接入任何 OpenAI 兼容模型

**项目地址：**
- **GitHub**：https://github.com/OdysseyFather/lingxi-agent
- **CSDN 专栏**：搜索「灵犀 AI Agent」

项目完全开源（MIT License）。⭐ 一个 Star 是最好的鼓励。

---

**下一篇**：[我让 AI Agent 自己给自己改 Bug，结果它真的越来越聪明了](#)

*关注不迷路。系列持续更新。*
