You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maka.apache.org by "likun666661 (via GitHub)" <gi...@apache.org> on 2026/09/14 11:40:56 UTC
[I] RFC: Improve WorkHub recall within the 32 most recent Sessions [maka]
likun666661 opened a new issue, #5299:
URL: https://github.com/apache/maka/issues/5299
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
# RFC：WorkHub 最近 32 个 Session 内的召回增强
- 状态：讨论稿，未批准实施；以下候选方案不代表当前产品行为。
- 日期：2026-09-14
- 代码基线：`54bf16aaf`
- 讨论目标：在保持时间候选边界的前提下，给协调模型补充足够便宜的任务语义与检索证据。
## 1. 问题与现状
WorkHub 当前从同一 Runtime Host 的 Session headers 构造候选：排除已归档、协调会话、特殊 role、子 Agent 与 side conversation，按最近活动降序取最多 32 个。活动时间使用 `lastMessageAt ?? statusUpdatedAt ?? createdAt`。
候选生成不接收查询文本。基础信息只有任务名称、工作区、状态、时间和身份引用，协调层另外补充存在时的委派标识；没有任务内容摘要或正文检索结果。名称相似或过于笼统时，模型缺少区分证据。
当前存在两条选择路径：主协调模型调用 `tasks.candidates` 后选择；或通过可选的独立 Intent / Recall 模型绑定路由决定。独立 Recall 仅收到当前请求、意图分类和有界候选元数据，没有协调对话历史。不能把可选适配器视为已默认启用。
代码入口：
- [候选筛选、排序和截断：candidateSet](../../packages/runtime-host/src/server/workhub-coordination-action-gate.ts)
- [候选投影与可选路由准备](../../packages/runtime-host/src/server/workhub-coordination-coordinator.ts)
- [Recall 输入、提示词和 Policy](../../packages/core/src/workhub-routing.ts)
- [协调模型提示词和工具边界](../../packages/runtime-host/src/server/hosted-execution-tool-profile.ts)
## 2. 已明确的边界
1. **严格保留最近 32 个 Session 的时间候选集合。** BM25 不从集合外补入旧任务，也不做全库相关性替代时间召回。
2. BM25 是集合内部低权重的辅助信号。零命中不等于不相关，不应据此淘汰候选；初步方向是不再做第二次候选截断。
3. 摘要服务于路由，只需粗略描述任务主题。允许陈旧，不要求维护精确的最新进度报告。
4. 协调模型结合对话关联、时间、摘要和检索证据选择目标；既有 Action Gate、显式新建规则与权限边界保持独立。
5. 本 RFC 讨论证据如何生成和使用，不宣布路由默认策略切换。
## 3. 候选方案：低频 Session 摘要
在 WorkHub 委派工作获得持久执行结果后，为目标 Session 触发一次后台摘要更新检查。建议触发点位于 Host，由目标执行事实驱动，而不是依赖 WorkHub 窗口收到结果。摘要生成不阻塞工作结果返回，不在任务中追加普通用户轮次。
摘要以任务目标、涉及对象和主要工作主题为核心，可保留少量识别性结论。无需逐轮同步进展，也无需为更新判断再调用一个模型。
频率的候选规则是：累计有效完成次数到 `1、2、4、8、16…` 时更新。指数间隔符合长期使用时降低成本的目标；本稿不默认加入固定时间刷新或间隔上限。中途主题改变可能导致摘要失真，是否提供显式失效或其他便宜的刷新条件仍需讨论。
生成输入可以是旧摘要与新增的有界内容。若增量过大，需要明确截断方法，不能假定“增量”天然便宜。摘要应携带覆盖到的源记录位置，以支持去重、重启恢复和防止旧生成结果覆盖新版本。
现有 [HostSessionEffectCoordinator](../../packages/runtime-host/src/server/session-effect-coordinator.ts) 和 [模型调用能力](../../packages/runtime-host/src/server/execution-model-authority.ts) 已有 tool-free recap，可评估复用；现有 recap 不等同于自动维护的路由摘要。字段落在 header、独立派生记录还是现有 artifact 中，尚未决定。
开放问题：一次“完成”按委派消息还是执行 Turn 计数？失败、停止、共享恢复 Turn 如何处理？仅 WorkHub 委派触发，还是普通任务也参与？没有摘要的任务保持可路由，不要求同步补全。
## 4. 候选方案：32 个 Session 内的 BM25
```text
现有筛选 + 时间排序 + 最多 32 个 Session
→ 读取这些 Session 的有界 eventlog 文本
→ BM25 检索并按 Session 汇总
→ 附加弱相关性信号与少量命中片段
→ 协调模型判断
→ 既有 Action Gate 校验
```
希望利用日志补充标题和粗摘要缺失的关键词，但不在第一版引入复杂的语义切片、自动低信息识别、去重流水线或额外模型调用。
一个可实验的简化选项：直接沿用现有消息边界，每个 Session 取最近固定条数的用户与 assistant 文本，每条限制长度，暂不纳入原始工具输出；计算消息得分后，Session 只取最高命中分。
**该选项尚未选定。** 它以可控成本换取证据遗漏：较早细节和工具输出中的错误码可能无法命中；固定条数不等于固定 token 成本；取最高分也无法彻底消除日志数量差异和偶然命中的影响。
另一个应对照的简单选项是每个 Session 取固定文本预算作为一个文档。它实现更直接，但长任务的多个主题可能互相稀释。通过样例比较后再选择，不预设分片方案必然更好。
### 评分需要明确的事
- “低权重”若只写进模型提示词，无法严格限制模型对该信号的依赖；若在代码里赋分，需要定义归一化、加分上限，以及如何与时间结合。
- 保留原始时间位置，让最终模型仍能识别“刚才、最近”的线索。暂不承诺某个权重公式或最高相关任务必定排首位。
- 中文、英文标识符、路径、错误码的分词会显著影响有效命中，需要用真实混合语言请求选择简单实现。
- BM25 的统计语料范围、索引更新与有界读取方式待定；无论统计如何实现，搜索结果只能来自本次 32 个候选。
- 查询若只有“继续刚才那个”，可以自然零命中。是否利用协调上下文生成检索词，以及独立 Recall 的指代信息如何传递，需要单独讨论，不能靠扩大检索词掩盖上下文丢失。
- 命中片段作为数据呈现，不赋予指令或授权地位。
## 5. 接入与一致性
摘要和命中片段需要同时检查 `tasks.candidates` 与可选 Recall 的输入投影，避免只在一条路径生效。候选发现接口当前没有查询参数，查询应从本次已接纳请求提取还是由工具提供，需要明确接口合同。
检索是附加证据，不重新定义 Session 身份。当前 `candidateSetId` 基于有序候选元数据生成，写入时重验；应避免仅因后台摘要更新或查询相关得分变化就无谓地使候选集合失效，同时保留真实目标变化的校验。具体版本策略待设计。
重复终态通知不重复计数，同一 Session 的摘要生成应合并或串行处理。摘要写入不应更新用于候选排序的用户活动时间，否则后台维护会改变最近 32 个的组成。摘要和检索失败时，应保留现有元数据路径，不能隐式新建任务。
## 6. 如何判断值得实现
使用相同的 32 个候选快照、请求和模型，对照：
1. 当前名称、工作区、状态和时间基线。
2. 基线 + 粗摘要。
3. 基线 + 粗摘要 + 低权重 BM25 证据。
覆盖同名任务、陈旧摘要、长日志重复内容、中英混合词、纯指代请求、零命中，以及目标位于时间第 33 位的情况。最后一项验证边界保持，不以扩大召回作为修复。
观察正确目标率、误选率、澄清率，以及额外延迟、读取量、模型输入和摘要调用次数。不预设准确率收益；如 BM25 增量很小或增加误选，可以只保留摘要。
## 7. 本轮讨论希望收敛的决策
- 是否先做低频摘要并建立基线，再决定 BM25 的投入？
- BM25 初版使用消息最高分还是每 Session 一个有界文档？文本范围如何限定？
- 弱相关性信号由代码赋分还是作为模型参考？“低权重”的可验证含义是什么？
- 指数摘要的计数单位、首轮范围，以及主题改变时是否需要刷新？
本文保留这些问题为开放讨论，不把探索性方案转写为已批准的实施清单。
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] RFC: Improve WorkHub recall within the 32 most recent Sessions [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han closed issue #5299: RFC: Improve WorkHub recall within the 32 most recent Sessions
URL: https://github.com/apache/maka/issues/5299
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] RFC: Improve WorkHub recall within the 32 most recent Sessions [maka]
Posted by "likun666661 (via GitHub)" <gi...@apache.org>.
likun666661 commented on issue #5299:
URL: https://github.com/apache/maka/issues/5299#issuecomment-5682692491
Thanks. On BM25, I am reconsidering whether we need an explicit “low-weight” score at all. The purpose is to expose plausible Session candidates and useful evidence to the coordinator, rather than calculate a final routing score.
Could we treat summaries and BM25 as two candidate sources, strictly within the same 32 most recent eligible Sessions?
- **Summary-based candidates:** the coordinator identifies plausible Sessions from their coarse summaries and the request context.
- **BM25-based candidates:** retrieve matching eventlog messages or text, then map those hits back to their owning Sessions.
- **Combine the sets:** a union seems like a reasonable starting point, deduplicated by Session identity. Preserve which source found each candidate and a small amount of matching evidence, then let the coordinator reason about the target. An intersection could indicate agreement between the sources, but should not be required for inclusion.
Under this approach, BM25 scores would help select lexical hits within its own retrieval path; they would not need to be combined numerically with summary relevance or recency. Repeated hits from one Session would not create additional candidates. This does not by itself solve repeated-log dominance within BM25 retrieval, so the text budget and hit-selection details still need evaluation.
This may also change the “highest message score vs. one document per Session” question: retrieving message-level evidence and mapping it back to Sessions is a plausible starting point, without necessarily defining a Session-level BM25 score. I would keep that as an option to compare, not a settled implementation choice.
The hard boundary remains unchanged: neither source can introduce a Session outside the original 32. A missing lexical match is not a reason to exclude a summary-based candidate, and if both sources yield insufficient evidence, we can retain the original bounded candidate context for clarification rather than infer that no existing task is relevant.
I agree with establishing the summary baseline first. We could then compare summary-only selection against this combined-candidate approach to see whether BM25 adds useful candidates and evidence. Does that framing make more sense than trying to define and verify a “low weight” upfront?
<details>
<summary>中文（点击展开）</summary>
谢谢。关于 BM25，我在重新考虑是否真的需要显式的“低权重”评分。主要目的是让协调器看到可能相关的 Session 候选和证据，而不是直接计算一个最终路由分数。
是否可以严格限定在同一批最近 32 个合格 Session 内，把摘要和 BM25 作为两条候选来源？
- **摘要候选：** 协调器结合粗摘要与请求上下文，识别可能相关的 Session。
- **BM25 候选：** 先检索 eventlog 中相关的消息或文本，再映射到所属 Session，实现间接召回。
- **集合合并：** 初步可以取并集，按 Session 身份去重。保留候选来源和少量命中证据，再交给协调器判断。交集可以表示两条来源都找到了它，但不应成为入选要求。
这样 BM25 分数只用于它自身检索路径里的命中选择，不必再与摘要相关性或时间做数值加权。同一个 Session 的重复命中不会增加候选数量。当然，这并没有解决重复日志在 BM25 检索内部占据命中的问题，文本预算和命中选择方式仍需评估。
这也可能改变“取消息最高分，还是每个 Session 一个文档”的问题：可以先尝试检索消息证据，再映射回 Session，不一定需要定义 Session 级 BM25 分数。它仍然只是待比较的方向，不是已确定的实施方案。
最近 32 个的硬边界保持不变，两条来源都不能引入范围外的 Session。BM25 零命中不应排除摘要找到的候选；两条来源证据都不足时，可以保留原有有界候选上下文用于澄清，而不是认定不存在相关任务。
同意先建立摘要基线，再比较“仅摘要”与这种候选合并方式，看看 BM25 能否补充有价值的候选和证据。相比先定义并验证“低权重”，这个问题框架是否更合适？
</details>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] RFC: Improve WorkHub recall within the 32 most recent Sessions [maka]
Posted by "ARE404 (via GitHub)" <gi...@apache.org>.
ARE404 commented on issue #5299:
URL: https://github.com/apache/maka/issues/5299#issuecomment-5683204522
This framing makes sense to me. I agree with combining the two sources: provide the candidate Sessions’ metadata and summaries, and attach supporting evidence to Sessions with BM25 hits. Overlap between the sources can provide additional support, without making a lexical match a requirement for inclusion.
Could we also revisit the limit of 32 recent Sessions? I understand that this preserves the existing boundary, but is 32 primarily a budget for the candidates presented to the coordinator, or an intentional limit on the retrieval scope?
Would it be worth exploring retrieval across all eligible Sessions on the same Host, while keeping the final candidate set and evidence budget bounded? For example, we could retain recent Sessions as a baseline and allow retrieval to bring in relevant older Sessions. This could help with requests to resume older work that currently falls outside the recent-32 window.
I would be interested in the rationale for the current limit and whether this broader retrieval scope should be evaluated here or in a separate follow-up.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] RFC: Improve WorkHub recall within the 32 most recent Sessions [maka]
Posted by "likun666661 (via GitHub)" <gi...@apache.org>.
likun666661 commented on issue #5299:
URL: https://github.com/apache/maka/issues/5299#issuecomment-5691205913
I think the 32-Session limit is reasonable as an intentional temporal boundary, rather than only a context-budget limit.
A WorkHub request such as “continue that work” is implicitly about a recent conversational context. Automatically reaching back to an old Session and sending it a new Message may be semantically wrong: it can turn a historical task into an apparently current continuation without enough evidence that the user intends to resume it now.
My preference would be:
- Keep the current 32 most recent eligible Sessions as the retrieval scope.
- Use summaries and BM25 only to improve evidence and candidate coverage inside that temporal window.
- If the user refers to work outside the window, do not silently revive it through broad retrieval. Ask for a more specific clarification, such as the task name, project, or what they want resumed.
- Consider an explicit future affordance for “find an older task” or “resume task X” if we decide that cross-window navigation is needed. That would be a different user intent from ordinary conversational continuation.
This treats the 32 limit as a product semantic boundary: recent Sessions are eligible for implicit continuation; older Sessions require explicit user grounding. It also keeps the coordinator from presenting a plausible lexical match as proof that an old task should receive new work.
I am not fully certain this is the only good policy, so I would be interested in your view: does treating the 32 boundary as an implicit-continuation window seem preferable to broad retrieval with a bounded final candidate list?
<details>
<summary>中文（点击展开）</summary>
我觉得 32 个 Session 更合理的定位是一个有意的时间边界，而不只是上下文预算限制。
像“继续那个工作”这样的 WorkHub 请求，隐含的是最近的对话上下文。自动回到很久以前的 Session 并给它发新 Message，语义上可能是不对的：它会在缺乏充分证据的情况下，把历史任务误判成当前的继续工作。
我的偏好是：
- 继续把最近 32 个合格 Session 作为检索范围。
- 摘要和 BM25 只在这个时间窗口内补充证据和候选覆盖。
- 如果用户指向窗口之外的工作，不要通过全量检索静默唤醒它，而是要求更具体的澄清，例如任务名、项目，或者明确要恢复什么。
- 如果以后需要跨窗口找任务，可以增加“查找较早任务”或“恢复任务 X”这类显式入口。这和普通的对话延续是不同的用户意图。
这样，32 的含义就是产品语义边界：最近 Session 可以被隐式延续；更早的 Session 必须由用户明确锚定。协调器也不会因为找到了一个看似相关的词，就把它当作应该接收新工作的证据。
我也不确定这是唯一合理的策略，想听听你的看法：把 32 视为隐式延续窗口，是否比全量检索后再限制最终候选集更合适？
</details>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] RFC: Improve WorkHub recall within the 32 most recent Sessions [maka]
Posted by "ARE404 (via GitHub)" <gi...@apache.org>.
ARE404 commented on issue #5299:
URL: https://github.com/apache/maka/issues/5299#issuecomment-5665726482
大方向赞同，倾向先做低频摘要、建立基线，再评估 BM25 的增量收益。
完成次数按 **Message 成功结束**计数；失败或停止不计数，也不触发摘要更新。
对于指数更新间隔变长后可能遗漏主题变化的问题，可以让模型判断主题是否发生较大变化。如果变化明显，可以把更新间隔回退一档，或保持当前频率、不再继续拉长。具体在哪个环节判断、是否需要额外模型调用，还需要收敛。
BM25 这部分想听听提案方的建议：初版更倾向按消息取最高分，还是每个 Session 一个有界文档？“低权重”准备如何定义和验证？可以先用对照样例证明相对于摘要基线的收益，再决定方案。
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] RFC: Improve WorkHub recall within the 32 most recent Sessions [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han commented on issue #5299:
URL: https://github.com/apache/maka/issues/5299#issuecomment-5717653251
This RFC states in its own header that it is a discussion draft not approved for implementation, and the thread is still settling first principles: whether BM25 needs an explicit weight at all, and whether the 32-Session limit is a context budget or a product boundary for implicit continuation. That conversation belongs in GitHub Discussions rather than an open issue: https://github.com/apache/maka/discussions. Closing here; once a scope is decided, please open a focused implementation issue for it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org