一个能协作、执行任务
并积累经验的 AI 工作空间

系统如何连接起来

Orchard 是用户可见的工作入口，也负责内容、成员和业务管理。Agent Runner 是独立的执行服务，接收当前空间、讨论、用户、Bot 身份和附件，再决定需要调用哪些能力。PriceBuddy 虽然可被 Runner 调用，依然是运行在 Orchard 内部的模块；TradingAgents 通常通过独立 Python 服务接入；需要实际运行代码时才使用 Daytona 沙箱。

这种分工让管理和执行各自清晰。管理员在 Orchard 维护搜索源、抓取规则、API 权限及 Bots；用户在 Thread 中表达需求；Runner 把自然语言任务转成工具调用，再把结果带回讨论。增加一个抓取提供商时，通常只需调整 PriceBuddy 的设置，Runner 仍可继续使用既有的搜索、追踪和查价工具。

以工作空间组织人、资料和持续讨论

Workspace 适合承载一个长期目标，例如装修采购、房产研究、经营数据分析或市场观察。空间内可以有多位用户与多个 Bots；每个 Thread 则聚焦一个具体议题，例如“浴室设备预算”“某街区房源”“本月销售异常”。同一主题的追问留在原 Thread，其他问题另建讨论，既保留上下文，也方便团队回看。

Orchard 维护空间名称、描述、所有者、成员、管理员与 Bot 成员，并通过讨论内容组织线程和消息。用户看到的是同一个协作界面，背后调用的可以是不同模型或不同服务。模型名称、角色说明与服务地址由相应配置决定，不需要所有任务都采用同一种 Bot。

空间中的参与者包括 Owner、Admin、Member 和 Bots。它们共同构成一个有人负责、有成员参与、也有 AI 协助执行的工作团队。空间角色用于组织管理和协作，具体操作仍由相应页面及 Orchard 权限控制。

Open 与 Private 是空间的访问方式。当前代码中的 Open 页面可公开访问；Private 页面要求登录，并实施成员与黑名单检查。需要准确理解的是：现有 Private 详情入口允许已登录用户通过链接加入，尚不能把它描述为“仅受邀成员可进入”的严格私密空间。团队应按实际访问规则决定放入哪些资料。

两类 Bots 满足不同工作方式

模型直连 Bots由 Orchard 直接接入 OpenAI、DeepSeek、Gemini 等模型 API，适合解释、写作、翻译、讨论和当前适配器提供的模型能力。不同提供商的会话延续、联网工具和流式输出方式有所差异，系统分别适配；直连 Bot 不会因为与 Runner Bot 出现在同一空间，就自动拥有 Runner 的全部工具与长期记忆。

Agent Runner Bots把问题交给独立执行服务。除了模型推理，它们还可按配置调用 PriceBuddy、TradingAgents、联网搜索和沙箱工具，并读取当前 Thread 与 Workspace 的相关知识。这类 Bot 适合“查找、核对、计算、保存，再继续追问”的任务。

新加入的 Agent Runner Bot 可以立即利用本空间已有的背景知识和共享记忆。这里的“立即”指它在加入后的首次任务中，就能通过相同的 Workspace 标识读取已经形成的共享知识，无须先与它重新进行一轮历史对话。Runner 会按本次问题检索相关的项目背景、已整理的文件知识、业务定义和工作经验，再结合当前 Thread 的上下文交给该 Bot。这个过程发生在任务执行时，已有记忆也无需重新训练进 Bot 所使用的模型。

同一 Workspace 的 Agent Runner Bots 共享同一空间的知识和记忆。在连接到同一 Workspace 记忆存储并具有相应访问权限的前提下，新增 Bot 或切换 Bot 不会另建一套空白的空间知识。不同 Bots 可以保留各自的角色说明、模型和笔记，同时复用共同的项目背景；一位 Bot 的发现一旦被整理为有效的空间共享记录，其他 Bots 后续处理相关任务时也能检索使用。

因此，Bot 的角色既包括“用什么模型思考”，也包括“被允许使用哪些工具、处于什么上下文、应该完成什么任务”。你可以把一般问答交给直连 Bot，把需要真实数据或文件处理的工作交给 Runner Bot；管理员则可以根据任务成本和能力需要选择服务。

用 Agent Runner Profiles 选择模型与运行方式

同一个工作空间可以配置连接不同 Runner 实例的 Bots：有的侧重日常问答，有的侧重文件分析或研究。Profile 是一套服务启动配置，把模型提供商、默认模型、工具开关、记忆处理与 TradingAgents 设置组织在一起。同一份 Runner 程序可以加载不同配置运行，用户通过所选 Bot 使用相应服务。

下表是本地项目在 2026-10-03 保存的基础配置，不是对线上进程实际参数的实时检测。文件名保留项目原有大小写；在区分大小写的系统上，.env.deepSeek 与 .env.deepseek 并非同一个文件。

这些 Profile 当前都选择了四项 Typesafe 决策服务，并指向同一个主机记忆目录。只要实例实际连接同一存储、使用同一 Workspace 标识并获得授权，换一个模型 Bot 仍可复用空间的共同知识。不同服务器上的相同路径名不会自动产生共享存储；Profile 本身也不会同步文件或创建跨服务器的分布式锁。

模型切换需要同时照顾协议差异。当前 Runner 的 Luna 工具调用在 Chat Completions 路径使用 reasoning_effort=none；独立的联网搜索使用 Responses 与 low 推理设置。MiniMax 则有自己的工具输出验证与推理元数据适配。它们帮助不同模型使用同一套业务工具，但不意味着更换模型后能力和结果质量完全一致。Luna 的接口限制可见 OpenAI 官方模型说明。

已有的 TradingAgents 进程需要单独核对。自动启动的新进程可以继承 Runner 环境；已运行的独立 Python 服务可能仍保留旧配置。只改 Runner Profile 并不能证明研究流程已经切换。应核对 TradingAgents 的 /config 返回及提供商账单；当前 Runner 会比对服务提供商和后端地址并记录不一致，模型名也应检查。这是后文成本估算真正落地的前提。

从自然语言问题到实际任务

对 Runner Bot 说“列出我关注的产品”，可以直接读取 PriceBuddy；说“在 Home Depot 搜索这个型号”，则先定位已配置的搜索源，再发起搜索；要求分析上传表格时，才需要文件处理和代码执行环境。已经保存的答案也能用于“继续”“把上一份报告翻译成中文”等同线程追问。

执行服务同时考虑当前问题、新附件和近期对话。可明确识别的任务走确定性路由；较模糊的需求可交给模型判断，部分判断还支持可选的 Typesafe 结构化决策服务。这减少了本来只需查询业务 API，却启动整个沙箱的情况。

较长的任务可以显示阶段进度。Runner 发送服务器事件流，Orchard 再把进度转发到讨论界面。用户可以看到正在查数据、运行研究或执行工具，而不只是面对一个长时间静止的等待提示。某些模型适配路径会集中返回完整片段，因此“有进度反馈”不等于所有提供商都逐字流式输出。

所请求的工作与附带整理分开完成。用户要求即时查价、搜索或完整分析时，系统需要等待相应结果；用户要求加入追踪或排队查价时，可以在任务被接受后返回。对话与尝试记录先保存，记忆摘要、评估和反思随后在后台处理，避免为这些派生工作继续阻塞最终答案。

Typesafe Jev：把小判断交给结构化决策模型

一项任务开始前，系统往往先要回答几个很小但影响成本的问题：需要运行代码吗？用户是在问公司名称，还是要求完整股票研究？需要读回几份旧报告？Typesafe 的 Jev 在这里负责提供结构化判断。它接受任务状态与类型化问题，返回可直接用于程序分支的结果；完整解释和最终答案仍由相应语言模型生成。

Jev 的三种基本输出是：Noul 给出一个陈述为真的概率，Choice 从限定选项中选择，Score 按评分量表返回位置。这使判断结果无需先生成一段自由文本，再尝试从中修复 JSON。概率和评分仍是模型判断，需要结合真实结果观察其效果。参见 Typesafe 官方说明。

四项功能可以独立启用，默认模型标识是 jev-latest。当前列出的 Profile 已写入 typesafe 选项，实际调用还需要有效服务配置。沙箱和报告回读判断失败时回到原模型判断；金融意图判断失败时保持原有执行分析的行为；评分失败时保留文字评估模型给出的分数。

它的经济价值应按少做了多少不必要的重任务衡量，同时扣除新增的决策请求费用。如果一个小判断避免了一次长篇多角色分析，可能节省很多调用；如果问题本来就能用规则确定，则无需为了使用 Jev 再增加一步。本项目保留了规则优先、模型处理模糊情况的分工。

让上传文件成为持续可用的工作资料

你可以把 PDF 报告、CSV、Excel、JSON、文本或办公文档放进讨论，请 AI 提取重点、比较数据、解释差异或生成图表。Runner 根据扩展名识别文件类别，记录路径、大小、内容哈希与可用预览，再把需要计算的工作交给沙箱。能够识别某种格式不代表所有文件都能无条件解析，实际处理仍取决于沙箱中的解析工具、文件内容与模型能力。

例如，上传几份供应商报价后，可以让 AI 整理产品型号、币种、税费口径和数量，再计算可比较的单价；下次讨论时，工作空间可以继续使用已经整理出的规则，而不必重新解释每个字段。生成的图表和文件可以从沙箱读取，Orchard 的集成还能取回图表并作为讨论中的媒体展示。

文件存储与对话记忆有明确分工：Orchard 管理原始附件的媒体存储；Daytona 的 Workspace 专属持久卷保留上传到执行环境的资料及计算产物；Runner 主机保存文件索引、对话、摘要和派生知识。删除沙箱卷不会自动清除主机记忆，三部分需要分别维护。

Daytona 沙箱：共享资料，各自执行，按需唤起

对用户而言，沙箱相当于由 AI 操作的一台临时分析电脑。它能实际打开文件、编写并执行脚本、检查运行结果、修正错误和导出图表。Runner 在主机上负责协调与调用模型，模型生成的分析命令则在 Daytona 环境中运行。

共享 Volume 如何工作

当前项目按 Workspace 分配独立的 Daytona Volume，名称由配置前缀与规范化的空间 ID 组成，例如 workspace-renovation。首次需要使用时自动创建并等待就绪，沙箱把它挂载到 /workspace。同一空间不同用户的沙箱挂载同一个卷，因此前一位成员保存的表格、脚本与图表可以成为后续工作的资料，不必为每个沙箱重新上传一份。

Daytona 的卷通过 FUSE 把对象存储呈现为文件目录，卷内数据独立于某个沙箱的生命周期。删除或重建计算沙箱后，新环境重新挂载原卷仍能读取资料。这种机制适合共享数据集和计算产物；内存中的变量、运行中的进程，以及未写到卷中的临时文件，则不能当作已经持久保存。参见 Daytona Volumes 文档。

这里的共享是同一项目空间内的文件共享，不是每个用户的私有文件夹。同空间成员应使用清晰的输出文件名，避免并发任务覆盖同一文件；不能把挂载卷当成提供事务和文件协作锁的数据库。不同 Workspace 使用不同卷，成员访问控制仍由 Orchard 与 Runner 的服务授权负责。

按“Workspace + User”唤起和复用

Runner 用空间 ID 和用户 ID 组合生成会话标识。同一用户在同一空间继续工作时，优先复用仍在运行的沙箱；没有可用热会话时，尝试从持久状态恢复，恢复失败再创建新环境并挂载原卷。另一位用户在该空间执行任务会使用另一个会话，但仍共享该空间的卷；同一用户切换空间则不复用原空间的会话。Thread 和 Bot 角色用于组织上下文，并非每个 Thread 或 Bot 都单独分配一台沙箱。

只有任务确实需要代码、文件处理等执行能力时才唤起。列出 PriceBuddy 产品、搜索已配置来源或回读已有报告，可以直接使用主机工具。Runner 还提供空闲自动停止、归档及删除的生命周期参数；代码缺省值分别为 15、60、360 分钟，具体触发条件按 Daytona 生命周期定义及部署覆盖值执行。停止或删除计算环境不等于删除独立 Volume，保留数据也仍需考虑存储费用。

沙箱里有哪些现成能力

当前默认环境由 Debian Slim 与 Python 3.12 构建，预装数据分析和文档工具。以下是默认镜像中可以实际利用的能力；选择自定义快照时，应以该快照安装的依赖为准。

例如，你可以要求：“读取本空间三份供应商报价，统一型号与币种，把缺失项单列出来，输出一份 Excel 和价格比较图。”Agent 可以在沙箱中真实执行这些步骤，再返回文件和结果依据。遇到扫描 PDF、旧版 Office 或音视频时，可能还需 OCR、格式转换器或转录服务；默认安装清单不代表这些扩展均已具备。

从搜索商品到长期追踪价格

PriceBuddy 把一次性的商品链接变成可持续维护的追踪对象。用户既能在 Orchard 管理页面操作，也能通过 Runner Bot 查询产品、商店与搜索源，搜索候选商品、加入追踪、排队查价或立即获取新价格。

商店配置与搜索源各有职责。商店配置说明如何读取某个网站的商品详情；搜索源说明如何提交关键词并提取候选名称、链接和可用的搜索页价格。两者分别设置请求方式、渲染选项与规则。搜索结果可以勾选后批量追踪，但搜索页价格只是预览，只有后续详情检查成功才形成正式价格观察记录。

一个商品可以关联多个商店条目。产品列表按商店分组；详情页展示各条目的价格、单位价格、币种、库存状态和检查时间，也可删除不再需要的条目。定时检查持续建立价格历史，汇总时区分币种和商品数量，避免把不同货币或不同包装的数字直接混为同一价格。

“在既有商店中查找同款”比关键词搜索更进一步。它只搜索选定且可访问的已配置商店，结合品牌、制造商型号、GTIN、颜色、尺寸或必需规格检查候选。结果区分强同款证据、仍需确认和规格冲突；标题相似本身不能得到强匹配。用户核对后再把候选链接附加到现有商品，工作流不会悄悄扩展到未经配置的商店。

抓取层支持直接 HTTP、配置好的浏览器服务，以及 ScraperAPI、ZenRows、Zyte；可选 AI 提取与规则修复需要单独启用。结构化数据、CSS、XPath 等规则负责解释抓取内容，提供商负责取得页面。可配置的 ScraperAPI → ZenRows 失败回退并非所有提供商之间的通用自动切换。

当页面被拒绝访问、出现验证页、超时或限流，用户会看到具体失败状态。系统保留上一次成功价格，不把失败抓取写成新价格。对“现在多少钱”的回答应看本次成功检查的结果和时间，不能把旧缓存当作刚抓到的价格。提醒则由独立的通知流程发送，可按配置接入邮件、Telegram、Discord、ntfy 等渠道。

PriceBuddy 的数据服务：页面抓取与房源接口

面对不同网站，PriceBuddy 把“取得内容”和“解释内容”分开。ScraperAPI、ZenRows、Zyte 在当前集成中主要返回 HTML，再由 PriceBuddy 的结构化数据或提取规则寻找名称、链接与价格；RealtyAPI 则返回专门的房源数据，由模块进行字段映射。更换抓取服务可以改善页面获取，但无法自动修正不匹配的选择器，也不能保证所有网站都返回价格。

搜索页和详情页要分别配置。搜索源处理“关键词 → 候选列表”；商店处理“商品链接 → 详情价格”。例如，Home Depot 的搜索页需要 JavaScript 才能形成结果，并不意味着每个详情页都需要同样的等待规则。启用渲染后，等待选择器应匹配真实结果或“无结果”提示，不能让正常的空搜索一直等待。国家选择控制访问地区，不等于已经选择某家零售门店或邮编。

抓取服务的成本来自实际请求方式。渲染和高级代理通常增加耗时或计费；ScraperAPI 官方目前说明，普通 JavaScript 渲染请求使用 10 个 API credits。因此可先用样本确认最简单且有效的设置，再按需要升级，而不是对每个页面都打开所有选项。ZenRows 和 Zyte 的实际费用需按账号方案及请求类型核算，不能只比较首页套餐价格。参见 ScraperAPI 渲染说明、ZenRows 参数文档和 Zyte 浏览器动作文档。

模块为 ZenRows、Zyte、RealtyAPI 提供默认值为 1 的最大并发设置，协调同一租户进程中的搜索、即时查价与后台工作；多个服务器共享同一个提供商账号时，还需分配总并发额度。429 表示限流，抓取失败和提取为空也各有不同含义。失败不会写成零价格，也不会覆盖最近一次成功价格。

显式启用 ScraperAPI → ZenRows 回退后，符合条件的超时、网络故障、部分 HTTP 错误或已识别验证页可以触发一次 ZenRows 调用；认证错误、正常空结果或一般价格提取失败并不会触发它。第二次调用也可能产生费用，因此成功率应与每次成功取得有效数据的总成本一起衡量。

RealtyAPI 的搜索与详情是两条独立接口：搜索给出候选，详情检查才建立追踪观察。当前搜索读取第一页、最多 50 条，管理页面展示最多 10 条，不会自动遍历全部分页。已售记录的旧挂牌价格不作为成交价。接口来源可核对 地点搜索文档和 详情文档。

用自然语言搜索房源和已售记录

通过 RealtyAPI 搜索源，PriceBuddy 的查询能力延伸到 Realtor.ca 房源。用户可以问“Mississauga 最近七天售出的房屋”“Mississauga 最新挂牌”或“按价格排序的出租房源”。Runner 把地点、出售或出租状态、已售时间范围和排序方式转成每次请求的参数，不改变管理员保存的搜索源默认值。

房源可以被追踪并进行详情检查。回答会区分在售、出租与已售状态，也会核对服务器实际应用的搜索条件。地点搜索可能包含附近城市，需要把明显属于其他城市的地址分开说明；“最新挂牌”目前指按新旧排序的在售房源，不等于严格筛选“今天新增”或“新建住宅”。

已售状态与成交价必须分开看。当前已核实的提供商响应没有可靠的实际成交价字段，因此已售结果不把旧挂牌金额当成成交价；已有追踪价格会明确作为历史挂牌价保留。这个区分使房地产查询可以提供线索，而不制造数据来源并未给出的成交事实。

让多位金融研究智能体共同分析

用户需要金融研究时，Runner 可调用 TradingAgents，把问题交给有明确分工的研究流程：技术与市场分析、基本面分析、新闻与情绪分析形成材料，多空研究员讨论不同判断，交易员形成方案，风险团队从激进、中立和保守角度审视，最后汇总为研究报告。

多角色安排让结论能够呈现不同的证据和分歧。用户可以继续问“主要风险是什么”“对比前两份报告”或“把结论解释得更容易理解”。Runner 保存完整报告并支持回读，在只是总结或翻译已有报告时，尽量避免重复启动整条昂贵的研究流程；明确要求重新分析时才走新的分析路径。

当前主要集成方式是由 Runner 主机通过 HTTP 连接独立 Python 服务，也可按配置启动该服务。服务内部使用 LangGraph 组织分析与讨论，返回阶段进度、报告与决策结果；行情和新闻等材料来自配置的数据提供商。分析日期与数据来源会影响结论时效。

这里的用户功能是金融研究与决策辅助。当前 Runner 集成中未看到向券商自动下单的执行链路，不应把生成交易方案描述为已经完成实盘交易。

低成本模型，让持续研究和空间记忆更可负担

TradingAgents 的一份最终报告背后有多次模型调用：分析师读材料，研究员进行多空讨论，风险角色评估，最后再汇总。前一步输出还可能成为后一步输入；用户后续追问、评估和记忆整理也会继续产生费用。因此，最终答案的字数不能代表整个流程的 token 用量。

模型选择可以降低每个 token 的单价；相关性检索、报告复用和任务路由则减少不必要的 token 与调用次数。这两类节省可以叠加，但低价模型的质量、工具调用可靠性和重试次数仍需实际评估。若为修复一次失败反复重跑，便宜的单价未必带来更低的总成本。

一次 TradingAgents 分析的可复算例子

以下为预算示例，不是本项目实测账单。假设同一分析流程所有角色累计使用 100,000 个未缓存输入 token、20,000 个计费输出 token，输出包含服务商计入输出费用的推理 token；各模型使用相同数量只是为了比较单价。采用美元、标准 API 价格，每个 OpenAI 请求均不超过 272K 输入，不计 Batch、Flex、地区附加费或缓存写入。价格核对日期为 2026-10-03。

计算方式是 输入 token ÷ 1,000,000 × 输入单价 + 输出 token ÷ 1,000,000 × 输出单价。例如 Luna 为 0.1 × 0.10 + 0.02 × 0.50 = $0.020。同一假设下，Luna 比 DeepSeek 高峰费率低约 63%，比非高峰低约 26%；这不是模型质量相同的证明，也不是保证每次分析只花这些钱。

DeepSeek 项目的研究配置使用 deepseek-v4-flash。官方当前说明该旧标识由 DeepSeek-V4.1-Flash 提供服务，并按 Flash 费率收费，因此表格采用现行 Flash 价格；不能把这组数字直接套到 Runner 的 deepseek-chat 或 TensorMesh 托管模型上。DeepSeek 高峰为工作日 UTC 01:00–04:00 和 06:00–10:00（中国公众假期除外），其他时段按非高峰计。价格与别名以 DeepSeek 官方计费页为准；OpenAI 数值来自 官方价格表。

如果一个团队每月处理 1,000 次这样的研究，在固定 token 假设下，相比 Sol，Luna 的模型预算少 $380，DeepSeek 少 $346–$373。省下的预算可以用于更多核验、更多覆盖对象和必要的质量复查。真实总账单还包括 Runner 的组织回答、Typesafe 判断、后台评估与记忆、联网搜索、市场数据、抓取服务、Daytona 计算与存储；本表只计算研究流程假定的模型 token 费。

怎样把节省落到日常使用中

1. 按任务选择 Profile。先用 DeepSeek、Luna、MiniMax、GLM 或 TensorMesh 的合适模型处理日常任务，以来源准确率、工具成功率和重复运行次数检验效果；对关键结论再增加更强模型或人工复核。这里是一种使用策略，当前系统并未承诺自动选择最低成本模型。
2. 同时设置研究服务的两类模型。快思考模型可用于材料整理，深思考模型用于复杂综合；也可像当前 DeepSeek / Luna Profile 一样两者使用同一经济型模型。更改后确认实际 Python 服务配置，避免 Runner 显示新模型而后台仍按旧模型计费。
3. 用报告回读完成追问。“总结刚才的风险”“翻译上一份报告”优先利用保存内容。需要更新行情时再明确要求重跑；同时保留分析日期，不能为省钱把旧报告冒充新研究。
4. 让记忆检索选重点。从空间记忆中选择相关背景，用摘要和文件索引定位原文，避免每次携带全部聊天和所有文件。稳定前缀有机会获得提供商缓存折扣；缓存是否命中必须看实际 usage，本文成本表未假定任何命中。
5. 控制推理、输出和重试预算。简单问题用合适的推理档位，按结果需要设置输出上限，并限制研究轮数。更大的最大输出 token 只是上限，费用来自实际生成；不应因为模型便宜就要求每次都写到上限。
6. 把后台整理算入预算。EntiGraph、反思、评估都有额外调用。限制实体与关系数量，复用已处理的文件版本，并核对后台模型配置；“后台执行”改善等待体验，并不会让费用消失。

成本节省的重要性在持续使用后更明显：一个空间会不断增加资料、成员、Bots 和讨论。合理配置让团队有条件长期维护知识，而不是只做几次昂贵演示。评估指标应是完成一次可靠任务的总成本，同时看准确性、延迟、失败重试和外部数据费用。

让 AI 记住有用的上下文

工作空间的记忆分为几个层次。Thread 对话记忆帮助理解“继续”“上面的产品”“第二份报告”等指代；Workspace 共享知识保留可跨讨论复用的定义、规则和经验；角色笔记与运行记录保存不同 Bots 的工作线索和来源。它们不需要把所有历史原封不动地塞进每次模型请求。

例如，一位成员确认了“销售额必须扣除退款”，这一口径可被整理为共享知识；另一条讨论分析新月份的数据时，就有机会检索到它。某个 Thread 的临时草稿则可以继续留在该线程范围。管理员或外部程序还能通过记忆输入与输出 API 接入已有知识，按来源追溯哪些角色、运行和讨论贡献了哪些内容。

这种共享也让新 AI 成员更快接手工作。例如，装修空间已经记录预算、尺寸要求和候选设备信息，后来加入的“采购分析 Bot”在第一次被询问时，就能按问题检索这些现有背景；原有“资料整理 Bot”后来补充并整理出的有效规格知识，也可以在采购 Bot 的后续任务中复用。成员不必为每个新 Bot 重新讲述整个项目，Bots 的贡献则逐渐汇入空间的共同知识。

共享的是当前有效、可供检索的空间知识，而每次任务只选取与问题相关的内容。Thread 的完整历史和角色笔记仍按各自范围组织，不会因为新增一个 Bot 就把全部记录无差别复制给它。这样既支持共同背景，也保留了不同讨论和角色的上下文层次。

检索同时考虑关键词、可选的语义向量、置信度、时间、证据和知识类别。还可选择较均衡的结果组合，或采用 MMR 减少重复内容占满上下文。在语义向量服务不可用时，关键词与元数据检索仍可工作。

知识本身也有生命周期：可复用技能可以处于草稿、已推广或已弃用状态；新记录可替代旧记录；失败经验和已弃用方法仍能保留以供审计。这里的 public 通常指该记忆范围内可供共享上下文使用，不表示发布到互联网上。角色私有笔记也不应被理解为独立的访问权限边界，协调器可以读取部分同线程角色上下文。

把一次次任务转化为可积累的经验

CORAL 研究强调共享持久记忆、独立评估和持续反思，让智能体在后续尝试中利用先前发现。这里借鉴的是 CORAL — Towards Autonomous Multi-Agent Evolution for Open-Ended Discovery，不是同名的其他协议。

Agent Runner 已把其中若干思想实现为工作空间机制。每次任务有尝试记录，可保存父尝试标识、产物和角色贡献；独立的评估调用检查答案依据、缺失核验与潜在问题；后台 Heartbeat 再整理可复用经验。出现低分、新的较好结果或连续停滞时，系统可以触发针对性的反思，并提出下一次应改变的方向。

整理后的内容分成观察笔记、技能和失败经验。知识演化图进一步连接记忆、尝试、评估和任务交接，表示某条结论来自哪次工作、替代了哪条旧结论、又与哪些记录相关。图可以通过 API 获取，其紧凑摘要也会用于后续上下文；这不意味着当前 Orchard 页面已经提供了完整的图形化知识管理界面。

多角色协作也是现有能力之一：Runner 的 API 支持先让多个角色依次处理任务，再由协调器汇总；角色间可共享精选发现，并保存任务交接与信息传递记录。当前 Orchard 常用流式入口主要传递所选 Bot 的角色身份，不能把 API 能力写成“每次聊天都会自动组建并行研究团队”。

因此，“自进化空间”在这个产品中有一个具体含义：系统积累资料、经验、质量反馈和更有效的上下文，让后续工作有条件做得更好。它并未完整复现 CORAL 的开放式长期自治搜索，也没有证明质量一定逐次上升。模型评估依然可能出错，真实工具结果、原始资料与用户纠正仍是改进的重要依据。

从保存文件走向理解文件中的实体与关系

许多文件的难点不只是找出一句话，而是理解其中的组织、产品、指标和约束如何关联。Continually self-improving AI 中讨论的 EntiGraph，为此提供了思路；其原始方法见 Synthetic continued pretraining：抽取实体，再围绕实体关系生成多样化的知识表达。原论文还利用这些材料继续预训练模型。

本项目采用了适合工作空间的改造方式。启用 EntiGraph 后，上传文件可在后台完成文本提取和规范化，产生文档摘要、实体说明以及选定实体对的关系分析，再写入工作空间记忆。一个文档因此拥有多个检索入口：后续问题既能围绕某个实体检索，也能围绕两个实体之间的关系检索。

例如，一份装修规格文件可能同时包含浴缸型号、尺寸、安装空间和材料限制。实体说明整理各自的属性，关系记录整理“某型号与安装约束”的关联。用户以后问“为什么这个尺寸不适合”，系统更容易找到已有的相关知识，再按需要核对原文。当前关系分析主要发生在单份文档内部，不能据此宣称已经实现任意文件之间完整、自动且可靠的知识图谱推理。

实现细节还包括内容哈希识别、相同内容避免重复处理、已完成条目的恢复、同路径新版本对旧记录的替代，以及实体数、关系数和并发数上限。相同文档作为稳定的请求前缀，也为支持前缀缓存的提供商创造复用机会；是否命中和如何计费仍由提供商决定。

原文是核对依据，派生内容是检索辅助。当前实现会要求模型给出引用，并在本地检查引用是否出现在规范化原文中；不过判定只要求找到至少一条匹配引用，重试后仍未匹配的非空结果也可能以较低置信度保留。因此它不能被宣传为所有生成事实都通过认证。重要判断仍应回到原文件核验。

这项功能需要显式启用，默认关闭。当前上传钩子可直接处理的交集包括 PDF、TXT、CSV、TSV、JSON 与 JSONL；分析链路还识别其他格式，但不应把它们全部等同于自动 EntiGraph 支持。文本过少的扫描 PDF 会跳过蒸馏，不会自动获得 OCR 能力。Markdown 在蒸馏模块声明中存在，但上传分类使用不同名称，目前不宜列为已贯通的自动处理格式。

一个工作空间中的连续工作示例

假设你建立了一个家庭装修 Workspace。成员先把预算表、设备规格和供应商资料放进不同 Thread，Runner 帮忙整理币种、数量、型号与安装条件；这些内容中的通用要求可进入共享知识。

采购讨论中，你要求搜索已配置商店里的候选产品。PriceBuddy 返回名称、链接和可用的搜索页价格；确认后加入追踪，再通过详情检查建立价格记录。需要跨店找同款时，使用型号与规格核对的流程，而不是只比较相似标题。

几天后另一位成员继续问“按原来的尺寸要求，哪些候选值得再检查”。Runner 可以结合该线程记录、工作空间的要求和 PriceBuddy 当前数据组织回答。若要求“立即查价”，它等待实际检查；若要求“排队更新”，它在接受任务后先返回，价格更新由后台执行。

分析完成后，系统继续整理“哪些字段经常缺失”“哪些规格必须人工确认”等经验。后续问题有机会复用这些结果。用户逐步得到的，是一套围绕自己的项目积累起来的资料与工作方法。

用户体验背后的工程能力

使用前需要理解的边界

配置决定可用功能。抓取服务、联网搜索、金融数据、模型 API、自动价格追踪与文件知识处理都有相应开关、权限或服务要求。API 存在不等于普通用户界面已经提供全部控制项。模型能力、运行耗时和第三方数据可用性也会影响一次任务的结果。

共享空间不自动等于共享业务账户。PriceBuddy 按 Token 所属用户读取和修改追踪清单。Runner 开启共享访问时，多个获准调用 Runner 的用户和 Workspace 使用同一 Token 所有者的清单；关闭时才适用连接配置中的空间和用户限制。它不是为每个 Workspace 自动建立一个独立 PriceBuddy 账户。

凭据与数据各有归属。Orchard → Runner 的服务凭据、Runner → PriceBuddy 的用户 Token，以及 Orchard 内加密保存的抓取提供商密钥是不同层次。供应商密钥留在管理端，PriceBuddy 工具不把它们作为模型参数传递。空间对谁开放，仍应由实际成员规则和部署授权共同控制。记忆复用发生在相应 Runner 的存储与授权范围内，不同部署不会自动同步。

后台不代表永久运行保障。PriceBuddy 的价格与发现任务有数据库中的持久工作记录；Runner 的反思、摘要与文件蒸馏使用进程内队列，需要服务保持运行。现有持久内容和部分恢复机制有助于再次处理，但不能宣称所有中断任务都会在重启后自动续跑。

记忆不替代事实核查。旧价格需要时间戳，房源状态不等于成交金额，研究报告不等于已经执行的交易，模型评分不等于客观真值。工作空间能够积累经验，也需要保留原始资料、实际工具结果和纠正记录，才能让后续使用更可靠。