比DeepSeek超级代理更早，Comma已经把长期记忆做进代理「大管家」

机器之心发布 上个月告诉助手「订机票选靠窗座位，优先上午的航班」，这次出差让它订票，它还记得吗？换一个对话、交给另一个执行任务的 Agent，这条要求还在吗？ 近日，DeepSeek 在《Super-agent 设计探索》中为下一代智能体提出了四个特征：连续、高效、主动、持久，并主张「Session 应当是系统的实现细节，而不应是用户的认知负担」。会话交给系统管理之后，用户交代过的要求、做过的任务、给出的反馈，怎样进入下一次工作，就成了系统设计要回答的问题。 常驻型个人智能体 Comma 给出了一套完整的工程实现： 整个工作区只保留一条主会话，用快速决策模型 Jev 维护一份所有 Agent 共享的事实清单，让 Agent 自己编写监控程序，并根据人工验收和实际花费持续调整任务分配。 值得一提的是，Comma 在这条路线上起步更早。今年 4 月 28 日，Comma 的前身 Bridge 公开发布，产品形态就是一个常驻的主 Agent 统一接收请求、把具体任务分派给子 Agent；6 月 3 日，固定的主对话与任务委派在产品中正式上线。作为对照，Anthropic 在 6 月 23 日推出了理念相近的 Claude Tag，让团队在 Slack 频道里共用一个 Claude。10 月 1 日，Comma 正式发布，比 DeepSeek 的文章早了一个月。从公开发布算起，Comma 比 Claude Tag 早了近两个月，比 DeepSeek 公布 Super-agent 设计早了约半年，如今已经在真实的个人与团队工作中持续运行。 图 1 | Comma、Claude Tag 与 DeepSeek Super-agent 的公开时间线。 官网：https://comma.surf 代码：https://github.com/AFK-surf/Comma 技术博客：https://comma.surf/blog 图 2 | Comma 的整体结构。一条主会话汇集所有入口，Worker 并行执行任务，精简工作区在所有会话间共享当前事实。 在深入细节之前，先看看 Comma 日常是怎么工作的。 路上随手拍一张广告牌，让它做一个复古滤镜 app。Comma 会派出 Worker 写好这个小应用并直接部署出预览，照片可以在里面套用各种复古滤镜： 图 3 | 演示：让 Comma 做一个复古滤镜 app。 在手机上，连接的邮箱、Slack 等应用，以及等待你确认的任务，都汇总在同一个地方： 图 4 | 演示：手机端汇总连接的应用和待处理任务。 换个对话，之前的事还在吗？一个工作区只有一条主会话 Comma 为每个工作区运行一个常驻的 Router。群聊、私聊、客户端里的消息都进入同一条会话，Router 在多个讨论之间共享上下文。具体任务交给独立的 Worker 会话执行，完成后将结果和来源交回 Router。 Comma 将这种设计称为 single-session。 这样一来，Router 始终在同一条会话中工作，所有任务结果都留在同一份连续记录里。上下文窗口占满时，较早的内容会被压缩出模型上下文，原始记录则完整保留：Router 可以在自己的历史中搜索原始消息和工具结果，包括已被压缩的部分，并读回完整原文。 举个例子，用户想知道上次去上海时为什么订了离地铁站远一些的那家酒店。Router 可以直接检索当时的任务返回、比价结果和执行记录，找到原因后再决定这次是否沿用。 单一主会话也带来新的挑战：Router 需要依次处理所有请求，历史越长，找到某个过去的决定所需的工作也越多。精简工作区正是为此设计的。 图 5 | Comma 客户端。左侧是与 Router 的主会话，右侧是它派出的各项任务及状态。 在同一条对话里，用户可以同时推进几件事。下面的例子中，「查局域网 IP 再连上空调」的任务还在等用户补充信息，用户已经接着让它看最近的邮件、问 OpenAI 昨天发了什么： 图 6 | 演示：一条对话里同时推进多项任务。 该记住什么、何时更新？用 Jev 维护共享事实清单 精简工作区（Condensed Workspace）是一份按工作区维护的事实清单，用户可以在 Comma 设置中开启。开启后，工作区内每个 Router 和 Worker 的上下文中都有这份清单的最新版本，每条内容是一句话。 清单进入了每个会话的上下文，写进去的内容就要可靠，过时的内容也要及时更新。Comma 把这两项判断交给快速决策模型 Jev。Jev 接收一段状态和若干个独立的问题，返回结构化的判断；对是非题，它给出概率，Comma 再按阈值决定如何处理。 写入前：逐条判断是否值得共享 Agent 新增或修改条目时，每一条都作为一个独立的是非题交给 Jev：这条内容是否属于工作区内其他 Agent 也需要知道的当前事实？任何一条的概率低于阈值，这次更新会退回给 Agent，由 Agent 做最终决定；它仍然认为应当写入时，可以确认后再次提交。 问题的问法经过对比测试。在人工标注的样本上，用反向问法提问时，合适的事实也会得到很高的概率，几乎所有更新都会被拒；改为正向提问后，两类内容之间拉开了明显差距，阈值就设在这段差距中。 每轮回复后：判断清单是否过时、工作是否跑偏 Agent 每完成一次回复，Comma 会结合当前清单、最近的对话和本轮的工具调用，向 Jev 提出两个独立的问题： 是否需要更新： 对话中是否出现了其他 Agent 需要知道的新事实，例如一个决定、一位负责人、一个状态、一项约束或某样东西的位置，而清单尚待补充，或清单中的说法已经过时； 是否偏离： Agent 最近的回复和工具调用是否与清单或用户的请求相矛盾，是否在重复已经失败的做法，是否在追求对话之外的目标。 「需要更新」的概率超过阈值，系统会提醒 Agent 修改清单；「偏离」的概率超过阈值，会提醒它先对照当前事实和用户请求检查计划。提醒由 Agent 自行判断是否采纳。这两个阈值同样根据人工标注的回复确定。 回到开头的例子。用户提出「订机票选靠窗座位，优先上午的航班」，Agent 写入清单时，Jev 判断这是工作区需要共享的当前事实，条目随即生效。之后无论机票由 Router 自己预订，还是交给一个新建的 Worker 去比价，这条要求都已在上下文中。用户后来提到「最近腰不好，长途航班改选过道座位」，如果旧条目还留在清单里，下一轮的检查会判断清单已经过时，并提醒 Agent 更新。 图 7 | 精简工作区中的两次 Jev 判断：写入前的共享判断，以及每轮回复后的过时与偏离检查。 私聊里说的事，群里会知道吗？团队版的长期记忆与 IFC 精简工作区存放简短的当前事实，更完整的信息存放在 Router 的长期记忆中，包括用户偏好、相关人员、工作环境和按日期记录的工作日志。长期偏好、用户要求记住的内容和待交接的进度，由 Router 在对话过程中写入；Worker 通过任务交接获得所需信息。 在团队版 Comma for Teams 中， 一个 Router 服务整个团队，它同时接收群聊、私聊和私密频道的消息，这些信息的读者各不相同。 为此，Comma for Team