Liu ZhuoQi

OpenClaw 记忆系统的向量检索默认不可用——但 BM25 文本搜索兜底让系统照常运转了两周。当你发现「不配 embedding 也能跑」，到底要不要修？怎么用 NVIDIA 免费 API 零成本补上？

OpenClaw 的 daily-ai-news 定时任务连续超时。根因不是模型不够强——是 SKILL.md 里少写了一行绝对路径，导致 Agent 每次花 15 次 exec 搜索工具位置。消息数 165→54，exec 调用 44→7，一行路径比任何算法调优都管用。

背景：Agent 工具调用的成本困境 # 在传统 Agent 工具调用模型中，每调用一个工具都需要完成一次"模型推理 → 工具执行 → 结果返回 → 模型再推理"的完整回合。这个看似自然的循环，在工具调用变多时会暴露出三个致命问题： 上下文污染：每个工具的结果都被原封不动地注入上下文窗口。查 20 个员工的报销记录，2000+ 条费用明细全部进入 context，即使你只需要知道"哪 3 个人超预算了"。 推理开销：每个工具调用都需要一次完整的模型推理。5 个工具调用 = 5 次推理 pass，每次几百毫秒到几秒不等。 噪声导致准确率下降：当上下文窗口塞满了中间结果，模型不得不在大量噪声中寻找信号。Context Rot 研究 表明，LLM 在复杂任务上的性能会随上下文增长而下降 50-70%。 正如 Bruno 在 Claude Code Architecture Guide 中所指出的：“Outer Loop（模型外的一切：上下文管理、工具调用、验证、记忆巩固）开始比模型推理本身更决定系统质量。” Anthropic 在 2025 年 11 月到 2026 年 2 月间陆续推出的一系列工具使用增强功能，本质上都是为了解决 Outer Loop 的效率问题。其中 Programmatic Tool Calling (PTC) 和 Dynamic Filtering 是最具范式转移意义的两项。

从部署到排障，记录 OpenClaw 从启动失败、飞书消息静默吞回复到 production 稳定的全链路实战经验——compaction safeguard、五层排查法、model-harness-fit 与记忆系统对比。

2026 年 4 月，我们把 seo-project 的任务队列从 Celery 全面迁移到了 Temporal。删除的依赖只有一个（celery），新增的核心代码有 11 个文件（src/infrastructure/temporal/），容器从 api/worker/beat 变成了 api/temporal_worker_blue/green（蓝绿部署）。 这件事做完后，最常被问到的问题是：为什么不用 Celery？已经能跑的东西换它干什么？ 这篇文章就是答案。它不来自文档对比，来自生产环境跑 Agent 流水线时逐条撞上的坑。 Celery 能做的事，为什么在 Agent 场景里开始不够用 # 先说清楚一个基本判断：Celery 是好工具。对于"发封邮件、生成一张缩略图、推送一条通知"这类标准异步任务，它完全够用，工业界跑了十几年。 但我们跑的负载和这不一样： 1 2 3 4 5 6 一个 Run 包含 N 条 longtail 每条 longtail 跑 A → B → C → D 四个 Agent 阶段 每个阶段调一次或多次 AI API 总耗时任意一条都在 60-180 秒区间 每一步的中间结果需要持久化 任何一步失败需要知道"停在哪、为什么、能不能只重试这一步" 这是有状态的、长时的、多阶段的业务流程。任务队列和业务流程引擎之间的分界线，就在这里。