很多 Agent 已经具备了长对话、记忆、工具调用、任务恢复和历史报告保存能力。但当用户希望围绕同一个目标持续研究几个星期，甚至几个月时，这些能力组合起来，仍然可能缺少重要的一环。
一次研究结束了，研究目标却没有结束。
我的 ETF Agent 已经能够独立执行研究 Run、保存正式回答、读取历史证据，也能够通过 Memory 保留用户偏好。但这些能力并没有自动构成一个长期研究空间。
这次设计 Research Workspace，我希望解决的不是如何让 Agent 永远运行，而是：如何让多次独立的研究，共同服务于一个长期目标，同时保留每次研究原本的身份、证据、版本和权限？
最终选择的方案，是增加一个独立的 Workspace Module，负责组织长期目标与研究成果，却不另建一套研究执行器。
一、为什么对话历史和 Memory 还不够？
先看一个教学场景。
假设用户希望持续评估某只基金的流动性风险。
第一周，Agent 根据公开报告分析了基金规模和交易情况，形成报告 A。
第二周，用户发现基金持有人结构发生变化，又生成报告 B。报告 B 提出了与报告 A 不完全一致的判断。
第四周，一份新的基金公告发布。用户希望 Agent 重新评估风险，并解释：此前哪些判断仍然成立，哪些需要调整？
这是一个跨时间、跨证据版本的研究任务。
最简单的做法，是把前两次对话全部交给模型。但这样会遇到三个问题。
首先，历史上下文并不等于历史证据。模型可能看到报告 A 的摘要，却不知道它对应哪个原始版本、何时形成、是否已经有后续修订。
其次，历史信息越积越多，模型不应该每次都读取全部内容。它真正需要的，可能只是报告 A 的某个旧版本、报告 B 的结论，以及最新公告。
最后，长期研究目标也不能被某次模型回答覆盖。用户提出的研究目标，与模型在某次分析中形成的临时判断，本来就不属于同一类状态。
已有能力解决的是不同问题：
这也与常见 Agent 框架中的持久化机制有所区别。例如，OpenAI Agents SDK 的 Session 管理跨轮对话历史；LangGraph 的 Checkpointer 保存线程执行状态，Store 则支持跨线程数据。这些机制提供了重要基础，但不自动定义一个金融研究目标如何关联不同报告，以及历史材料何时可以被下一次研究使用。
Workspace 需要回答的是更具体的产品问题：用户正在研究什么，过去留下了哪些材料，下一次研究究竟复用了什么，以及目前有哪些问题仍未解决？
二、Workspace 应该成为独立 Module，而不是第二个 Agent
一种直觉方案，是创建一个长期运行的 Project Agent。
它负责维护目标、调度任务、记忆结论、检索资料，并控制后续执行。这样似乎能够让系统拥有连续的研究能力。
但在已有成熟 Run、Publication、Memory 和 Artifact 能力的系统中，这个方案容易引入重复职责。
例如，旧 Run 结束后，谁能决定它重新执行？Workspace 保存的历史报告能否绕过原来的权限检查？某个研究结论修改后，究竟由 Publication 还是 Workspace 负责记录正式版本？
如果这些问题没有明确答案，长期研究模块可能逐渐变成另一套运行时。
我的选择是把 Workspace 的职责限定在三个方面：目标、关系和进展。
目标是用户持续研究的主题及其版本；关系是 Workspace 与原有 Conversation、Run、Publication、Artifact 之间的关联；进展则是带来源的可选研究摘要和未解决问题。
一次实际研究仍然交给原来的 Run 执行。
graph TD
UserQuestion --> OriginalRunAdmission
OriginalRunAdmission --> BoundedHistoryCatalog
BoundedHistoryCatalog --> OriginalMaterialChecks
OriginalMaterialChecks --> ExactVersionRead
OriginalMaterialChecks --> LocalUnavailable
ExactVersionRead --> IndependentResearch
LocalUnavailable --> IndependentResearch
IndependentResearch --> OriginalPublication
OriginalPublication --> WorkspaceAssociation
这是一张职责关系图，而不是不区分成功与失败的强制流程。原始材料合格时，新 Run 可以读取精确历史版本；不合格时仅把相关材料标记为不可用，并在其他合法证据足够的条件下继续研究，或者诚实说明缺口。实际是否发布答案仍由原有研究与发布机制决定。
这条路径最重要的特点，是 Workspace 不接管执行权。
用户进入 Workspace 并提出新问题时，系统通过原来的 Entry、Host 和 Run 准入路径创建一次独立研究。新的 Run 拥有自己的身份、资源限制和当次授权。
它可以读取合格的旧研究材料，但不能继承旧 Run 的全部权限，也不会因此重新启动已经完成的旧任务。
同样，Workspace 也不需要复制旧报告正文。它保存的是原有研究对象的关联，真正的内容读取、版本确认和发布仍然由原有模块负责。
这样的 Module 有清楚的接口和实现，但不是新的 Agent 进程，更不是额外的模型循环。
三、跨 Run 研究的关键：不能把“找到”当成“用过”
Workspace 最值得深入设计的，是历史材料的消费过程。
在一次普通对话中，用户可能主动指定上一份报告。长期研究则不同：用户只会提出新的问题，系统需要让模型发现多个可能相关的旧材料。
这里存在一个容易忽略的差异：
一份报告出现在历史目录中，不代表模型已经读取它；模型读取了报告，也不代表正确使用了它的结论。
因此，Workspace 将历史材料的处理分成几个不同阶段。
第一步是发现候选。
Workspace 根据当前所属用户、关联的 Conversation 和原有研究结果，建立有界的历史材料目录。目录提供的是对象身份、版本和相关来源信息，而不是无条件把所有报告正文注入 Prompt。
候选规模受到限制，目录也会保留不完整或不可用的状态。系统不会因为某份材料没有出现在本次结果里，就声称历史上不存在这份材料。
第二步是选择与读取。
模型可以根据当前问题决定读取哪些历史材料。每项读取都必须经过原有权威模块的检查，包括原始对象身份、版本、内容摘要、来源依赖和当前 Run 的访问资格。
第三步才是实际进入模型请求。
只有当历史内容通过校验、被实际读取，并进入相应的模型输入时，系统才有依据说这份历史材料被当前研究消费过。
这比“我们在 Prompt 里写了请参考历史报告”更可验证。
一个具体例子
延续前面的基金研究场景。以下 JSON 是教学示意，不是实际 API，也不包含真实金融数据。
{
"goal": "持续评估某基金的流动性风险",
"goalVersion": 2,
"question": "新公告是否改变此前判断？",
"selectedHistory": [
{
"material": "第一周报告 A@v1",
"status": "已读取精确版本"
},
{
"material": "第二周报告 B@v1",
"status": "已读取精确版本"
}
],
"currentEvidence": "第四周新增公告",
"outcome": "产生独立的新研究报告"
}
这里有两个重要细节。
第一，报告 A 的 v1 是明确的历史版本。如果后来发布了 v2，系统不能为了方便，悄悄用新版本替换用户当时希望重新检查的旧判断。
第二，新公告和历史报告具有不同的时间语义。历史报告说明过去在什么信息条件下形成了某种判断，新公告则可能提供更新证据。二者不能被混为同一时点的事实。
在 ETF Agent 的受控实现验证中，已经覆盖这样的路径：模型读取两个来自既有研究的精确 Publication 版本，其中包含非最新版本；相应内容进入新的模型请求，新的回答再由原 Publication 路径独立保存和读取。
这证明了跨 Run 材料消费的工程路径能够成立，但不等于真实模型必然能够准确判断哪份历史报告更有价值。选择能力和金融判断质量仍然需要独立评估。
四、为什么 Workspace 还要保存研究进展？
只有历史报告还不够。
用户可能已经积累十几份研究结果，但仍然不知道当前有哪些问题没解决，下一次应该从哪里继续。
这正是 Workspace Checkpoint 的用途。
它不是执行恢复时保存的运行状态，而是一份可选的、版本化的研究进展记录。
例如，在一次研究完成后，模型可以提出：
“此前关于流动性的判断需要重新核实，新增公告尚未解决持有人集中度问题，下一步建议检查最新披露的申赎数据。”
这段内容可以帮助用户理解研究正在向哪里推进，但不能因此变成基金的真实状态，更不能覆盖用户原本的研究目标。
所以 Checkpoint 需要保留产生它的原始 Run、已接受的 Publication、所引用的历史材料和来源依赖，并明确标记为模型建议性质的内容。
在实现中，它还有几个重要约束。
进展更新是可选的。 模型没有提出有效的更新，不应该让原本合法的研究回答失败，也不应该凭空生成一份“研究已完成”的记录。
更新必须遵守版本。 研究进展采用基于预期修订版本的并发控制（CAS）。如果另一项更新已经发生，旧提议不能覆盖较新的进展。未被明确更新的问题也不能因为一次模型省略就自动消失。
来源不可用时，旧进展不能冒充仍然有效。 如果某份派生研究记录依赖的原始资料或历史 Publication 已不再具备读取资格，读取端会返回不可用状态，而不是继续展示缓存的旧判断。
这意味着 Workspace Checkpoint 和 Memory 有不同职责。
Memory 适合保存经过其自身治理的长期偏好与经历；Checkpoint 表示围绕某个研究目标、根据特定来源形成的阶段性建议。它也不是可自动改写的 Investment Thesis，更不是用户确认过的投资决策。
目前 Workspace 自动学习 Memory 仍属于后续方向，没有必要为了实现第一阶段的长期研究，就提前建设第二套记忆系统。
五、长期存在的东西，更需要清楚的生命周期
Workspace 既然可以长期保存，就一定会遇到目标修改、并发请求、归档和删除。
这些场景比创建一个文件夹更能检验架构是否合理。
目标修改不能改写正在执行的研究
假设用户先提交了一次研究，随后修改了 Workspace 的目标。
已经获准执行的 Run 应继续使用当时被冻结的目标版本和材料选择。之后的新 Run 才使用更新后的目标。
这样，用户回看历史结果时，才能解释为什么某次研究仍然围绕旧目标展开。
如果重试请求带来了与原记录不同的 Workspace 或历史材料选择，系统也不能把它当成相同请求继续执行。
归档不等于停止原有 Run
归档的含义是：这个 Workspace 暂时不再接收新的关联研究。
它不应该获得取消全部原始任务的权力。已经获准执行的 Run 仍由自己的执行、停止和恢复机制负责结算；原有报告仍可按自己的权限被读取。
归档是可恢复的组织状态，不是删除操作。
删除 Workspace 不等于删除研究成果
如果用户删除 Workspace，系统移除的是这个研究空间本身的组织关系、目标和附属进展，阻止之后的新关联。原有 Conversation、Run、Publication 以及已经由原 Artifact 模块合法保留的文件，并不会因此被连带删除。
即使某个此前获准的 Run 在删除之后才完成，也不能把已经移除的 Workspace 重新创建出来。
这项设计的核心是让不同数据的生命周期仍然由各自的权威模块负责。未来若要支持“清除所有关联数据”，需要另行定义明确的删除范围、权限和后果，而不是把它偷偷绑定到删除 Workspace 的按钮。
文件留存也遵守同样原则
Workspace 可以为当前支持的 HTML Artifact 发起留存与关联请求，但真正保存文件内容、确认留存资格、控制下载和处理过期的，仍然是原 Artifact 模块。
Workspace 关联成功不等于它获得了文件的所有权。若原文件留存成功、Workspace 关联却未确认，系统也必须明确区分这两种结果。
不能因为界面出现了一个文件入口，就宣称所有 PDF、Markdown 或任意格式的历史文件都能永久保存。
六、这套设计实际上验证到了哪里？
Workspace P0 已经合入 ETF Agent 的主干代码。
目前的实现包括独立的业务接口、持久化记录、研究目标及版本控制、原始 Conversation 关联、历史材料目录、跨 Run 消费、可选 Checkpoint、Artifact 关联及 Web 操作入口。
工程验证中，除了普通的接口测试，还使用了合成研究材料、脚本化模型响应以及原有 HTTP、Runtime、Publication 和 PostgreSQL 路径，检查独立新 Run 如何消费旧版本、保存新结果，并在服务进程重新启动后重新读取。相同请求身份的重试也有对应验证，避免凭重试无意增加一次独立研究。
这些观察支持当前实现的主要机制，而不是仅靠类型定义或界面截图说明能力存在。
与此同时，需要准确区分合入主干与完成正式验收：这次合并保留了完整应用类型检查的超时缺口，正式全量验收尚未结束，功能默认关闭，也没有据此宣称真实用户或真实金融研究质量已通过验证。
公开的 open-etf-agent 仓库目前也还没有提供这套 Workspace 模块的独立可运行版本，因此本文是一篇基于已实现工程机制的架构实践文章，而不是公开安装教程。
对于长期研究产品来说，这样的分阶段交付是可以接受的，但不能把工程路径走通直接等同于产品效果已经得到证明。
七、什么时候值得引入 Workspace？
并不是所有 Agent 都需要一个 Workspace。
如果用户只是在同一个对话中连续追问，普通 Session、对话历史和适当的上下文管理通常已经足够。
但当任务出现三个特征时，就值得考虑一个独立的长期研究 Module：
- 用户的目标跨越多次独立研究，单个 Run 结束后目标仍然持续存在。
- 历史结论需要按原始身份、版本和时点精确重新消费，不能只依赖最新摘要。
- 用户需要管理研究进展、旧成果和生命周期，同时又不能让新的组织层接管原有权限或执行权。
此时，Workspace 的价值不是替模型记住更多文字，而是让研究对象之间的关系变得可管理、可验证。
它也带来了真实代价：更多持久化关系、版本冲突处理、跨模块读取校验，以及有界目录可能遗漏候选资料的问题。如果业务不需要跨 Run 的目标连续性，这些复杂度就不值得引入。
结语
设计 Workspace 之前，我更容易把 Agent 的连续性理解为“保存历史、保留记忆、支持恢复”。
但这次工程实践让我更加明确：执行连续性、对话连续性和研究目标连续性，是三个不同的问题。
一次 Run 可以结束，一份报告可以被修订，某份旧材料可以变得不可用，甚至整个研究空间可以被移除。这些变化不应迫使系统复制或重写其他模块原本拥有的事实。
长期研究真正需要的，是一个稳定的用户目标、一组能够追溯到原始对象的关系，以及在每次新研究中重新确认材料资格的机制。
所以我没有选择打造一个永不停止的 Project Agent，而是让 Workspace 成为一个职责足够清楚的独立 Module。
长期研究并不要求 Agent 一直运行，而是要求每次重新开始时，它都能准确知道：目标是什么，过去有哪些材料，哪些仍然可用，以及这一次究竟依据什么形成了新判断。
这或许是个人研究 Agent 从聊天工具走向长期工作空间时，更值得优先解决的工程问题。
延伸阅读：跨 Run 历史压缩 · 从投研聊天到持续研究。Open ETF Agent 是独立的开源教学实现，尚未提供本文的 Workspace 模块；如果这些可运行示例对你有帮助，欢迎为仓库点个 Star。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
Many Agent already has long-term dialogue, memory, tool call, mission recovery and historical report preservation capabilities. However, when users wish to continue studying the same goal for several weeks, or even months, these capabilities may still lack an important link.
One study was completed and the goal was not.
My ETF Agent has been able to carry out research independently, Run, save official answers, read historical evidence, and retain user preferences through Memory. However, these capabilities do not automatically constitute a long-term research space.
This design Research Workspace, which I hope will address, is not how to make Agent work forever, but how to allow multiple independent studies to serve a long-term goal, while retaining the original identity, evidence, version and permission for each study.
The final option was to add an independent Worldspace Modeule to organize long-term objectives and research results without creating a separate research implementer.
I. Why is the history of dialogue and memory not enough?
Let's start with a teaching scene.
It is assumed that the client wishes to continuously assess the liquidity risk of a particular fund.
In the first week, Agent analysed the size of the Fund and its transactions on the basis of a public report, resulting in report A.
In the second week, users discovered a change in the structure of the fund holders and generated a report B. Report B presents a judgement that is not entirely consistent with report A.
Fourth week, a new fund announcement publish. Users would like Agent to reassess the risks and explain: which judgements were still valid and which needed adjustment?
This is a time- and evidence-based task.
The simplest approach would be to hand over all the first two dialogues to the model. But there are three problems.
First, history context does not amount to historical evidence. The model may see the summary of Report A, but it is not known which original version it should be, when it was formed and whether it has been subsequently revised.
Second, the more historical information is accumulated, the model should not be able to read all of it every time. What it really needs may be just an old version of report A, the conclusions of report B and the latest bulletin.
Finally, long-term research objectives cannot be covered by a model response. The research objectives proposed by the users are not in the same state as the ad hoc judgements formed by the model in a given analysis.
What is in a position to address are different issues:
This is also different from the sustainability mechanism in the common Agent framework. For example, the session of Open AI Commissions SDK manages the history of cross-cycle dialogues; the checkpointer saves thread performance in LangGraph supports cross-line data. These mechanisms provide an important basis, but do not automatically define how a financial research objective relates to different reports and when historical materials can be used in the next study.
Workspace needs to answer more specific product questions: What is being studied by users, what material has been left in the past, what is being reused in the next study, and what problems remain?
II. Workspace should be independent Module, not the second Agent.
An intuitive solution is to create a long-run Project Agent.
It is responsible for maintaining objectives, movement tasks, memory conclusions, retrieval of information and controls follow-up implementation. This seems to allow the system to have continuous research capacity.
However, in systems with well-established capacities in Run, Publicization, Memory and Artifact, the programme can easily introduce duplicate functions.
For example, after the old Run, who can decide to re-enforce it? Can the Workspace saved history reports bypass the original permission check? Is it the Publicization or Workspace that records the official version of the book?
If there is no clear answer to these questions, the long-term study module may gradually become another set of operational hours.
My choice is to limit the role of Workspace to three areas: goals, relationships and progress.
The goal is the subject of ongoing research by users and its version; the relationship between the Worldspace and the original Congress, Run, Publicization, Artifact; and progress is an optional study with source summary and unresolved issues.
A practical study was still entrusted to the original Run for execution.
graph TD
UserQuestion --> OriginalRunAdmission
OriginalRunAdmission --> BoundedHistoryCatalog
BoundedHistoryCatalog --> OriginalMaterialChecks
OriginalMaterialChecks --> ExactVersionRead
OriginalMaterialChecks --> LocalUnavailable
ExactVersionRead --> IndependentResearch
LocalUnavailable --> IndependentResearch
IndependentResearch --> OriginalPublication
OriginalPublication --> WorkspaceAssociation
This is a chart of functional relationships, not a mandatory process that does not distinguish between success and failure. When the original material is qualified, the new Run will be able to read an accurate historical version; if it is ineligible, only the relevant material will be marked as not available and research will continue under conditions that are sufficient for other legitimate evidence, or an honest description of the gap. Whether or not the answer to publish is in fact still determined by the original study and the publish mechanism.
The most important feature of this path is that Workspace does not take over enforcement.
Users enter the Workspace and ask new questions, and the system creates an independent study through the original Entry, Host and Run access paths. The new Run has its own identity, resource constraints and current mandate.
It can read qualified old research materials, but cannot inherit all of the old Run permission, nor will it restart the old tasks that have been accomplished.
Similarly, Workspace does not need to copy the body of the old report. It preserves the connection of the original subject of the study, and genuine content reading, version confirmation and publish remain the responsibility of the original module.
This Module has a clear interface and realization, but it is not a new Agent process, much less an additional model cycle.
The key to cross-Run research: cannot "find" as "used"
Workspace is the process of consumption of historical materials.
In a general dialogue, users may choose to designate the previous report. Long-term research is different: users can only ask new questions, and the system needs to allow models to find multiple old materials that may be relevant.
Here's an easy difference:
The fact that a report appears in the historical catalogue does not mean that the model has read it; nor does it read the report, nor does it represent the correct use of its conclusions.
Thus, the workspace divides the processing of historical materials into several stages.
The first step is to find candidates.
Workspace has developed a catalogue of historical materials based on current users, associated review and original research. The directory provides information on the identity of the object, the version and the relevant source, rather than an unconditional injection of all the body of the report into Prompt.
If the size of the candidate is limited, the directory will remain incomplete or unavailable. The system does not claim the historical absence of a particular material because it does not appear in this outcome.
The second step is choice and reading.
The model can determine which historical materials to read on the basis of current problems. Each reading must be checked by the original authoritative module, including original object identification, version, content summary, source dependence and current Run eligibility.
The third step is the actual entry request.
Only when the historical content is validated, physically read and entered into the corresponding model input is there a basis for the system to say that this historical material has been consumed by current research.
This is more verifiable than "We wrote history reports in Prompt."
A specific example.
Continue the previous Fund research landscape. The following JSON is a teaching illustration, not a real API, nor does it contain real financial data.
{
"goal": "continuous assessment of a fund's liquidity risk,"
"goalVersion": 2,
"Question": "Did the new bulletin change the judgment?"
"selectedHistory": [
{
"Material": "First week report A@v1"
"Status": "Accurate version read."
},
{
"Material": "Second week report B@v1"
"Status": "Accurate version read."
}
],
"CurrentEvidence": "New announcement for the fourth week,"
"outcome":
}
Here are two important details.
First, the v1 of Report A is a clear historical version. If later publish v2, the system cannot quietly replace, for convenience, the old judgement that the user wanted to recheck.
Second, new bulletins and historical reports have different temporal synonyms. The historical report illustrates the information conditions under which a judgement was formed in the past, and the new bulletin may provide updated evidence. They cannot be confused with the same facts.
In the controlled realization verification of ETF Agent, the path is already covered: the model reads two accurate versions of Publication from existing studies, which contain non-latest versions; the corresponding content enters a new model request and the new answer is independently saved and read by the original Publicisation path.
This proves that the engineering path across Run material consumption can be established, but it does not mean that the true model is necessarily able to determine precisely which historical report is more valuable. The choice of competencies and the quality of financial judgement still require independent assessment.
iv. Why is Workspace still keeping research progress?
Historical reports alone are not enough.
Users may have accumulated more than a dozen research findings, but they still do not know what problems remain and where to proceed next.
This is exactly what the Workspace Checkpoint is for.
It is not a state of operation that is maintained at the time of recovery, but an optional, versionable record of research progress.
For example, after a study has been completed, the model could propose:
“Previous judgement on liquidity needs to be re-verified, the issue of concentration of holders has not yet been resolved in the new bulletin, and next step recommends checking the newly disclosed foreclosure data.”
This element helps users understand where research is going, but it cannot be translated into the true status of the Fund, let alone cover the original research objectives of the users.
So Checkpoint needs to retain the original Run, accepted Publicization, reference to historical material and source dependence, and clearly labeled as the recommended nature of the model.
There are also important constraints in achieving this.
An update of progress is optional. The model does not present an effective update and should not allow otherwise legitimate research responses to fail, nor should it generate a record of “research completed”.
Updates must follow the version. The progress of the study is based on the expected revised version of concurrent controls (CAS). If another update had taken place, the old proposal could not cover more recent developments. Problems that are not explicitly updated cannot automatically disappear as a result of a model omission.
When sources are not available, old progress cannot be assumed to remain valid. If the source or history on which a derivative research record relies is no longer qualified to read, the reading end returns to an unusable state instead of continuing to display the old cache judgment.
This means that Workspace Checkpoint and Memory have different duties.
Memoory is well suited to preserve long-term preferences and experiences that are governed by its own governance; Checkpoint indicates a phased proposal based on a particular research objective. Nor is it an automatic rewriting of investment Thesis, much less a user-recognized investment decision.
Workspace AutoLearning is still in follow-up and there is no need to build a second memory system ahead of schedule in order to achieve the first phase of long-term research.
V. Long-standing things that require a clear life cycle
Workspace, since it can be kept for a long period of time, is bound to encounter objective modifications, requests, filings and deletions.
These scenes test the structure better than creating a folder.
Target modification cannot rewrite ongoing research
It is assumed that the user submitted a study and subsequently modified the Worldspace target.
Run, which has been approved for implementation, should continue to use the target version and selection of the material then frozen. Then the new Run used the updated target.
Thus, when users look back at historical results, they can explain why a particular study still revolves around old goals.
If the retry request brings with it a choice of workspace or historical material that differs from the original record, the system cannot continue to perform as the same request.
Archiving doesn't mean stopping old Run.
The idea of archiving is that this workspace will not receive any new association studies for the time being.
It should not be given the power to cancel all original mandates. Run, which has been approved for implementation, remains under its own enforcement, cessation and rehabilitation mechanism; the original report is still available under its own permission.
Archive is a recoverable organizational state, not a deletion operation.
Remove Workspace is not the same as delete research results
If users delete Workspace, what the system removes is the organizational relationship, objectives and ancillary progress of the research space itself, preventing subsequent new linkages. The original review, Run, Publicization and documents that have been legally retained by the original Artifact module will not be deleted.
Even if one of the previously approved Runs was done after the deletion, it would not be possible to recreate the removed Workspace.
Central to this design is that the life cycle of different data remains the responsibility of their respective authoritative modules. To support “cleaning all associated data” in the future, there is a need for a clearly defined scope for deletion, permission and consequences, rather than for it to be secretly tied to a button to remove Workspace.
The same principles apply to the retention of documents.
Workspace can initiate retention and association requests for currently supported HTML Artifact, but the actual preservation of file content, confirmation of retention eligibility, control of downloads and processing of expired is still the original Artifact module.
Workspace's connection successfully does not mean that it acquired ownership of the document. If the original document is retained successfully and the Worldspace connection is not confirmed, the system must also make a clear distinction between the two outcomes.
A file entry should not be created on the interface to claim that all PDF, Markdown or any historical document in any format can be permanently preserved.
VI. Where does this design actually prove?
Workspace P0 has been integrated into the ETF Agent backbone code.
Current achievements include a stand-alone business interface, durable records, research objectives and version control, raw access, catalogue of historical materials, cross-Run consumption, optional Checkpoint, Artifact connection and Web access.
In addition to standard interface tests, synthetic research materials, script model responses and the original HTTP, Runtme, Publicisation and PostgreSQL paths were used to verify how the new independent Run consumes old versions, saves new results and rereads them once the service process is restarted. retry, which is the same requesting identity, also has a matching test to avoid the fact that retry has no intention of adding an independent study.
These observations support the main mechanisms currently being achieved, rather than relying solely on type definitions or interface screenshots to demonstrate capacity.
At the same time, a precise distinction needs to be made between integration and completion of the formal acceptance check: this merger retains the timeout gap for full application type checks, the formal full volume of acceptance check has not yet been completed, the functionality has by default been closed, and the quality of real users or real financial research has not been certified.
The open open open-etf-agent repository also does not currently have an independent and operational version of the Workspace module, so this paper is a structured and practical article based on the achieved engineering mechanisms, rather than a public installation course.
Such phased delivery is acceptable for long-term research products, but it cannot be directly equated with product effects.
When is it worth introducing Workspace?
Not all Agent needs a workspace.
If users are merely following up on each other in the same dialogue, ordinary session, dialogue history and proper context management are usually sufficient.
But when the mission has three features, it is worth considering an independent long-term study, Module:
- The targets of the users span multiple independent studies, and individual Run end-of-life targets persist.
- Historical conclusions require accurate re-consumption by original identity, version and time, and cannot rely solely on the latest summary.
- Users need to manage research progress, old results and life cycles without allowing new layers of organizations to take over the original permission or executive powers.
At this point, the value of the Workspace is not to remember more text for the model, but to make the relationship between the subject of the study manageable and verifiable.
It also brings real costs: more enduring relationships, version conflict management, cross-module reading and validation, and the possible omission of candidate information from the directory. These complexities are not worth introducing if operations do not require continuity of objectives across Run.
Concluding remarks
Before designing Workspace, it was easier for me to interpret the continuity of Agent as “historizing history, preserving memory, supporting recovery”.
But this engineering practice makes it clearer to me that continuity of implementation, continuity of dialogue and continuity of research objectives are three different issues.
Run could end once, a report could be revised, an old material could become unusable and even the entire research space could be removed. These changes should not force the system to replicate or rewrite facts originally held by other modules.
What is really needed for long-term research is a stable user goal, a set of relationships that can be traced back to the original object and a mechanism for re-qualification of material in each new study.
So I didn't choose to build a never-ending Project Agent, but rather to make Workspace an independent Module with a clear mandate.
Long-term research does not require Agent to be running at all times, but it requires that every time it restarts, it is able to know exactly what the goal is, what material was in the past, what is still available, and on what basis the new judgement was made this time.
This may be the more important engineering issue for personal research as Agent moves from chat tools to long-term workspace.
Extended Reading: Cross Run History Compression — From Research Chat to Ongoing Research. Open ETF Agent is a stand-alone open-source teaching realization that has not yet been made available for this workspace module; if these runable examples are helpful to you, a warehouse point is welcome.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.