Comma智能体：换对话仍记需求，实现持久工作记忆

如果上个月你告诉助手订机票要选靠窗座位且优先上午航班，这次出差让它订票时，它还会记得吗？如果换个对话，或是交给另一个执行任务的智能体，这条要求还会保留吗？

近期，行业内对下一代智能体的设计展开了探讨，有机构提出智能体需具备连续、高效、主动、持久四大特征，并强调会话应作为系统的实现细节，而非给用户带来认知负担。当会话交由系统管理后，用户过往的要求、完成的任务、给出的反馈如何在后续工作中延续，成为系统设计的核心问题。

常驻型个人智能体Comma给出了一套完整的工程实现方案：每个工作区仅保留一条主会话，用快速决策模型Jev维护所有智能体共享的事实清单，允许智能体自行编写监控程序，并根据人工验收结果和实际花费持续调整任务分配。

Comma在该领域的布局起步较早：今年4月28日，其前身Bridge公开发布，以常驻主智能体统一接收请求、分派具体任务给子智能体为核心形态；6月3日，固定主对话与任务委派功能正式上线；同期，Anthropic在6月23日推出理念相近的Claude Tag，支持团队在Slack频道内共用一个Claude。10月1日，Comma正式发布，比相关理念的文章早了近一个月，比Claude Tag上线早了约两个月，也比提出下一代智能体四大特征的相关研究早了半年，目前已在个人与团队的实际工作中持续运行。

有相关图示对比了Comma、Claude Tag与该研究的公开时间线。Comma的整体结构为：一条主会话汇集所有用户入口，Worker并行执行具体任务，精简工作区在所有会话间共享当前事实。

先看Comma的日常运作场景：路上随手拍一张广告牌，让它开发一个复古滤镜应用，Comma会派出Worker完成应用开发并直接部署预览，用户可在应用中为照片套用各类复古滤镜。在手机端，连接的邮箱、Slack等应用以及待确认的任务会汇总在同一界面中。

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

Comma为每个工作区运行一个常驻的Router，群聊、私聊、客户端内的消息都会进入同一条会话，Router可在多个讨论间共享上下文；具体任务由独立的Worker会话执行，完成后将结果与来源交回Router。这种设计被称为single-session。

通过这种设计，Router始终在同一条会话中工作，所有任务结果都留在连续的记录里。当上下文窗口占满时，较早的内容会被压缩出模型上下文，但原始记录会完整保留——Router可在自身历史中搜索原始消息与工具结果，包括已被压缩的部分，并读回完整原文。例如，用户想知道上次去上海时为何订了离地铁站较远的酒店，Router可直接检索当时的任务返回、比价结果与执行记录，找到原因后决定是否沿用。

单一主会话也带来挑战：Router需依次处理所有请求，历史越长，查找过往决定的工作量越大，精简工作区正是为此设计的。

在同一条对话中，用户可同时推进多项任务：比如「查局域网IP并连接空调」的任务还在等待补充信息时，用户已让它查看最近邮件、询问其他内容。

该记住什么、何时更新？用Jev维护共享事实清单

精简工作区是按工作区维护的事实清单，用户可在Comma设置中开启。开启后，工作区内每个Router和Worker的上下文中都会有这份清单的最新版本，每条内容为一句话。

清单需可靠且过时内容及时更新，Comma将这两项判断交给快速决策模型Jev。Jev接收一段状态与若干独立问题后返回结构化判断，对是非题给出概率，Comma再按阈值决定处理方式。

写入前：逐条判断是否值得共享

当智能体新增或修改清单条目时，每条内容都会作为独立是非题交给Jev：这条内容是否属于工作区内其他智能体需要知道的当前事实？若概率低于阈值，更新会退回给智能体，由其做最终决定；若智能体仍认为应写入，可确认后再次提交。

问题的问法经过对比测试：反向提问时，合适事实的概率也会很高，几乎所有更新都会被拒；改为正向提问后，两类内容的差距明显，阈值便设在这段差距中。

每轮回复后：判断清单是否过时、工作是否跑偏

智能体每完成一次回复，Comma会结合当前清单、最近对话与本轮工具调用，向Jev提出两个独立问题：一是是否需要更新——对话中是否出现其他智能体需知道的新事实，如决定、负责人、状态、约束或位置，而清单需补充或已过时；二是是否偏离——智能体的回复与工具调用是否和清单或用户请求矛盾，是否重复失败做法，是否追求对话外目标。

若「需要更新」的概率超过阈值，系统会提醒智能体修改清单；若「偏离」概率超阈值，会提醒其对照当前事实与用户请求检查计划，提醒由智能体自行判断是否采纳，两个阈值同样根据人工标注的回复确定。

回到开头的订票场景：用户提出订机票选靠窗座位、优先上午航班，智能体写入清单时，Jev判断这是工作区需共享的事实，条目生效。之后无论由Router预订，还是交给新建Worker比价，该要求都会保留。若用户后续提到因腰不好改选过道座位，下一轮检查会判断旧条目过时，提醒智能体更新。

私聊里说的事，群里会知道吗？团队版的长期记忆与IFC

精简工作区存放简短当前事实，更完整的信息存放在Router的长期记忆中，包括用户偏好、相关人员、工作环境与按日期记录的工作日志。长期偏好、用户要求记住的内容与待交接进度，由Router在对话中写入；Worker通过任务交接获取所需信息。

在团队版Comma for Teams中，一个Router服务整个团队，同时接收群聊、私聊与私密频道的消息，而这些消息的读者各不相同。为此，团队版用信息流控制（IFC）管理信息去向：每份信息标明有权读取的人员，智能体对外发送内容时需声明来源，IFC会检查目标对话的读者是否有权读取这些来源，通过才会发出；若被拦下，智能体可去掉受限内容重发，或请相关人员批准，IFC的判定由Lean实现的内核执行。

长期记忆遵循同样规则：群组记忆对整个群组可见，来自私聊或私密频道的信息会写入按受众划分的笔记，笔记读者范围由写入时的来源决定。比如，私聊中提到的客户报价会被Router记下，供后续使用，而群内成员看到的回复只会包含他们有权读取的内容。

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

团队版中，成员间的请求需经对方确认：比如同事在Slack中让Comma询问另一成员的iOS进度，请求会先送到对方，由其选择拒绝、交给自身Router或直接创建任务。

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

很多工作需等待外部事件，如合同签回、代码变更、航班信息变化等，Comma让智能体为每项监控编写C程序，编译为eBPF后在集群中常驻运行，称为Loop。

每个Loop等待定时器或事件，检查条件，必要时唤醒所属智能体；需语义判断时，可向Jev提出结构化问题，Jev仅返回判断结果，具体操作与权限由智能体掌握。

智能体编写的程序需与成千上万个其他Loop运行在同一进程，且只能访问自身内存，这是机制成立的前提。Comma的Loop运行时async-ebpf给出了机器检查证明：约4万行Lean证明确立，通过校验的程序编译后仅访问自身内存，返回时保留调用方状态，证明针对实际运行代码，编译Loop的C编译器也在沙箱中运行。

以航班比价为例：让Comma查询次日上海飞昆明的机票，它会先返回当前最低价航班；之后价格变化由Loop持续监控，出现值得处理的变化时叫醒智能体告知用户。

下次交给哪个模型？根据验收和花费调整调度

除记录要求外，Comma还会根据任务结果调整模型选择。每个任务会被归入路由类别，如「比价订票」「整理邮件」，调度层为每类任务记录所用模型、推理强度、完成次数与花费，完成与否以人工验收为准：验收通过记为成功，失败记为失败。

调度层选择每完成一个任务平均花费最低的组合，同时让少量任务在团队允许的模型范围内尝试其他组合以积累依据，每类任务记录越多，分配越准确，成本越低。

结语

相关研究提出的连续、高效、主动、持久四大特征，为下一代智能体指明了方向。Comma在相关研究发文前约半年便已公开发布，并围绕「持久」特征给出了实现：一条主会话保留完整工作记录，Jev维护共享并持续校验的事实清单，长期记忆按受众划分并交由用户修改，Loop承担等待任务，任务调度从每次验收积累依据。

对用户而言，一次交代的事会被记住并沿用，记错的内容也可查找修改。随着智能体越来越多地常驻团队工作流，这类系统层面的设计，会和模型能力一样，决定智能体能否长期胜任工作。