想聊就聊，没收 AI 对话框的中止按钮！一天让你的 Agent 支持异步后台深度研究
真正的 Personal Agent，不应该让一项长研究占住整个聊天框。 用户把任务交出去之后，应该还能随时问别的问题、查看原研究进度、追加新的要求；研究各自继续，回答和控制操作也不能串到别的任务上。
这听起来像一个前端交互优化，但我们开发 ETF Agent 时发现：难的不是让两个模型请求同时运行，而是让同一段对话里的不同意图和执行始终对应正确的任务。
我们实际做了这样一次演示：
- 先问：“为什么纳斯达克大跌？”——启动一项较长的研究。
- 再问：“黄金与美债有什么关联？”——在前台独立回答，不必等前一项结束。
- 中途补充：“需要与 A 股的大跌进行对比。”——明确交给原研究，而不是新开一份无关答案。
交互关系示意：独立问题独立回答，明确追加的要求交给原研究；图中距离不代表执行耗时。
页面上的效果很直观：后台研究入口保留在顶部，黄金与美债的回答仍出现在主对话，新增的 A 股比较要求显示“已交给研究模型”。用户不用为了继续聊天先中止原任务；真正的停止按钮仍在，只是属于对应的研究，而不是整个输入框。
标题里说的“一天”，指的是在 ETF Agent 已经具备研究循环、工具、持久历史、恢复和正文发布能力的基础上，接通这套并发交互；不是说一天从零实现了完整研究 Agent。
一、把研究交出去，聊天框就不应该变成进度条
原来的 ETF Agent 已经能在用户离开页面后继续执行研究。但前端仍容易围绕一个全局的“正在生成”状态组织输入：后台任务存在，新消息便很容易被理解成对它的补充。
这造成一个产品上的悖论：服务端已经能独立工作，用户却仍要围着那项工作等待。
我们比较过三种看似容易的办法。收到新消息就抢占旧回答，会让一个随口的提问打断重要研究；把短问题排队，仍然无法及时响应；再创建一个常驻前台 Agent 来统一协调，则会引入第二套长期上下文和任务生命期。
最后选择的是更克制的结构：同一段会话可以存在多次独立执行，而不是靠一个永远忙碌的前台 Agent 维持秩序。
长研究沿原有 Research Run 运行；短问题有自己的执行身份；前端的连接与流只负责让用户看见进展，并不拥有研究是否继续的决定权。收起面板、换到另一条对话、网络断线，都不等于停止已经接纳的研究。
研究仍有独立入口，前台可以显示另一条已经完成的回答。
这项选择没有另建后台任务账本，而是复用已有的任务、控制、恢复和发布身份。新增加的是消息属于哪个任务、用户现在想做什么、页面应该更新哪一块。
二、用户新说的一句话，到底是在问问题，还是修改研究？
这是整个体验最容易被忽略、却最影响正确性的判断。
“纳斯达克研究正在进行”是系统状态；“黄金与美债有什么关系”是用户的新问题。不能仅因为系统忙碌，就自动把后一句塞进前一项研究。
我们保留普通入口对自然语言意图的理解，但用户明确指定目标时，不再让模型重新猜测：
实现里有一个 Coord 协调结果，但它不是新的常驻 Agent，也不拥有第二份研究状态。
还有一个现实约束：输入框能持续接收消息，不等于系统可以无限并发执行。初期配置允许三个短交互和一项后台研究；短问并发、单次研究预算、供应商请求容量仍是三类不同的资源。后台名额满了，就明确说明新研究未被接纳，而不是悄悄把它变成旧研究的补充。
这给产品设计一个直接启发：不要用“页面正忙”替代对用户意图的判断，也不要用一个全局 loading 状态表达多项任务的真实关系。
三、“已收到调整”和“研究真的采用了调整”，不是一回事
当用户说“还需要与 A 股的大跌进行对比”，系统首先保存的是这句原始用户消息，再把消息身份与目标研究关联。
为什么不直接让入口模型重写成一段精炼的研究指令？
因为模型的转述可能丢掉日期、对象和用户限制；请求失败重试时，还可能把同一个修改重复送入研究。我们让入口负责判断要调整哪项任务，交接内容则从已经保存的原消息读取。同一次合法重试读回原交接结果，而不是再造一次调整。
用户消息和交接回执都留在对话里；研究使用自己的执行与历史记录。
但这时也不能立刻宣布“研究已理解并完成调整”。这里至少有三个不同事实：
消息已保存，说明要求没有丢；后续模型请求实际带上了它，说明交接发生；最终报告满足新要求，还要看资料和研究结果。它们不能互相冒充。
这也是为什么前台的随口聊天不会自动成为后台研究的上下文。短问只读取提交时有资格取得的历史快照；只有明确交接的调整，才进入原研究的后续请求。后发的短问即使先完成，也不能倒过来改变先发请求当时看到的材料。
四、真正的并发，不是同时出现几个转圈动画
把输入框解锁后，另一个问题随之暴露：一个回答在页面上出现的位置，可能与它在服务端的执行顺序不同。
例如，用户先后发起两条短问，后发的一条先完成。前端不能继续用“最后一条 assistant 消息”推断对应关系，而要沿原 Run 找到发问、回答、工具进度和控制操作。
我们曾遇到一个真实交接故障：页面先显示临时回答行，历史读取随后用正式消息替换它；流式内容却仍然更新旧临时 ID，导致回答找不到自己的位置。修复不是多补一份正文，而是沿原 Run 定位当前承载回答的消息，保留正文自己的发布身份。
类似地，结束通知先到了，数据库视图可能还未更新；早发出的历史读取还可能比新请求更晚返回。我们用有界的只读补查和页面读取顺序保护显示，避免把暂时没读到的结果误认为研究失败，也不让旧快照覆盖新内容。
实际准入也踩过坑：第一次并发观察中，短问还有名额，却因为数据库短暂锁竞争而被立即拒绝。我们修的是准入阶段对短事务的有界等待，而不是偷偷把用户任务放进一条新队列。
这些问题都有一个共同根源：当系统从“一个会话只有一个当前任务”演化到多个独立执行，消息身份、结果归属和资源占用就不能再借用界面的先后顺序。
五、一次“取消”差点让整项研究提前收尾
体验中更有代表性的反例发生在用户中途纠偏时。
模型请求可能正在生成；新要求抵达后，系统需要让当前请求在安全位置让位，再把完整要求交给下一次请求。
但一次真实研究中，纠偏已经被保存，当前模型请求也按预期中断。请求适配层却把这种局部抢占压成普通的“取消”；运行时于是误以为整项研究只能进入收尾，不再继续查资料。最终留下了部分回答，用户需要的完整比较没有完成。
问题不在“应该增加几次重试”，而是两个不同动作被混为一谈：
- 用户主动停止研究：结束原 Run，不能因迟到的调整把它重新启动。
- 为采纳新要求而中断当前请求：保留原 Run 的授权、预算、已完成结果与未知用量；若仍合格，继续研究。
后来我们修复了请求中断原因的交接，使后续研究仍能在原准入规则下取证，而不是被过早推入收尾阶段。
这条实践尤其值得 Agent Runtime 开发者借鉴：一次模型请求的生命期，不等于整项研究任务的生命期。 不能让一个通用的取消错误码，代替原任务作最终决定。
六、交互做成了，不等于每份研究都已经做对
最初的纳斯达克演示里，黄金与美债短问可以独立阅读，新增 A 股比较要求也实际送入了原研究。但原报告没有拿到完成同日比较所需的 A 股行情和资金数据，只能给出有明确限制的分析框架。
这是原始演示的真实缺口：要求已经交接，充分的数据比较仍未完成。
之后的 2026 年 10 月 26 日，另一次独立的金融研究真实验收取得了更完整的交互证据：后台研究与三个短问题重叠运行、最终各自完成；定向调整的完整原文进入后续研究请求；短问正文没有串入后台输入；报告和对话历史也在实际浏览器中回读。对应工程验收已正式归档。
但连这次正常完成的研究，也不能直接宣称金融判断全部正确。人工复核发现模型根据两份文件的措辞推断某项跟踪约束“严一倍”，缺乏足够同口径依据。后续独立读取一手资料，明确撤回这项推断，并把更正与原报告分别保存。
这两段经历共同说明了一件事：前台是否真正可用、后台是否真正继续、研究是否准确回答问题，是三个需要分别核对的成果。
并发交互的真实验收，不意味着长期生产稳定性、所有资金与费用数字、金融语义质量都已经得到认证。我们保留这些边界，不用一个漂亮的“已完成”掩盖它们。
七、最值得复制的，不是后台面板，而是任务关系
如果要为现有 Chat 产品增加这种能力，我会优先作出三个选择。
第一，让长研究拥有独立生命期。 接纳后由服务端记录任务；前台连接只是进度与内容的观看方式，不是任务的存在条件。停止必须有明确目标，不靠整个聊天框的一个开关。
第二，让新消息按真实意图进入正确的任务。 独立短问独立回答，明确调整沿原消息和原研究身份交接。只收到、真正采用、最终完成分别留证；没有容量就明确拒绝，不偷偷改目标。
第三，让前端以任务身份组织乱序内容。 后发回答先到、临时消息被历史替换、结束信号快于持久化读取，都不应造成串话、消失或重复执行。
这三件事都不需要再造一个常驻的“前台总 Agent”。它们首先要求原有研究、控制、发布和历史事实之间能可靠对应。
好的 Personal Agent 不是永远占着输入框告诉你“我正在思考”，而是你把复杂工作交出去之后，仍然可以自然地继续提问、改变要求，并最终找回属于那项任务的真实结果。
这才是我认为异步后台深度研究最值得让读者看见的产品体验，也是支撑它的架构选择。
延伸阅读：异步研究的时间约定与离线交付讨论到点交付与历史重读；渐进回答的连贯性讨论同一回答如何持续改善。本文聚焦前台继续对话、后台任务归属和运行中调整，不重复这两篇的机制细节。
延伸阅读与交流
本文也收录于 ETF Agent 工程手记，另有完整英文版。如果这些工程记录对你有帮助，欢迎在 GitHub 文集 点个 Star，方便后续阅读。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
If you want to talk, confiscate the suspension button of the AI dialogue! One day, Agent, you're going to have to backstage research.
The real personaAgent, shouldn't let a long study take over the chat box. Users should also be able to ask other questions at any time, see the progress of the original study and add new requirements; each should continue, and answer and control operations should not be associated with another task.
It sounds like a front-end interactivity optimization, but when we developed ETF Agent, we found that it was hard not to let the two models request to run at the same time, but to keep the different intentions in the same conversation and to carry out tasks that were always right.
We actually did this:
- First of all, "Why did NASDAQ fall?" - Start a longer study.
- Ask again, “What is the connection between gold and the United States debt?” — An independent answer at the front desk, without waiting for the previous end.
- Midway addition: “There is a need to compare with the fall of A shares.” — Unequivocal referral to the original study, rather than a new unrelated answer.
Interactivity signals: independent answers to independent questions, with explicit additional requests being sent to the original study; distance does not represent time-consuming implementation.
The results on the page were intuitive: the back-office research portal was kept at the top, the answer to the gold and the United States debt was still in the main conversation, and the new A stock comparison required that the “referral to the study model” be shown. The user does not have to abort the original task for the purpose of continuing the chat; the real stop button is still in place, only for the corresponding research, not the entire input box.
The title refers to “one day”, which is to connect and interact on the basis that ETF Agent already has the capability of research cycle, tools, lasting history, recovery and body publish; not to complete research from zero a day.
i. The chat box should not be turned into a progress note
The original ETF Agent has been able to continue research after the user has left the page. However, the front end is still easily fed around a global “emerging” status: back-office tasks exist and new messages are easily understood as complementary.
This creates a product paradox: the service has been able to work independently, while the user is still waiting around the job.
We've compared three seemingly easy ways. When new information is received, the old answers are taken away, allowing a random question to interrupt important research; quelling short questions and still failing to respond in a timely manner; and creating a permanent desk, Agent, to harmonize coordination, introducing a second set of long-term context and mission life.
The final choice was a more restrained structure: the same session could be implemented on an independent basis many times, rather than maintaining order by a busy front desk, Agent.
Long-term research runs along the old Research Run; short questions have their own executing identity; front-end connections and streams are only responsible for allowing users to see progress and do not have the authority to decide whether to continue the study. The closing of panels, the switch to another conversation, and the disconnection of the network do not mean the cessation of the research that has been admitted.
There is still an independent portal to the study, which shows another completed response.
This option was not to create a separate back-office book, but to revert to existing tasks, controls, restorations and publish identities. What's new is which task the message belongs to, what the users want to do now, which section the page should update.
ii. Is the user asking questions or modifying research?
This is the judgment that the whole experience is most easily ignored, but that affects correctness.
The “Nasdak study is ongoing” is the state of the system; “What is the relationship between gold and United States debt” is a new issue for users. The latter sentence cannot be automatically inserted into the previous study simply because the system is busy.
We retain the understanding of natural language intent at the ordinary entrance, but when the user clearly specifies the target, no longer lets the model re-guess:
There's a Coord co-ordinated result in it, but it's not a new resident in Agent, nor a second state of research.
There is also a practical constraint: input boxes can receive messages on an ongoing basis and do not mean that the system can be implemented indefinitely. The initial configuration allows for three short interactive and one back-office study; the synopsis, single study budget, and vendor request capacity remain three distinct types of resources. When the back office is filled, it is clear that new research is not accepted, rather than quietly turning it into a complement to old research.
This is a direct inspiration for product design: do not substitute " Page Busy" for a judgement of user intent, and do not express the true relationship of multiple tasks in a global loading state.
“Received adjustments” and “research has actually applied adjustments” are not the same thing.
When the user says “there's still a big drop against A”, the system first saves this original user message and then connects the message identity to the target study.
Why not just rewrite the portal model into a refined research directive?
Because the recitation of the model may lose date, object and user limit; if the request fails, the same modification may be repeated in the study. We leave it to the portal to determine which task to adjust, and the handover is read from the original message that has been saved. The same legitimate retry read back the handover results instead of another adjustment.
User messages and back-to-back messages remain in the dialogue; research uses its own implementation and history records.
But it cannot be immediately declared that the “research has been understood and adjusted”. There are at least three different facts:
The message was kept, indicating that the request had not been lost; the follow-up model request had actually been accompanied by it, indicating that the handover had taken place; and the final report met the new requirement and also looked at the information and findings. They can't impersonate each other.
And that's why random chats at the front desk don't automatically become context in backstage research. Only historical snapshots that are eligible at the time of submission are read for short questions; follow-up requests from the original study are entered only when adjustments are clearly communicated. The latter questions, even if completed first, cannot reverse the material that was seen at the time of the initial request.
iv. Real side-haired, not a few spin-ring animations at the same time.
When the input box is unlocked, another question becomes exposed: an answer appears on the page in a different order of execution than it would be at the service end.
For example, two questions were initiated by the user, and one was completed first. The front-end cannot continue to extrapolate the correspondence with the Last Asistant message, but instead find questions, answers, tool progress and control operations along Run.
We had a real intersection failure: the page showed a temporary response line, history read it and then replaced it with a formal message; the current content was still updating the old temporary ID, resulting in the answer not finding its place. The restoration was not to add an additional text, but to locate the message of the current load response along the original Run and retain its own publish identity.
Similarly, the closing notice was received first and the database view may not have been updated; early historical reading may have returned later than new requests. We use read-only and page-reading sequence protections to avoid misperceiving the results that have not been read for the time being as a failure of research or allowing old snapshots to overwhelm new content.
Physical access has also gone through the pits: for the first time, there was still room for question-and-answer, but it was refused immediately because the database was locked in competition. What we are repairing is that the access phase waits for short-term issues, rather than sneaking user assignments into a new line.
These problems all have a common root cause: when the system evolves from “one session with only one current task” to more than one independent implementation, the information identities, attribution of results and resource occupation can no longer be borrowed in the sequence of interfaces.
V. A "cancellation" almost finished the whole study ahead of schedule.
A more representative example of the experience occurs in the midst of user bias.
Model requests may be in the process of being generated; upon arrival of the new requirements, the system will need to make the current request secure and then submit the complete request to the next request.
However, in a genuine study, the correction has been preserved and the current model request has been interrupted as expected. The appropriate layer is requested to transform the partial seizure into an ordinary “cancellation”; it operates on the mistaken assumption that the entire study can only be completed and no further information will be sought. Partial responses were eventually left and the complete comparison required by the users was not completed.
The problem is not that “there should be a few additional retrys”, but that two different actions are confused:
- Users have taken the initiative to stop research: end the old Run and do not restart it with late adjustments.
- Discontinuation of the current request for the adoption of the new request: retention of the original Run mandate, budget, completed results and unknown usage; continuation of the study if qualified.
Later, we repaired the handover of the reasons for the interruption of the request, so that the follow-up study could still take evidence under the original rules of access, rather than being pushed prematurely to the end.
This practice is of particular value to Agent Runtme developers: the life span requested by a model is not the life span of the entire research mission. A generic uncoded error cannot be allowed to replace the original task for final decision.
VI. Interactivity is not the same as every research is done correctly.
In the initial NASDAQ demonstration, gold and American debt briefs could be read independently, and the new A stock comparison requirement was actually sent to the original study. The original report, however, did not provide the A equity and financial data needed to complete the same date comparison, but only gave a clearly limited analytical framework.
This is the real gap in the original demonstration: the request has been handed over and a full data comparison is still incomplete.
On October 26, 2026, another independent financial study, the real acceptance check, produced more complete and interactive evidence: The back-office study overlapped with the three short questions and was eventually completed; the full text of the orientation adjustments entered into the follow-up study request; the short-question body did not enter the back-stage input; and the report and dialogue history was also read back in the actual browser. The corresponding project acceptance check has been formally archived.
But even this normally completed study cannot directly claim that the financial judgement is all correct. The manual review found that the model relied on the wording of both documents to infer that a tracking constraint was “twice” and lacked a sufficiently homogenous basis. Follow-up, independent reading of first-hand information, explicitly withdrawing this inference and preserving the corrections separately from the original report.
The two experiences together illustrate one thing: whether the front desk is really available, whether the backstage is really continuing, and whether the study is an accurate answer is the result of three separate checks.
The fact that acceptance check is interactive does not mean that long-term production stability, all financial and cost figures, and financial semantic quality are certified. We keep these borders without a beautiful “completed” cover.
VII. The most worthy of replication is not the background panel, but the mission relationship
I would give priority to three options if I were to add this capability to existing Chat products.
First, give long-term research an independent lifetime. When accepted, the task is recorded by the service; the front-office connection is only a view of progress and content, not a condition for the mission. Stop must have a clear target, not a switch on the entire chat box.
Secondly, let the new news enter the right mission with real intent. Independent short questions are answered independently, clearly adjusting the interface between the original message and the original research identity. Separate certificates are received, actually adopted, and finalized; explicit refusal without capacity does not change targets.
Thirdly, the front end is to organize the content as a mission. Subsequent replies should not result in stringing, disappearing or repeated execution, either first-in, temporary messages being replaced by history, or ending signals faster than lasting reading.
None of these three things require the creation of a permanent "Directorate Agent." They first require a reliable correspondence between the original research, control, publish and historical facts.
Well, Personal Agent didn't always take the input box to tell you that I'm thinking about it, but after you hand over the complicated work, you can naturally continue to ask questions, change demands and finally find the real results of that task.
And that's what I think is the product experience that's most worthy of being seen by readers, and the structure choices that support it.
Extending reading: The time frame for the study is scheduled to coincide with the delivery of offline to discuss point delivery and historical re-reading; consistency of incremental responses discusses how the same answer can be improved on a continuous basis. This paper focuses on continuing dialogue, attribution of back-office tasks and adjustments in operation without repeating the details of the mechanisms.
Extension reading and communication
This document is also available in the ETF Agent project manual, which is also available in full English. If these project records are of help to you, please order Star in GitHub collection for follow-up.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.