Comma把长期记忆做进Agent大管家：单会话设计早于DeepSeek

上个月跟助手交代过「订机票选靠窗座位，优先上午的航班」，这次出差再让它订票，它还记不记得？换个对话、换给另一个执行任务的Agent，这条要求还能带过去吗？

近日DeepSeek在《Super-agent设计探索》里给下一代智能体列了四个特征：连续、高效、主动、持久，并提出「Session应当是系统的实现细节，而不应是用户的认知负担」。会话交由系统管理后，用户提过的要求、做过的任务、给过的反馈怎么进入下一次工作，成了系统设计绕不开的问题。

常驻型个人智能体Comma拿出了整套工程做法：一个工作区只留一条主会话，用快速决策模型Jev维护一份所有Agent共用的事实清单，让Agent自行编写监控程序，再依据人工验收和实际花费不断调整任务分配。

Comma在这条路上起步更早。4月28日，其前身Bridge公开发布，形态就是一个常驻主Agent统一接请求、把具体任务分派给子Agent；6月3日，固定的主对话与任务委派在产品中正式上线。作为对照，Anthropic在6月23日推出理念相近的Claude Tag，让团队在Slack频道里共用一个Claude。10月1日Comma正式发布，比DeepSeek的文章早了一个月。从公开发布算起，它比Claude Tag早了近两个月，比DeepSeek公布Super-agent设计早了约半年，如今已在真实的个人与团队工作中持续运行。

图 1 | Comma、Claude Tag 与 DeepSeek Super-agent 的公开时间线。

图 2 | Comma 的整体结构。一条主会话汇集所有入口，Worker 并行执行任务，精简工作区在所有会话间共享当前事实。

• 官网：https://comma.surf
• 代码：https://github.com/AFK-surf/Comma
• 技术博客：https://comma.surf/blog

细看之前，先看Comma平时怎么干活。

在路上随手拍块广告牌，让它做个复古滤镜app。Comma会派Worker把这个小应用写出来，直接部署出预览，照片能在里面套各种复古滤镜：

手机端也一样：接进来的邮箱、Slack等应用，还有等你确认的任务，全汇总在同一处：

视频链接：https://mp.weixin.qq.com/s/CMQlwfh8N68I7VkAPtqaUg

换个对话，之前的事还在不在？一个工作区只有一条主会话

每个工作区里，Comma都跑着一个常驻Router。群聊、私聊、客户端的消息统统进同一条会话，Router在多个讨论间共享上下文。具体任务由独立的Worker会话执行，做完把结果和来源交回Router。这套设计Comma叫它single-session。

于是Router始终在同一条会话里干活，所有任务结果都留在同一份连续记录中。上下文窗口塞满时，较早的内容会被压出模型上下文，原始记录则完整留着：Router能在自己的历史里搜原始消息和工具结果，连被压缩的部分也能搜到，并读回完整原文。

比如用户想知道上次去上海为什么订了离地铁站远一点的那家酒店。Router可以直接翻当时的任务返回、比价结果和执行记录，找到原因，再判断这回要不要照旧。

单一主会话也带来新麻烦：Router得依次处理所有请求，历史越长，翻出某个旧决定要做的功也越多。精简工作区就是冲着这个来的。

图 5 | Comma 客户端。左侧是与 Router 的主会话，右侧是它派出的各项任务及状态。

同一条对话里，用户可以几件事一起推。下面这个例子中，「查局域网IP再连上空调」的任务还等着用户补信息，用户已经接着让它看最近的邮件、问OpenAI昨天发了什么：

从公开节奏看，Comma在4月28日以Bridge之名亮相、6月3日上线主对话与任务委派、10月1日正式发布，这条单会话加Worker的路线已经跑在真实场景里。

哪些内容该记、什么时候该改？Comma 交给 Jev 来维护一份共享事实清单。

按工作区维护的这份事实清单叫精简工作区（Condensed Workspace），用户可在 Comma 设置里打开。打开之后，工作区内每个 Router 和 Worker 的上下文中都会带上清单的最新版本，每条只有一句话。

清单既然进了每个会话的上下文，写进去的东西就得靠得住，过期内容也要马上换掉。这两项判断 Comma 都交给了快速决策模型 Jev：它接收一段状态和若干独立问题，返回结构化的判断；碰到是非题，Jev 给出概率，Comma 再按阈值处理。

写入之前，逐条判断值不值得共享。

Agent 新增或改动条目时，每一条都会单独作为一道是非题抛给 Jev：这条内容算不算工作区内其他 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 Teams 用信息流控制（Information Flow Control，IFC）来管信息去向：每份信息都标明哪些人有权读取，Agent 每次对外发送内容，都要声明用到了哪些来源，IFC 再检查目标对话里的读者是否都有权读取这些来源。检查通过才发得出去；被拦下时，Agent 会收到原因，可以去掉受限内容后重发，或者请相应的人批准。IFC 的判定由一个用 Lean 实现的内核执行。

团队版里，长期记忆也遵循同样的规则。群组记忆对整个群组可见，所以来自私聊或私密频道的信息会写进按受众划分的笔记，笔记的读者范围由写入时用到的来源决定。比如你在私聊里提到的客户报价，Router 会记下来供之后使用，而群里其他成员看到的回复里，只会出现他们有权读取的内容。

长期记忆以文件形式保存，用户能直接查看和修改：偏好写得过宽、口径已经过时，都可以直接修正；需要作为固定规则的要求，可以写进 Router 的指令。

团队版里，成员之间的请求也要经对方确认。下面的例子中，一位同事在 Slack 里让 Comma for Teams 去问另一位成员的 Comma 要 iOS 的进度，请求先送到对方那里，由对方选择拒绝、交给自己的 Router，或者直接创建任务：

图 9 | 团队版 Comma for Teams 中，长期记忆按受众写入，对外发送前由 IFC 检查读者范围。

等待交给谁？让 Agent 自己编写 Loop。

很多工作要等外部事件，比如合同签回、代码仓库出现相关变更、航班信息变化。Comma 的做法是让 Agent 为每项监控写一段 C 程序，编译为 eBPF 后在集群中常驻运行，这被称为 Loop。

每个 Loop 都会等定时器或事件，检查条件，需要时把所属的 Agent 唤醒。碰上要作语义判断的情况，Loop 可以向同一个决策模型 Jev 提结构化问题，Jev 只给判断结果；具体怎么操作、权限归谁，仍由 Agent 掌握。

Agent 写出的程序，得和成千上万个其他 Loop 挤在同一个进程里跑，每个程序只能碰自己的内存——这是整套机制能立住的前提。Comma 的 Loop 运行时 async-ebpf 为此拿出了机器检查的证明：约 4 万行 Lean 证明确立，凡是过了校验的程序，编译成 x86_64 机器码后只会访问属于它自己的那块内存，返回时调用方的状态完整保留。证明盯的正是实际运行的代码：运行时的 Rust 模块先经 Charon 和 Aeneas 翻译成 Lean，再加以证明。连编译 Loop 用的 C 编译器本身也被编译成 eBPF，放进同样的沙箱里运行。

拿航班比价来说：让 Comma 查第二天上海飞昆明的机票，它会先比出当下最便宜的那班，用卡片形式返回；后面的价格变动交给 Loop 持续盯着，出现值得处理的变化再叫醒 Agent 告诉用户。

图 11 | 演示：航班比价，查询第二天上海飞昆明的最低价机票。

下一次该派给哪个模型？看验收结果和花销来调

除了记录要求，Comma 还会依据任务结果，调整任务交给哪个模型去做。

每个任务会归入路由表里的某一类，比如「比价订票」「整理邮件」。调度层按类分别记下所用模型和推理强度、完成次数与花费。算不算完成，以人工验收为准：待审核的任务通过验收，记一次成功；任务失败，记一次失败。

在这之上，调度层挑的是每完成一个任务平均花费最低的组合，同时让少量任务在团队允许的模型范围内试别的组合，攒下比较的依据。同一类任务记录攒得越多，分配就越准，成本也越低。

图 12 | 两条反馈回路：用户修正改变做事的规则，验收与花费改变任务交给谁做。

结语

DeepSeek 提出的连续、高效、主动、持久，描述的是下一代智能体的方向。Comma 在 DeepSeek 发文前约半年就已公开发布，并围绕其中的「持久」拿出了自己的做法：一条主会话保留完整的工作记录，Jev 维护所有 Agent 共享并持续校验的事实清单，长期记忆按受众划分、交给用户修改，Agent 编写的 Loop 负责等待，任务调度从每一次验收中积累依据。

用户只要说过一次，往后就能被记住、被接着用；记岔的地方也查得到、改得动。团队工作流里常驻的 Agent 正变多，这类系统层面的设计，跟模型能力一样，都会影响 Agent 能不能长期把活干好。