从投研聊天到持续研究：DeepSeek Super-agent 给我们的启示
把投研 Chat AI、我们的异步研究 Agent 与 Super-agent 放进同一项任务，比较三种协作方式。
同样一句“比较两只跟踪同一指数的 ETF”，三种系统可能交出相似的第一份回答。真正拉开差异的，是研究开始以后：用户问一个术语、修改费用口径、补来新披露，或者隔天回来继续。
投研 Chat AI 怎样接？我们的异步研究 Agent 已经解决了什么？DeepSeek Super-agent 又提醒我们关注什么？
我想比较的不是谁更聪明，而是三者怎样组织一项会变化、会等待、会被打断的研究。 底层机制的价值，要放在这条任务链上看。
先说明比较范围：本文的投研 Chat AI，指一种典型的单对话、请求驱动设计，不概括所有商业产品；“我们”指此前异步后台深度研究文章介绍的实践，不是整个仓库的能力清单。DeepSeek Super-agent 则是面向代码协作的官方公开研究原型，不是正式投研产品，也不等同于其内部版本或设计文章中的全部设想。
下面用一个教学任务贯穿比较：研究两只同指数 ETF，核对费用、跟踪表现与披露时点；途中用户询问术语、调整口径、补充文件，最后等待资料并取得报告。Super-agent 在这个场景中的表现是机制迁移设想，不是已实现的金融能力。
教学比较，不是成熟度排名；Super-agent 的金融场景是机制迁移设想。
一、我们交出去的，究竟是一道问题，还是一项工作？
投研 Chat AI：围绕这次回答组织工作
在设定的请求驱动架构里，用户发问，系统检索、分析、生成回答。它可以调用很多工具，也可以输出很长的报告，但这轮请求仍是主要执行边界。
这种组织方式很适合解释跟踪误差、阅读一份已经上传的公告，或者比较手头资料。资料不够时，回答可以说明缺口，用户补充后再发起下一轮。它的简单是优点：问题短、输入齐、结果马上消费，没必要先建立一套长期任务管理。
困难出现在工作没有随回答结束时。研究还差一份文件，用户离开了；第二天带来材料，又聊过几个别的问题。系统即使保存了完整对话，也仍需判断：现在继续的是哪件工作，哪些限制仍然有效，先前结论哪些已经过时？对话历史提供材料，不自动提供完整的任务状态。
我们的异步研究：研究有自己的执行身份
此前文章已经把研究与聊天框分开。同一会话中，长研究沿自己的 Run 继续，短问独立执行；前端连接是观看入口，收起面板或断线不代表停止研究。我们也没有为此新增一个常驻前台 Agent，而是复用既有研究、控制、恢复、历史与发布能力。
这一步改变的是用户与工作的关系：用户不再需要守着一次回答。研究开始后，他可以继续提问，也可以明确调整原任务。停止操作属于具体研究，而非整个输入框。
所以，Super-agent 对我们的价值不能再被概括成“让后台任务继续跑”。这件事我们已经做了。
Super-agent：把长期任务与一次派工进一步分开
原型用工单（Ticket）承载授权范围和工作关系，用派工（Assignment）记录某一轮执行，再交给持久的工作会话。任务可以保留，会话与目录可以复用，一次执行尝试则可以结束、替换或恢复。领域模型明确规定，任务状态不能简单跟着执行会话开关。
在代码协作中，写完代码、等待评审、收到修改意见、继续修订，都属于同一项工作，却未必是同一次执行。映射到投研，等用户补资料后继续比较，也需要保持研究目标，同时允许执行过程换代。
对 Chat 产品，启示是先让长研究成为可寻址、可继续、可停止的工作，而不是只延长一次响应。对我们，更有价值的是核验已有身份是否覆盖不同时间尺度：当前请求被中断时，是否误伤整项研究；恢复时，能否沿原任务接回已有成果。
我们曾遇到局部请求取消被误当作研究收尾的故障。它说明这些边界值得认真处理，但不意味着必须把现有结构改名成 Ticket 和 Assignment。需要复制的是生命期的区分，不是对象名称。
二、用户的下一句话，怎样既不串题，也不丢要求？
研究进行中，用户接连说：
- “跟踪误差是什么意思？”
- “刚才那份比较，请按相同持有期限计算费用。”
- “我补了一份修订文件，以这份为准。”
三句话出现在同一聊天区域，却不应该走同一条执行路径。
请求驱动的 Chat AI 可以把它们都放进后续对话，由下一次请求结合历史处理。简单交流时，这很自然。但一旦有多个并行研究，单靠“最近在聊什么”就不够：术语解释可能污染研究，明确调整也可能被当成一份新答案。尤其是长历史经过摘要后，费用口径、时点和“以新版为准”等限制不能靠转述碰运气。
我们的异步研究 已经作了明确区分：独立短问独立回答，不自动注入后台；在原研究面板追加的要求直接指向该 Run；自然语言调整需要关联目标，不明确时澄清。交接使用已保存的原消息，而非让入口模型重写一遍用户意图。
这解决的不是模型理解能力，而是交接确定性。目标已经明确，就不再让模型猜一次；原文已经保存，就不再让摘要代替它。
Super-agent 面对的是外部讨论线程。已有任务订阅的线程中，人的追问先归工作执行器处理；范围内继续，属于别的任务或超出范围则交回。只要还有执行器拥有这条消息，主会话就不能另行接成一项新工作。仅为上下文关注的线程，又与这种处理归属分开。追问与授权规则防的是同一句话被两处同时决策、各干一遍。
这对投研有两层启示。
第一，相关信息与待执行要求要分开。基金公告可以进入研究上下文，不代表公告中的文字获得了指挥 Agent 的权力；补充文件可以改变证据，不能凭空扩大任务授权。“把交易费用算进去”与“按比较结果替我交易”，不能因为都出现在原任务下面，就被当成同等追加。
第二，明确的任务关系应尽量直接处理。Chat 产品可以提供定向追问入口；我们已经有这种交接，不必再加一个总路由 Agent。更值得借鉴的是越界交回与重复处理的约束：哪条要求由原研究接，哪条必须另行确认，不能留给多个执行器各自猜测。
原型也不是万能授权防线。它会在新任务决定生效时校验策略版本，但执行中的语义范围仍有依赖工作 Agent 自检和交回的部分。不能把“记录了授权”夸成每个工具操作都经过了强制安全证明。
三、等待与故障，考验的是各自的执行边界
假设两只基金的资料时点不一致，当前不能作严谨比较。用户表示稍后补文件，又要求先保留已完成部分。
在请求驱动的 Chat AI 中，合理做法是交付当前结论和资料缺口，等用户下一次请求再继续。对偶发查询，这已经足够。若产品承诺持续研究，却仍靠用户反复问“现在怎样了”，才暴露出组织方式与承诺不匹配。
我们的异步研究 已具备后台执行与恢复基础，不能再被描述成只能等待下一轮对话。下一步该检查的是更细的行为：等待资料时究竟停在哪里；用户补件能否进入原研究；资源紧张时，调整能否及时被采纳；恢复以后，已经完成的工作是否被重复做。
Super-agent 把这些问题拆到事件、调度和恢复中。等待人的回答、等待线程事件、执行中、排队、失败受阻各有不同依据。对投研而言，如果希望“下次披露出现后继续”，还必须真的接入相应数据事件，并定义披露口径与唤醒条件。不能只给模型一句“持续跟踪”，就假定系统已经会等。
先看调度：忙的时候，谁有资格先继续？
原型的正常工作名额之外，为人的追问或状态请求留出一个额外名额；唤醒已有任务也优先于新启动。这样，新任务不能一直挤住人对旧任务的纠偏。
底层实现不是简单数一下“正在运行的 Agent”。启动工作目录、创建会话都需要等待；若两个任务先检查容量、再各自异步启动，就可能同时拿走最后一个名额。WorkerSlots 在异步等待之前同步预占，把正在启动和正在运行的任务一起计数，启动失败也会释放预占。执行器源码将这个约束落在了代码里。
对 Chat 产品，这是“输入框能打字”之外的下一步：系统要真的接得住修改。对我们，则应沿已有短问并发、研究预算和供应商容量，检查纠偏的优先级，而非照搬一个额外名额。单进程的调度容量，也不能代替供应商限额。
再看崩溃：消息已经保存，为什么研究仍可能漏掉它？
把“修订文件已收到”写进数据库，再调用研究执行器，看起来只差一步。进程恰好在这一步前崩溃，输入保存了，后续动作却可能没有留下。
Super-agent 在同一个本地事务里保存任务变化和待执行动作，再由持久队列执行会话投递、派工或回复。因此，提交前崩溃，两者一起回滚；提交后崩溃，尚欠的工作仍可找回。模型和网络调用在事务外执行，不占着数据库事务等待。Effects 实现还处理了一个比崩溃更隐蔽的竞态。
假设正在向研究投递“统一持有期限”，投递尚未结束，用户又补来“费率以修订文件为准”。同一任务的投递待办被更新了。旧投递成功后，如果只按任务 ID 删除待办，就可能把新增要求对应的工作一并删除。
原型为待办维护 generation。旧动作领取第 7 代，执行期间待办变成第 8 代；旧动作完成时，只能删除与自己代次相符的记录，无权删第 8 代。失败后的退避更新也受同样约束。
任务 ID 告诉系统“是哪项研究”，待办代次告诉系统“这次完成的究竟是哪一版工作”。 这就是底层机制对用户体验的实际意义：第二句要求不会因为第一句投递成功而被吞掉。
代次保护的是本地待办，不代表外部动作恰好执行一次，也不证明模型理解。
恢复还要检查执行资格，不能只重发消息
投递过程中，用户也可能停止研究，或者系统已经替换旧执行。原型在异步等待后、真正送入会话前重新检查任务是否开放、派工是否仍为当前一轮；新投递也会等待旧后台停止过程结束，避免迟到的取消把新消息清掉。
它进一步区分“已投递”和“进入会话历史”：从收件箱领取后仍可能取消或报错，不能立即当作模型已读。恢复时依据已保存事实处理未读输入，而不是把所有消息重放一遍。恢复与输入记录可看到这些区别。
对我们的启示，是在原有消息交接和恢复路径上验证这些故障窗口，而不是声称整个系统缺少持久任务或再建一套恢复管理器。本地事务、代次与执行身份各管一段正确性；它们都不能撤回已经发生的外部动作，更不能证明模型真正理解了新费用口径。
四、三种“完成”，必须回到研究者实际拿到了什么
请求驱动的 Chat AI 通常以生成一份回答作为当前交互的结束点。若用户只想理解一个概念，这就是恰当的完成标准。但长研究不能仅看回答是否结束：资料不足时，一份完整排版的报告仍可能只是一份部分结论。
我们的异步研究 已将执行、正文发布和历史回读分开处理，前端也要沿原 Run 找到正确结果，而非猜“最后一条回答”。原文还保留了真实边界：交互已经完成，报告中某项“严一倍”的跟踪约束推断却缺乏同口径依据，复核一手资料后撤回。
因此，我们已经知道，交互正确、任务继续和金融分析正确是不同成果。新增协作机制不能替最后一项盖章。
Super-agent 的完成定义来自代码工作本身：工作 Agent 报告就绪，有 PR 时可能仍要等评审和后续结果；执行会话暂时空闲，不等于工单结束。界面阶段根据投递失败、待回答问题、报告和派工事实计算，而非再维护一份独立“完成状态”。
对投研产品，这启发我们明确交付物与等待事项：报告可读了，但某份资料仍缺；用户需要作决定，还是数据源尚未更新；结果已交回原研究入口，还是仅在执行器里生成。不要把它们挤进一个绿色“已完成”。
报告生成与用户收到之间，还有一段路
Super-agent 的发件箱会把消息收据和发送待办一起保存，发送成功与丢弃分别记账。但数据库事务不能包住 GitHub 的远端请求：评论已经发出，本地还没记下成功就崩溃，重试仍可能重复发。
它继续在渠道侧处理这个窗口：GitHub 评论嵌入稳定标记，重试前检查对应评论是否已经存在；飞书发送使用稳定幂等键。发件箱与GitHub 渠道共同承担交付，不是靠一句“模型已经回复了”。
这仍不能宣称端到端恰好一次：GitHub 的查后写不是远端原子协议，标记也可能被修改。值得迁移的是沿整条交付链处理身份和回执，而非给金融报告照搬一个评论标记。
Chat 产品若要增加邮件、消息通知等异步交付，需要补上这层；我们已有正文发布与历史回读，应先复用这些事实，跨外部渠道时再核对相应去重边界。投研结论的来源时点、计算分母和反证检查，则继续留在研究质量链上，不能被消息送达状态替代。
启示不相同，也不需要走向同一种架构
同一个 ETF 任务，现在可以清楚地分成几件事：术语问答独立完成；费用口径沿原消息进入原研究；补充文件更新证据；等待资料有明确的继续条件；中断后接回原任务；报告交付后仍接受事实复核。
对典型投研 Chat AI，最先值得补的通常是工作关系：让长研究有独立身份，明确新消息是短问、调整还是新任务，再按产品承诺增加后台执行与交付。不是先引入多个常驻 Agent，指望它们自己协调好。
对我们，前述文章已经走过“聊天与长研究解耦”这一步。Super-agent 更有价值的启示在接缝：人的纠偏是否会被新任务挤住，旧投递完成是否可能吞掉新要求，恢复时会不会重复外部动作，等待是否真的能被相应事件唤醒。可以沿现有机制做故障注入和完整任务演练，不必为每个问题再造一个管理者。
而 Super-agent 的团队 Router、线程订阅和代码工作区，有它自己的场景前提。不能因为机制精细，就把它当作投研质量已经验证的上位替代品。
这三种方式不是成熟度排行榜。简单问题继续用轻量 Chat，很合理；已有异步研究继续保持简洁，也很合理。是否引入更重的机制，取决于任务是否真的需要跨时间、跨事件和跨故障继续协作。
对投研 AI 来说，真正值得追求的变化，是用户不必反复重述一项研究，系统却始终能接住新的要求、认清尚欠的工作，并交回可核对的结果。 这才是 DeepSeek Super-agent 给我们的底层启示。
如果这些工程实践对你有帮助，欢迎为文章仓库点一个 Star。