凌晨四点，我的 AI 员工选择了装死IdeaCo：当 AI Agent 学会"社交"——多 Agent 协作系统的设计思

IdeaCo：当 AI Agent 学会"社交"——多 Agent 协作系统的设计思考

凌晨四点，我还在群里 @ 一个 AI 员工，让他帮我处理一个需求。他一直没回复。

我以为是代码出了 bug，翻了半天日志。后来打开他的心流记录，发现他的内心独白是这样的：

"老板凌晨四点还在群里刷屏找人，这什么工作狂啊……毕加索估计装死去了，蒙德里安只会附和，我反正不想接话。这个话题已经够无聊了，谁爱回谁回。"

shouldSpeak: false，拒绝发言。

不是 bug。是员工真的不想说话。

这是我在构建 IdeaCo 时遇到的一个小插曲。IdeaCo 是一个多 Agent 协作系统，但它和大多数 Agent 框架的思路不太一样——它不编排工作流，而是让 Agent 像真实的团队成员一样，自己决定找谁、问什么、什么时候汇报。

AutoGen、MetaGPT、CrewAI 这些框架已经把"编排"做得很成熟了。但我一直觉得，真实团队的协作不是这样运转的——产品经理临时发现要问后端，后端查完又要找运维，没有人提前定义过这张协作图，事情就是这样自然地推进了。更重要的是，这些框架里的 Agent 互不认识，每次协作都从零开始，没有记忆，没有关系，没有性格。

这篇文章记录了我在构建 IdeaCo 时遇到的五个核心问题，以及我目前的解法。

🔗 IdeaCo - GitHub　欢迎 Star ⭐ 和讨论

第一个问题：Agent 之间怎么"自然地"对话？

问题

传统的多 Agent 对话存在一个显著的问题——轮次感过强。A 说完 B 说，B 说完 C 说，如同一场严格按顺序发言的会议。但真实的群聊并非如此——有人主动发言，有人选择旁观，有人隔了五分钟才回复一句。

如果通过一个中央调度器来决定"现在轮到谁说话"，本质上仍然是编排，只是换了一种形式。

我的思考

一个直观的类比是即时通讯群聊。

群聊中没有"调度器"。有人发了一条消息，其他人收到通知后自行判断——有话可说就回复，没有则继续处理其他事务。过一段时间再回来查看是否有新消息。

这个模式有三个关键特征：

消息驱动，而非轮次驱动
每个参与者自主决定是否回复
关注频率是自适应的——讨论活跃时频繁查看，话题平淡时则降低关注频率

解法：链式反应 + 自适应轮询

我设计了一个链式反应引擎：

员工 A 发送消息
    │
    ▼
消息写入群聊日志
    │
    ▼
随机延迟后通知（Nudge）所有群成员
    │
    ├──→ 员工 B 被唤醒 → 读消息 → 思考 → 决定回复 → 触发新一轮通知
    ├──→ 员工 C 被唤醒 → 读消息 → 思考 → 决定沉默
    └──→ 员工 D 被唤醒 → 读消息 → 思考 → 决定回复 → 触发新一轮通知

没有中央调度器。 对话是通过 Agent 之间的相互触发自然涌现的。

同时，每个员工运行一个自适应定时器。每次思考后，AI 会输出两个指标：

interestLevel（兴趣度 1-10）：这个话题跟我有多大关系？
topicSaturation（话题饱和度 1-10）：这个话题还有多少可聊的？

系统根据这两个指标动态调整下次查看消息的间隔：

delay = MIN + (0.6 × interestFactor + 0.4 × saturationFactor) × (MAX - MIN) ± 10% 抖动

高兴趣 + 低饱和 → 10-15 秒后再次查看（讨论正在活跃进行）低兴趣 + 高饱和 → 4-5 分钟后再次查看（话题趋于饱和）

这模拟了真实人类的注意力分配模式——在讨论活跃时保持高频关注，在话题趋于平淡时降低关注频率。

发言控制的核心：Flow-of-Thought 机制

上述链式反应和自适应轮询描述了 Agent 何时被唤醒、多久查看一次消息。但还有一个关键问题：Agent 被唤醒后，如何决定是否发言？

许多 LLM 本身已经具备思考能力（如 Chain-of-Thought¹、ReAct² 等）。但在多 Agent 社交场景下，我们需要的不是更好的推理，而是一个强制性的发言决策流程——每次 Agent 收到新消息时，无论最终是否发言，都必须走完这个流程。

这就是 Flow-of-Thought 机制的核心定位：它不是为了让 Agent 思考得更好，而是为了控制发言频率，同时确保即使不发言也能完成记忆更新和任务推进等副作用操作。

具体而言，每次 Agent 被唤醒后，LLM 返回一个结构化的 JSON：

{
  "innerThoughts": "Bob 的方案听起来不错，但我觉得他忽略了缓存的问题……不过 Alice 已经提到了类似的观点，我就不重复了",
  "topicSaturation": 6,
  "interestLevel": 7,
  "shouldSpeak": true,
  "reason": "我有一个关于缓存的补充观点，和 Alice 说的不完全一样",
  "messages": [{ "content": "关于缓存这块，我补充一点……" }],
  "memorySummary": "团队在讨论 API 设计方案，Bob 倾向 REST，Alice 关注性能",
  "memoryOps": [...],
  "relationshipOps": [...],
  "taskOps": [...]
}

这个设计有三个关键点：

发言决策由 Agent 自主做出：shouldSpeak 字段决定是否发言，Agent 根据话题相关性、是否有新观点、当前任务优先级等因素综合判断。
不发言 ≠ 不工作：即使 shouldSpeak 为 false，memoryOps、relationshipOps、taskOps 等操作仍然会被执行。Agent 可以在沉默中更新记忆、推进任务、调整对同事的印象。这是传统多 Agent 框架中不具备的能力——在大多数框架中，Agent 不发言就意味着完全不活动。
内心独白提供可观测性：innerThoughts 字段记录了 Agent 的内心独白——不会发送到群聊，但会被系统记录。这使得开发者可以观察每个员工在想什么、为什么决定说话或沉默，为调试和优化提供了重要依据。

不是 bug，是员工真的不想说话。这种可观测性让调试变得非常直观——你能清楚地看到每个 Agent 的"心理活动"，而不是对着一个黑盒猜测为什么它没有响应。

企业微信截图_c9106b63-b3fa-48f8-b21e-7eec065e245b.png

企业微信截图_243db0fe-8eec-48f9-a1a0-8ddb760245a3.png

每次 Flow-of-Thought 触发时，注入 LLM 的上下文包括：

输入	说明
个人信息	姓名、角色、性格、说话风格
场景上下文	群名、成员列表、部门使命
聊天历史	最近 20 条消息（已读/未读标记）
记忆	滚动摘要 + 长期记忆 + 短期记忆
社交记忆	对当前对话中同事的印象和亲密度
待办任务	紧急度升级的任务清单
去重提示	"同事已经回复了 X，不要重复"
视角种子	随机思考角度，防止观点趋同

注意待办任务在这个列表中的位置——它和记忆、社交关系一样，是 Agent 思考时的核心上下文。这就是为什么 Agent 能在多个对话之间切换时始终记得自己的主线任务。

第二个问题：怎么防止 Agent 变成"复读机"？

问题

让多个 Agent 自由讨论，很快就会遇到一个经典问题：观点趋同。这个问题在学术界也有广泛讨论——Multi-Agent Debate³ 的研究表明，让多个 Agent 互相辩论可以提升事实性和推理能力，但前提是 Agent 之间要有真正的观点差异，否则辩论就变成了互相附和。

由于所有 Agent 背后都是同一个 LLM（或同一类 LLM），它们的思维模式天然相似。让三个 Agent 讨论一个技术方案，很可能三个都表示赞同——这不是真正的讨论，而是缺乏多样性的回声效应。

另一个严重的问题是消息泛滥。如果不加控制，Agent 会高频回复，短时间内产生大量内容相近的消息。

我的思考

真实的群聊为什么不会出现这种情况？主要有三个原因：

个体差异——每个人有不同的性格和视角，有人偏乐观，有人偏谨慎，有人关注细节，有人着眼全局
社交约束——如果他人已经表达了相似的观点，通常不会再重复
自然节奏——人类的发言频率受到认知和社交规范的约束，存在天然的间隔

解法：三层防趋同机制

第一层：人格系统

每个员工有 12 种性格原型之一，通过多层 prompt 注入确保性格一致性。这借鉴了 CAMEL⁴ 中角色扮演（Role-Playing）的思路——通过 inception prompting 让 Agent 深度代入角色，但我们更进一步，不仅定义角色的专业能力，还定义了性格特质和情感倾向：

性格	特点	对讨论的影响
🎭 阴阳怪气型	表面微笑，内心吐槽	会提出反面意见，但用讽刺的方式
💪 卷王型	"这个我来！"	主动接任务，推动进度
🧘 佛系摸鱼型	"都行~"	降低讨论热度，防止过度发散
😰 焦虑完美主义型	"让我再检查一遍..."	关注风险和边界情况
🤔 哲学家型	讨论午饭能扯到人生意义	把讨论引向更深层次
😤 叛逆摸鱼型	态度差但活干了	挑战权威观点

性格不仅影响说话风格，还影响决策倾向——卷王更容易主动接任务，佛系更容易保持沉默，焦虑型会反复确认。

第二层：视角种子（Perspective Seed）

每次思考时，系统从 10 个预设角度中随机选一个注入 prompt：

"提出相反或不同的观点"
"追问某个具体细节"
"轻微吐槽或调侃"
"质疑或挑战刚才说的话"
"从个人经验出发"
……

配合去重提示（"同事已经回复了 X，不要重复"），系统能产生多样化的讨论。

第三层：多重过滤门控

即使 LLM 决定要说话，回复还要通过多重过滤：

LLM 决定说话
    │
    ▼
话题饱和度 ≥ 7？ ──→ 🔇 强制沉默
    │ No
    ▼
防刷屏：窗口内消息过多？ ──→ 🔇 强制沉默
    │ No
    ▼
冷却期：刚发过言？ ──→ 🔇 强制沉默
    │ No
    ▼
   ✅ 允许发言

门控	工作群	休闲群
防刷屏	5 分钟最多 2 条	10 分钟最多 4 条
冷却期	发言后 60 秒沉默	发言后 30 秒沉默
话题饱和度	≥7 强制沉默	≥7 强制沉默

第三个问题：Agent 怎么"记住"彼此？

问题

在大多数多 Agent 框架中，Agent 之间缺乏持续的关系——每次对话都从零开始。然而，真实的团队协作高度依赖关系记忆：

你记得 Alice 曾帮你解决过一个棘手的 CSS 问题，因此下次遇到前端问题会优先向她请教
你了解 Bob 对进度的估计往往偏乐观，他说"快好了"通常意味着还需要两天
你与 Charlie 合作默契，因此更愿意在他需要时提供支持

缺少这些记忆，Agent 之间的协作将是机械的、缺乏上下文连续性的。

我的思考

人类的记忆并非扁平的数据库，而是具有层次结构的：

短期记忆：刚才讨论了什么（几小时后就忘了）
长期记忆：重要的事实和经验（永久保存）
社交记忆：对每个人的印象和关系（持续更新）
历史摘要：对过去事件的压缩概括（模糊但有用）

这种分层设计与 Generative Agents⁵ 中的记忆流（Memory Stream）有相似之处——他们用 Observation、Reflection、Planning 三层来组织记忆。但我认为他们缺少了一个关键维度：社交记忆。Agent 不仅要记住发生了什么事，还要记住对每个人的印象。

此外，一个关键的观察是：人会自主决定记住什么、遗忘什么。 并非所有信息都值得长期保存。Reflexion⁶ 的研究表明，让 Agent 通过自然语言反馈来自主管理经验（而非更新模型权重），能显著提升后续决策质量。我将这一思路应用到了记忆管理上——让 AI 自主判断哪些信息值得长期保存，哪些仅作为临时上下文。

解法：四层记忆 + AI 自主管理

Memory
  ├── 📜 historySummary    — 滚动 AI 压缩的旧消息摘要（按群组）
  ├── 💾 longTerm          — 永久存储，按重要性排序（1-10），上限 200 条
  ├── ⚡ shortTerm          — TTL 自动过期，默认 24h，上限 20 条
  └── 👥 relationships     — 社交印象表：Map<employeeId, {name, impression, affinity}>

关键设计决策：让 AI 自己管理记忆。

每次对话后，AI 通过结构化输出中的 memoryOps 操作自己的记忆：

{
  "memoryOps": [
    { "op": "add", "type": "long_term", "content": "Alice 擅长前端", "importance": 8 },
    { "op": "add", "type": "short_term", "content": "当前在讨论 API 设计", "ttl": 3600 },
    { "op": "delete", "id": "mem_xxx" }
  ]
}

社交记忆的设计更值得关注。每个员工维护一张关系印象表：

字段	说明
`impression`	≤200 字符的印象描述
`affinity`	1-100 亲密度，每次互动 ±5-15

AI 通过 relationshipOps 自主更新：

{
  "relationshipOps": [
    { "employeeId": "emp_123", "name": "Alice", "impression": "代码写得好，很靠谱", "affinity": 75 }
  ]
}

社交记忆采用按需注入策略——仅在对应员工出现在当前对话中时才注入 prompt，以控制 token 消耗。这意味着随着交互的积累，员工之间会逐渐形成信任、好感、甚至不满等关系动态，模拟了真实团队中的人际关系演化过程。

当然，这个机制也会带来一些"副作用"。有一次系统出现 bug，导致某个员工的交付物反复出问题，其他员工对他的印象就真的变差了——关系印象表里留下了这样的记录：

"交付物屡次出问题，技术执行力存疑"

企业微信截图_bd1b14cd-7c95-4bd9-a4e8-382193d879c9.png

这让我意识到，社交记忆是一把双刃剑：它让 Agent 之间的关系更真实，但也意味着系统的 bug 或异常行为会被"记仇"。在实际使用中，可能需要提供一个重置关系记忆的机制。

第四个问题（核心）：Agent 怎么"带着任务"去沟通？

问题

前面三个问题解决了 Agent 之间"如何对话"的问题。但仅有对话能力是不够的——Agent 需要带着明确的目标去沟通。

考虑这样一个场景：Boss 让员工 Alice 去调研一个技术方案。Alice 需要：

记住"我要调研技术方案"这个主线任务
去工作群里问 Bob 关于后端架构的问题
在等 Bob 回复的过程中，可能被其他群聊的消息打断
Bob 回复后，Alice 要想起来自己还有个任务要完成
综合信息后，主动回到 Boss 的对话汇报结果

这个流程的难点在于：

Agent 在多个对话之间切换，怎么不忘记主线任务？
任务完成后，怎么自动触发跨对话的回调？
任务拖了太久怎么办？

传统的做法是在代码层面硬编排这个流程。但这种方式的问题在于：每种协作模式都需要编写一套专门的编排逻辑，扩展性较差。

我的思考

回到真实的工作场景，人是如何管理多任务的？

维护一份待办清单——清楚自己有哪些未完成的事项
每次行动前回顾待办——判断当前最应该推进什么
任务具有紧急度——刚布置的优先级较低，拖延已久的则需要立即处理
完成后主动汇报——将结果反馈给任务的发起者

所以我的设计思路是：不要在代码层面编排任务流转，而是把任务清单注入到 Agent 的思考上下文中，让 Agent 自己决定怎么推进。

解法：任务系统（Task Manager）

任务的数据结构

{
  id: "task-uuid",
  description: "Ask Bob about API design preferences",
  type: "oneshot",           // oneshot | long-running | conditional
  condition: null,           // conditional 类型：完成条件描述
  status: "pending",         // pending | resolved | failed
  result: null,              // 完成结果
  onResolveTarget: "boss-chat-alice-id",  // 完成后通知哪个对话
  onResolveHint: "Report the API design decision back to boss",  // 完成后做什么
  createdAt: "2024-01-01T00:00:00Z",
  resolvedAt: null
}

三种任务类型对应三种协作模式：

oneshot：一次性任务，问个问题、查个信息，完成即结束
long-running：持续任务，比如"监控部署状态"，直到显式解决
conditional：条件任务，AI 自己判断条件是否满足（比如"等所有人确认方案"）

任务注入：让 Agent "想起"自己的任务

这是整个设计最关键的部分。每次 Agent 思考时，系统会把它的待办任务列表注入到 prompt 中。

当没有待办任务时，任务指令是轻量的：

## Task Operations
- taskOps: Manage your personal task list. When the boss or a colleague assigns you work, create a task to track it.

但当有待办任务时，指令会升级为最高优先级指令：

## ⚡ Task Operations — YOUR PRIMARY OBJECTIVE
🚨 YOU HAVE URGENT TASKS THAT NEED IMMEDIATE ACTION!
You have 2 pending task(s). Completing tasks is your TOP PRIORITY — above casual conversation, above everything else.

### Task Completion Rules (MANDATORY)
1. Every response must advance your tasks.
2. Use tools proactively — don't just talk about it.
3. Resolve immediately when conditions are met.
4. Report back on resolve.
5. Fail fast if blocked.

同时，每个任务的详情也会被注入，包括紧急度升级：

### 🔵 Task: task-abc123
- Description: Ask Bob about API design preferences
- Type: oneshot
- Urgency: 3min

### 🟠 Task: task-def456
- Description: Compile the frontend performance report
- Type: long-running
- Urgency: ⚠️ OVERDUE (18min) — Needs immediate attention

紧急度会随时间自动升级：

时间	紧急度	提示
< 5 分钟	🔵 normal	正常推进
5-15 分钟	🟡 aging	"跟进一下"
15-30 分钟	🟠 overdue	"需要立即关注"
> 30 分钟	🔴 critical	"立即升级或解决！"

这意味着：即使 Agent 被其他对话打断，下次它思考时，任务清单会再次出现在它的上下文中，而且紧急度可能已经升级了。 Agent 不会忘记自己的主线任务。

任务操作：AI 自主管理

Agent 通过结构化输出中的 taskOps 来管理任务：

{
  "taskOps": [
    {
      "op": "create",
      "description": "Ask Bob about API design",
      "type": "oneshot",
      "onResolveTarget": "boss-chat-alice-id",
      "onResolveHint": "Report the answer back to boss"
    }
  ]
}

{
  "taskOps": [
    {
      "op": "resolve",
      "taskId": "task-abc123",
      "result": "Bob says use REST with versioned endpoints"
    }
  ]
}

其中 onResolveTarget 和 onResolveHint 是任务系统中最关键的设计。

onResolve：跨对话的自动回调

当一个任务被 resolve 时，系统会自动触发目标对话的聊天流程：

Alice 在工作群里问 Bob 问题
    │
    ▼
Bob 回复了答案
    │
    ▼
Alice 的 Flow-of-Thought 触发
    │
    ▼
Alice 看到答案，决定 resolve 任务
    │
    ▼
taskOps: [{ op: "resolve", taskId: "xxx", result: "Bob says use REST" }]
    │
    ▼
系统检测到 onResolveTarget = "boss-chat-alice-id"
    │
    ▼
自动触发 Alice 在 Boss 对话中的回复流程
    │
    ▼
系统注入提示："你的任务已完成，请向 Boss 汇报结果"
    │
    ▼
Alice（在 Boss 对话中）："老板，我问了 Bob，他建议用 REST + 版本化端点……"

这个流程的关键是：onResolve 不是机械地写一条消息，而是触发 Agent 的正常聊天流程。 Agent 会根据自己的性格、记忆和上下文来组织汇报内容。

onResolve 支持三种目标类型：

boss-chat-xxx：回到 Boss 对话汇报
dm-xxx：回到某个私聊对话
group-chat-xxx：回到某个群聊

如果没有指定 onResolveTarget，系统会默认回到 Boss 对话——因为大多数任务最终都需要向 Boss 汇报。

完整的协作流程示例

以下通过一个完整的示例展示任务系统如何驱动跨 Agent 协作：

1. Boss 对 Alice 说："帮我调研一下我们应该用 REST 还是 GraphQL"

2. Alice 的 Flow-of-Thought 触发，她决定：
   - 创建任务：{ description: "Research REST vs GraphQL", onResolveTarget: "boss-chat-alice" }
   - 回复 Boss："好的，我去问问后端团队的意见"
   - 使用 send_message 工具给 Bob 发消息

3. Bob 收到消息，在工作群里回复了他的看法

4. Alice 被 Nudge 唤醒，读到 Bob 的回复
   - 她的 prompt 中包含待办任务："Research REST vs GraphQL (3min, 🔵 normal)"
   - 她决定还需要问问 Charlie 关于性能的数据
   - 她在群里 @Charlie 提问

5. Charlie 回复了性能数据

6. Alice 再次被唤醒，读到 Charlie 的回复
   - 她的 prompt 中包含待办任务："Research REST vs GraphQL (8min, 🟡 aging — Follow up soon)"
   - 她综合了 Bob 和 Charlie 的意见，决定 resolve 任务
   - taskOps: [{ op: "resolve", taskId: "xxx", result: "REST for simplicity, GraphQL for complex queries" }]

7. 系统检测到 onResolveTarget，自动触发 Alice 在 Boss 对话中的回复
   - Alice："老板，我调研完了。Bob 建议用 REST，理由是……Charlie 提供了性能数据……综合来看我建议……"

整个过程中，没有任何硬编码的工作流。Alice 自主决定问谁、问什么、什么时候汇报。任务系统只是确保她不会忘记自己的主线目标。

插曲：Human-in-the-Loop，随时介入

上面描述的任务系统让 Agent 能够自主推进协作。但有一个问题：如果我想改变方向怎么办？

真实的工作中，需求随时会变。老板可能在项目进行到一半时说"算了，换个方案"，或者"先暂停，等我确认一下"。如果 Agent 已经在自主推进任务，这种临时调整怎么传达？

解法：直接进群聊天

IdeaCo 的答案很简单——你可以随时在需求群里发消息，就像和真实员工聊天一样。

你（Boss）：等一下，先不要做 REST 方案了，我刚和客户确认，他们需要实时推送，改成 GraphQL + Subscription

Alice：好的，我收到了。我现在去跟 Bob 说一下，让他先停下 REST 的调研。
Bob：了解，我这边暂停。Alice，要不要我顺便把 GraphQL Subscription 的方案也一起调研了？
Alice：好主意，Bob 你来负责 GraphQL 这块，我去找 Charlie 确认一下 WebSocket 的基础设施支持情况。

没有任何特殊指令，没有"暂停任务"的 API 调用。你的消息进入群聊，Agent 的 Flow-of-Thought 被触发，他们读到你的新指令，自然地调整了方向。

为什么这样设计

这背后有一个设计原则：Human-in-the-Loop 不应该是一个特殊的系统功能，而应该是协作的自然组成部分。

大多数 Agent 系统的 Human-in-the-Loop 是这样的：系统在某个节点暂停，弹出一个确认框，等待人类点击"批准"或"拒绝"，然后继续执行。这种模式适合流程确定、需要审批的场景，但对于需求探索和方向调整来说太重了。

IdeaCo 的方式更接近真实的工作模式——你不需要"介入系统"，你只需要"和团队说话"。你的消息和 Agent 的消息在同一个群聊里，地位是平等的。Agent 会把你的消息当作来自 Boss 的指令，结合当前任务状态和上下文，自主决定如何响应。

这也意味着你可以做很多事：

调整需求方向：直接说"换个方案"，Agent 会自动更新任务
追加信息：补充背景信息，Agent 会把它纳入后续决策
询问进度：问"现在进展怎么样了"，Agent 会汇报当前状态
紧急叫停：说"先停下来，等我确认"，Agent 会暂停推进并等待

当然，这种设计也有局限——如果你的指令和 Agent 正在进行的任务产生冲突，Agent 需要自己判断如何处理。这依赖于 LLM 的理解能力，并不总是完美的。但在大多数情况下，它的表现比想象中要自然得多。

第五个问题：Agent 也会"累"吗？

问题

每次 LLM 调用都有成本。如果 Agent 无限制地思考、回复、调用工具，成本会失控。而且，一个 Agent 如果反复在同一个问题上失败，继续重试是没有意义的。

我的思考

人在工作中也存在类似的调节机制——疲劳和压力。连续工作 8 小时后效率会明显下降，在同一个问题上反复受阻后会倾向于调整策略。Voyager⁷ 在 Minecraft 中让 Agent 通过技能库实现终身学习，其中一个关键设计是 Agent 会根据反馈调整策略而非盲目重试。我将类似的思路应用到了资源管理上——让 Agent 内化成本意识。

解法：体力系统（Stamina）

舒适度 = 耐心 - (疲劳 × 0.4 + 压力 × 0.6)

三个区间：

🟢 绿区（> 70）— 正常运作
🟡 黄区（40-70）— 策略调整，注入成本意识
🔴 红区（< 40）— 强制反思："你一直在做什么不起作用的事？为什么不起作用？应该尝试什么完全不同的方法？"

不同事件对体力的影响：

事件	耐心	疲劳	压力
任务完成	+20	-15	-15
任务失败	-10	+10	+25
审查通过	+15	-10	-20
审查驳回（第3次+）	-30	+15	+30

体力系统与任务系统形成互补——任务完成会恢复体力，任务失败会消耗体力。当体力降至低位时，Agent 会被强制进入反思模式，重新审视当前策略，而非继续低效重试。

架构总览：五层企业隐喻

综合来看，上述设计最终形成了一个五层架构：

┌─────────────────────────────────────────────────────┐
│                   👤 User (Boss)                     │
│              Chat interface / Mailbox                │
├─────────────────────────────────────────────────────┤
│                 🧑‍💼 Secretary                        │
│      Intent parsing · HR coordination · Reporting   │
├─────────────────────────────────────────────────────┤
│              🏢 Organization Layer                   │
│     Company · Department · Team · Requirement       │
├─────────────────────────────────────────────────────┤
│               👥 Employee Layer                      │
│   Memory · Personality · Task · Stamina · Skills    │
├─────────────────────────────────────────────────────┤
│               🤖 Agent Layer                         │
│        LLM Agent · CLI Agent · Web Agent            │
│       (Unified interface, zero business logic)      │
└─────────────────────────────────────────────────────┘

最底层的 Agent 是纯粹的通信引擎——仅负责与 LLM/CLI/Web 后端交互。Employee 层在 Agent 之上叠加了记忆、人格、任务和体力等维度，使其成为一个具备社交能力和自主意识的完整个体。

这种分层设计意味着可以随时替换某个员工的底层 LLM，而不影响其积累的记忆、人格特征、任务状态和社交关系。

与传统多 Agent 框架的对比

	传统 Agent 框架	IdeaCo
协作模式	DAG / 工作流编排	自主社交 + 任务驱动
任务管理	代码层面硬编排	Agent 自主创建/推进/完成任务
跨对话协作	需要显式编排	onResolve 自动触发跨对话回调
Agent 生命周期	临时的，按任务创建	持久的，有记忆和人格
记忆	无或简单 RAG	四层：长期 + 短期 + 社交印象 + 滚动摘要
社交	Agent 互不认识	员工形成观点、追踪亲密度、记住同事
自主性	由代码触发	员工自主轮询、思考、决定说话或沉默
对话控制	无	话题饱和度 + 防刷屏 + 冷却期 + 视角种子
资源意识	无	体力系统（耐心/疲劳/压力 → 舒适度）

💡 值得一提的是，LLM-based Agent 的综述论文⁸ 将 Agent 的核心能力归纳为四个维度：规划（Planning）、记忆（Memory）、工具使用（Tool Use）和行动（Action）。IdeaCo 在这四个维度之上，额外引入了**社交（Social）和情感（Emotional）**两个维度，这是传统框架较少涉及的领域。

设计哲学："管人"而非"调函数"

回到最初的问题：如果我们不编排 Agent 的工作流，而是让它们像真实的团队成员一样自主协作，会怎样？

IdeaCo 的回答是：与其设计完美的工作流，不如培养有能力的员工。

当 Agent 具备记忆、性格、社交关系和任务清单时，许多复杂的协调逻辑会自然涌现——如同真实的团队协作一样。无需告诉 Alice "先问 Bob，再问 Charlie，然后汇报给 Boss"，只需要说"帮我调研一下"，Alice 会自主决定咨询谁、询问什么、何时汇报。

任务系统是这个设计的关键枢纽——它让 Agent 不只是"聊天"，而是带着目标去沟通。onResolve 机制让任务完成后的信息流转变得自然而非机械。紧急度升级确保任务不会被遗忘。

这并非否定编排的价值——对于确定性强、流程可预测的场景，编排仍然是最优选择。但对于需要灵活应变、创造性思考和自主判断的协作场景，社交协作或许是一个值得探索的范式。

IdeaCo 仍在演进中。这篇文章记录的是当前的设计思考，未来可能会有新的问题和新的解法。但核心理念不会变：把 Agent 当作有个性的团队成员来管理，而不是当作函数来调用。

做完这个系统，我反而有了更多问题

构建 IdeaCo 的过程中，有几个问题我越想越觉得没有想清楚。写在这里，不是为了给出答案，而是觉得这些问题本身值得认真对待。

涌现，还是幻觉？

系统跑起来之后，确实出现了一些"意想不到"的行为——员工之间形成了偏好，有人主动揽活，有人习惯性沉默，有人在 bug 之后真的对同事产生了负面印象。这些行为看起来很像真实团队的动态。

但我有时候会怀疑：这是真正的涌现，还是我在 prompt 里埋下的种子长出来的果？

人格系统、视角种子、关系印象——这些设计本身就在引导 Agent 产生差异化的行为。当 Agent 表现出"个性"时，我很难判断这是系统真正涌现出来的复杂性，还是我精心设计的 prompt 在按预期执行。这个边界在哪里，我目前没有好的答案。

社交记忆是资产，还是包袱？

四层记忆系统让 Agent 能够积累对彼此的印象，这是 IdeaCo 区别于大多数框架的核心设计之一。但随着系统运行时间拉长，我开始意识到这个设计有一个隐患：记忆会固化偏见。

一个员工因为某次 bug 被记录了"技术执行力存疑"，这个印象会影响后续所有人对他的协作意愿。在真实团队中，人会随着时间重新评估彼此；但在 AI 系统里，如果没有主动的记忆修正机制，早期形成的负面印象可能会持续放大。

更深层的问题是：我们真的希望 Agent 之间形成"偏见"吗？ 这让协作更真实，但也让系统更难预测和控制。

自主性的边界在哪里？

任务系统让 Agent 能够自主创建任务、决定找谁沟通、判断何时汇报。这在大多数场景下运转良好。但我一直没有想清楚一个问题：当 Agent 的自主判断和用户的真实意图产生偏差时，谁来纠正？

Human-in-the-Loop 的设计让用户可以随时介入，但这依赖用户主动发现问题。如果 Agent 在一个错误的方向上自主推进了很久，用户可能根本不知道——因为系统看起来在"正常工作"。

透明度（内心独白、任务状态、关系印象）是我目前给出的答案，但这要求用户有意愿去主动观察系统状态。在实际使用中，大多数用户不会这样做。

这个范式适合什么，不适合什么？

构建 IdeaCo 的过程让我越来越清晰地意识到，"社交协作"不是一个万能范式。

它在某些场景下有明显优势：需要多人并发推进的复杂任务、信息需要在多个角色之间流转、协作过程本身需要灵活应变。但在另一些场景下，它可能不如传统编排：需要严格确定性的流程、对延迟敏感的任务、需要精确控制每一步行为的场景。

更根本的问题是：我们是否真的需要 Agent 之间有"关系"？ 还是说，这只是让系统看起来更有趣，但对实际任务完成质量的提升是有限的？

这个问题我没有数据来回答。IdeaCo 目前缺乏系统的评估框架——什么算"好的协作"，什么算"自然的对话"，这些标准本身就很难量化。这是我认为最需要在后续工作中补上的一块。

写在最后：不足与展望

客观而言，IdeaCo 目前仍存在诸多不足，我们的思考也远未成熟：

效率问题：社交协作模式天然比编排模式消耗更多的 LLM 调用。自适应轮询虽然缓解了这个问题，但在 Agent 数量较多时，成本仍然是一个挑战。我们还在探索更高效的唤醒和沉默策略。
可控性：赋予 Agent 自主决策能力的同时，也引入了行为的不可预测性。在需要严格流程控制的场景下，这种设计可能不如传统编排可靠。如何在自主性和可控性之间取得平衡，是我们持续思考的问题。
评估困难：多 Agent 社交协作的效果很难量化评估。什么算"好的协作"？什么算"自然的对话"？我们目前还缺乏系统的评估框架。
记忆系统的局限：四层记忆架构在小规模场景下表现不错，但随着交互时间拉长、Agent 数量增多，记忆的检索效率和相关性筛选仍有很大的优化空间。
人格一致性：虽然我们通过多层 prompt 注入来维持性格一致性，但 LLM 本身的不稳定性仍然会导致偶尔的"人设崩塌"。这是一个底层模型能力的问题，我们只能在工程层面尽量缓解。

以上问题我们都在持续研究和优化中。本文分享的更多是一种思路和方向，而非最终答案。 多 Agent 协作是一个快速发展的领域，我们的许多设计决策可能会随着新的研究成果和实践经验而调整。

如果你对多 Agent 社交协作感兴趣，或者对本文的设计有任何想法、质疑或建议，非常欢迎交流讨论：

🔗 GitHub：github.com/ymssx/IdeaC…
💬 欢迎通过 Issue 或 Discussion 参与讨论
🍴 欢迎 Fork 和 PR，一起把这个方向做得更好

我们相信，多 Agent 协作的未来不只是"更好的编排"，而是让 Agent 真正具备"社交"能力。这条路还很长，期待与更多同行者一起探索。

参考文献

Wei, J., Wang, X., Schuurmans, D., et al. "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models." NeurIPS 2022. arXiv:2201.11903, 2022. ↩
Yao, S., Zhao, J., Yu, D., et al. "ReAct: Synergizing Reasoning and Acting in Language Models." ICLR 2023. arXiv:2210.03629, 2022. ↩
Du, Y., Li, S., Torralba, A., et al. "Improving Factuality and Reasoning in Language Models through Multiagent Debate." ICML 2024. arXiv:2305.14325, 2023. ↩
Li, G., Hammoud, H.A.A.K., Itani, H., et al. "CAMEL: Communicative Agents for 'Mind' Exploration of Large Language Model Society." NeurIPS 2023. arXiv:2303.17760, 2023. ↩
Park, J.S., O'Brien, J.C., Cai, C.J., et al. "Generative Agents: Interactive Simulacra of Human Behavior." UIST 2023. arXiv:2304.03442, 2023. ↩
Shinn, N., Cassano, F., Gopinath, A., et al. "Reflexion: Language Agents with Verbal Reinforcement Learning." NeurIPS 2023. arXiv:2303.11366, 2023. ↩
Wang, G., Xie, Y., Jiang, Y., et al. "Voyager: An Open-Ended Embodied Agent with Large Language Models." NeurIPS 2023. arXiv:2305.16291, 2023. ↩
Xi, Z., Chen, W., Guo, X., et al. "The Rise and Potential of Large Language Model Based Agents: A Survey." arXiv preprint arXiv:2309.07864, 2023. ↩

凌晨四点，我的 AI 员工选择了装死

IdeaCo：当 AI Agent 学会"社交"——多 Agent 协作系统的设计思考

第一个问题：Agent 之间怎么"自然地"对话？

问题

我的思考

解法：链式反应 + 自适应轮询

发言控制的核心：Flow-of-Thought 机制

第二个问题：怎么防止 Agent 变成"复读机"？

问题

我的思考

解法：三层防趋同机制

第三个问题：Agent 怎么"记住"彼此？

问题

我的思考

解法：四层记忆 + AI 自主管理

第四个问题（核心）：Agent 怎么"带着任务"去沟通？

问题

我的思考

解法：任务系统（Task Manager）

任务的数据结构

任务注入：让 Agent "想起"自己的任务

任务操作：AI 自主管理

onResolve：跨对话的自动回调

完整的协作流程示例

插曲：Human-in-the-Loop，随时介入

解法：直接进群聊天

为什么这样设计

第五个问题：Agent 也会"累"吗？

问题

我的思考

解法：体力系统（Stamina）

架构总览：五层企业隐喻

与传统多 Agent 框架的对比

设计哲学："管人"而非"调函数"

做完这个系统，我反而有了更多问题

涌现，还是幻觉？

社交记忆是资产，还是包袱？

自主性的边界在哪里？

这个范式适合什么，不适合什么？

写在最后：不足与展望

参考文献

Footnotes