协作流

虾饺的协作流让多个 Agent 自动接力完成一项任务——你只需要发一句话，整条流水线自动运转。

多 Agent 协作——AI 生成水墨插画 + 团队总结

真实案例：小说家完成创作后自动生成水墨插画，并输出团队工作总结。

什么是协作流？

协作流 = 协作链 + 可视化面板。

协作链：在群组中配置 Agent 接力顺序，消息自动流转
可视化面板：实时展示每个 Agent 的状态、输出、进度

协作流可视化面板——运行中

协作流运行中：小说家（15s 完成）→ 翻译官（处理中）→ 发布，进度 33%。顶部可视化面板实时展示每个节点状态。

简单说：你给第一个 Agent 下达指令，后面的 Agent 自动一个接一个地干活，每个环节的进展你都能看到。与多 Agent 群聊中的群组、@mention 配合使用效果最好。

协作链运行中：用户请求写诗配插图，小说家回复与链上节点同屏

协作链与用户指令同屏：@小说家写诗并配插图时，链上状态与 Agent 输出（含后续文生图）一并可见。

与手动 @mention 的区别

维度	手动 @mention	协作流
触发方式	你手动 @每个 Agent	发一条消息自动触发
流转	Agent 各自独立回复	上一个的输出自动传给下一个
可见性	在聊天流中看回复	可视化面板实时展示状态
人工干预	随时可以 @别的 Agent	可以在节点间暂停确认
适合	灵活的临时协作	重复性的标准流程

协作链

配置方式

在群组设置中定义 Agent 接力顺序：

小说家 → 编辑 → 翻译官

每个箭头表示"前一个完成后，输出自动传给下一个"。

运行示例

你：写一首关于月光的诗

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  ✍️ 小说家   │ ──→ │  📝 编辑     │ ──→ │  🌐 翻译官   │
│             │     │             │     │             │
│ 创作诗歌     │     │ 润色修改     │     │ 英译         │
│ 状态：已完成  │     │ 状态：进行中  │     │ 状态：等待中  │
└─────────────┘     └─────────────┘     └─────────────┘

实际效果：

小说家 收到"写一首关于月光的诗"，创作诗歌
诗歌自动传给编辑（附带上下文："小说家写了以下诗歌，请润色"）
润色后的诗歌自动传给 翻译官（附带上下文："请将以下润色后的诗歌翻译成英文"）
最终输出：原创诗歌 + 润色版 + 英文翻译

翻译官输出英文诗歌

翻译官在协作链中接力完成英文翻译 — "Beneath the Stars"

浅色模式 — 小说家创作诗歌，翻译官自动接力翻译为英文

协作链的上下文传递

每个 Agent 不仅收到上一个 Agent 的输出，还收到完整的协作上下文：

[协作链上下文]
协作链：小说家 → 编辑 → 翻译官
当前步骤：第 2 步（编辑）
用户原始指令：写一首关于月光的诗
上一步输出（小说家）：
  月光如水洒庭前，
  清辉万里照无眠...

请基于以上内容完成你的任务。

可视化面板

协作链运行时，界面上显示一个实时状态面板。

节点状态

每个 Agent 节点有四种状态：

状态	图标	说明
⏳ 等待中	灰色	还没轮到
🔄 运行中	蓝色动画	正在处理
✅ 已完成	绿色	输出已就绪
❌ 出错	红色	处理失败

面板功能

功能	说明
实时进度	看到当前执行到哪一步
中间输出	展开节点查看每一步的完整输出
耗时统计	每个节点的处理耗时
终止	随时停止整条链
历史回放	查看过去的协作链运行记录

人工干预

协作流不是"设好就不管"——你可以在关键节点介入。

确认后继续

小说家(完成) → [等待你确认] → 编辑 → 翻译官

如果小说家写的诗不满意，你可以：

修改后继续 — 编辑小说家的输出，再让编辑接力
终止 — 停止整条链
重新生成 — 让小说家重新创作

编辑中间结果

你可以在任何节点之间修改中间结果：

1. 小说家写了诗 ✅
2. 你觉得第二句不太好 → 手动改掉
3. 修改后的版本传给编辑
4. 编辑继续润色

这种人机协同是虾饺协作流的核心设计理念——AI 做 80% 的重活，你把控关键节点。

实际应用场景

场景 1：内容生产流水线

协作链：小说家 → 编辑 → 翻译官

你：写一篇关于远程办公的文章
→ 小说家创作初稿（~800 字中文）
→ 编辑润色、修改结构
→ 翻译官翻译成英文
→ 得到中英双语文章

场景 2：代码审查流程

协作链：代码助手 → 编辑

你：写一个 Express 的 JWT 认证中间件
→ 代码助手编写代码 + 注释
→ 编辑审查代码风格、补充文档

场景 3：研究报告

协作链：代码助手 → 翻译官

你：调研 2024 年最流行的 CSS 框架
→ 代码助手调用 web_search 搜索、整理对比报告
→ 翻译官翻译成英文（适合发海外社区）

场景 4：客户支持

协作链：代码助手(RAG检索) → 编辑(润色回复)

客户：你们的 API 怎么分页？
→ 代码助手从知识库检索 API 文档
→ 编辑整理成友好的客户回复

协作链配置建议

链条长度

长度	建议
2 个 Agent	✅ 最常用，效率高
3 个 Agent	✅ 适合内容生产
4+ 个 Agent	⚠️ 每一步都有延迟，总体耗时较长

Agent 选择

第一个 Agent 应该是"生产者"——创作、检索、代码生成
中间的 Agent 应该是"加工者"——编辑、审查、优化
最后一个 Agent 应该是"输出者"——翻译、格式化、发布

与手动协作的结合

你不需要在协作链和手动 @mention 之间二选一。同一个群组可以：

有协作链处理标准流程
同时用 @mention 做临时交互
协作链运行中，你可以 @链外的 Agent 做其他事

工作流引擎（Roadmap）

工作流引擎是比协作链更强大的编排机制，目前在路线图中：

特性	协作链（已实现）	工作流引擎（规划中）
拓扑	线性	DAG（有向无环图）
条件分支	❌	✅ 根据结果走不同路径
循环	❌	✅ 支持重试、迭代
错误处理	终止	重试 / 跳过 / 回退
人工审批	简单暂停	完整审批流
变量传递	输出→输入	结构化变量

为什么先做协作链？

协作链覆盖了 80% 的场景，配置简单（一行字定义顺序），理解直观。工作流引擎是面向更复杂场景的进阶能力，我们会在协作链稳定后推出。

配置协作链的完整步骤

第 1 步：创建群组

在通讯录中点击"创建群组"，起一个名字，比如"写作工作室"。若还不熟悉群组与 @mention，请先阅读多 Agent 群聊。

第 2 步：添加 Agent 成员

把参与协作的 Agent 拉入群组。比如小说家、编辑、翻译官。

第 3 步：设置协作链

在群组设置中找到"协作链"配置：

协作链顺序：小说家 → 编辑 → 翻译官
Leader：小说家（默认接收消息）

第 4 步：测试

发一条消息试试。观察可视化面板中各节点的状态变化：

状态面板显示：
├── 小说家 ⏳ 生成中 (3.2s)
├── 编辑   ⏸ 等待中
└── 翻译官 ⏸ 等待中

→ 小说家完成后：
├── 小说家 ✅ 完成 (5.1s)
├── 编辑   ⏳ 生成中 (1.5s)
└── 翻译官 ⏸ 等待中

→ 全部完成：
├── 小说家 ✅ 完成 (5.1s)
├── 编辑   ✅ 完成 (3.2s)
└── 翻译官 ✅ 完成 (4.8s)
总耗时：13.1 秒

性能优化技巧

协作链中 Agent 串行执行，总时间 = 各环节之和。优化方式：

技巧	说明
快速模型用于非关键环节	编辑/翻译用 GPT-4o-mini，创作用 GPT-4o
精简 SOUL.md	每个 Agent 的 SOUL.md 控制在 500 字内
控制输出长度	中间环节输出越短，下一环节越快
减少不必要的记忆注入	协作链中间环节通常不需要历史记忆

协作流 ​

什么是协作流？ ​

与手动 @mention 的区别 ​

协作链 ​

配置方式 ​

运行示例 ​

协作链的上下文传递 ​

可视化面板 ​

节点状态 ​

面板功能 ​

人工干预 ​

确认后继续 ​

编辑中间结果 ​

实际应用场景 ​

场景 1：内容生产流水线 ​

场景 2：代码审查流程 ​

场景 3：研究报告 ​

场景 4：客户支持 ​

协作链配置建议 ​

链条长度 ​

Agent 选择 ​

与手动协作的结合 ​

工作流引擎（Roadmap） ​

配置协作链的完整步骤 ​

第 1 步：创建群组 ​

第 2 步：添加 Agent 成员 ​

第 3 步：设置协作链 ​

第 4 步：测试 ​

性能优化技巧 ​

相关文档 ​

协作流