去年排查过一个性能问题. 一个包含很多正则替换的函数, 在处理几十万字符长度的文本时, 跑了 10 秒才完成. 最后定位到问题正则形式如下:

\s*xyz blahblah

几年前排查过 灾难性回溯 问题, 但这个正则的结构其实完全没有相关特征. 如果真的是灾难性回溯, 处理几十万字符的字符串早就卡死了, 而不是只跑 10 秒.

最后解决方案是先用

xyz blahblah

找 match, 再处理 leading spaces. 时延是毫秒内.

源于一个比喻, 模型是 horse, 人是 rider, 中间那层是 harness. 从字面来看 harness 是指为确保模型按预期行为运行而构建的约束框架与支撑体系. 至少可以从两个角度理解.

• 产品侧: Agent 产品 (如 Claude Code) 自己做的 harness (Anthropic 在 Scaling Managed Agents 进一步把有关大模型决策的部分称为 harness, 而 session, tools, sandbox 等独立为其他模块).
• 用户侧: 开发者使用 coding agent 时为了保证复杂项目受控做的脚手架 (比如 SDD, ralph loop 等).

随着模型能力变化, harness 也需要改变, 如 Harness design for long-running application development.

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

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

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

若干层压缩.

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. 不清楚是否合规.

简单小工具.

定义 tool 参数后, 不引入其他库, 仅用 Pydantic 自动生成符合 OpenAI 规范的 Tool Schema. 想法很简单, 把 Pydantic 的 model_json_schema 生成的 JSON Schema 处理成 OpenAI 规范即可.

好处是 (1) 不用引入或依赖其他乱七八糟的库; (2) 不用手动额外维护一套工具描述; (3) 能利用 Pydantic 的一些功能, 从 JSON string load 之后自动校验参数, 自动转换类型等.