书接上回, 增补 Auto Memory 保存和召回细节; 以及介绍 auto-dream.

WebSearch 调用服务端的搜索工具, WebFetch 本地抓 URL、HTML 转 markdown、再交给一个小模型按 prompt 提炼.

延迟 tool 加载

用 FileReadTool 统一读文件. 如果用户使用 @ 提及文件或目录, 则先把它们变成 attachment 再在发给模型前重建成一组“伪造的上下文消息”.

分为 Session Memory和 Auto Memory (跨 session).

若干层压缩.

2020 年时想的问题, 一直搁着. 今天突然想起来了.

瑞士轮编排通常要满足这些约束:

• 匹配过的两人不再重遇 (硬规则)
• 同分或近分者优先匹配
• 先后手尽量均衡 (棋类: 保证选手执黑 / 执白次数大致相等)
• 满足上述条件后适度随机 (部分严肃比赛不做随机)

要找到一组同时满足上述约束的匹配并不 trivial. 一种朴素做法是按经验法则先构造一组匹配, 再检查是否满足约束, 不满足就回溯重试 (trial and error). 早年 FIDE (国际棋联) 的裁判就是这样手工编排的. 这种启发式搜索的复杂度已经很高; 若改为暴力枚举所有可能的匹配再随机抽, 由于匹配数量随人数呈阶乘级增长, 更不可行. 因此需要更高效的算法求解.

2025 年大家都忙着搞 agent. 下面分类是随便分的.

• antirez. 2026-01. Don’t fall into the anti-AI hype

2025 年大家都忙着开发 agent, 这里简要回顾一下 RAG.

RAG 基本操作

• Offline: 文件解析, 文本切片, embedding (以前通常用 bge)
• 对 query embedding 后做召回 (通常就算个 cos, chunk 量大时用向量数据库牺牲一定精度加速召回)
• Rerank (通常是 bge-reranker)

这套早在 2023 年就玩烂了.

• 基本的 “进阶” 操作可见 NisaarAgharia/Advanced_RAG, 以及 NirDiamant/RAG_Techniques
• 这是一篇很好的综述: 【同济大学 王昊奋】Agentic RAG 时代
• 另外可以参考一些 字节跳动 RAG 实践手册 将 RAG 分为数据层, 索引层, 检索层, 生成层.

非常粗糙.

如果同时开启知识库和联网搜 (searchOrchestrationPlugin.ts), 则用 SEARCH_SUMMARY_PROMPT 做意图分析和 query 改写. 简单地把两种搜索的结果拼接起来 (不会混起来重排), index 加上偏移量避免重叠. 如果设置了召回 memory 也会拼在后面.

联网搜分为两种:

• 一种是 local search (见 LocalSearchProvider.ts), 直接解析 SERP (比如 https://www.google.com/search?q=%s). 免费.
• 另一种就是调搜索 API, 比如 Tavily.

访问搜索引擎以及 fetch url 内容都是通过 Electron 在后台打开不可见的浏览器窗口加载指定的 url.

window.api.searchService.openUrlInSearchWindow(uid, url)

类似白嫖搜索引擎的项目还有比如 duckduckgo-mcp-server 以及 open-webSearch. 不清楚是否合规.