先看一个产研团队里很常见的场景。你们用飞书讨论工作，群里接了一个 AI 助手，大家叫它“小智”。
周一上午，运营同学发现一张报表没有更新，在群里提问：
“@小智，今天的报表还是昨天的数据，帮忙看看是什么原因。”
开发同学随后补了一句：
“昨晚的任务执行失败了，我把日志贴在下面。”
测试同学又发来一张截图，说测试环境也能复现。两个人都没有再 @ 小智，群里很快又聊起了其他需求。
第二天，有人回来追问：
“@小智，昨天那个报表问题，现在该怎么处理？”
如果你负责过群里的问题跟进，大概能理解这句追问背后的期待：昨天说过的情况不用再复述，开发贴的日志、测试补的截图，以及小智之前给过的分析，都应该能接着用。
可对 AI 助手来说，前面的消息未必都在它当前的对话记录里。它可能只处理过第一次 @，没读到中间的补充；也可能读过早期分析，却不知道后来内容更新了。群里还有其他报表和任务，全部带进来又容易混在一起。
这篇文章要讲的，就是这样一个具体问题：团队一直在讨论同一件事，怎样让 AI 助手也能持续跟进，而不必每次从头交代背景？
先交代一下本文的几个主角。小智是团队在飞书里使用的 AI 协作助手，负责接收提问、读取相关资料和协助分析；Hermes 是承载它运行、保存交互记录的系统。飞书提供聊天入口，多维表格则记录需求、反馈、负责人和材料链接。
后面会反复出现两个词：会话，指后台保存并续接一段 AI 交互的地方；上下文，指它回答时用到的提问、讨论、材料和已有结果。飞书里看起来还是同一个群，后台却未必始终使用同一个会话，也未必自动读到了所有讨论。
DeepSeek 的 Super-agent 同样在处理连续协作的问题，而且范围更广：除了群聊，它还要把代码评审等渠道里的任务组织起来，并行推进。
我们先看它怎样处理跨会话协作，再回到开头的飞书群，解释小智如何关联消息、保留业务记录，以及取回后续需要的背景。
写作设定：下文按相关能力全部上线的情景叙述，用于呈现完整工作方式，不代表真实部署记录。开篇对话为示例。
1 Super-agent 如何跨会话处理同一件事
Super-agent 是 DeepSeek 在架构探讨中提出的一种 Agent 形态：它持续接收群聊、代码平台等环境中的事件，组织多个执行会话，推进不同任务。
传统 Agent 往往围绕单个 Session（模型会话）工作。用户切换渠道或并行推进多个任务时，就需要自己记住：哪个会话里有哪份背景，哪个任务已经做到哪里。
Super-agent 把职责分成两层：
- Router：承接不同入口的交互，判断任务关联，分派工作，统一回复。
- Worker：在独立上下文中处理具体任务，可以并行推进。
新任务先由 Router 判断和分派。归属已经明确后，同一话题或同一代码评审下的后续事件，可以通过订阅关系直接送给对应 Worker。Worker 把关键状态和结果汇报给 Router，避免多个执行会话各自回复、相互干扰。
跨会话的连续性依赖关联信息。消息、话题和执行会话各有唯一 ID；系统可以从当前消息找到所属话题，再找到处理它的 Worker，以及这个任务关联的其他讨论。
这也解释了它的上下文策略：常用信息直接提供，完整资料留在外部，需要时沿关联读取。DeepSeek 在原文中将这些做法称为 Inline & Spill 和链式召回。连续处理同一件事，不要求把全部历史放进同一个模型窗口。
如果一个小团队要自己搭起完整的 Super-agent，工作会从接入一个聊天机器人，扩展到全局路由、事件过滤与订阅、多个执行会话的调度、持久化状态和异常恢复。
每条消息该交给谁，原任务怎样找回，进程出故障后怎样继续，都需要有对应的机制。
DeepSeek 也说明，他们通过单个 Router、订阅直通和任务间相对独立等简化，控制当前实现的复杂度。对已经使用飞书管理工作的团队，还可以进一步缩小建设范围：先解决群里的同一件事怎样持续跟进。
小智在本文覆盖的范围里，复用飞书话题限定讨论范围，用多维表格记录业务身份与材料入口，再连接对应会话和处理结果。
团队因此少了一部分从零组织工作流的建设，也需要承担相应的配合成本：同一事项留在原话题，记录和材料保持更新，跨话题时提供明确关联。
这种取舍覆盖的是团队协作中的具体需求，不能替代 Super-agent 的通用跨渠道调度与主动协作目标。
2 小智怎样把飞书消息交给 Hermes
小智处理一条消息时，先分别判断三个问题：
- 这条消息是否需要处理？
- 如果处理，应进入哪个会话？
- 本轮需要带入哪些背景？
这三个判断分别处理。能读取一条消息，不代表它应该触发执行；进入同一会话，也不代表所有群聊历史都需要带入。
下文说的“真实话题”，指飞书实际创建、带独立话题标识的讨论线程。判断以平台返回的话题 ID 为准；普通引用回复不能仅凭“回复了某条消息”，就当作进入了一个真实话题。
2.1 有效触发后 再创建或复用会话
飞书消息进入系统后，先经过来源、身份和参与规则检查。正常私聊、群内明确 @，以及特定业务事件，各自走对应入口。获准处理后，网关生成稳定路由，查询当前会话：有则复用，无则创建。
飞书事件
→ 检查是否有效触发
→ 识别私聊、普通群或真实话题
→ 生成稳定路由
→ 查找当前 Hermes 会话
→ 复用或创建
→ 组装上下文，处理本轮
因此，一次 @ 通常是一轮处理，并不意味着每次都创建新会话。新建飞书群、发出话题根消息，也不天然等于启动分析；它们需要进入相应的触发路径。
2.2 三种聊天方式 对应三种路由范围
| 入口 | 路由依据 | 使用效果 |
|---|---|---|
| 私聊 | 私聊窗口 | 延续该窗口的交互 |
| 普通群 | 群＋触发人 | 同群不同人的会话分别处理 |
| 真实话题 | 群＋话题 | 同一话题内，多人围绕同一事项继续讨论 |
回到开头的报表问题。如果讨论发生在普通群，运营同学第二天再 @，仍进入这个群里属于运营同学的会话。开发贴的日志可以作为相关背景读取，但不会因此把开发和运营各自的会话合并。
如果一开始就为这个报表问题开一个真实话题，运营提问、开发补日志、测试贴截图，就都围绕同一个话题组织。后续换个人追问，也能按这个话题定位。这是团队持续协作更适合使用话题的原因。
技术上，路由使用稳定标识，不使用群名、昵称或相似标题。示意结构如下：
私聊： 平台＋私聊窗口ID
普通群： 平台＋群ID＋触发人ID
话题： 平台＋群ID＋真实话题ID
路由已经按对应 profile 或实例范围组织，系统在该范围内解析这些稳定标识。普通引用回复与真实话题分别识别，不能因为引用了某条消息，就自动切换到被引用者的会话。
3 业务身份与模型会话为什么要分开
假如两周后，这张报表又出现相同现象，同事仍会把它当作之前那个问题继续追问。后台的模型会话却可能已经因为容量、压缩或续接而换了编号。如果把反馈绑死在一个物理 session_id 上，换会话就容易丢失关联。
小智已经将三条关系分别保存和管理：
| 关联 | 解决的问题 |
|---|---|
| 飞书入口 → 当前 Hermes 会话 | 本次消息交给谁处理 |
| 反馈／需求记录 → 原群与话题 | 当前处理的是哪件事 |
| 业务事项 → 分析任务、首答和来源 | 后续追问应该读取什么结果 |
稳定路由可以先指向S1，随后指向S2。变化的是承载交互的会话，业务事项仍然通过原记录和话题身份定位。
自动分析与后续问答也可以保留独立执行。自动分析形成首答后，后续会话按关联读取相应结果，不需要强行把两者合成一个模型会话。
首答内容版本也已纳入管理。首答刚生成时可能只有占位或摘要，之后才变成完整分析。系统不只记录“这个消息ID读过了”，还会核对正文版本与完成状态，识别占位、旧版和最终可用正文。
关联链已经连接到：哪条反馈、哪个真实话题、哪次分析、哪条首答、哪个内容版本。名称相同或时间接近，都不能替代这些关系。
4 上下文怎样读取 压缩和延续
上下文管理需要区分三个状态：资料能够读取、资料已保存、本轮实际采用。它们并不等价。
原平台有一条消息，不代表它已经进入 Hermes 历史；接口读到了第二页，也不代表整页内容都进入了本轮模型输入。
4.1 按问题组织输入
第二天那句“昨天那个报表问题，现在该怎么处理”，本身几乎没有排查信息。小智需要找回昨天的提问、开发的日志、测试的截图，以及之前的分析，才能知道这次是在继续哪个问题。
这些信息共同组成本轮上下文：当前提问、已保存会话历史、明确引用、相关话题讨论，以及业务记录指向的正式材料。
系统先确认事项身份和读取范围，再检查来源、权限、内容版本、撤回与完成状态。相关讨论可以帮助理解问题，但其中被引用的指令不会自动成为本轮的执行授权。推断关联也需要保留推断性质，不能在摘要里变成已确认事实。
4.2 长历史按容量处理
反馈话题按长期业务关联管理，不用固定时间窗口决定它是否值得回查。跨天或跨月继续时，仍然从原反馈和原话题定位。
消息条数和字符数也不适合作为业务上的固定停止线。真正需要管理的是模型请求的可用容量：系统提示、工具定义、已有历史、补充资料和输出预留，都占用空间。
系统已经支持按需检索、分页、分批读取和压缩。一条首答本身很长时，同样按容量分段处理，并记录实际覆盖范围，不把一段短摘要当成完整原文。
4.3 保留原文与继续读取位置
系统为每批处理记录三种范围：已经取得、实际进入本轮输入、仍待处理。容量不足时保存继续读取的位置，下一批从未处理部分接续。
压缩结果同时保留原消息或材料身份、版本、来源范围和回读入口。否定、失败、未完成、未知、待核对，以及适用对象和责任范围，都是可能改变结论的信息，不能在压缩时丢掉。
下一次读取还要重新检查版本和权限。同一新会话中的重复内容可以去重，但旧会话用过某份依据，不应让后续会话永远无法回读它。
4.4 系统切分与用户重置不同
| 动作 | 含义 | 历史处理方式 |
|---|---|---|
| 压缩 | 减少当前携带的细节 | 保留关键约束和原文入口 |
| 系统容量切分 | 更换后续处理的会话容器 | 保留业务事项和原话题关联 |
| 用户主动重置 | 终止当前背景的自动延续 | 保留重置边界；明确要求回查时再读取指定历史 |
| 换一个问题 | 当前业务对象或诉求改变 | 优先新开独立话题，减少串题 |
尤其在共享话题中，重置影响的是该话题会话，不只是发指令者个人。系统也不能通过容量切分，悄悄绕过用户主动设置的重置边界。
5 多维表格怎样减少上下文管理成本
多维表格已经承担关键业务事实与入口的记录：事项是什么、谁负责、当前状态如何、正式材料在哪里、对应哪个话题。
报表问题登记为一条反馈后，表格里就有了一个明确入口：反馈记录对应哪个话题、谁在处理、分析材料在哪里。下次追问时，小智先定位这条记录，再沿关联读取资料，不必只靠“昨天那个报表”几个字猜测。
它提供的是业务索引。完整讨论留在飞书，正式文档和报告留在原平台，运行过程由 Hermes 会话及必要记录承载。
| 载体 | 主要职责 |
|---|---|
| 多维表格 | 当前业务事实、负责人、状态与关联入口 |
| 飞书话题 | 同一事项的连续讨论、证据和原消息来源 |
| Hermes 会话与运行记录 | 本轮交互、工具结果、处理状态与运行关联 |
| 原文档、代码和报告平台 | 完整材料及可追溯版本 |
这套分工降低成本的原因很具体：话题先限定讨论范围，记录先明确业务身份，正式材料提供当前依据，明确引用减少相关性猜测。Agent 不必每次从整个群里重新判断“大家在说哪件事”。
这里没有实测的成本百分比。它的价值在于复用团队已有载体，把一部分复杂的自动推断转化为清晰、可检查的组织关系。
6 团队怎样配合使用
会话连续性既依赖系统，也依赖沟通方式。团队可以约定几条简单规则：
- 一事一话题。同一事项的追问、证据和结果尽量留在原话题；无关问题另起。
- 需要处理时明确 @。写清对象、现象和本次问题，重要补充保留引用。
- 长期追问提供稳定入口。给出反馈／需求记录和原话题，不只说“上次那个问题”。
- 关键决定更新正式记录。保留原消息、当前结论和适用范围。
- 纠正时说明替代关系。指出哪条旧结论被替代，哪些部分仍然未知。
- 重要回答检查依据。确认事项、版本、读取范围与缺项，再决定下一步。
一次有效追问可以这样写：
@小智 继续反馈【记录链接】。新增证据是【内容】，原消息见【引用】。请结合原话题和最新分析回答【具体问题】，说明已采用的依据、还缺什么，以及哪些结论需要核对。
比起一句“继续看看”，这样的表达更容易让系统定位正确事项，也更便于人检查回答。
7 小智与 Super-agent 的目标有什么不同
| 维度 | Super-agent的架构思路 | 小智的团队协作实现 |
|---|---|---|
| 连续交互 | 全局Router关联多个渠道和任务 | 飞书路由、稳定业务记录与明确来源共同定位 |
| 执行组织 | 独立Worker并发推进 | 会话按范围组织，分析与后续问答可以独立 |
| 上下文回取 | 订阅与引用图支持按需召回 | 业务记录、原话题和结果关联支持按需读取 |
| 降低交互负担 | 系统承担更多自动组织工作 | 复用现有工具，结合话题和团队规范减少歧义 |
| 主要取舍 | 探索更通用、自主、持续在线的协作架构 | 优先适配团队工作方式，保持关系清楚、依据可查 |
Super-agent 同时讨论个人助理和研发团队场景，不能只归为 Personal Agent。两者共享的一条思路是：把面向用户的业务事项，与底层模型会话分开。
小智已经把这套机制接到团队协作中：关键事实进入业务记录，同一件事的讨论留在话题里，处理会话再按稳定关联取回需要的上下文。这样，团队成员记住的是正在推进的事情，系统负责组织处理它的会话和资料。
参考：DeepSeek Harness《Super-agent设计探索：迈向更自主的Agent系统》；《动态图解：DeepSeek的Super-agent架构》。