[{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/tags/ai-agent/","section":"Tags","summary":"","title":"AI Agent","type":"tags"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/categories/ai-agent-in-practice/","section":"Categories","summary":"","title":"AI Agent in Practice","type":"categories"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/categories/ai-agent-%E5%AE%9E%E6%88%98/","section":"Categories","summary":"","title":"AI Agent 实战","type":"categories"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/tags/bm25/","section":"Tags","summary":"","title":"BM25","type":"tags"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/tags/cron-job/","section":"Tags","summary":"","title":"Cron Job","type":"tags"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/tags/embedding/","section":"Tags","summary":"","title":"Embedding","type":"tags"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/tags/memory-system/","section":"Tags","summary":"","title":"Memory System","type":"tags"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/tags/nvidia/","section":"Tags","summary":"","title":"NVIDIA","type":"tags"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/tags/openclaw/","section":"Tags","summary":"","title":"OpenClaw","type":"tags"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/series/openclaw-production-notes/","section":"Series","summary":"","title":"OpenClaw Production Notes","type":"series"},{"content":"这是 OpenClaw 生产实战 系列的第二篇。第一篇 聊的是 compaction 静默吞回复和 Outer Loop 的防御性设计。这篇聚焦记忆系统——具体来说，是一个让我重新理解\u0026quot;向量检索到底值不值\u0026quot;的真实经历。\n背景：OpenClaw 的记忆检索是怎么工作的 # OpenClaw 的记忆检索是一个混合检索系统——向量（embedding similarity）和 BM25（文本关键词匹配）按 7:3 权重融合，再经过 PPO 自适应的五维加权（recency 0.35 + frequency 0.25 + semantic 0.25 + saliency 0.15 + procedural 按需）产出最终结果。\n架构上看：\n1 2 3 4 5 6 7 8 9 10 11 12 用户查询 ↓ ┌──────────────┐ ┌──────────────┐ │ 向量检索(70%) │ │ BM25 检索(30%)│ │ embedding → │ │ 关键词匹配 → │ │ 余弦相似度 │ │ TF-IDF 打分 │ └──────┬───────┘ └──────┬───────┘ └────────┬─────────┘ ↓ 混合排序 + PPO 五维加权 ↓ Top-K 记忆片段 看起来很完美。但部署后跑了两周，我发现了一个让人困惑的事实。\n发现：向量搜索挂了，系统照常运转 # 起因是一次常规巡检。跑 openclaw memory status 时，我注意到一个异常：\n1 2 3 Vector store: unknown Embedding cache: enabled (0 entries) FTS: ready 向量存储状态 unknown，embedding 缓存 0 条——这意味着向量检索根本没在工作。但奇怪的是：记忆系统每天照常检索、Dreaming 照常巩固、Agent 的回复质量也没有明显下降。\n再看 FTS（全文检索）那行：ready。BM25 一直在正常兜底。\n追查原因，是 openclaw.json 里的 memorySearch 配置项缺少 embedding provider——系统启动时 embedding 初始化失败，静默降级到了纯 BM25 模式。没有报错、没有告警，就是悄悄地只用了 30% 权重的那条检索通道，而且它扛住了。\n这意味着什么 # 903 个记忆 chunk、512 条 recall 条目——整个记忆系统跑在纯文本检索上，用了两周，没人发现有什么问题。\n这逼着我重新审视一个基本假设：在编程 Agent 的记忆场景下，向量检索到底有多重要？\n为什么 BM25 在这个场景下够用 # 编程 Agent 的记忆内容有几个特征，恰好是 BM25 的甜区：\n1. 记忆内容高度结构化。 OpenClaw 的记忆文件是 Markdown，有 frontmatter（name、type、description）、有标题层级、有明确的技术术语。不是自然语言的模糊表述，而是 compaction safeguard、Gemini 429 配额耗尽、fable-5 全球禁用 这样的精确描述。BM25 对这类\u0026quot;半结构化技术文档\u0026quot;的匹配效果本来就不错。\n2. 查询和文档用同一套词汇。 用户问\u0026quot;compaction 怎么配\u0026quot;，记忆里写的就是\u0026quot;compaction\u0026quot;这个词。不存在\u0026quot;用户说苹果、文档写 Apple\u0026quot;的语义鸿沟。编程领域的术语体系高度统一——429 就是 429，context overflow 就是 context overflow。这恰好是 BM25 最擅长的：精确词匹配。\n3. 记忆总量在千级，不在百万级。 99 个文件、903 个 chunk——这个规模下，BM25 的 precision 和 recall 都不会太差，因为候选集本身就不大。向量检索的优势在大规模数据集上才真正体现，1000 个 chunk 的场景下优势可忽略。\n4. PPO 五维加权弥补了检索质量。 即使 BM25 的初始排序不够精准，recency（最近用过的记忆排前面）和 frequency（常被调用的记忆权重更高）两个维度会把高频使用的记忆推到顶部。这些维度不依赖 embedding，纯靠使用统计。\n一句话总结：在\u0026quot;技术术语精确、数据量千级、有使用统计加权\u0026quot;的场景下，BM25 本身就是一个足够好的检索方案。\n这也呼应了我在 记忆选型框架 里写的结论：能不用 RAG 就不用 RAG。向量检索不是默认选择，是数据量和语义复杂度逼你选的。\n那为什么还要修？ # 既然 BM25 够用，为什么我最终还是把向量检索补上了？三个原因：\n1. 跨语言检索。 我的记忆文件里中英文混杂——有些事故记录是中文（\u0026ldquo;Gemini 资源池配额枯竭\u0026rdquo;），有些是英文（\u0026ldquo;unrestricted key enforcement\u0026rdquo;）。BM25 对跨语言的模糊匹配无能为力：用中文\u0026quot;资源耗尽\u0026quot;搜不到英文的\u0026quot;quota exhausted\u0026quot;。向量检索的 embedding 空间天然做了语义对齐，同义词、跨语言都能匹配。\n2. 概念级检索。 问\u0026quot;之前遇到过 bot 不回复的情况吗\u0026quot;——BM25 会匹配\u0026quot;不回复\u0026quot;三个字，但不会匹配 compaction 静默吞回复（虽然这正是答案）。向量检索能把\u0026quot;bot 不回复\u0026quot;和\u0026quot;静默吞回复\u0026quot;在语义空间里拉近。随着记忆积累越多，这种概念级关联会越来越重要。\n3. 混合检索的互补性。 向量强在语义召回，BM25 强在精确匹配——两者混合的效果严格优于任何单独一个。7:3 的权重分配意味着：BM25 给你保底的精确匹配，向量给你锦上添花的语义发现。前两周纯 BM25 够用，但\u0026quot;够用\u0026quot;和\u0026quot;好用\u0026quot;之间差了一个向量检索。\n实现：用 NVIDIA 免费 Embedding API 零成本补全 # 修复的关键约束是：不能花钱。OpenClaw 本身已经在消耗模型 API 额度，如果 embedding 还要按 token 计费（OpenAI text-embedding-3-small 每百万 token $0.02），对于 903 个 chunk 的持续索引和每次查询的实时 embedding，虽然不多但完全没必要。\nNVIDIA 的 nv-embed-v1 是免费的 embedding 模型，通过 NVIDIA API Catalog 提供，兼容 OpenAI API 格式。它在 MTEB 排行榜上的表现和 OpenAI 的 embedding 模型在同一梯队，4096 维度，对多语言支持良好。\n获取 API Key # 注册 NVIDIA API Catalog 账号 在 NV-Embed-V1 模型页面点击 \u0026ldquo;Get API Key\u0026rdquo; 拿到一个 nvapi- 前缀的 key，免费使用，有速率限制但对 Agent 记忆这种低频场景完全够用 配置 OpenClaw # 在 openclaw.json 的 agent 配置中加入 memorySearch 段：\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 { \u0026#34;agents\u0026#34;: { \u0026#34;defaults\u0026#34;: { \u0026#34;memorySearch\u0026#34;: { \u0026#34;enabled\u0026#34;: true, \u0026#34;provider\u0026#34;: \u0026#34;openai\u0026#34;, \u0026#34;remote\u0026#34;: { \u0026#34;baseUrl\u0026#34;: \u0026#34;https://integrate.api.nvidia.com/v1\u0026#34;, \u0026#34;apiKey\u0026#34;: \u0026#34;nvapi-你的key\u0026#34; }, \u0026#34;model\u0026#34;: \u0026#34;nvidia/nv-embed-v1\u0026#34; } } } } 这里有一个关键点：provider 填的是 \u0026quot;openai\u0026quot; 而不是 \u0026quot;nvidia\u0026quot;。因为 NVIDIA API Catalog 的接口完全兼容 OpenAI 的 /v1/embeddings 格式——request body 结构一样、response 格式一样。OpenClaw 只要知道\u0026quot;这是一个 OpenAI 兼容的 embedding 端点\u0026quot;，剩下的全靠 baseUrl 路由到 NVIDIA 的服务器。\n这也是 OpenAI embedding API 格式成为事实标准的一个例证：NVIDIA、阿里通义、Jina、Cohere 等厂商的 embedding API 全都兼容这个格式。选 provider 时不用纠结，只要接口兼容，\u0026quot;openai\u0026quot; 就是万能适配器。\n重建索引 # 改好配置后重启 Gateway，然后重建记忆索引：\n1 openclaw memory reindex --deep 输出：\n1 2 3 Indexed: 99/99 files · 903 chunks Vector dims: 4096 Embedding cache: enabled (779 entries) 99 个文件全部被重新 embedding、索引到向量存储里。4096 维度是 nv-embed-v1 的默认维度，比 OpenAI 的 1536 维（text-embedding-3-small）更高，理论上语义空间更细腻。\n验证混合检索 # 用语义模糊的查询测试：\n1 openclaw memory search \u0026#34;之前 bot 不响应的事故怎么回事\u0026#34; 返回的 top-1 结果是 compaction 静默吞回复的记忆条目——这在纯 BM25 模式下是匹配不到的（因为记忆里没有\u0026quot;不响应\u0026quot;这三个字，只有\u0026quot;静默丢弃\u0026quot;和\u0026quot;Compaction 输出空摘要\u0026quot;）。\n再试一个跨语言的：\n1 openclaw memory search \u0026#34;Gemini quota issue\u0026#34; 匹配到了中文写的\u0026quot;Gemini 资源池整体配额枯竭\u0026quot;记忆条目。BM25 不可能完成这个匹配。\n修复前后对比 # 维度 修复前（纯 BM25） 修复后（向量 + BM25 7:3） 精确术语匹配 正常 正常 语义/概念匹配 不支持 支持 跨语言检索 不支持 支持 同义词匹配 不支持 支持 成本 0 0（NVIDIA 免费） 索引规模 903 chunks 903 chunks Embedding 缓存 0 779 条 检索延迟 \u0026lt;10ms \u0026lt;50ms（含 API 调用） 系统稳定性 稳定 稳定（BM25 仍兜底） 最后一行值得强调：即使 NVIDIA 的 API 偶尔超时或不可用，系统会自动降级回纯 BM25——和修复前一模一样。向量检索是增益，不是依赖。\n经验总结 # 1. 先跑起来，再补锦上添花。 向量检索没配好，系统跑了两周没人发现。这说明记忆系统的核心价值不在检索算法的精度，而在\u0026quot;记忆是否被写入、是否被管理、是否在需要时出现\u0026quot;。BM25 能解决 80% 的检索场景，剩下 20% 的语义匹配是优化项，不是必需品。\n2. 混合检索的正确心态是\u0026quot;BM25 保底、向量加分\u0026quot;。 不要反过来理解成\u0026quot;向量为主、BM25 辅助\u0026quot;。在生产环境里，确定性（BM25 的精确匹配一定能找到关键词完全一致的记忆）比概率性（向量的语义相似度可能把不相关的内容排上来）更重要。7:3 的权重分配里，那个 3 才是系统的安全网。\n3. OpenAI 兼容格式是 embedding 领域的事实标准。 无论你用 NVIDIA、阿里、Jina 还是 Cohere 的 embedding 模型，配置方式都是：provider: \u0026quot;openai\u0026quot; + baseUrl: \u0026quot;厂商端点\u0026quot; + model: \u0026quot;模型名\u0026quot;。不需要为每个厂商写适配器。这也意味着：如果 NVIDIA 的免费额度哪天取消了，切换到其他免费 embedding 服务只需要改两行配置。\n4. 免费 ≠ 不好用。 NVIDIA nv-embed-v1 是 MTEB 同梯队的模型，4096 维度，多语言支持良好。它免费是因为 NVIDIA 要推广自己的 API 生态——你拿到的是一个真正有竞争力的 embedding 模型，不是阉割版。\n5. \u0026ldquo;向量检索到底值不值\u0026quot;取决于你的数据特征。 如果你的记忆全是精确技术术语、数据量在千级、查询和文档用同一套词汇——BM25 就够了，向量检索是可选项。如果你的记忆里有跨语言内容、自然语言描述、概念级关联——向量检索从\u0026quot;可选\u0026quot;变成\u0026quot;需要\u0026rdquo;。我的场景是后者（中英文混杂、事故描述 vs 技术术语的语义关联），所以最终还是补上了。\n下一篇：一行路径省掉 84% 的工具调用——Cron Job 排障实录。当你的 AI Agent 每次执行都花 15 次 exec 调用搜索一个 skill 的路径，消息数从 54 膨胀到 165，根因只是 SKILL.md 里少写了一行绝对路径。这比任何算法调优都管用。\n","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/posts/openclaw-memory-text-to-vector/","section":"文章","summary":"OpenClaw 记忆系统的向量检索默认不可用——但 BM25 文本搜索兜底让系统照常运转了两周。当你发现「不配 embedding 也能跑」，到底要不要修？怎么用 NVIDIA 免费 API 零成本补上？","title":"OpenClaw 记忆实战：从「向量搜索挂了也能用」到用 NVIDIA 免费 API 补全最后一块拼图","type":"posts"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/series/openclaw-%E7%94%9F%E4%BA%A7%E5%AE%9E%E6%88%98/","section":"Series","summary":"","title":"OpenClaw 生产实战","type":"series"},{"content":"这是 OpenClaw 生产实战 系列的第三篇。第一篇 讲 compaction 静默吞回复，第二篇 讲记忆系统从\u0026quot;向量搜索挂了也能跑\u0026quot;到用 NVIDIA 免费 API 补全。这篇讲一个更朴素但影响更大的问题：当你的 AI Agent 不知道工具在哪，它会怎么做？\n现象：定时任务连续超时 # OpenClaw 有一个每天 21:05 执行的 cron job——daily-ai-news，功能是抓取当日 AI 领域新闻、生成摘要、配一张 banner 图、发到飞书群。\n某天我注意到这个任务连续失败。看日志：\n1 2 3 Status: error Duration: 1200s+ (timeout) Tokens: in=2,800,000+ out=15,000+ 20 分钟超时，消耗了 280 万 input token。一个日报任务。\n排障：从日志反推 Agent 行为 # OpenClaw 的 cron 执行会留完整的对话日志。我拉出最近一次失败的日志，统计关键指标：\n指标 失败运行 总消息数 165 exec 工具调用 44 次 tool_result 总大小 1,122 KB 运行时间 1200s+（超时） 165 条消息？44 次 exec？一个\u0026quot;抓新闻 → 写摘要 → 生图 → 发飞书\u0026quot;的流程，正常情况下不该超过 60 条消息和 10 次工具调用。\n逐条翻日志，发现了罪魁祸首。\n根因：Agent 不知道工具在哪 # daily-ai-news 的 SKILL.md（skill 的指令文件）里有一行：\n1 生成 banner 图片时使用 create-img / gpt-image-2 生成。 就这么一句。没有路径，没有调用方式，没有参数。\nAgent 拿到这个指令后，它知道要调用 create-img，但不知道这个东西在哪。于是它开始搜索：\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 # Agent 的第 1 次尝试 find /home/openclaw -name \u0026#34;create-img\u0026#34; -type d # 没找到想要的，继续 grep -r \u0026#34;create-img\u0026#34; /home/openclaw/.openclaw/ # 找到了一些引用，但不确定是不是可执行的 ls -la /home/openclaw/.openclaw/plugin-skills/ # 没看到，换个目录 ls -la /home/openclaw/.agents/skills/ # 找到了！但不确定怎么调用 cat /home/openclaw/.agents/skills/create-img/SKILL.md # 读完了，但还要确认脚本路径 find /home/openclaw/.agents/skills/create-img -name \u0026#34;*.py\u0026#34; # 确认了脚本，但不确定 Python 环境 which python3 python3 --version # 确认了 Python，但不知道虚拟环境在哪 ls /home/openclaw/workspace/.venv*/ # 找到了虚拟环境，开始拼命令... 15 次 exec 调用，只是为了找到一个工具的位置和调用方式。\n更要命的是，这个搜索过程产生的 tool_result 体积巨大——每次 find、grep、ls 的输出都会被塞进对话上下文。44 次 exec 调用累计产出 1.1MB 的工具结果，直接把上下文撑爆，触发 compaction，进一步拖慢执行。\n恶性循环 # 这是一个经典的上下文膨胀恶性循环：\n1 2 3 4 5 6 7 8 SKILL.md 缺路径 → Agent 搜索工具位置（15 次 exec） → 搜索结果塞满上下文（+900KB） → 触发 compaction（压缩耗时 + 可能丢信息） → 压缩后 Agent 忘记之前搜到的路径 → 再搜一遍（又 15 次 exec） → 上下文再次膨胀 → 超时 没错——compaction 压缩掉的恰恰是 Agent 好不容易搜到的工具路径，于是下一轮它又从头搜。这就是 165 条消息的来源：Agent 至少做了 2-3 轮完整的\u0026quot;搜索 → 找到 → 被压缩 → 再搜\u0026quot;循环。\n修复：一行绝对路径 # 修复方法极其简单。在 ai-news-digest 的 SKILL.md 末尾加一段，告诉 Agent 工具的完整调用方式：\ncreate-img 调用方式（直接使用，不要搜索）\n先读取 skill 规范：/home/openclaw/.openclaw/plugin-skills/create-img/SKILL.md 调用脚本（命令见下方） 生成后用 lark-cli im images create --file \u0026lt;图片路径\u0026gt; 上传飞书取得 image_key 1 2 3 4 5 6 7 8 source /home/openclaw/.bashrc /home/openclaw/workspace/.venv314/bin/python \\ /home/openclaw/.openclaw/plugin-skills/create-img/scripts/omniroute_image_batch.py \\ --prompt \u0026#34;\u0026lt;图片描述\u0026gt;\u0026#34; \\ --size 1536x864 \\ --quality high \\ --format png \\ --out-dir /home/openclaw/.openclaw/workspace/tmp/ai-news-banner 就这些。给 Agent 一个可以直接复制粘贴的完整命令，包括：\nPython 解释器的绝对路径（虚拟环境的） 脚本的绝对路径 所有必要参数 输出目录 修复效果 # 修复后的第一次运行：\n指标 修复前 修复后 变化 总消息数 165 54 -67% exec 工具调用 44 7 -84% tool_result 大小 1,122 KB 204 KB -82% 运行时间 1200s+（超时） 317s 从超时到 5 分钟完成 消息数砍掉三分之二，exec 调用砍掉 84%，工具结果体积砍掉 82%。\n一行路径，比任何算法调优都管用。\n为什么这个问题这么隐蔽 # 这个 bug 有三个让它难以发现的特征：\n1. 不是每次都失败 # 如果 Agent 第一轮搜索就找到了工具路径，且没有触发 compaction，任务就能正常完成——只是慢一点。只有当上下文刚好在搜索过程中触及 compaction 阈值时，才会进入恶性循环。这意味着它是一个概率性超时，不是确定性失败，让排障方向很容易跑偏到\u0026quot;是不是上游 API 慢了\u0026quot;。\n2. Agent 的搜索行为看起来很\u0026quot;合理\u0026quot; # 翻日志时，Agent 的每一步操作都是合理的：不知道路径 → 搜索文件系统 → 读文件确认 → 检查环境。这是一个\u0026quot;聪明但低效\u0026quot;的行为模式。你不会觉得 Agent 做错了什么，只是觉得\u0026quot;怎么这么慢\u0026quot;。\n3. SKILL.md 的\u0026quot;模糊引用\u0026quot;不会报错 # 写 使用 create-img 生成图片 这种指令，从语法上完全合法——SKILL.md 没有类型检查，不会告诉你\u0026quot;create-img 路径未解析\u0026quot;。Agent 接到指令后也不会说\u0026quot;我找不到 create-img\u0026quot;然后停下来——它会自己去找。这种静默降级到搜索模式是最难发现的问题。\n深层教训：给 AI Agent 写指令的原则 # 这个 bug 让我意识到一个更基本的问题：我们给 AI Agent 写的指令，精度要求远高于给人写的文档。\n给人 vs 给 Agent # 给人写文档时，你可以写\u0026quot;使用 create-img 生成图片\u0026quot;——人类开发者会去问同事、搜 wiki、翻目录结构，这些探索行为的成本几乎为零（不消耗 token，不占上下文）。\n给 Agent 写指令时，同样的模糊引用触发的探索行为每一步都有成本：\n每次 find / grep 消耗一次工具调用 每个工具结果占用上下文空间 上下文膨胀触发 compaction compaction 可能丢掉已经找到的信息 Agent 的\u0026quot;好奇心\u0026quot;是有代价的，而且代价按上下文空间计算。\nSKILL.md 写作规则 # 基于这次教训，我给自己定了几条 SKILL.md 的写作规则：\n1. 所有外部工具引用必须包含绝对路径。 不是\u0026quot;使用 create-img\u0026quot;，而是 /home/openclaw/.openclaw/plugin-skills/create-img/scripts/omniroute_image_batch.py。宁可 SKILL.md 多 5 行，也不要让 Agent 搜索。\n2. 可执行命令必须可直接复制。 包括解释器路径、虚拟环境激活、所有参数。Agent 应该能直接把命令粘贴到 exec 里执行，不需要任何额外的路径解析。\n3. 明确写\u0026quot;不要搜索\u0026quot;。 在提供完整路径的同时，显式告诉 Agent\u0026quot;直接使用以下路径，不要搜索文件系统\u0026quot;。这看起来多余，但 Agent 有时会\u0026quot;验证\u0026quot;你给的路径是否存在——一句\u0026quot;不要搜索\u0026quot;能省掉这个验证步骤。\n4. 环境依赖写死。 Python 虚拟环境路径、Node.js 版本、需要 source 的配置文件——全部写死。不要假设 Agent 知道运行环境。\n一个类比 # 这很像写 Dockerfile 和写 README 的区别：\nREADME（给人看）：\u0026ldquo;先安装 Python 3.14，然后在虚拟环境里 pip install -r requirements.txt\u0026rdquo; Dockerfile（给机器跑）：RUN /usr/local/bin/python3.14 -m venv /app/.venv \u0026amp;\u0026amp; /app/.venv/bin/pip install -r /app/requirements.txt SKILL.md 是给 Agent 执行的指令，不是给人阅读的文档。它的精度要求更接近 Dockerfile，而不是 README。\n更广的视角：Outer Loop 的性能瓶颈在哪 # 回顾这个系列的三篇文章，有一个清晰的模式：\n问题 根因 修复 Compaction 静默吞回复 harness 的压缩策略没有保护关键信息 加 safety margin + 结构化 prompt 向量搜索挂了没人发现 配置缺失导致静默降级 补 embedding provider 配置 Cron job 超时 SKILL.md 缺路径导致搜索膨胀 加一行绝对路径 三个问题的共同特征：都不是模型能力的问题，都是 Outer Loop 的配置/指令精度不够。\n这验证了第一篇的核心论点：在 harness 时代，系统质量的瓶颈从来不在模型推理，而在模型之外的一切——上下文管理、工具调用规范、指令精度、降级路径、监控告警。\n一行路径省掉 84% 的工具调用，一个 embedding provider 配置让向量检索复活，一个 safety margin 参数防止 compaction 吞回复。这些修复没有一个需要换更强的模型——它们需要的是更好的 harness 维护。\n当你的 Agent 表现不好时，先别想着换模型。打开日志，数一数工具调用次数，看看上下文是怎么膨胀的。答案大概率在 SKILL.md 的某一行里。\n这是 OpenClaw 生产实战系列的第三篇。如果你也在运维 AI Agent 的 cron job，希望这个\u0026quot;一行路径\u0026quot;的教训能帮你少走弯路。系列会持续更新——下一个话题可能是 Agent 的工具调用成本控制和上下文预算管理。\n","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/posts/openclaw-cron-skill-optimization/","section":"文章","summary":"OpenClaw 的 daily-ai-news 定时任务连续超时。根因不是模型不够强——是 SKILL.md 里少写了一行绝对路径，导致 Agent 每次花 15 次 exec 搜索工具位置。消息数 165→54，exec 调用 44→7，一行路径比任何算法调优都管用。","title":"OpenClaw 实战：一行路径省掉 84% 的工具调用——Cron Job 排障实录","type":"posts"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/tags/performance/","section":"Tags","summary":"","title":"Performance","type":"tags"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/tags/prompt-engineering/","section":"Tags","summary":"","title":"Prompt Engineering","type":"tags"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/tags/skill.md/","section":"Tags","summary":"","title":"SKILL.md","type":"tags"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/tags/vector-search/","section":"Tags","summary":"","title":"Vector Search","type":"tags"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/tags/%E8%AE%B0%E5%BF%86%E7%B3%BB%E7%BB%9F/","section":"Tags","summary":"","title":"记忆系统","type":"tags"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/posts/","section":"文章","summary":"","title":"文章","type":"posts"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/tags/%E5%90%91%E9%87%8F%E6%90%9C%E7%B4%A2/","section":"Tags","summary":"","title":"向量搜索","type":"tags"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/tags/%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96/","section":"Tags","summary":"","title":"性能优化","type":"tags"},{"content":"","date":"2026-06-20","externalUrl":null,"language":"zh","permalink":"/","section":"卓琪的开发笔记","summary":"","title":"卓琪的开发笔记","type":"page"},{"content":"","date":"2026-06-13","externalUrl":null,"language":"zh","permalink":"/tags/agent-architecture/","section":"Tags","summary":"","title":"Agent Architecture","type":"tags"},{"content":"","date":"2026-06-13","externalUrl":null,"language":"zh","permalink":"/series/agent-architecture-deep-dives/","section":"Series","summary":"","title":"Agent Architecture Deep Dives","type":"series"},{"content":"","date":"2026-06-13","externalUrl":null,"language":"zh","permalink":"/tags/agent-%E6%9E%B6%E6%9E%84/","section":"Tags","summary":"","title":"Agent 架构","type":"tags"},{"content":"","date":"2026-06-13","externalUrl":null,"language":"zh","permalink":"/series/agent-%E6%9E%B6%E6%9E%84%E6%B7%B1%E5%BA%A6/","section":"Series","summary":"","title":"Agent 架构深度","type":"series"},{"content":"","date":"2026-06-13","externalUrl":null,"language":"zh","permalink":"/tags/claude/","section":"Tags","summary":"","title":"Claude","type":"tags"},{"content":" 背景：Agent 工具调用的成本困境 # 在传统 Agent 工具调用模型中，每调用一个工具都需要完成一次\u0026quot;模型推理 → 工具执行 → 结果返回 → 模型再推理\u0026quot;的完整回合。这个看似自然的循环，在工具调用变多时会暴露出三个致命问题：\n上下文污染：每个工具的结果都被原封不动地注入上下文窗口。查 20 个员工的报销记录，2000+ 条费用明细全部进入 context，即使你只需要知道\u0026quot;哪 3 个人超预算了\u0026quot;。 推理开销：每个工具调用都需要一次完整的模型推理。5 个工具调用 = 5 次推理 pass，每次几百毫秒到几秒不等。 噪声导致准确率下降：当上下文窗口塞满了中间结果，模型不得不在大量噪声中寻找信号。Context Rot 研究 表明，LLM 在复杂任务上的性能会随上下文增长而下降 50-70%。 正如 Bruno 在 Claude Code Architecture Guide 中所指出的：\u0026ldquo;Outer Loop（模型外的一切：上下文管理、工具调用、验证、记忆巩固）开始比模型推理本身更决定系统质量。\u0026rdquo;\nAnthropic 在 2025 年 11 月到 2026 年 2 月间陆续推出的一系列工具使用增强功能，本质上都是为了解决 Outer Loop 的效率问题。其中 Programmatic Tool Calling (PTC) 和 Dynamic Filtering 是最具范式转移意义的两项。\nProgrammatic Tool Calling：用代码编排取代自然语言编排 # 核心范式转移 # Michael Ridland 在 Team 400 博客 中一针见血地指出了传统工具调用的瓶颈：\n\u0026ldquo;每次 Agent 需要调用工具——查询数据库、检查 API、读取文件——都必须完成一个完整的模型往返。模型生成工具调用，你的代码执行它，结果返回模型，模型处理结果，然后可能生成下一个工具调用。重复。\u0026rdquo;\n而 Programmatic Tool Calling 的范式转移在于：Claude 不再一个一个地请求工具并等待结果回到上下文，而是写一段 Python 代码来编排所有工具调用，只把最终 stdout 注入到上下文窗口。\n1 2 3 4 5 传统方式: Prompt → Claude → Tool 1 → Result 1 → Claude → Tool 2 → Result 2 → Claude → Answer (3 个工具 = 3 次推理、3 份中间结果全量入上下文) PTC 方式: Prompt → Claude → 写 Python → 代码调用 Tool 1, 2, 3 → stdout → Claude → Answer (3 个工具 = 1 次推理、仅最终输出入上下文) 这个概念看似简单，但它的含义深远——它把编排逻辑从模型的\u0026quot;推理链\u0026quot;转移到了\u0026quot;代码执行环境\u0026quot;中。 循环、条件判断、数据处理、错误处理都变成了显式的代码而非隐式的模型推理。Claude Lab 的 Masaki Hirokawa 在生产实践指南中总结道：\n\u0026ldquo;Claude 写代码的能力极强。让它用 Python 表达编排逻辑而不是用自然语言，你获得的是更可靠、更精确的控制流。\u0026rdquo;\n工作原理：容器内的代码编排 # PTC 依赖 Code Execution 工具（沙箱容器）来运行：\n标记工具：通过 allowed_callers 字段指定哪些工具可从代码中调用 Claude 生成编排代码：Claude 写出包含多步工具调用、数据处理、控制流的 Python 脚本 容器执行并暂停：当代码调用工具时，容器暂停，API 返回 tool_use block 你提供工具结果：结果返回给代码（而非模型上下文），代码继续执行 仅最终输出回到 Claude：所有中间结果被过滤，Claude 只看到 stdout 的最终输出 1 2 3 4 5 6 7 8 9 10 11 { \u0026#34;tools\u0026#34;: [ {\u0026#34;type\u0026#34;: \u0026#34;code_execution_20260120\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;code_execution\u0026#34;}, { \u0026#34;name\u0026#34;: \u0026#34;query_database\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;Execute SQL. Returns rows as JSON: id (str), name (str), revenue (float).\u0026#34;, \u0026#34;input_schema\u0026#34;: {...}, \u0026#34;allowed_callers\u0026#34;: [\u0026#34;code_execution_20260120\u0026#34;] } ] } 关键在于 allowed_callers 字段，它有三个可选值：\nallowed_callers 值 含义 省略 / [\u0026quot;direct\u0026quot;] 仅传统方式调用 [\u0026quot;code_execution_20260120\u0026quot;] 仅可从沙箱代码调用 [\u0026quot;direct\u0026quot;, \u0026quot;code_execution_20260120\u0026quot;] 两种方式均可（不推荐——会让 Claude 困惑） Bruno 在架构指南中强调了一个重要的安全提示：allowed_callers 不是硬安全边界。 它是一个强指导（Claude 被训练为尊重它），但你的客户端仍应为任何工具准备处理直接的 tool_use 请求。\n容器生命周期 # 容器有 4.5 分钟的空闲超时和 30 天的最大生命周期。每次收到响应时都要检查 expires_at 字段。如果容器过期，Claude 会将工具调用视为超时并重试。\n实际的性能数据 # Claude Lab 提供了详细的基准测试对比：\n1 2 3 4 5 6 7 8 9 10 11 12 13 基准: 10-URL 网络研究任务 传统工具调用: 往返次数: 10 (1 次搜索 + 9 次页面抓取) 推理次数: 11 平均延迟: 45 秒 Token 消耗: ~120,000 tokens PTC: 往返次数: 2 (1 次代码生成 + 1 次结果返回) 推理次数: 2 平均延迟: 8 秒 (并行抓取) Token 消耗: ~25,000 tokens Anthropic 官方数据同样验证了这一点：\n在复杂研究任务上，输入 token 消耗平均下降 37%（从 43,588 降至 27,297） 在 BrowseComp 测试上，准确率从 42% 提升至 71%（PTC 是关键解锁因素） 在含 75 个工具的项目管理 Agent 基准上，启用 PTC 后计费 token 减少约 38%，且任务准确率未下降 社区分析师 Shayan Tabe 的报告进一步证实了约 37% 的总体 token 削减，尽管这个数字尚未被 Anthropic 官方确认。\n生产模式：四种 PTC 编程范式 # PTC 真正的威力体现在四种具体的编程模式上，这些模式都可以在单次推理中完成：\n1. 批量处理 (Batch Processing) # 1 2 3 4 5 6 7 regions = [\u0026#34;West\u0026#34;, \u0026#34;East\u0026#34;, \u0026#34;Central\u0026#34;, \u0026#34;North\u0026#34;, \u0026#34;South\u0026#34;] results = {} for region in regions: data = await query_database(f\u0026#34;SELECT * FROM sales WHERE region = \u0026#39;{region}\u0026#39;\u0026#34;) results[region] = sum(row[\u0026#34;revenue\u0026#34;] for row in data) top_region = max(results.items(), key=lambda x: x[1]) print(f\u0026#34;Top region: {top_region[0]} with ${top_region[1]:,}\u0026#34;) 2. 提前终止 (Early Termination) # 1 2 3 4 5 for endpoint in [\u0026#34;us-east\u0026#34;, \u0026#34;eu-west\u0026#34;, \u0026#34;apac\u0026#34;]: status = await check_health(endpoint) if status == \u0026#34;healthy\u0026#34;: print(f\u0026#34;Found healthy endpoint: {endpoint}\u0026#34;) break # 不检查剩余 endpoint 3. 条件工具选择 (Conditional Tool Selection) # 1 2 3 4 5 6 file_info = await get_file_info(path) if file_info[\u0026#34;size\u0026#34;] \u0026lt; 10000: content = await read_full_file(path) else: content = await read_file_summary(path) print(content) 4. 数据过滤 (Data Filtering) # 1 2 3 4 5 logs = await fetch_logs(server_id) errors = [log for log in logs if \u0026#34;ERROR\u0026#34; in log] print(f\u0026#34;Found {len(errors)} errors\u0026#34;) for error in errors[-10:]: # 只返回最后 10 条 print(error) 这些模式的关键点在 Team 400 的 Michael Ridland 那里得到了强调：\n\u0026ldquo;如果 20 次数据库查询返回了 5000 行数据，但只有 3 个员工超预算，模型只会看到那 3 个员工。这可能是 100 倍的 token 削减。\u0026rdquo;\n适用场景判断（含反模式警示） # Claude Lab 和 Anthropic 官方文档合起来给出了清晰的决策矩阵：\n强适用场景：\n处理大数据集且只需要聚合或摘要结果 运行 3 个或以上依赖工具调用的多步工作流 在 Claude 看到结果之前需要过滤、排序或转换工具结果 中间数据不应影响 Claude 推理的任务 跨多个项目运行并行操作（例如检查 50 个端点） 弱适用场景：\n严格顺序的工作流，每一步都依赖 Claude 对上一结果的推理 少量工具调用且响应很小 需要用户在调用间立即反馈的工具 Anthropic 在 τ²-bench 上的内部评估揭示了 PTC 的盲区：在每轮只做 1-2 次顺序工具调用的航空/零售/电信领域测试中，PTC 没有改善分数，反而增加了约 8% 的成本。顺序单调用工作流不会受益于 PTC。\n约束与陷阱 # PTC 不是银弹，以下约束需要在架构阶段考虑：\n约束 说明 不支持 ZDR 需要 Zero Data Retention 合规的场景无法使用 不兼容 MCP 工具 通过 MCP 连接器提供的工具不能以编程方式调用 不兼容 strict: true 结构化输出 (strict: true) 不能与 PTC 同时使用 不支持强制特定工具 不能通过 tool_choice 强制以编程方式调用特定工具 容器超时 如果工具执行太慢导致容器超时，Claude 会重试，可能产生重复调用 调试难度增加 出问题时需要检查代码执行输出而非逐步追踪 Michael Ridland 特别警告了调试问题：\n\u0026ldquo;当 PTC 出问题时，逻辑存在于生成的代码中。你需要检查代码执行输出来理解发生了什么。在你的系统中构建日志记录。\u0026rdquo;\nDynamic Filtering：Web Search 的上下文瘦身革命 # 问题本质 # Web 搜索是 token 消耗最大的任务之一。传统流程是：发起查询 → 获取搜索结果 → 抓取多个网页的完整 HTML → 在上下文中推理所有内容。但搜索到的上下文往往大量无关——导航栏、广告、页脚、推荐内容……\nAnthropic 在官方博客中描述了解决方案：\n\u0026ldquo;Claude 的 web search 和 web fetch 工具现在会自动编写和执行代码来后处理查询结果。Claude 不再在完整 HTML 文件上推理，而是在加载到上下文之前动态过滤搜索结果，只保留相关的内容，丢弃其余部分。\u0026rdquo;\n工作原理 # Dynamic Filtering 本质上是 PTC 理念在 Web Search 场景的原生实现——让 Claude 写 Python 代码预处理搜索结果：\n1 2 3 传统: Query → Search API → 10 个原始 HTML → 全部进入上下文 → Claude 推理 Dynamic Filtering: Query → Search API → 10 个原始 HTML → Claude 写代码提取关键信息 → 过滤后摘要进入上下文 → Claude 推理 基准测试数据 # Anthropic 在两个严格的基准测试上评估了 Dynamic Filtering：\nBrowseComp 数据集：\n模型 无过滤 有过滤 提升 Sonnet 4.6 33.3% 46.6% +13.3 pp Opus 4.6 45.3% 61.6% +16.3 pp DeepSearchQA： 测试 Agent 是否能系统地规划和执行多步搜索而不遗漏任何答案。\n模型 无过滤 有过滤 提升 Sonnet 4.6 (F1) 52.6% 59.4% +6.8 pp Opus 4.6 (F1) 69.8% 77.3% +7.5 pp 整体上，Dynamic Filtering 平均提高了 11% 的准确率，同时减少了 24% 的输入 token。\nPoe by Quora 的内部团队验证了这些数据：\n\u0026ldquo;Opus 4.6 + Dynamic Filtering 在我们内部评估中取得了最高准确率。\u0026quot;—— Gareth Jones, Product and Research Lead at Quora\n\u0026ldquo;模型的行为像一个真正的研究者，编写 Python 来解析、过滤和交叉引用结果，而不是在上下文中推理原始 HTML。\u0026rdquo;\n配置示例 # 1 2 3 4 5 6 7 8 9 10 11 12 13 14 { \u0026#34;model\u0026#34;: \u0026#34;claude-opus-4-6\u0026#34;, \u0026#34;max_tokens\u0026#34;: 4096, \u0026#34;tools\u0026#34;: [ {\u0026#34;type\u0026#34;: \u0026#34;web_search_20260209\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;web_search\u0026#34;}, {\u0026#34;type\u0026#34;: \u0026#34;web_fetch_20260209\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;web_fetch\u0026#34;} ], \u0026#34;messages\u0026#34;: [ { \u0026#34;role\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;content\u0026#34;: \u0026#34;Search for the current prices of AAPL and GOOGL, then calculate which has a better P/E ratio.\u0026#34; } ] } 注意：使用 web_search_20260209 / web_fetch_20260209 版本时，Dynamic Filtering 在 Sonnet 4.6 和 Opus 4.6 上默认开启。如果不需要（比如为了 ZDR 合规），可以通过 \u0026quot;allowed_callers\u0026quot;: [\u0026quot;direct\u0026quot;] 关闭。\n重要限制： 基本版 web_search_20250305 有 ZDR 资格，但 Dynamic Filtering 版本因为依赖内部代码执行，默认不支持 ZDR。\n三位一体：PTC + Tool Search + Tool Use Examples # Anthropic 的 Advanced Tool Use 实际上是三个互补功能的组合：\n功能 解决的问题 使用场景 Tool Search Tool 工具定义太多导致上下文膨胀 50+ 个 MCP 工具的场景 Programmatic Tool Calling 中间结果污染上下文 3+ 步工具调用工作流 Tool Use Examples Schema 无法表达使用模式 复杂嵌套参数的工具 Bruno 在架构指南中给出了清晰的优先级建议：\n\u0026ldquo;先解决你最大的瓶颈：上下文被工具定义撑爆？→ Tool Search。大量中间结果污染上下文？→ PTC。参数错误频发？→ Tool Use Examples。\u0026rdquo;\nTool Search：按需发现 # 一个真实的案例：在连接 5 个 MCP 服务器（GitHub 35 工具 + Slack 11 工具 + Sentry 5 工具 + Grafana 5 工具 + Splunk 2 工具）时，传统方式需要将全部 58 个工具定义预加载到上下文，消耗约 55K tokens。启用 Tool Search 后，只有 ~500 tokens 的搜索工具常驻上下文，匹配到的 3-5 个相关工具（~3K tokens）按需加载。85% 的 token 开销被消除。\n内部测试显示：\nOpus 4 的工具选择准确率从 49% 提升至 74% Opus 4.5 从 79.5% 提升至 88.1% Tool Use Examples：教会 Claude 怎么用你的工具 # JSON Schema 能定义结构，但无法表达：什么时候填入可选参数？哪些参数组合是合理的？你的 API 有什么约定？\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 { \u0026#34;name\u0026#34;: \u0026#34;create_ticket\u0026#34;, \u0026#34;input_schema\u0026#34;: { /* ... */ }, \u0026#34;input_examples\u0026#34;: [ { \u0026#34;title\u0026#34;: \u0026#34;Login page returns 500 error\u0026#34;, \u0026#34;priority\u0026#34;: \u0026#34;critical\u0026#34;, \u0026#34;labels\u0026#34;: [\u0026#34;bug\u0026#34;, \u0026#34;authentication\u0026#34;, \u0026#34;production\u0026#34;], \u0026#34;reporter\u0026#34;: { \u0026#34;id\u0026#34;: \u0026#34;USR-12345\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Jane Smith\u0026#34;, \u0026#34;contact\u0026#34;: {\u0026#34;email\u0026#34;: \u0026#34;jane@acme.com\u0026#34;, \u0026#34;phone\u0026#34;: \u0026#34;+1-555-0123\u0026#34;} }, \u0026#34;due_date\u0026#34;: \u0026#34;2026-06-13\u0026#34; }, { \u0026#34;title\u0026#34;: \u0026#34;Add dark mode support\u0026#34;, \u0026#34;labels\u0026#34;: [\u0026#34;feature-request\u0026#34;, \u0026#34;ui\u0026#34;], \u0026#34;reporter\u0026#34;: {\u0026#34;id\u0026#34;: \u0026#34;USR-67890\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Alex Chen\u0026#34;} }, { \u0026#34;title\u0026#34;: \u0026#34;Update API documentation\u0026#34; } ] } 三个例子教会 Claude：\n日期用 YYYY-MM-DD 格式，用户 ID 用 USR-XXXXX，标签用 kebab-case 严重 bug 需要完整联系信息 + 升级配置；功能请求有 reporter 但不需要 escalation；内部任务只需标题 Anthropic 内部测试：复杂参数处理的准确率从 72% 提升至 90%。\n架构决策：何时部署，何时绕过 # 综合多篇文章的实践智慧，应该这样看待这套工具集的架构定位：\n正确理解外层循环 (Outer Loop) # Bruno 在架构指南中提出了一个核心观点——\u0026ldquo;Less scaffolding, more model\u0026rdquo;（更少的脚手架，更多的模型信任）。这个哲学在 Claude Code 中体现为：\n\u0026ldquo;没有意图分类器。没有任务路由器。没有 RAG 管道。没有 DAG 编排器。没有 Planner/Executor 分离。模型本身决定何时调用工具、调用哪些工具、何时完成。\u0026rdquo;\nPTC 和 Dynamic Filtering 延续了这个理念——它们不是添加新的抽象层，而是减少不必要的抽象：不需要把中间结果传给模型再等它\u0026quot;想\u0026quot;下一步，直接用代码完成编排。\n模型兼容性 # PTC 需要 code_execution_20260120，当前支持：\nClaude Opus 4.5+ Claude Sonnet 4.5+ Claude Fable 5 / Mythos 5 Dynamic Filtering 需要 web_search_20260209，在 Opus 4.6 / Sonnet 4.6 上默认开启。\n部署检查清单 # Team 400 给出了实用的四步部署法：\n在 API 调用中启用代码执行工具 为应从代码调用的工具添加 allowed_callers 用需要多次工具调用的提示进行测试 对比传统方法和 PTC 方法的延迟、token 使用和输出质量 Bruno 特别强调了一个容易踩的坑：不要给同一个工具同时设 [\u0026quot;direct\u0026quot;, \u0026quot;code_execution_20260120\u0026quot;]。选一个——这会给 Claude 提供关于最佳使用方式的更清晰指导。\n总结 # Programmatic Tool Calling 和 Dynamic Filtering 代表了 Agent 架构中一个重要的范式转移：从\u0026quot;一切经过模型推理\u0026quot;转向\u0026quot;代码编排 + 按需过滤\u0026rdquo;。\n这不是 Anthropic 凭空创造的概念——它是对一个已经被实践反复验证的原则的系统化落地：让模型做它最擅长的事（推理和决策），让代码做代码最擅长的事（循环、过滤、并行执行）。\n两者的本质差异：\n维度 传统工具调用 PTC / Dynamic Filtering 编排逻辑位置 模型的推理链 Python 代码 中间结果去向 全部进入上下文 被代码过滤，不入上下文 N 次工具调用的推理次数 N+1 1~2 Token 消耗 随调用数线性增长 大幅削减（37%~80%） 调试方式 逐步追踪每个回合 检查代码执行输出日志 适合任务 简单查找、需人对中间结果决策 批量处理、数据聚合、多步研究 这篇文章综合了以下来源（均非 AI 生成，为人类工程师的分析和官方文档）：\nAnthropic Engineering: Introducing advanced tool use（官方博客，2025.11） Claude Blog: Improved Web Search with Dynamic Filtering（官方博客，2026.02） Claude API Docs: Programmatic tool calling（官方文档） How Claude Code Works: Architecture \u0026amp; Internals（Florian Bruniaux 技术分析，2026.02） Claude Lab: PTC Production Guide（Masaki Hirokawa 生产实践，2026.03） Team 400: Why PTC Matters for AI Agent Performance（Michael Ridland 实战分析，2026.03） ","date":"2026-06-13","externalUrl":null,"language":"zh","permalink":"/posts/claude-programmatic-tool-calling-dynamic-filter/","section":"文章","summary":"背景：Agent 工具调用的成本困境 # 在传统 Agent 工具调用模型中，每调用一个工具都需要完成一次\"模型推理 → 工具执行 → 结果返回 → 模型再推理\"的完整回合。这个看似自然的循环，在工具调用变多时会暴露出三个致命问题：\n上下文污染：每个工具的结果都被原封不动地注入上下文窗口。查 20 个员工的报销记录，2000+ 条费用明细全部进入 context，即使你只需要知道\"哪 3 个人超预算了\"。 推理开销：每个工具调用都需要一次完整的模型推理。5 个工具调用 = 5 次推理 pass，每次几百毫秒到几秒不等。 噪声导致准确率下降：当上下文窗口塞满了中间结果，模型不得不在大量噪声中寻找信号。Context Rot 研究 表明，LLM 在复杂任务上的性能会随上下文增长而下降 50-70%。 正如 Bruno 在 Claude Code Architecture Guide 中所指出的：“Outer Loop（模型外的一切：上下文管理、工具调用、验证、记忆巩固）开始比模型推理本身更决定系统质量。”\nAnthropic 在 2025 年 11 月到 2026 年 2 月间陆续推出的一系列工具使用增强功能，本质上都是为了解决 Outer Loop 的效率问题。其中 Programmatic Tool Calling (PTC) 和 Dynamic Filtering 是最具范式转移意义的两项。\n","title":"Claude 工具调用范式转移：Programmatic Tool Calling 与 Dynamic Filter 深度解读","type":"posts"},{"content":"","date":"2026-06-13","externalUrl":null,"language":"zh","permalink":"/tags/code-execution/","section":"Tags","summary":"","title":"Code Execution","type":"tags"},{"content":"","date":"2026-06-13","externalUrl":null,"language":"zh","permalink":"/tags/context-engineering/","section":"Tags","summary":"","title":"Context Engineering","type":"tags"},{"content":"","date":"2026-06-13","externalUrl":null,"language":"zh","permalink":"/tags/dynamic-filtering/","section":"Tags","summary":"","title":"Dynamic Filtering","type":"tags"},{"content":"","date":"2026-06-13","externalUrl":null,"language":"zh","permalink":"/tags/programmatic-tool-calling/","section":"Tags","summary":"","title":"Programmatic Tool Calling","type":"tags"},{"content":"","date":"2026-06-13","externalUrl":null,"language":"zh","permalink":"/tags/tool-calling/","section":"Tags","summary":"","title":"Tool Calling","type":"tags"},{"content":"","date":"2026-06-13","externalUrl":null,"language":"zh","permalink":"/tags/%E4%BB%A3%E7%A0%81%E6%89%A7%E8%A1%8C/","section":"Tags","summary":"","title":"代码执行","type":"tags"},{"content":"","date":"2026-06-13","externalUrl":null,"language":"zh","permalink":"/tags/%E5%B7%A5%E5%85%B7%E8%B0%83%E7%94%A8/","section":"Tags","summary":"","title":"工具调用","type":"tags"},{"content":"","date":"2026-06-13","externalUrl":null,"language":"zh","permalink":"/tags/%E4%B8%8A%E4%B8%8B%E6%96%87%E5%B7%A5%E7%A8%8B/","section":"Tags","summary":"","title":"上下文工程","type":"tags"},{"content":"","date":"2026-05-27","externalUrl":null,"language":"zh","permalink":"/tags/compaction/","section":"Tags","summary":"","title":"Compaction","type":"tags"},{"content":"","date":"2026-05-27","externalUrl":null,"language":"zh","permalink":"/tags/debugging/","section":"Tags","summary":"","title":"Debugging","type":"tags"},{"content":"","date":"2026-05-27","externalUrl":null,"language":"zh","permalink":"/tags/feishu/","section":"Tags","summary":"","title":"Feishu","type":"tags"},{"content":"","date":"2026-05-27","externalUrl":null,"language":"zh","permalink":"/series/openclaw-production/","section":"Series","summary":"","title":"OpenClaw Production","type":"series"},{"content":" 为什么是 OpenClaw # 编程 Agent 的能力跃迁不只是\u0026quot;更强\u0026quot;——每次范式转移改变的是验证循环的归属权。提示词工程时代（Copilot, 2021）：人类写 prompt、AI 补全、人类验证——验证完全在人手里。上下文工程时代（Cursor, 2023）：AI 生成代码块、人类审查 diff——验证仍以人为主，但 AI 开始做 lint/fix 的轻量自检。驾驭工程/harness 时代（Claude Code / Codex CLI / OpenClaw, 2025）：AI 写代码、AI 跑测试、AI 看报错、AI 修——验证循环从人转移到 harness，人不再逐条审查输出，而是设计和维护验证系统的规则。整个 Outer Loop（模型外的一切：上下文管理、工具调用、验证、记忆巩固）开始比模型推理本身更决定系统质量。OpenClaw 是这个趋势里记忆侧最激进、但 harness 稳定性最不足的一个。\n同一代内还有一条关键分岔：Vibe Coding（Bolt.new、Lovable、Replit）把验证也扔给用户\u0026ndash;\u0026ldquo;生成即交付\u0026rdquo;；Engineering Rigor（Claude Code、Aider、OpenClaw）则把验证编码进 harness\u0026ndash;测试跑不过就重试。两者的差距不在模型，在 outer loop 的设计哲学。\n先看一眼 OpenClaw 的整体架构——用思维导图展示组件层级，后面所有踩坑都跟这些模块有关：\nmindmap root((OpenClaw)) 📨 消息入口 飞书 企业微信 WebChat Telegram 🔌 Channels 层 消息路由 allowlist 去重 dedup 会话绑定 envelope 🖥️ Gateway 守护进程 WebSocket Server :18789 认证 设备配对 定时任务 CRON 引擎 🔄 Agent Loop 消息摄入 agent RPC 上下文组装 bootstrap session skills 模型推理 多后端 fallback 工具执行 memory shell web 回复生成 流式投递 🧠 Memory 系统 MEMORY.md 长期记忆 每日流水 YYYY-MM-DD.md DREAMS.md 巩固日记 向量 BM25 混合检索 7:3 OpenClaw 是驾驭工程时代的自治编程 Agent，跨模型 CLI，支持 DeepSeek / Anthropic / OpenAI 多后端。它最吸引我的一点是记忆系统——在当前所有生产可用的编程 Agent 中，它的记忆架构是最激进的：\nPPO 认知权重自适应：唯一的在生产工具中用强化学习调整记忆检索权重的系统。检索信号五维加权（recency 0.35 + frequency 0.25 + semantic 0.25 + saliency 0.15 + procedural 按需），随时间动态衰减 三重睡眠巩固：Light Sleep（Jaccard 去重，零 LLM 成本）→ REM Sleep（置信度评分）→ Deep Sleep（三条件晋升门：score≥0.80 + merge≥3 + recall≥3），自动将短期经验固化为长期记忆 向量 + BM25 混合检索（7:3）：比纯向量检索更鲁棒 但拉上生产环境跑了三周后，我的结论是：记忆系统有多先进，踩的坑就有多深。下面按时间线记录从部署到稳定全过程中真正折腾过的问题。\n第一坑：启动失败三重奏 # 第一次在 VPS 上启动 OpenClaw Gateway，连续三种报错，每种原因都不一样。\ngateway token missing — 最容易被忽略。OpenClaw 的 Gateway 模式需要独立的 OPENCLAW_GATEWAY_TOKEN 环境变量，不是飞书的 App Secret。systemd unit 文件里漏写一个 Environment= 就直接 401。\nNo credentials for provider — auth-profiles.json 里的 keyRef 必须和环境变量名精确匹配。一个字符对不上就报这个错，而且错误信息不会告诉你是哪个 keyRef 没匹配到，只能肉眼对。\n400 InvalidParameter / 模型不存在 — Omniroute 的模型名必须是 \u0026lt;provider\u0026gt;/\u0026lt;model\u0026gt; 格式。写成 gpt-5.5 会报 400，必须写 codex/gpt-5.5。再加上 OpenClaw 自己的 provider 前缀，最终是 omniroute/codex/gpt-5.5。三层前缀嵌套，少一层都不行。\n1 2 3 4 # 排查时这三步最省时间 systemctl cat openclaw-gateway.service | grep Environment # 检查环境变量 python3 -c \u0026#34;import json; json.load(open(\u0026#39;/home/openclaw/.openclaw/openclaw.json\u0026#39;))\u0026#34; # JSON 语法 journalctl -u openclaw-gateway.service -n 50 --no-pager | grep -iE \u0026#34;error|unauth\u0026#34; # 看错误 第二坑：日志去哪了 # OpenClaw 运行时日志全部走 journald，不写文件。/tmp/openclaw/openclaw-*.log 只在启动阶段有几行，运行时的错误全在 journald 里。我被这个坑了半小时——盯着文件日志 tail 了半天，什么都没看到，最后才意识到：\n1 2 # 这才是正确的看日志方式 journalctl -u openclaw-gateway.service -f 第三坑（最严重）：Compaction 静默吞回复 # 这是这三周里最严重的一次事故。在说具体时间线之前，先看图理解 Compaction 在 Agent Loop 中的位置和失败路径：\nflowchart TB MSG[\"👤 用户消息进入\"] LOOP[\"🔄 Agent Loop 处理组装上下文 → 推理 → 生成回复\"] CHECK{\"📏 上下文 ≤ 模型限制?\"} DELIVER[\"✅ 回复投递到飞书\"] COMPACT[\"🧹 Auto-Compaction 触发压缩旧消息为摘要\"] OVERFLOW{\"⚠️ Compaction prompt 也超限?\"} EMPTY[\"💀 模型输出空字符串Conversation is empty\"] LOST[\"❌ 回复静默丢弃用户感知：bot 不回复\"] SAFEGUARD[\"🛡️ safeguard 模式reserveTokens + fallback压缩完成 → 正常投递\"] MSG --\u003e LOOP --\u003e CHECK CHECK --\u003e|\"✅ 未超限\"| DELIVER CHECK --\u003e|\"❌ 超限 209K \u003e 200K\"| COMPACT --\u003e OVERFLOW OVERFLOW --\u003e|\"❌ 无保护\"| EMPTY --\u003e LOST OVERFLOW --\u003e|\"🛡️ 修复后\"| SAFEGUARD --\u003e DELIVER style EMPTY fill:#ff6b6b,color:#fff style LOST fill:#ff6b6b,color:#fff style SAFEGUARD fill:#51cf66,color:#fff style DELIVER fill:#51cf66,color:#fff 一条正常的用户消息，Agent 已经生成了完整回复，但用户什么都没收到，bot 像死了一样安静。\n时间线 # 01:43:40 飞书新闻群用户发消息：\u0026ldquo;失败请求占用到我们账户的请求资源的，麻烦方便的时候检修下程序中错误的请求参数\u0026rdquo; 01:43:57 Agent 生成了完整文本回复（session trajectory 里能看到 message event with assistant response） 01:44:00 Auto-compaction 触发：session context 已经到了 209K tokens，超过 primary model 的 200K 限制 01:44:00 回复消失：compaction 输出空摘要 \u0026quot;Conversation is empty\u0026quot;，session 结束，回复未投递到飞书 用户侧完全感知为\u0026quot;bot 不回复\u0026quot; 根因 # Compaction 是一个隐式中间层。正常情况下它压缩上下文；但当上下文本身已经超过模型限制（209K \u0026gt; 200K），compaction prompt 也装不下完整上下文时，模型输出空字符串。OpenClaw 默认没有对此做保护——不报错、不降级、不通知，只是悄悄地把已生成的回复扔掉了。\n这是 middleware-semantic-leak 的教科书级案例：中间层在极端情况下从\u0026quot;压缩上下文\u0026quot;变成了\u0026quot;丢弃回复\u0026quot;，语义完全翻转，且没有任何信号。\n翻开源码可以清晰地看到这个静默失败路径的完整链路。OpenClaw 的 compaction.ts 中定义了一个看起来无害的常量：\n1 2 // src/agents/compaction.ts const DEFAULT_SUMMARY_FALLBACK = \u0026#34;No prior history.\u0026#34;; 当 summarizeChunks() 收到空消息列表时，直接返回这个字符串——不抛错、不告警、不走降级。\n而发给模型的 compaction prompt 本身也完全没有防御性指令。这是 system prompt：\n1 2 3 4 5 6 7 8 // packages/agent-core/src/harness/compaction/compaction.ts SUMMARIZATION_SYSTEM_PROMPT: \u0026#34;You are a context summarization assistant. Your task is to read a conversation between a user and an AI coding assistant, then produce a structured summary following the exact format specified. Do NOT continue the conversation. Do NOT respond to any questions in the conversation. ONLY output the structured summary.\u0026#34; user prompt 的模板是：\n1 2 3 4 5 6 7 8 // packages/agent-core/src/harness/compaction/compaction.ts SUMMARIZATION_PROMPT: \u0026#34;\u0026lt;conversation\u0026gt; [这里塞入完整的对话历史, 209K tokens 时已经是十几万字的原始消息] \u0026lt;/conversation\u0026gt; The messages above are a conversation to summarize. Create a structured context checkpoint summary that another LLM will use to continue the work.\u0026#34; 关键设计缺陷就在这个 \u0026lt;conversation\u0026gt; 标签里：prompt 的指令部分（\u0026ldquo;summarize the conversation\u0026rdquo;）在对话历史之后. 当对话历史超过模型上下文窗口时，模型看到的不是\u0026quot;一堆对话\u0026quot; + \u0026ldquo;请总结\u0026rdquo;，而是一个被截断的 \u0026lt;conversation\u0026gt; 开头，后面什么都没有——既看不到 \u0026lt;/conversation\u0026gt; 闭合标签，也看不到总结指令。system prompt 只是说\u0026quot;你是总结助手，只输出结构化摘要\u0026quot;，没有告诉模型\u0026quot;如果对话内容被截断了该怎么办\u0026quot;。\n于是模型面对的是：一个残缺的 XML 片段 + 一个只说\u0026quot;输出摘要\u0026quot;的 system prompt。在多数模型的默认行为下，这意味着一个极短的空输出——恰好对应 trajectory 里看到的 \u0026ldquo;Conversation is empty\u0026rdquo;。\n更致命的是 summarizeWithFallback() 的最后兜底路径：当全文摘要和部分摘要先后失败（chunk 超限、模型 5xx、token 溢出），回退到：\n1 2 3 4 5 6 // src/agents/compaction.ts — summarizeWithFallback 最终 fallback return ( `Context contained ${messages.length} messages ` + `(${oversizedNotes.length} oversized). ` + `Summary unavailable due to size limits.` ); 这几个字就是你在 session trajectory 里看到的 \u0026ldquo;Conversation is empty\u0026rdquo; 的源头——compaction pipeline 的设计假设\u0026quot;摘要失败后还有原始上下文可用\u0026quot;，但 209K \u0026gt; 200K 的极端情况正好击穿了这个假设：原始上下文塞不进 prompt，摘要模型也返回空，唯一的输出是一条\u0026quot;摘要不可用\u0026quot;的自然语言通知——而 OpenClaw 把它当成正常的 compaction 结果继续执行，已生成的回复就静默丢弃了。\n两个常数的叠加也值得注意：\n1 2 3 // src/agents/compaction.ts const SAFETY_MARGIN = 1.2; // 20% buffer for estimateTokens inaccuracy const SUMMARIZATION_OVERHEAD_TOKENS = 4096; // prompt/system prompt overhead SAFETY_MARGIN 是 token 估算的 20% buffer——estimateTokens() 用的是字符数/4 的粗略估算，对多字节字符、特殊 token、代码 token 会有系统性低估。这意味着\u0026quot;看起来还有 10K 余量\u0026quot;时，实际已经撞墙了。SUMMARIZATION_OVERHEAD_TOKENS 是 compaction prompt + system prompt + 序列化包装的固定开销——但不包括 previous summary 的体积。当 session 精炼多轮后 previous summary 本身已经有几十 KB，这个 4096 的固定预留是不够的。\n而确认这是默认行为而非配置错误的证据在类型定义中：\n1 2 3 4 5 6 7 // src/config/types.agent-defaults.ts export type AgentCompactionConfig = { mode?: AgentCompactionMode; // 可选字段——不设就是无 safeguard 的默认模式 reserveTokens?: number; keepRecentTokens?: number; // ... }; mode 是 optional，不显式配置 \u0026quot;safeguard\u0026quot; 就不会启用 reserveTokens 和 maxHistoryShare 保护。生产环境的默认行为，就是让 compaction 裸跑。\n修复 # 两步，缺一不可：\n1 2 3 4 5 6 7 8 9 // openclaw.json \u0026#34;compaction\u0026#34;: { \u0026#34;mode\u0026#34;: \u0026#34;safeguard\u0026#34;, \u0026#34;reserveTokens\u0026#34;: 20000, \u0026#34;keepRecentTokens\u0026#34;: 16000 }, \u0026#34;model\u0026#34;: { \u0026#34;fallbacks\u0026#34;: [\u0026#34;deepseek/deepseek-v4-flash\u0026#34;] } safeguard 模式为 compaction 后的总结保留 token 预算，防止占用满窗口。而 fallback 到 deepseek-v4-flash（1M context window）则保证了即使主模型窗口不够，compaction 任务本身永不会超限。\n通用教训 # 这不是 OpenClaw 专属的问题。任何带自动上下文压缩的 Agent 系统，都面临同样的风险：compaction 的失败模式是静默的。如果你的 Agent 突然不回复了，第三个要检查的就是 compaction——在 session trajectory 里找 compaction event 的 content 是否为空。\n飞书消息不响应：五层排查法 # 这次事故之后，我沉淀了一套从外到内、按概率排序的排查链路。下次 bot 不回复，按这个顺序查：\n层 检查点 怎么看 L1 飞书应用层 Bot 是否收到消息 lark-cli im +chat-list --as bot 确认群在 allowlist L2 事件接收层 消息是否到达 Gateway 检查 dedup 记录是否有最近条目 L3 Session 层 Agent 是否处理了消息 看 session trajectory 的最后 event——这步最关键 L4 模型调用层 模型是否正常响应 journalctl grep 429/401/500/timeout L5 投递层 飞书发送是否成功 用 CLI 直接发一条测试消息验证权限 以后再遇到消息不响应，按下面这个决策树走，先看 trajectory 的最后 10 行——八成问题在第三步就能定位：\nflowchart TD PROBLEM[\"❓ 飞书群 bot 不回复\"] L1[\"L1: 群权限lark-cli im +chat-list --as bot\"] L1_OK{\"群在 allowlist?Bot 在群内?\"} L1_FIX[\"修复权限 / 加群到 allowlist\"] L2[\"L2: 消息到达查看 dedup 记录\"] L2_OK{\"dedup 有最近条目?\"} L2_FIX[\"检查飞书事件订阅 URLOPENCLAW_GATEWAY_TOKEN\"] L3[\"🔑 L3: Session Trajectorycat session/*.jsonl 最后 10 events\"] L3_MSG{\"最后 event 是什么?\"} L4[\"L4: 模型调用journalctl grep 429/500/timeout\"] L5[\"L5: 投递lark-cli im +send-message 测试\"] L3_CTX[\"💀 compaction 为空→ context overflow→ 本文事故，立即加 safeguard\"] L3_MESSAGE[\"回复已生成→ 问题在投递层→ 跳到 L5\"] L3_ERROR[\"有 error event→ 跳到 L4 查模型\"] PROBLEM --\u003e L1 L1 --\u003e L1_OK L1_OK --\u003e|\"✓ 正常\"| L2 L1_OK --\u003e|\"✗ 异常\"| L1_FIX L2 --\u003e L2_OK L2_OK --\u003e|\"✓ 有记录\"| L3 L2_OK --\u003e|\"✗ 无记录\"| L2_FIX L3 --\u003e L3_MSG L3_MSG --\u003e|\"compaction 空\"| L3_CTX L3_MSG --\u003e|\"assistant text\"| L3_MESSAGE L3_MSG --\u003e|\"error\"| L3_ERROR L3_ERROR --\u003e L4 L3_MESSAGE --\u003e L5 style L3 fill:#ffd43b,color:#333 style L3_CTX fill:#ff6b6b,color:#fff style L3_MESSAGE fill:#51cf66,color:#fff style L3_ERROR fill:#ff922b,color:#fff Outer Loop：为什么框架比模型更决定成败 # SWE-bench Pro 是目前最受认可的企业级编程 benchmark（Princeton 维护，独立评审），它有一个极具说服力的数据：同一个模型 Claude Opus 4.5，在不同 harness 下的得分可以差 9.5 个百分点——SEAL 标准化脚手架 45.9%，Cursor 50.2%，Auggie 51.8%，Claude Code 55.4%。模型完全一样，换一个 harness 就是 5 到 10 个百分点的差距。而 Anthropic 在 2025 年 11 月的工程博客 Effective harnesses for long-running agents 里也确认了同一个结论：把\u0026quot;干活\u0026quot;和\u0026quot;评估\u0026quot;拆到不同 Agent 里，用硬性 pass/fail 门禁取代模型自评，单 Agent 跑 20 分钟崩溃的任务，三 Agent harness 跑了 6 小时产出了完整可用的应用。OpenClaw 甚至没有出现在任何主流 benchmark 的榜单上——不是模型能力的问题，是它的 harness 质量还不足以支撑 benchmark 级别的稳定表现。\n这不是偶然。2025 年行业里一个收敛的认知是：\u0026ldquo;Structure around the model matters more than cleverness inside the model.\u0026rdquo; 模型只负责生成，而生成是便宜的——真正决定系统质量的是 Outer Loop 里的三件事：\nOuter Loop 组件 做什么 失败时发生什么 验证（Verification） 编译器、测试套件、linter 检查输出 AI 生成错误代码没人发现 上下文管理（Context Engineering） Compaction、pruning、memory flush 就是本文的事故——静默丢回复 工具定义（ACI） Tool schema、参数约束、防呆设计 参数传错、文件写错路径、静默重试 这三层都不在模型里面——它们是你部署和维护的系统。Compaction 事故的根因不是模型不够聪明，是你没告诉 harness \u0026ldquo;当压缩失败时，不要扔回复，要报错\u0026rdquo;。\n这也解释了为什么 Anthropic 观察到\u0026quot;最成功的 Agent 实现很少用复杂框架\u0026quot;——框架是别人写的 Outer Loop，你没法控制它的失败模式。OpenClaw 的多后端支持看起来是优势，但每个模型的 context window 不同、reasoning profile 不同、API 行为不同——每多一个模型，compaction 的边界条件就多一组组合，outer loop 的测试矩阵指数增长。\n这引向一个更根本的结构性问题——记忆系统的路线分歧。\nOpenClaw vs Claude Code：记忆系统的路线分歧 # OpenClaw 记忆系统最独特的机制是 Dreaming 后台巩固——它不是简单的\u0026quot;记下来\u0026quot;，而是有一个三阶段自动流水线：\nflowchart LR subgraph 短期[\"📝 短期记忆\"] SESSION[\"Session 对话\"] RECALL[\"recall traces\"] end subgraph LIGHT[\"💡 Light Sleep — 零 LLM\"] SORT[\"Jaccard 语义去重 + 排序\"] end subgraph REM[\"🌙 REM Sleep — 主题发现\"] REFLECT[\"模式识别 + 反思不写 MEMORY.md\"] end subgraph DEEP[\"🧠 Deep Sleep — 三条件晋升\"] RANK[\"score ≥ 0.80\"] MERGE[\"merge ≥ 3\"] RECALL_THRESH[\"recall days ≥ 3\"] end subgraph 长期[\"📦 长期记忆\"] MEM[\"MEMORY.md\"] end 短期 --\u003e LIGHT --\u003e REM --\u003e DEEP DEEP --\u003e|\"✓ 全过\"| MEM DEEP --\u003e|\"✗ 不满足\"| LIGHT style DEEP fill:#b197fc,color:#fff style MEM fill:#51cf66,color:#fff 跑了一段时间后，两个系统可以并排对比：\n维度 OpenClaw Claude Code 检索机制 向量+BM25 混合 (7:3) LLM 语义判断 (Sonnet) 权重进化 PPO 自适应 人工固定分类 巩固机制 三重睡眠 三门四阶段 AutoDream 模型锁定 多模型 仅 Claude 记忆分类 按时间（长期蒸馏/短期流水） 按类型（user/feedback/project/reference） 生产成熟度 早期 百万级 Agent 验证 OpenClaw 的记忆架构更\u0026quot;学术正确\u0026quot;——PPO 自适应权重、三重睡眠、混合检索，每一层都接近记忆系统前沿论文。Claude Code 看上去\u0026quot;更土\u0026quot;：记忆就是四类 Markdown 文件（user/feedback/project/reference），检索靠 Sonnet 语义判断，没有 PPO 也没有 BM25。\n但这里有一个反直觉的结构事实：文件记忆 \u0026gt; 向量记忆。不是量化的\u0026quot;好一点\u0026quot;，是质的差异。工业界从 Claude Code、Codex CLI 到 Cursor，全部选择 Markdown 文件作为主记忆介质，向量只做辅助索引。为什么？因为编程场景下确定性 \u0026gt; 概率检索——你不能让 PPO 权重决定\u0026quot;要不要记住 API key 泄漏过\u0026quot;。\n更大的问题在于：记忆系统的先进程度和 Outer Loop 的稳定性是乘积关系，不是加法。你的记忆检索算法再精准，如果 compaction 中间层悄悄把回复扔了，用户感知的不是\u0026quot;记忆不够好\u0026quot;，是\u0026quot;bot 死了\u0026quot;。OpenClaw 把 80% 的创新预算花在记忆侧（PPO、Dreaming、混合检索），但 Outer Loop 的防御侧（compaction safeguard、故障信号、降级路径）投入不足。Claude Code 反过来——记忆侧保守，但 harness 花了几百万 Agent 的实战验证。\n这是选型时需要警惕的陷阱：看 benchmark 时看的是模型+记忆的能力上限，但生产系统活在 Outer Loop 的下限里。\nCompaction 设计的结构性差异：从 prompt 学到的 # 前面从源代码看了 OpenClaw 的 compaction prompt 为什么在溢出时会静默失败——\u0026lt;conversation\u0026gt; 标签在前、指令在后，上下文溢出时模型看不到指令。那做得更好的长什么样？\n2026 年 3 月 Anthropic 的 npm .map 文件意外泄露了 Claude Code 的完整 system prompt，Piebald-AI/claude-code-system-prompts 从编译 JS 中提取并整理了所有 prompt。对比两个 compaction prompt，差距不在模型本身——都在用类似的 LLM 做摘要——而在 prompt 的结构性防御：\n摘要格式：9 段式 vs 5 段式。 Claude Code 要求 9 个结构化节：\nPrimary Request and Intent — 用户核心诉求 Key Technical Concepts — 技术概念 Files and Code Sections — 文件 + 完整代码片段 + 为什么重要 Errors and fixes — 所有错误 + 修复方式 + 用户反馈 Problem Solving — 已解决和排查中的问题 All user messages — 所有用户消息（非工具结果） Pending Tasks — 待处理任务 Current Work — 当前正在做的事（含文件名+代码片段） Optional Next Step — 下一步 + 对话原文引用 OpenClaw 只有 5 个（Decisions / TODOs / Constraints / Asks / Identifiers），缺失的恰好是 compaction 事故中最致命的部分：错误修复记录、用户消息的完整保存、当前工作的精确描述。\n安全指令逐字保留。 Claude Code 的 prompt 明确要求：\u0026ldquo;Note any security-relevant instructions or constraints the user stated\u0026hellip; These MUST be preserved verbatim in the summary so they continue to apply after compaction.\u0026rdquo; 这意味着\u0026quot;不要读 .env 文件\u0026quot;、\u0026ldquo;不要提交密钥\u0026rdquo;、\u0026ldquo;必须用 HTTPS 而非 HTTP\u0026quot;这类指令在 compaction 后仍然生效。OpenClaw 只做标识符保留（identifier policy），不做安全指令保留。\n用户反馈不会被压缩掉。 Section 6 要求列出 ALL user messages，Section 4 要求记录用户对每个错误的反馈。两个设计合在一起的效果是：用户说过\u0026quot;不要那样做，要这样做\u0026rdquo;——这件事经过 compaction 后不会消失。对比本文事故：一条用户消息触发 compaction → 已生成的回复静默丢弃 → 用户侧只看到 bot 不回复。如果 compaction 摘要里强制保留了\u0026quot;用户说了什么\u0026quot;，至少排障时一眼能看到触发源。\n下一步必须引用原文。 Section 9 要求：\u0026ldquo;Include direct quotes from the most recent conversation showing exactly what task you were working on and where you left off. This should be verbatim to ensure there\u0026rsquo;s no drift in task interpretation.\u0026rdquo; 这个设计防止了\u0026quot;摘要模型用自己的话重述任务\u0026quot;导致的语义漂移——重述过的任务，下一代 Agent 可能理解成完全不同的东西。\n分析先于输出。 Claude Code 的 prompt 要求先 \u0026lt;analysis\u0026gt; 标签内逐消息分析，再输出 \u0026lt;summary\u0026gt;。这不是装饰——它是把思考过程嵌入质量控制：如果 analysis 里没提到某个错误修复，summary 就不会有它。OpenClaw 的 prompt 没有这个内置的完整性检查。\n断路器。 连续 3 次 auto-compact 失败后停止。OpenClaw 无此机制，理论上可以无限 compaction → 失败 → 再 compaction。\n部分压缩。 Claude Code 支持只压缩前半段、保留后半段原文。独立 prompt 告诉模型：\u0026ldquo;this summary will be placed at the start of a continuing session; newer messages will follow\u0026rdquo;——模型清楚自己输出的是前缀，不会试图假装有全文视野。\n把这些差异放一张表里：\n设计维度 Claude Code OpenClaw 摘要格式 9 段式，含错误修复+用户消息 5 段式 安全指令保留 verbatim 逐字保留 仅标识符保留 用户反馈保护 ALL user messages + 原文引用 无 输出前分析 \u0026lt;analysis\u0026gt; → \u0026lt;summary\u0026gt; 两步 直接输出 Circuit breaker 3 次连续失败停止 无 Prompt 架构 指令在前，对话在后 对话在前，指令在后 失败信号 显式错误消息 静默 fallback 部分压缩 独立 prompt，\u0026ldquo;前缀心态\u0026rdquo; 不支持 文件引用追踪 post-compaction 提醒重读 post-compaction 读 AGENTS.md 这里有一个值得停下来想的结构性观察：Claude Code 的 9 段格式不是\u0026quot;更聪明\u0026quot;，是\u0026quot;更不容易丢东西\u0026quot;。每一个设计决策——安全指令 verbatim、用户消息逐条列出、下一步引用原文——都在防御同一个风险：compaction 是信息损失的天然节点，prompt 的唯一职责是把这个损失降到最低。OpenClaw 在 compaction 上投入的 prompt engineering 明显不足——不是在模型能力上不够，是在\u0026quot;什么东西绝对不能丢\u0026quot;这个问题上没有做足够的防御性设计。\n这也回到了本文的核心论点：Outer Loop 的质量不取决于你用了多强的模型，取决于你写的 prompt 在极端情况下会不会漏东西。本事故中的 SAFETY_MARGIN = 1.2、SUMMARIZATION_OVERHEAD_TOKENS = 4096、\u0026lt;conversation\u0026gt; 在指令之前的排列——这些都不是模型的问题，是 prompt 没考虑溢出场景。而 Claude Code 的 prompt 即使溢出，至少也会留下错误修复记录、用户消息、原文引用——排障所需的上下文不会全部蒸发。\n总结：三个比踩坑更底层的判断 # 1. Outer Loop 是新的护城河，不是模型。 2025 年后，模型能力在快速趋同——Gemini 2.5 Pro 有 1M context、DeepSeek-V4 有 1M、GPT-5.5 有 200K。模型之间的差距在收敛，但 harness 质量（compaction safeguard、验证循环、降级路径、故障信号）的差距在拉大。本文的 compaction 事故就是证据——它不是\u0026quot;模型不够好\u0026quot;的问题，是 harness 少了一行配置。Claude Code 2026年1月 ARR 到 ~$2B，不是因为它用的 Claude 模型比别人聪明，是它的 outer loop 经过了百万级 Agent 的实战验证。\n2. 确定性优于概率性——在记忆、在路由、在故障处理。 OpenClaw 的 PPO 自适应权重和混合检索在论文上是对的，但当 compaction 静默失败时，用户不关心你的检索 recall 提高了多少。在系统边界上（compaction、fallback、错误处理），确定性规则（rule-based）比概率规则（RL-based）更安全。Claude Code 选\u0026quot;土\u0026quot;的分类法不是因为它不会做 PPO，是因为手工规则在\u0026quot;不丢东西\u0026quot;这件事上更可预期。\n3. 2025-2026 的行业趋势是 BYOK 和 harness 开源化。 大量用户从 Cursor 迁移到 Claude Code CLI、Aider、OpenCode——不是因为这些工具功能更多，是因为 BYOK（Bring Your Own Key）让你掌控 outer loop。SaaS 工具的 compaction 策略、缓存策略、重试策略全是黑盒，出问题你只能等厂商修。而 OpenClaw 的 openclaw.json 里每一行配置你都能看到、能改、能版本控制。这也是 OpenClaw 真正的长期价值——不是记忆系统多先进，而是 harness 完全透明。\n","date":"2026-05-27","externalUrl":null,"language":"zh","permalink":"/posts/openclaw-pitfalls/","section":"文章","summary":"从部署到排障，记录 OpenClaw 从启动失败、飞书消息静默吞回复到 production 稳定的全链路实战经验——compaction safeguard、五层排查法、model-harness-fit 与记忆系统对比。","title":"OpenClaw 生产踩坑：当最先进的记忆系统遇到最静默的失败","type":"posts"},{"content":"","date":"2026-05-27","externalUrl":null,"language":"zh","permalink":"/tags/%E9%A3%9E%E4%B9%A6/","section":"Tags","summary":"","title":"飞书","type":"tags"},{"content":"","date":"2026-05-27","externalUrl":null,"language":"zh","permalink":"/tags/%E6%8E%92%E9%9A%9C/","section":"Tags","summary":"","title":"排障","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"language":"zh","permalink":"/categories/agent-architecture/","section":"Categories","summary":"","title":"Agent Architecture","type":"categories"},{"content":"","date":"2026-05-16","externalUrl":null,"language":"zh","permalink":"/tags/agent-engineering/","section":"Tags","summary":"","title":"Agent Engineering","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"language":"zh","permalink":"/tags/agent-%E5%B7%A5%E7%A8%8B/","section":"Tags","summary":"","title":"Agent 工程","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"language":"zh","permalink":"/categories/agent-%E6%9E%B6%E6%9E%84/","section":"Categories","summary":"","title":"Agent 架构","type":"categories"},{"content":"","date":"2026-05-16","externalUrl":null,"language":"zh","permalink":"/tags/backend/","section":"Tags","summary":"","title":"Backend","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"language":"zh","permalink":"/tags/celery/","section":"Tags","summary":"","title":"Celery","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"language":"zh","permalink":"/tags/production/","section":"Tags","summary":"","title":"Production","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"language":"zh","permalink":"/tags/python/","section":"Tags","summary":"","title":"Python","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"language":"zh","permalink":"/tags/temporal/","section":"Tags","summary":"","title":"Temporal","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"language":"zh","permalink":"/tags/workflow-engine/","section":"Tags","summary":"","title":"Workflow Engine","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"language":"zh","permalink":"/tags/%E5%B7%A5%E4%BD%9C%E6%B5%81%E5%BC%95%E6%93%8E/","section":"Tags","summary":"","title":"工作流引擎","type":"tags"},{"content":"","date":"2026-05-16","externalUrl":null,"language":"zh","permalink":"/tags/%E5%90%8E%E7%AB%AF%E6%9E%B6%E6%9E%84/","section":"Tags","summary":"","title":"后端架构","type":"tags"},{"content":"2026 年 4 月，我们把 seo-project 的任务队列从 Celery 全面迁移到了 Temporal。删除的依赖只有一个（celery），新增的核心代码有 11 个文件（src/infrastructure/temporal/），容器从 api/worker/beat 变成了 api/temporal_worker_blue/green（蓝绿部署）。\n这件事做完后，最常被问到的问题是：为什么不用 Celery？已经能跑的东西换它干什么？\n这篇文章就是答案。它不来自文档对比，来自生产环境跑 Agent 流水线时逐条撞上的坑。\nCelery 能做的事，为什么在 Agent 场景里开始不够用 # 先说清楚一个基本判断：Celery 是好工具。对于\u0026quot;发封邮件、生成一张缩略图、推送一条通知\u0026quot;这类标准异步任务，它完全够用，工业界跑了十几年。\n但我们跑的负载和这不一样：\n1 2 3 4 5 6 一个 Run 包含 N 条 longtail 每条 longtail 跑 A → B → C → D 四个 Agent 阶段 每个阶段调一次或多次 AI API 总耗时任意一条都在 60-180 秒区间 每一步的中间结果需要持久化 任何一步失败需要知道\u0026#34;停在哪、为什么、能不能只重试这一步\u0026#34; 这是有状态的、长时的、多阶段的业务流程。任务队列和业务流程引擎之间的分界线，就在这里。\n第一条裂缝：任务状态只有\u0026quot;成功\u0026quot;和\u0026quot;失败\u0026quot; # Celery 的任务模型是：入队 → worker 拿到 → 执行 → 成功 or 失败。中间过程是一个黑盒。\n当 Agent D 在生成 SEO 元数据时超时了，Celery 告诉你的是：\u0026ldquo;task failed, state=FAILURE\u0026rdquo;。但你想知道的是：\nAgent A（关键词分析）成功了吗？结果是什么？ Agent B（大纲生成）跑完了吗？ Agent C（正文生成）生成的 HTML 落库了没有？ Agent D 是在调哪个模型时超时的？重试应该从 D 重跑，还是从 C 重跑？ 这些问题，Celery 的答案都是\u0026quot;你自己记\u0026quot;。你可以往 Redis/DB 里写状态，但你本质上是在任务队列上手工搭状态机——而这恰恰是 Temporal workflow 的原生能力。\nTemporal 的 workflow 代码就是你写的那段业务逻辑，每一步执行到哪、什么值、抛了什么异常，全部自动持久化。Worker 重启后 workflow 从断点继续，不需要任何额外代码。\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 # Celery 版本：你要自己管每一步的状态 @app.task(bind=True, max_retries=3) def run_pipeline(self, longtail_id): try: result_a = agent_a(longtail_id) # 如果这里成功 save_checkpoint(\u0026#34;step_a_done\u0026#34;, result_a) result_b = agent_b(result_a) # 这里失败 # 重试时你从哪开始？自己判断 checkpoint except Exception: self.retry() # Temporal 版本：workflow 代码就是状态机 @workflow.defn class PipelineWorkflow: @workflow.run async def run(self, longtail_id: str) -\u0026gt; dict: result_a = await workflow.execute_activity(agent_a, longtail_id) result_b = await workflow.execute_activity(agent_b, result_a) result_c = await workflow.execute_activity(agent_c, result_b) result_d = await workflow.execute_activity(agent_d, result_c) return result_d 注意 Temporal 版本里没有 checkpoint 管理代码。如果 agent_c 超时，重试直接从 agent_c 开始——agent_a 和 agent_b 的返回值已经持久化在 workflow history 里，不需要重新执行。\n第二条裂缝：整批回滚——\u0026ldquo;一条超时，八条陪葬\u0026rdquo; # 这是真正的生产事故。\n我们的 Agent 批量流水线是：一个 task 里循环跑 N 条 longtail，每条跑 A→B→C→D。历史代码把数据库 commit 放在循环外面：\n1 2 3 4 5 # 反模式：整批一个事务 async with unit_of_work(autocommit=False) as uow: for longtail in batch: await run_pipeline(longtail) await uow.commit() # 一次提交所有 问题来了：第 3 条的 Agent C 调 AI 超时 → SQLAlchemy session 进入 invalid 状态 → 第 4-8 条所有后续 get/save/commit 全部抛 PendingRollbackError → 整批 8 篇文章一个没落库。\n修复方案是把事务边界收缩到单条 longtail：每轮自己 commit，失败那轮也 commit 失败状态。配合 Temporal 后，这个模式变得更自然——每条 longtail 是一个独立的 workflow execution，Temporal 原生保证它的幂等性和可重放性。\nCelery 模型里，task 失败 = 整个 task 回滚 = 你要自己控制重试粒度。Temporal 模型里，一个 workflow 的失败不影响其他 workflow，每条 workflow 的 history 独立可查。运营看到的是 \u0026ldquo;1 failed / 7 succeeded\u0026rdquo; 而不是 \u0026ldquo;8 vanished\u0026rdquo;。\n第三条裂缝：长时任务与 Worker 重启 # Agent 流水线单条跑 60-180 秒是常态。Celery 的 worker 重启（部署、OOM、节点回收）会直接杀掉正在跑的任务，默认行为是 ack 后重新入队——从头开始跑。\n这对短任务（\u0026lt;5 秒）问题不大。对一条已经跑了 120 秒、AI token 已经烧了十几万、就差最后一步的 Agent 流水线来说，从头跑意味着前面的 token 成本全部白费。\nTemporal 的 durable execution 模型不同：即使 worker 重启，workflow 状态在 Temporal Server 中持久存在。新 worker 拿到 workflow history，从最后完成的步骤继续执行。这对于 AI 流水线的成本控制有直接意义。\n第四条裂缝：排障时看不到\u0026quot;发生了什么\u0026quot; # 生产上一条 Agent 流水线失败后，Celery 的排障路径是：\n找到 task ID 去 Flower（如果装了）看 task 状态 grep 应用日志里的 trace_id 手动拼出\u0026quot;A 生成了什么 → B 生成了什么 → C 卡在哪一步\u0026quot; 如果中间有重试，信息更乱 Temporal 的排障路径是：\n打开 Temporal Web UI 点进这个 workflow execution 每一步的输入、输出、耗时、异常信息全部可视化在一条时间线上 你可以直接看到\u0026quot;Agent C 的 generate_article activity 在第 47 秒超时，重试了 2 次，每次的 prompt 和返回的 HTML 片段都可以展开查看\u0026quot; 这不是\u0026quot;Temporal 有个好看的 UI\u0026quot;，而是调试效率的量级差异。对于多 Agent 流水线这种\u0026quot;调用链长、状态多、中间产物重要\u0026quot;的场景，可视化的 workflow history 是刚需，不是锦上添花。\n第五条裂缝：定时调度的可靠性 # Celery Beat 是一个独立进程，用 celery beat 启动。它的常见问题：\nBeat 挂了 → 定时任务停了，没有 failover Beat 重启 → 可能重复触发同一时间的任务 错过了调度窗口 → 不会自动补发，需要手工处理 schedule 变更 → 需要重启 Beat 我们在 Agent 项目中有一个需求：每天为每个站点生成一批文章。如果某天调度器宕机或错过窗口，需要自动检测缺失日期并补发。\nCelery 做这件事的方案是\u0026quot;写个脚本对比日期差，手动投递\u0026quot;。Temporal Schedule 原生支持：\nOverlap Policy: 上一个 workflow 还在跑时下一次触发怎么办 Catch-up Window: 错过了多久以内的窗口自动补发 Pause/Resume: 不需要改 cron 表达式，直接暂停调度 对于内容生产这类\u0026quot;错过一天就得补\u0026quot;的业务，Schedule 的补发语义是硬需求，不是 nice-to-have。\n选型对照表 # 维度 Celery Temporal Agent 场景谁赢 任务模型 无状态 task 有状态 workflow Temporal（Agent 流水线天然有状态） 中间状态持久化 自己实现（Redis/DB） 自动持久化 workflow history Temporal（零额外代码） 重试语义 task 级别重试，从头跑 activity 级别重试，断点续跑 Temporal（长时 AI 调用 token 成本差异大） 失败可视性 日志 grep + Flower Web UI 时间线 + 每步 I/O Temporal（排障效率量级差异） 定时调度 Beat 进程，无 failover Schedule，内置 catch-up Temporal（内容补发是硬需求） 批量任务失败半径 取决于你怎么写 commit 每条 workflow 天然隔离 Temporal（独立幂等单元） Worker 重启影响 正在跑的任务丢失，从头重试 workflow 从断点恢复 Temporal（120 秒的 AI 调用不白跑） 运维复杂度 Worker + Beat + Flower + Broker (Redis/RabbitMQ) Worker + Server (自带 Web UI) 相当（Temporal Server 需要独立部署，但省了 Flower 和 Beat 的运维） 学习曲线 低（Python 生态原生） 中（workflow/activity 确定性约束需要理解） Celery 胜（上手更快） 适用场景 短时、无状态、失败成本低 长时、有状态、中间产物重要、需要可审计 看任务性质 什么时候你不需要 Temporal # 不是说 Celery 就该被替换。如果你面对的是下面这些场景，Celery 仍然是最优解：\n任务耗时 \u0026lt;10 秒，失败从头跑成本可以忽略 不需要看到中间步骤的输入输出（比如发邮件） 不需要按步骤重试（整个任务成功或失败即可） 团队对 Temporal 的确定性约束不熟悉，短期无学习预算 现有 Celery 系统运行稳定，迁移收益 \u0026lt; 迁移成本 我们的决定不是\u0026quot;Temporal 比 Celery 好\u0026quot;，而是**\u0026ldquo;Agent 流水线的特征恰好卡在 Celery 的薄弱面和 Temporal 的核心能力之间\u0026rdquo;**。\n迁移后落地的架构模式 # 迁移到 Temporal 后，几个关键的架构决策也随之定型：\n1. 一条 longtail = 一个 workflow = 一个事务边界\n批量任务变成\u0026quot;外层投递 N 个 workflow，内层每个 workflow 独立管理自己的事务\u0026quot;。这是 concepts/backend 中\u0026quot;[数据库] 批量任务：per-iteration 事务边界\u0026quot;和 Temporal 的天然结合。\n2. Unit of Work 的两种语义\nFastAPI 路由用 autocommit=True（请求级短事务），Temporal worker 用 autocommit=False（workflow 级长事务，自己接管 commit/rollback 时机）。同一套 UoW 代码，不同的生命周期语义。\n3. 蓝绿部署\n容器从单实例 worker 变成 temporal_worker_blue + temporal_worker_green。发版时先切流量到新颜色，旧颜色等正在跑的 workflow 全部完成后再回收。这是 Temporal Task Queue 的 routing 能力带来的零停机部署。\n4. 幂等重放是免费的\n每条 workflow execution 的 history 存在 Temporal Server 里。出问题时，你可以用同一份 history 在本地重放整个 workflow——输入相同、路径相同、数据库操作被 mock 掉——来定位是哪个 activity 的哪次调用的哪个返回值导致了错误。这在 Celery 时代是好几个小时的体力活。\n总结 # 把 Temporal 当成\u0026quot;更强大的 Celery\u0026quot;是对两者的误解。它们解决的是不同层级的问题：\nCelery 解决的是\u0026quot;把一段代码放到另一台机器上跑\u0026quot; Temporal 解决的是\u0026quot;保证一段多步骤业务流程可靠地跑到终点，并让过程中的每一步都可审计\u0026quot; Agent 流水线恰好是一个多步骤、长耗时、中间产物重要、失败代价高的业务流程。用任务队列去模拟业务流程引擎，不是在用错工具——是用了正确工具的上一个版本，然后手工实现了正确工具已经内置的能力。\n这篇文章基于 seo-project 的生产实践。迁移记录见 LLM Wiki → log.md (2026-04-10) 及 concepts/backend.md。\n","date":"2026-05-16","externalUrl":null,"language":"zh","permalink":"/posts/why-temporal-not-celery/","section":"文章","summary":"2026 年 4 月，我们把 seo-project 的任务队列从 Celery 全面迁移到了 Temporal。删除的依赖只有一个（celery），新增的核心代码有 11 个文件（src/infrastructure/temporal/），容器从 api/worker/beat 变成了 api/temporal_worker_blue/green（蓝绿部署）。\n这件事做完后，最常被问到的问题是：为什么不用 Celery？已经能跑的东西换它干什么？\n这篇文章就是答案。它不来自文档对比，来自生产环境跑 Agent 流水线时逐条撞上的坑。\nCelery 能做的事，为什么在 Agent 场景里开始不够用 # 先说清楚一个基本判断：Celery 是好工具。对于\"发封邮件、生成一张缩略图、推送一条通知\"这类标准异步任务，它完全够用，工业界跑了十几年。\n但我们跑的负载和这不一样：\n1 2 3 4 5 6 一个 Run 包含 N 条 longtail 每条 longtail 跑 A → B → C → D 四个 Agent 阶段 每个阶段调一次或多次 AI API 总耗时任意一条都在 60-180 秒区间 每一步的中间结果需要持久化 任何一步失败需要知道\"停在哪、为什么、能不能只重试这一步\" 这是有状态的、长时的、多阶段的业务流程。任务队列和业务流程引擎之间的分界线，就在这里。\n","title":"生产环境 Agent 实践：为什么我们从 Celery 迁移到 Temporal","type":"posts"},{"content":"","date":"2026-05-16","externalUrl":null,"language":"zh","permalink":"/tags/%E7%94%9F%E4%BA%A7%E5%AE%9E%E8%B7%B5/","section":"Tags","summary":"","title":"生产实践","type":"tags"},{"content":" 信息收集 # 本博客为静态网站，不主动收集任何个人身份信息。不设评论系统、不设用户注册、不设 Cookie 追踪。\n托管与 CDN # 网站通过以下服务托管和加速：\nCloudflare Pages（国际访客）：可能记录访问日志用于安全防护 阿里云 OSS + CDN（国内访客）：可能记录访问日志 这些日志由平台自动生成，本站不进行二次处理。\n第三方服务 # 本站目前未启用任何第三方分析工具（如 Google Analytics、百度统计、Umami）。若未来启用，将更新本隐私政策并告知访客。\n外部链接 # 文章中含有指向外部网站的链接（如 GitHub、arXiv、Cloudflare 文档等）。本站对这些第三方网站的隐私政策不负责任，点击外部链接前请自行了解其隐私政策。\nCookie # 本站不主动设置任何 Cookie。CDN 服务商可能设置必要的技术 Cookie（如 Cloudflare 的 __cf_bm），用于安全防护。\n联系方式 # 如有隐私相关问题，请通过以下方式联系：\nGitHub: @YouToco Email: 见 GitHub profile 政策更新 # 本隐私政策可能不定期更新，更新后将在本站发布。最后更新日期：2026-05-16。\n","date":"2026-05-16","externalUrl":null,"language":"zh","permalink":"/privacy/","section":"卓琪的开发笔记","summary":"信息收集 # 本博客为静态网站，不主动收集任何个人身份信息。不设评论系统、不设用户注册、不设 Cookie 追踪。\n托管与 CDN # 网站通过以下服务托管和加速：\nCloudflare Pages（国际访客）：可能记录访问日志用于安全防护 阿里云 OSS + CDN（国内访客）：可能记录访问日志 这些日志由平台自动生成，本站不进行二次处理。\n第三方服务 # 本站目前未启用任何第三方分析工具（如 Google Analytics、百度统计、Umami）。若未来启用，将更新本隐私政策并告知访客。\n外部链接 # 文章中含有指向外部网站的链接（如 GitHub、arXiv、Cloudflare 文档等）。本站对这些第三方网站的隐私政策不负责任，点击外部链接前请自行了解其隐私政策。\n","title":"隐私政策","type":"page"},{"content":"","date":"2026-05-14","externalUrl":null,"language":"zh","permalink":"/tags/chatgpt/","section":"Tags","summary":"","title":"ChatGPT","type":"tags"},{"content":"2026 年 5 月，中文 AI 圈被一波 ChatGPT Business 优惠刷屏了。英国区 2 席位月付 £11、美国区 $20、澳洲区 AU$25，最长持续 48 个月。codestonegb、thealloynetwork、firstfocus 这些神秘代码在 V2EX、linux.do、各大博客之间疯狂扩散。\n但一个关键问题没人回答：这些码到底从哪来的？\n我花了几天做了多源溯源调查。结论比\u0026quot;L 站首发\u0026quot;复杂得多。\n优惠码不是 OpenAI 公开发布的 # 先把最重要的事实摆出来：OpenAI 官方从未在任何公开渠道发布过这些优惠码。\n查遍 OpenAI 官方信息出口：\nopenai.com/index/（官方博客）——只发产品发布公告，从不写 Promo Code help.openai.com（帮助中心）——有促销机制的通用 FAQ，但从不列出具体码 openai.com/pricing（定价页）——标准价格，无优惠入口 官方 X 账号 @OpenAI——没有相关推文 OpenAI 的促销分发机制在官方文档里写得很清楚：通过电子邮件定向发给\u0026quot;符合资格的用户\u0026quot;，或在产品内弹窗触发。 资格由 OpenAI 决定，不是所有人可见。\n那这些码怎么泄露出来的？\n真正源头：Stripe 合作伙伴网络 # OpenAI 从 2023 年起使用 Stripe Billing + Stripe Checkout 处理 ChatGPT 付费订阅。这套系统支持 Promo Code 机制——Stripe 允许为特定合作伙伴生成专属优惠码，通过 URL 参数 ?promoCode=XXX 传递给支付网关。\n每个码背后都是一家 Stripe 合作企业：\n优惠码 区 关联企业 codestonegb 英国 CodeStone (IT 服务商) thealloynetwork 美国 The Alloy Network firstfocus 澳 First Focus IT THINKTECHNOLOGIESUS 美国 Think Technologies monicaius 美国 Monica AI datroaiuk 英国 Datro AI geccogb 英国 GECC 这些企业通过 Stripe 拿到专属码后，本应内部使用。但总有人会\u0026quot;手抖\u0026quot;——某个员工把链接发到了公开社区，然后就像野火一样扩散。\n所以真正的源头是 Stripe 企业合作伙伴的员工，而不是任何一个社区。\n各码的实际首现渠道 # 追踪每个码的最早出现时间戳，发现不存在单一源头：\n优惠码 最早时间 首发渠道 alongsideus / monicaius 5月1日 邮莓生活 (mailberry.com.cn) THINKTECHNOLOGIESUS 5月8日 linux.do（topic/2092962，现已不可访问） codestonegb 5月9日 X + linux.do 同步出现 firstfocus 5月10日 OzBargain (澳洲 deal 社区) thealloynetwork 5月10日 linux.do 福利羊毛版块 datroaiuk 5月12日 数字居民论坛 (shuzijumin.com) geccogb 5月10日 OzBargain 5 月 8 日是真正的首发节点。 通过浏览器直接访问 linux.do 交叉验证，最早记载 THINKTECHNOLOGIESUS 的帖子是 topic/2092962，标题为\u0026quot;[5/8 US新优惠,20刀！！！] ChatGPT Team/Business 买一送一持续48个月！\u0026quot;，发在福利羊毛板块。该帖现已不可访问（被删除或设为私有），但在 topic/2141860（5月9日由 leon8 发布）的第16楼，用户 cyfer 的回复中保留了原文引用。5 月 9 日凌晨是信息大规模扩散的引爆点——钛刻科技教程记录当时\u0026quot;在 X 和 L 站都看到了\u0026quot;，说明 X (Twitter) 与 L 站的转帖几乎同步出现。\n也就是说：\nlinux.do 是中文圈核心集散地，且在本次事件中确认是 THINKTECHNOLOGIESUS 的最早公开来源（5月8日，早于 X） X (Twitter) 上的日语/英语博主在 5 月 9 日凌晨与 L 站转帖基本同步扩散 OzBargain 是澳洲/英国区码的首发渠道 数字居民论坛 偶尔爆冷门新码 时间线：各码泄露的精确节奏 # gantt title ChatGPT Business 优惠码泄露时间线 dateFormat YYYY-MM-DD axisFormat %m-%d tickInterval 2day section 前奏期 Team免费试用接口关闭 :done, crit, a1, 2026-04-28, 1d 80aj转载2月免费版 :done, a2, 2026-04-30, 1d section 第一批码 alongsideus / monicaius :active, b1, 2026-05-01, 1d 码(邮莓生活首发) : b1a, 2026-05-01, 1d section 爆发期 THINKTECHNOLOGIESUS(L站首发):done, crit, c0, 2026-05-08, 1d codestonegb (X+L站同时) :done, crit, c2, 2026-05-09, 1d X+L站大规模扩散 :done, crit, c1, 2026-05-09, 1d section 扩散期 firstfocus (OzBargain首发) :done, d1, 2026-05-10, 1d thealloynetwork (L站首发) :done, d2, 2026-05-10, 1d geccogb (OzBargain) :done, d3, 2026-05-10, 1d xwuxl.com教程发布 :done, d4, 2026-05-10, 1d section 长尾期 L站价格对比帖 :done, e1, 2026-05-11, 1d V2EX大规模扩散 :done, e2, 2026-05-11, 1d datroaiuk (数字居民论坛) :done, e3, 2026-05-12, 1d 4月28日 GPT Team 免费试用接口被关 → 4月30日 中文圈开始注意到 US IP 2月免费版 → 5月1日 第一批 Stripe 企业码流出 → 5月8日 THINKTECHNOLOGIESUS 在 linux.do 首发 → 5月9日凌晨 X+L站大规模扩散引爆 → 5月10-12日 各区域码密集出现。\n完整传播链路 # flowchart TD A[\"🏢 Stripe 企业合作伙伴（码的真正诞生点）\"] A --\u003e B[\"💬 企业员工泄露TG / Discord 私聊\"] A --\u003e C[\"🐦 X (Twitter)日英博主分享\"] A --\u003e D[\"🦘 OzBargain澳洲 deal 社区\"] B --\u003e E[\"🐧 linux.do中文圈信息集散地\"] C --\u003e E D --\u003e E E --\u003e F[\"📰 80aj.com / Toy4.30 首发2月免费版\"] E --\u003e G[\"🌐 V2EX5.11 大规模传播\"] E --\u003e H[\"📝 博客转载xwuxl.com / mailberry\"] F --\u003e I[\"📱 B站 / 知乎 / 公众号5.11-12 末梢扩散\"] G --\u003e I H --\u003e I style A fill:#c44020,stroke:#a03018,color:#fff style E fill:#2563eb,stroke:#1d4ed8,color:#fff style I fill:#6b7280,stroke:#4b5563,color:#fff 关键特征：不是链式传播，而是多源并行泄露。\n各区域实际到手价对比 # 同一套餐（2 席位月付），不同区域码的到手价差异可达 40%：\n区域 原价 (2席位) 优惠后 折合 CNY 优惠幅度 英国 £36 £11 ~¥102 减 £25 (69%) 澳洲 AU$70 AU$25 ~¥120 减 AU$45 (64%) 美国 US$50 US$20 ~¥145 减 US$30 (60%) 英国区码到手价最低，比美区便宜约 30%。但需要英国 IP + 对应码。\n为什么 linux.do 被误认为源头 # L 站整理和归纳能力最强——散落在各平台的零碎信息被集中到一个帖子里，附带 Console 脚本和支付教程 80aj.com 等博客在转载时明确写了\u0026quot;据 linux.do 用户爆料\u0026quot;，强化了\u0026quot;L 站是源头\u0026quot;的印象 L 站的时效性标签很清晰，发布时间戳容易追溯，而 X 上的碎片信息容易淹没 中文用户的信息获取路径天然以 L 站为中心 但实际调查发现更复杂的图景：美国码 THINKTECHNOLOGIESUS 确认是 L 站首发（5月8日 topic/2092962），早于 X 上的大规模扩散（5月9日凌晨）。但澳洲区码首发在 OzBargain，部分英国码首发在数字居民论坛和 X。 没有\u0026quot;唯一源头\u0026quot;，但 L 站在本次事件中的首发地位比此前认知的更强。\n想第一时间追到这类优惠，该蹲哪里 # 按优先级排序：\n优先级 渠道 擅长方向 备注 P0 linux.do 福利羊毛 全球码汇总 + 脚本 本次 THINKTECHNOLOGIESUS 确认首发，但需登录才能访问该板块 P0 X (Twitter) 日/英/美区新码 搜 ChatGPT promo code，与泄露几乎同步，无需登录 P0 L 站 Telegram 频道 热门帖推送 t.me/linux_do_channel，比刷论坛更即时 P0 OzBargain 澳洲/英国区码 ozbargain.com.au 搜 ChatGPT P1 数字居民论坛 偶尔有冷门码 shuzijumin.com P1 TG / Discord 私群 Stripe 企业员工泄露第一落点 不可控，靠人脉 P2 V2EX 中文扩散 比 L 站慢半天到一天 P3 各类博客 教程整理 系统但时效性最差 一句话：多平台同时蹲，不要押注单一信息源。\n这波活动到底什么时候结束的 # THINKTECHNOLOGIESUS 的生命周期短得离谱：5 月 8 日首发，5 月 9 日封车，前后不到 48 小时。 5 月 9 日当天就有 L 站用户发帖「4年team活動剛開始但是好像剛結束了」——不管是资格号还是普通号，都显示\u0026quot;无法使用此优惠\u0026quot;。\n到 5 月 14 日，L 站还有人在问「team优惠码没了吗？」——确认全线拉闸。有用户形容这是**\u0026ldquo;4小时快闪活动\u0026rdquo;，虽然有点夸张，但确实反映了一个事实：每一个 Stripe 合作伙伴码都有固定配额**，名额抢完了就关，跟到期日无关。\n其他区域码也差不多：\n英国区 codestonegb / datroaiuk：比美国码多撑了两三天，随后也陆续提示\u0026quot;无法使用\u0026quot; 澳洲区 firstfocus：同理，配额耗尽即停 后续还有没有：L 站用户的共识是\u0026quot;肯定还会有，48 一样的\u0026quot;——OpenAI 的 SMB 合作计划还在跑，新的合作伙伴码随时可能冒出来 规律很清楚：不是按时间到期，是按配额关门。 所以蹲到了就立刻下手，别想着\u0026quot;先收藏回头再搞\u0026quot;。\n更高维度的认知 # 这波 ChatGPT Business 优惠的本质是：\nOpenAI 通过 Stripe Partner Network 对 B 端客户进行定向补贴，用 B 端渠道间接获客。 这不是面向消费者的促销，而是企业级销售的副产品。每个码都是真金白银的企业合作成本，所以随时可能被收回——没有公告，没有预警。\n理解这一点，你就不会把这类优惠当成\u0026quot;可以一直薅的羊毛\u0026quot;，而是精准狙击，快速上车，及时下车。\n信息截止 2026-05-14，多源交叉验证。\n","date":"2026-05-14","externalUrl":null,"language":"zh","permalink":"/posts/chatgpt-business-promo-investigation/","section":"文章","summary":"2026 年 5 月，中文 AI 圈被一波 ChatGPT Business 优惠刷屏了。英国区 2 席位月付 £11、美国区 $20、澳洲区 AU$25，最长持续 48 个月。codestonegb、thealloynetwork、firstfocus 这些神秘代码在 V2EX、linux.do、各大博客之间疯狂扩散。\n但一个关键问题没人回答：这些码到底从哪来的？\n我花了几天做了多源溯源调查。结论比\"L 站首发\"复杂得多。\n优惠码不是 OpenAI 公开发布的 # 先把最重要的事实摆出来：OpenAI 官方从未在任何公开渠道发布过这些优惠码。\n查遍 OpenAI 官方信息出口：\nopenai.com/index/（官方博客）——只发产品发布公告，从不写 Promo Code help.openai.com（帮助中心）——有促销机制的通用 FAQ，但从不列出具体码 openai.com/pricing（定价页）——标准价格，无优惠入口 官方 X 账号 @OpenAI——没有相关推文 OpenAI 的促销分发机制在官方文档里写得很清楚：通过电子邮件定向发给\"符合资格的用户\"，或在产品内弹窗触发。 资格由 OpenAI 决定，不是所有人可见。\n那这些码怎么泄露出来的？\n真正源头：Stripe 合作伙伴网络 # OpenAI 从 2023 年起使用 Stripe Billing + Stripe Checkout 处理 ChatGPT 付费订阅。这套系统支持 Promo Code 机制——Stripe 允许为特定合作伙伴生成专属优惠码，通过 URL 参数 ?promoCode=XXX 传递给支付网关。\n","title":"ChatGPT Business 48 个月优惠的源头究竟在哪——一次羊毛溯源调查","type":"posts"},{"content":"","date":"2026-05-14","externalUrl":null,"language":"zh","permalink":"/categories/investigation/","section":"Categories","summary":"","title":"Investigation","type":"categories"},{"content":"","date":"2026-05-14","externalUrl":null,"language":"zh","permalink":"/tags/openai/","section":"Tags","summary":"","title":"OpenAI","type":"tags"},{"content":"","date":"2026-05-14","externalUrl":null,"language":"zh","permalink":"/tags/osint/","section":"Tags","summary":"","title":"OSINT","type":"tags"},{"content":"","date":"2026-05-14","externalUrl":null,"language":"zh","permalink":"/tags/promo-codes/","section":"Tags","summary":"","title":"Promo Codes","type":"tags"},{"content":"","date":"2026-05-14","externalUrl":null,"language":"zh","permalink":"/tags/reverse-engineering/","section":"Tags","summary":"","title":"Reverse Engineering","type":"tags"},{"content":"","date":"2026-05-14","externalUrl":null,"language":"zh","permalink":"/tags/stripe/","section":"Tags","summary":"","title":"Stripe","type":"tags"},{"content":"","date":"2026-05-14","externalUrl":null,"language":"zh","permalink":"/categories/%E8%B0%83%E6%9F%A5/","section":"Categories","summary":"","title":"调查","type":"categories"},{"content":"","date":"2026-05-14","externalUrl":null,"language":"zh","permalink":"/tags/%E4%BF%A1%E6%81%AF%E6%BA%AF%E6%BA%90/","section":"Tags","summary":"","title":"信息溯源","type":"tags"},{"content":"","date":"2026-05-14","externalUrl":null,"language":"zh","permalink":"/tags/%E4%BC%98%E6%83%A0%E7%A0%81/","section":"Tags","summary":"","title":"优惠码","type":"tags"},{"content":"","date":"2026-05-11","externalUrl":null,"language":"zh","permalink":"/tags/memory/","section":"Tags","summary":"","title":"Memory","type":"tags"},{"content":"","date":"2026-05-11","externalUrl":null,"language":"zh","permalink":"/tags/rag/","section":"Tags","summary":"","title":"RAG","type":"tags"},{"content":"做 Agent 系统的人迟早会撞上这个选择题：用户的数据往哪放，下次对话怎么记住？\n目前工业界有三条主流路线——RAG（向量检索）、LLM Wiki（结构化知识注入）、纯文本上下文记忆（CLAUDE.md / Cursor Rules 模式）。三条路各有拥趸，但选错的代价很大：RAG 做轻了是噪音生成器，纯文本做重了是 token 焚化炉。\n这篇给出一个可以直接用的决策框架。\n三种方案一句话定义 # 方案 核心机制 代表产品/模式 RAG 向量检索 → top-k 片段 → 拼入 prompt Mem0, Zep, LangChain RAG, Cursor Codebase Index LLM Wiki 结构化文档 → 全量或按需注入 system prompt Claude Projects, GPTs Knowledge, Notion AI 纯文本上下文 Markdown/文本文件 → 直接拼入 system prompt CLAUDE.md, Cursor Rules, AGENTS.md, Devin Knowledge 关键区别不在于\u0026quot;存哪里\u0026quot;，而在于检索方式和注入时机。\n决策矩阵 # 维度 RAG LLM Wiki 纯文本上下文 数据量 大（\u0026gt;100 篇文档） 中（10–100 篇） 小（\u0026lt;10 个文件，\u0026lt;200 行） 更新频率 高频，实时或近实时 中频，周/天级 低频，项目级约定 检索精度要求 需要语义匹配（\u0026ldquo;找和这个问题最相关的段落\u0026rdquo;） 需要结构化浏览（\u0026ldquo;看第三章第四节\u0026rdquo;） 不需要检索，全量加载 延迟 +50–500ms（embedding + 检索 + 重排） 0（预加载） 或 +100ms（按需 fetch） 0（全量在 prompt 里） token 成本 低（只注入相关片段） 中（按章节注入） 高（全量每次塞入） 可维护性 低（chunk 策略、embedding 模型、检索参数都要调） 中（文档结构需维护） 高（就是 Markdown，改一下 commit 就行） 可解释性 低（\u0026ldquo;为什么检索到这段？\u0026ldquo;难以回答） 高（\u0026ldquo;因为你看了第三章\u0026rdquo;） 最高（全部可见） 幻觉风险 高（检索噪音 → 错误上下文 → 幻觉） 低 低 适合场景 客服知识库、代码库搜索、大规模文档 QA 项目文档、产品手册、合规知识库 项目约定、编码规范、个人偏好 什么时候选 RAG # RAG 不是银弹。只有当数据量超过 prompt 容量上限时才值得上 RAG。 如果你只有 20 篇文档，直接全塞进去都比 RAG 好——因为检索噪音引入的错误比省下的 token 钱贵得多。\nRAG 的正确使用场景：\n文档量 \u0026gt;100 篇，且用户每次只关心其中 1-3 篇 需要语义匹配而非关键词匹配（\u0026ldquo;报错了\u0026quot;要能匹配到 \u0026ldquo;error log\u0026rdquo;） 数据实时更新（比如接入了实时数据库） 你可以接受偶尔检索到不相关的内容 RAG 的常见翻车姿势：\n把 10 篇文档建了个向量库——杀鸡用牛刀，检索噪音 \u0026gt; 信息增益 Chunk size 乱设——太小丢上下文，太大检索不准 不看重排（rerank）——top-k 里混入无关片段，模型被带偏 Embedding 模型和生成模型不匹配——用 OpenAI embedding 但用 Claude 生成，语义空间不一致 有一条经验法则：先试着把所有相关内容直接塞进 prompt。如果塞不下，再上 RAG。 这个顺序不能反过来——RAG 是不得已的选择，不是默认选择。\n什么时候选 LLM Wiki # LLM Wiki 指的是结构化的、可供模型按需检索或全量加载的知识库。它不像 RAG 那样靠向量相似度，也不像纯文本那样全量堆进去——它是\u0026quot;有目录的文档\u0026rdquo;。\n适合 LLM Wiki 的场景：\n知识有清晰的层级结构（产品手册、API 文档、合规条例） 用户需要\u0026quot;翻到某一节\u0026quot;而不是\u0026quot;搜一个片段\u0026rdquo; 需要人工审核和版本管理（合规场景尤其重要） Claude Projects 里的 Project Knowledge 就是典型的 LLM Wiki——你把文档传进去，模型在需要时引用。GPTs 的 Knowledge 功能同理。\nLLM Wiki vs RAG 的本质区别：\nRAG 是\u0026quot;我猜你想看这几段\u0026rdquo;，LLM Wiki 是\u0026quot;这是目录，你要看哪一章\u0026quot;。前者靠语义相似度，后者靠结构导航。前者可能猜错，后者不会——但后者要求用户或 Agent 知道该看哪一章。\n什么时候选纯文本上下文记忆 # 这就是 CLAUDE.md / Cursor Rules / AGENTS.md 模式。一个 Markdown 文件，每次对话全量注入 system prompt。听起来很笨，但在正确场景下是最优解。\n为什么这个\u0026quot;笨办法\u0026quot;反而是最好的：\n可审计——每次改了啥，git diff 一目了然 可版本管理——记忆有了 git history，你可以回到三天前的状态 零延迟——不需要 embedding，不需要检索，直接拼进 prompt 零噪音——你写的每个字都在 prompt 里，不存在\u0026quot;检索到错误段落\u0026quot; 不容易被 prompt injection——内容是人工写的，不是 AI 自动生成的 Cursor 1.2 给 Memories 加 user approval、Devin Knowledge 默认走 suggestion——都是被 prompt injection 教训之后的设计共识。纯文本记忆不需要\u0026quot;信任 AI 自己记的东西\u0026quot;，因为每一条都是人写的。\n适合纯文本记忆的场景：\n项目级约定（\u0026ldquo;我们用的 Java 17，Spring Boot 3.x\u0026rdquo;） 编码规范（\u0026ldquo;不要用 Lombok，用 record\u0026rdquo;） 个人偏好（\u0026ldquo;回答用中文，代码注释用英文\u0026rdquo;） Agent 行为约束（\u0026ldquo;调用工具前先确认\u0026rdquo;） 不适合的场景：\n数据量超过约 200 行——占用太多 context window，挤压真正有用的 token 需要动态更新的知识——每次改都要手动编辑文件 多项目共享的知识——容易拷贝粘贴导致不一致 实战决策树 # 1 2 3 4 5 6 7 8 9 10 11 12 13 你的知识数据有多大？ ├── \u0026lt;10 个 Markdown 文件，总计 \u0026lt;200 行 │ └── 纯文本上下文（CLAUDE.md / Cursor Rules） │ 优势：零延迟、可 git、零噪音 │ ├── 10–100 篇文档，有清晰结构 │ └── LLM Wiki（Claude Projects / GPTs Knowledge） │ 优势：结构化导航、按需加载、人工可审核 │ └── \u0026gt;100 篇文档，或需要语义搜索 └── RAG（Mem0 / Zep / 自建向量库） 前提：你已经验证过\u0026#34;全量塞 prompt\u0026#34;真的塞不下 提醒：RAG 的维护成本是另外两种方案的 10 倍 一个常见的错误组合 # 很多团队一上来就同时用了三种：\n1 2 3 CLAUDE.md（纯文本） + 向量库 RAG（一堆文档） + Wiki 知识库（产品文档） 三套系统同时往 prompt 里塞东西。结果：\nToken 成本爆炸 信息互相矛盾（纯文本说用 Go，Wiki 里的旧文档说用 Python） 排查问题变成\u0026quot;到底是哪段上下文导致的？\u0026quot; 正确做法：选一种作为主记忆层，另外两种仅在必要时补充。 大多数个人开发者和 10 人以下团队，纯文本 + 一个 LLM Wiki 就够了。RAG 是规模化之后的事。\n和 LLM 记忆调研的关系 # 这篇文章是 大模型为什么没有记忆 调研的工程落地篇。调研里讲的四层栈（裸 LLM → 架构内记忆 → 长上下文 → Agent 记忆层），本文聚焦在 L4 Agent 记忆层的选型。\n调研中 Karpathy 的类比这里再引用一次，因为太好用了：\n权重 = ROM（训练时烧入，静态） Context Window = RAM（推理时直接寻址） KV Cache = Working Memory（test-time 形成） 外部存储 = Disk（持久但需要 retrieve）\n你选的方案决定了 Agent 的\u0026quot;硬盘\u0026quot;长什么样——是高速 SSD（纯文本）、按需挂载的文件系统（LLM Wiki）、还是带搜索引擎的数据库（RAG）。\n总结 # 如果你\u0026hellip; 选这个 数据少、变更低频、需要可审计 纯文本上下文 数据有清晰结构、需要按章节引用 LLM Wiki 数据多、需要语义搜索、能接受检索噪音 RAG 没有银弹。但有一个铁律：能不用 RAG 就不用 RAG——等你真的需要它的时候，你会知道的。\n","date":"2026-05-11","externalUrl":null,"language":"zh","permalink":"/posts/memory-choice-framework/","section":"文章","summary":"做 Agent 系统的人迟早会撞上这个选择题：用户的数据往哪放，下次对话怎么记住？\n目前工业界有三条主流路线——RAG（向量检索）、LLM Wiki（结构化知识注入）、纯文本上下文记忆（CLAUDE.md / Cursor Rules 模式）。三条路各有拥趸，但选错的代价很大：RAG 做轻了是噪音生成器，纯文本做重了是 token 焚化炉。\n这篇给出一个可以直接用的决策框架。\n三种方案一句话定义 # 方案 核心机制 代表产品/模式 RAG 向量检索 → top-k 片段 → 拼入 prompt Mem0, Zep, LangChain RAG, Cursor Codebase Index LLM Wiki 结构化文档 → 全量或按需注入 system prompt Claude Projects, GPTs Knowledge, Notion AI 纯文本上下文 Markdown/文本文件 → 直接拼入 system prompt CLAUDE.md, Cursor Rules, AGENTS.md, Devin Knowledge 关键区别不在于\"存哪里\"，而在于检索方式和注入时机。\n","title":"什么时候用 RAG，什么时候用 LLM Wiki，什么时候用纯文本记忆——一个 Agent 记忆选型框架","type":"posts"},{"content":"","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/tags/alibaba-cloud/","section":"Tags","summary":"","title":"Alibaba Cloud","type":"tags"},{"content":"","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/tags/animation/","section":"Tags","summary":"","title":"Animation","type":"tags"},{"content":"","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/tags/cdn/","section":"Tags","summary":"","title":"CDN","type":"tags"},{"content":"","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/tags/cloudflare/","section":"Tags","summary":"","title":"Cloudflare","type":"tags"},{"content":"","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/tags/css/","section":"Tags","summary":"","title":"CSS","type":"tags"},{"content":"","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/categories/dev-log/","section":"Categories","summary":"","title":"Dev Log","type":"categories"},{"content":"","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/tags/hugo/","section":"Tags","summary":"","title":"Hugo","type":"tags"},{"content":"","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/tags/icp-filing/","section":"Tags","summary":"","title":"ICP Filing","type":"tags"},{"content":"","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/tags/icp%E5%A4%87%E6%A1%88/","section":"Tags","summary":"","title":"ICP备案","type":"tags"},{"content":"","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/tags/llm/","section":"Tags","summary":"","title":"LLM","type":"tags"},{"content":"","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/categories/research/","section":"Categories","summary":"","title":"Research","type":"categories"},{"content":"","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/tags/research/","section":"Tags","summary":"","title":"Research","type":"tags"},{"content":"","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/tags/shortcode/","section":"Tags","summary":"","title":"Shortcode","type":"tags"},{"content":"","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/tags/%E9%98%BF%E9%87%8C%E4%BA%91/","section":"Tags","summary":"","title":"阿里云","type":"tags"},{"content":"这不是一篇\u0026quot;AI 科普\u0026quot;——这是一次用 Exa / Tavily / Context7 / WebSearch 四源交叉验证，覆盖 67 条一手资料 的硬核调研。如果你在给 Agent 系统设计记忆层，或者想搞清楚 ChatGPT Memory / Claude Memory / Cursor Rules 到底是怎么回事，这篇是你要看的东西。\n→ 完整报告（含 14 产品对比表、9 条工程结论、3 年范式演进地图）\n一句话结论 # 所谓「大模型没有记忆」不是疏忽，而是 O(n²) 注意力 + KV Cache 显存 + 灾难性遗忘 + GDPR 合规 四重约束的均衡解。ChatGPT / Claude / Cursor 的 \u0026ldquo;Memory\u0026rdquo; 本质都是把结构化文本 塞回 system prompt，模型权重永远不动。未来 1–3 年的主流是 「无状态 LLM 内核 + 有状态 Agent 记忆层」 混合架构。\n为什么这个问题值得花 67 条资料去研究 # 因为每个做 Agent 的人都会撞到这堵墙：\n为什么我让 AI 记住用户偏好，它过 10 轮就忘了？ 为什么 Prompt Caching 不能替代 Memory？ 为什么所有产品都说有\u0026quot;记忆\u0026quot;，但没有一个改模型权重？ Mem0、Zep、Letta、LangGraph Store——到底选哪个？ 这些问题在 Anthropic/OpenAI/Google 的官方文档、Karpathy 的公开访谈、以及 arXiv 论文里都有答案——但分散在 67 个不同的地方。这篇调研把它们串起来了。\n4 层记忆栈 # 自下而上：\nL1 · 裸 LLM（冻结权重）：永远无状态，每次推理是新进程 L2 · 架构内记忆：Titans / Infini-attention / Mamba-2，最具研究价值，但尚未规模化验证（需 ≥70B / ≥10T token） L3 · 超长上下文：Gemini 2M、Magic 100M，会话内关联的最佳载体，但 O(n²) 天花板仍在 L4 · Agent 记忆层：外部数据库 + Agent Runtime，商业最成熟，Mem0 / Zep / Letta / LangGraph Store → 完整四层栈分析 + 14 产品对比表\n最适合工程团队的 3 条结论 # 不要把 Cache 和 Memory 混为一谈——Cache 跳过 prefill（省钱），Memory 决定 prompt 内容（涨能力），完全正交 写 Memory 就是写 System Prompt——markdown 文件（CLAUDE.md / Cursor Rules）永远比\u0026quot;让 AI 自己记\u0026quot;更可控、可 diff、可版本管理 AI 写 + 人审批 = 当前最稳的自动 Memory 形态——Cursor 1.2 加 user approval、Devin 默认走 suggestion 流，是被反复 prompt injection 教训后的共识 → 查看完整报告：包含 Karpathy 权威访谈原文、记忆经济学分析、9 条工程实用结论、3 年范式演进地图\n","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/posts/llm-memory-research/","section":"文章","summary":"这不是一篇\"AI 科普\"——这是一次用 Exa / Tavily / Context7 / WebSearch 四源交叉验证，覆盖 67 条一手资料 的硬核调研。如果你在给 Agent 系统设计记忆层，或者想搞清楚 ChatGPT Memory / Claude Memory / Cursor Rules 到底是怎么回事，这篇是你要看的东西。\n→ 完整报告（含 14 产品对比表、9 条工程结论、3 年范式演进地图）\n一句话结论 # 所谓「大模型没有记忆」不是疏忽，而是 O(n²) 注意力 + KV Cache 显存 + 灾难性遗忘 + GDPR 合规 四重约束的均衡解。ChatGPT / Claude / Cursor 的 “Memory” 本质都是把结构化文本 塞回 system prompt，模型权重永远不动。未来 1–3 年的主流是 「无状态 LLM 内核 + 有状态 Agent 记忆层」 混合架构。\n","title":"大模型为什么没有记忆——67 条一手资料的交叉验证","type":"posts"},{"content":" 一句话结论 # 所谓「大模型没有记忆」不是疏忽，而是 Transformer O(n²) 注意力 + KV cache 显存 + 权重纠缠（灾难性遗忘）+ GDPR 合规 四重约束的均衡解。ChatGPT / Claude / Cursor 的 \u0026ldquo;Memory\u0026rdquo; 本质都是把结构化文本塞回 system prompt，模型权重永远不动。Prompt Caching 只是性能优化，不是记忆。未来 1–3 年的主流是 「无状态 LLM 内核 + 有状态 Agent 记忆层」 混合架构。\n计算复杂度 100M ctx 成本 Cache 价格 主流 TTL O(n²) 638×H100 0.1× 5min–24h 1. 为什么 LLM 被设计成无状态 # 四个独立约束叠加，每一个单独都不致命，叠在一起就只剩\u0026quot;无状态\u0026quot;这一种工程解——这个结论来自对 67 条一手资料的交叉验证。\n架构约束 · O(n²) 注意力 # 自注意力关于序列长度 n 的计算复杂度是 O(n²)，KV cache 显存随 n 线性增长但系数巨大——4096 token 单序列就要约 2 GB 显存，32 并发就 64 GB，比模型权重本身还大。Llama 3.1 在 100M token 上下文中，仅 KV cache 就需要 638 块 H100（约 ¥40,000/小时）。\n→ Liu et al. \u0026ldquo;Lost in the Middle\u0026rdquo; (TACL 2024) 实证：长上下文不仅算得慢，模型对中段信息的利用呈 U 形曲线，比闭卷还差。\n训练约束 · 灾难性遗忘 # LLM 知识在数十亿权重里高度纠缠，没有\u0026quot;法语模块\u0026quot;或\u0026quot;用户偏好寄存器\u0026quot;可以独立写入。每次 fine-tune 都重塑整个参数景观，旧能力会被覆盖。即便是 LoRA，在 continual learning 场景下仍然受 catastrophic forgetting 困扰（arXiv 2404.16789）。\n→ 业界普遍做法是周/天级别的离线 retrain，没人做 per-request 的在线权重更新。\n合规约束 · 被遗忘权 # GDPR 第 17 条和 PDPA 要求数据控制者\u0026quot;不得无故拖延\u0026quot;地删除个人数据。一旦个人数据烘焙进数十亿权重，\u0026ldquo;被遗忘权\u0026quot;在工程上几乎无法精确执行——你无法从模型中\u0026quot;减去\u0026quot;某个用户的影响。Anthropic 和 OpenAI 都明确表示 Memory 数据存储在外部、不在权重内，这不是技术选择，是法务硬约束。\n→ RAG / Memory Layer 击败 fine-tuning 的根本原因是合规，不是技术优劣。\n安全约束 · 持久记忆 = 持久攻击面 # ChatGPT Memory 已被多次 prompt injection 攻破：通过 Google Doc / 图片 / 网页让模型调用 to=bio 写入恶意持久指令，从此影响所有未来对话（Embrace The Red 博客, 2024）。这正是 Cursor 1.0→1.2 给 Memories 强制加 user approval 的原因，也是 Anthropic 专门测试 sycophancy / harmful conversation 后才发布 Memory 的原因。\nKarpathy 的权威类比：权重 = ROM（训练时烧入，静态）；context window = RAM（推理时活跃，可直接寻址）；KV cache = working memory（test-time 形成的工作记忆）；外部 vector / KG store = disk（持久但要 retrieve）。原话：\u0026ldquo;权重里的知识是对训练时互联网文档的 hazy recollection；而 context window 里的内容是 directly accessible 的\u0026rdquo; — Andrej Karpathy, Dwarkesh Patel 专访 (2025-10)。 2. 主流产品的\u0026quot;记忆\u0026quot;策略对比（含 Cache vs Memory 辨析） # 14 个主流产品，没有任何一个真的修改了模型权重。在这节我们同时辨析三个常被混为一谈的概念：\nCache（KV / Prompt Caching）：缓存 attention 层的 K、V 投影张量，前缀逐 byte 匹配命中后跳过 prefill。生命周期 5min–24h。本质是算力优化，不是\u0026quot;记住\u0026quot;任何东西。 Memory（产品层）：文本存储在外部数据库 / 向量库 / markdown 文件里，每次调用拼到 system prompt 头部。用户可控。 真模型记忆（权重内）：改变模型权重本身。受灾难性遗忘、GDPR 被遗忘权、可解释性三重打击，业界普遍回避。 14 产品对比 # 产品 策略 本质 权重变? ChatGPT Memory 4 层: 元数据 + bio + ~40 条摘要 + 滑窗 Memory No OpenAI Prompt Caching ≥1024 token 自动 KV 缓存, 5min–24h TTL Cache No Anthropic Prompt Caching 显式 cache_control ≤4 断点, 逐 byte 匹配 Cache No Gemini Context Caching Implicit 90% 折扣 + Explicit 60min TTL Cache No Claude.ai Projects 项目说明 + 文件 + 历史, 全量塞 prompt Memory No Claude Memory (2025-10) 项目隔离, 24h 合成, 可视可编辑可导出 Memory No Claude Code CLAUDE.md + 模型自写 MEMORY.md (200 行) Memory No Cursor Rules / AGENTS.md 静态 markdown, 4 触发模式, Team \u0026gt; Project \u0026gt; User Memory No Cursor Memories (1.0+) AI 生成候选 → 用户审批 → 写入 Memory No Cursor Codebase Index Merkle 树 + 加密 + Turbopuffer 向量库 RAG No Windsurf Cascade global + workspace rules + 自动 Memories + RAG Memory No Devin Knowledge 人写 + AI 建议 + DeepWiki + VM Snapshots Memory+RAG No Replit Checkpoints VM 快照 = 文件 + DB + 对话 + Agent memory Snapshot No 斜体行 = Cache/RAG/Snapshot 类；粗体行 = Memory 类。没有一个产品改权重。\n关键反向工程证据：Manthan Gupta 三次实验证实：问 ChatGPT 一年前讨论过的具体话题，它根本不知道。ChatGPT Memory 没有用 RAG，存的只有：会话元数据 + 几十条 bio 条目 + 最近 ~40 个聊天的用户消息摘要（不存 ChatGPT 自己的回复）+ 当前滑窗。Cursor 官方文档第一句更直白：\u0026ldquo;Large language models don\u0026rsquo;t retain memory between completions. Rules provide persistent, reusable context at the prompt level.\u0026rdquo; 3. 未来范式：四层混合栈 # 自下而上：底层永远无状态，上面三层是\u0026quot;给它装记忆\u0026quot;的不同抽象。L4（Agent 记忆层）是短期主流，L2（架构内记忆）是最值得押注的研究跃迁。\nL4 · Agent 记忆层 # 商业最成熟 把 LLM 视为无状态 CPU，\u0026ldquo;记忆\u0026quot;放在外部数据库 + Agent runtime，每次推理把检索结果拼回 prompt。代表：Letta (MemGPT) · Mem0 · Zep + Graphiti · LangGraph Store · AutoGen Memory。\n✅ 可审计 · 可删除 · 模型无关 ⚠️ retrieval 质量决定上限 · 写入污染累积 Mem0 在 LoCoMo benchmark 上比 OpenAI Memory 高 26%、p95 延迟降 91%、token 降 90% L3 · 超长上下文 # 已商业化 把记忆塞进超长 context window。代表：Gemini 2M (needle 召回 \u0026gt;99%) · Magic LTM-2-Mini 100M tokens。\n✅ 会话内最佳载体 ⚠️ Lost-in-the-middle 仍未解 · 100M ctx 单用户 638×H100 L3 和 L4 是互补不是替代：超长上下文处理会话内的即时关联，Agent 记忆层处理跨会话/跨年的持久记忆。将两者组合是当前工程上的最优解。\nL2 · 架构内记忆 # 研究价值最高 把\u0026quot;持久记忆\u0026quot;做成可微模块嵌入网络——这可能是真正改写格局的方向。代表：Google Titans (短期 attention + 长期 neural memory) · Infini-attention · Mamba-2 · RWKV-7 Goose。\n✅ 常数显存 · 线性时间 ⚠️ 尚未规模化验证（需 ≥70B / ≥10T token 训练才能证明可行性） L1 · 裸 LLM（frozen weights） # 永远无状态 GPT / Claude / Gemini / Llama 内核。每次推理是新进程，权重不变。Continual learning 短期内不会成为 per-user 记忆主路。LoRA 用于领域/角色特化，不是 per-user。\n4. 记忆经济学：为什么 Cache TTL 是隐藏定价开关 # 这条暗线在全篇中最被低估。\nAnthropic 在 2026-03 把默认 cache TTL 从 1h 静默降到 5min，导致 Claude Code 用户实测多花 17–26%。没有任何公告，没有 SLA 承诺。这条改变暴露了一个残酷的事实：cache TTL 是直接影响用户单价、但不在任何 SLA 上的隐藏开关。\n指标 数值 Anthropic TTL 调整后成本上浮 17–26% Cache 费用占比透明度 0%（完全隐藏） 100M ctx 硬件成本（单用户） ~¥40k/小时 SLA 中 cache TTL 承诺 0 条 如果推演下去：未来的\u0026quot;记忆经济学\u0026quot;会越来越像云存储——分层（5min/1h/24h/永久）、可定价（微调 TTL 就是反向定价）、可锁定（agent 工作流依赖特定 cache 策略后迁移成本极高）。\n5. 3 年范式演进地图 # 基于 Anthropic、Letta、Karpathy、LeCun 等来源的判断。2026 年主流配置有较高确信，2027–2028 为推断，含不确定性。\n年份 工业主流配置 可能的黑马事件 2026 裸 LLM + Agent 记忆层 (Mem0/Zep/Letta) + 长上下文 caching Titans 系架构开始小规模商用；Sleep-time Compute 成 agent 标配 2027 Reflection / Sleep-time / TTT 进入主流 Agent 框架原语 某 SSM/Hybrid 7B 在 long-context benchmark 全面超 Transformer 2028 顶级模型可能集成 in-arch memory module（高风险预测）；否则 Memory Layer 仍是标配 LeCun H-JEPA + LLM 混合原型出现（5–10 年的早期信号） 2028 预测需谨慎：Titans 等架构内记忆方案需要 ≥70B 参数、≥10T token 训练才能规模化验证，目前仅在 arXiv。2028 年更可能的场景是 Agent 记忆层和架构内记忆共存，而非后者取代前者。 6. 给工程师的 9 条实用结论 # 不要把 Cache 和 Memory 混为一谈：Cache 是算力优化（跳过 prefill），Memory 是产品层决定把什么塞进 prompt。两者完全正交。\n写记忆就是写 system prompt：凡是能用 markdown 写下来的项目约定（Cursor Rules / CLAUDE.md / AGENTS.md），永远比\u0026quot;让 AI 自己记\u0026quot;更可控、可 diff、可版本管理。\n拼前缀顺序: static → dynamic：工具定义、System prompt、项目规则放最前；当前用户输入放最后。OpenAI / Anthropic / Google 三家文档的一致顶级建议。\nCompaction 必须 cache-safe：不要为 summarization 单开新 system prompt——会让全长对话按 uncached 全价重算。Claude Code 称之为 \u0026ldquo;cache-safe forking\u0026rdquo;。\nTTL 是产品决策不只是工程参数：Anthropic 1h→5min TTL 事件的教训。把 TTL 作为可配置项暴露给用户，否则用户会在账单里发现你的隐藏定价。\nAI 写、人审批 = 当前最稳的\u0026quot;自动 Memory\u0026quot;形态：Cursor 1.2 加 user approval、Devin 默认走 suggestion 流，是被反复 prompt injection 教训之后的设计共识。\n可视、可编辑、可导出 = trust：Anthropic 的 \u0026ldquo;natural language synthesis\u0026rdquo; 差异化和 ChatGPT 不透明合成，正反两面证明了这点。\n隐私模式与 Cache 有矛盾：OpenAI Extended cache 失去 ZDR 资格、Cursor 隐私模式不存原文——把\u0026quot;性能 vs 隐私\u0026quot;作为两档让用户选。\n真正的护城河是\u0026quot;上下文工程\u0026quot;不是\u0026quot;记忆模型\u0026rdquo;：把记忆写成 deterministic、version-controlled、人类可读的状态，curation cost 是一次性的，benefit 是 compounding 的。\n7. 关键引用源 # 全部为 2024–2026 年一手资料。共 30+ 条精选，涵盖原厂文档、arXiv 论文、研究者原文。\nA. 厂商一手资料 # OpenAI\nOpenAI Prompt Caching guide — KV cache 工作原理 + TTL + retention policy OpenAI Prompt Caching 201 cookbook — Extended cache 与 ZDR 的关系 Manthan Gupta · I Reverse Engineered ChatGPT\u0026rsquo;s Memory — 4 层结构反向工程 Embrace The Red · ChatGPT Hacking Memories — bio 工具与 prompt injection 攻击面 Anthropic\nAnthropic Prompt Caching docs — cache_control / 5min vs 1h / 4 breakpoints Lessons from building Claude Code — cache-safe forking 实践 Claude Code Memory docs — CLAUDE.md vs auto memory How does Claude\u0026rsquo;s memory work — RAG 工具调用 + 24h synthesis + 项目隔离 Google\nGemini API Context Caching — implicit vs explicit、TTL、storage 计费 Vertex AI Context caching overview — 90% 折扣 + 跨租户隔离 Cursor / Windsurf / Devin / Replit\nCursor Rules + Codebase Indexing + 1.0 changelog + 1.2 changelog Windsurf Cascade Memories — 5 层 context 拼接 Devin Knowledge — 人写 + AI + DeepWiki + VM Snapshots Replit Checkpoints — VM + DB + AI 对话快照 B. 关键论文 # 架构 / 长上下文\nLost in the Middle (TACL 2024) — U 形曲线实证 Gemini 1.5 Technical Report — 1M-10M token 标杆 Magic LTM-2-Mini — 100M token, 比 attention 省 1000× FLOPs Titans: Learning to Memorize at Test Time — Google neural memory module Infini-attention — Compressive memory, 1B 模型 5K → 1M passkey Mamba-2 / SSD (ICML 2024) + RWKV-7 Goose + KV-Direct Memory Layer / Agent 记忆\nMemGPT · Mem0 · Zep + Graphiti · A-Mem · Generative Agents · Sleep-time Compute Continual Learning\nContinual Learning of LLMs Survey · TTT (ICML 2025) · Memory Survey C. 范式判断 (Karpathy / LeCun / Raschka) # Andrej Karpathy · Dwarkesh Patel 专访 (2025-10) Karpathy · Intro to LLMs Yann LeCun · A Path Towards AMI LeCun at NVIDIA GTC 2025 Sebastian Raschka · Coding the KV Cache D. 工业框架 # LangGraph Persistence \u0026amp; Memory AutoGen Memory \u0026amp; RAG Letta Research Don\u0026rsquo;t Break the Cache (arXiv 2601.06007) ctx.ist · Context Determinism Thesis 调研方法：三路并行子代理（技术原理 + 产品 API 设计 + 未来范式），交叉验证四个信息源（Exa、Tavily、Context7、WebSearch）。共 67 条一手 URL，时效 2024-Q1 至 2026-Q2。\n","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/projects/llm-memory-research/","section":"作品","summary":"一句话结论 # 所谓「大模型没有记忆」不是疏忽，而是 Transformer O(n²) 注意力 + KV cache 显存 + 权重纠缠（灾难性遗忘）+ GDPR 合规 四重约束的均衡解。ChatGPT / Claude / Cursor 的 “Memory” 本质都是把结构化文本塞回 system prompt，模型权重永远不动。Prompt Caching 只是性能优化，不是记忆。未来 1–3 年的主流是 「无状态 LLM 内核 + 有状态 Agent 记忆层」 混合架构。\n计算复杂度 100M ctx 成本 Cache 价格 主流 TTL O(n²) 638×H100 0.1× 5min–24h 1. 为什么 LLM 被设计成无状态 # 四个独立约束叠加，每一个单独都不致命，叠在一起就只剩\"无状态\"这一种工程解——这个结论来自对 67 条一手资料的交叉验证。\n","title":"大模型为什么没有记忆——67 条一手资料的交叉验证调研","type":"projects"},{"content":"","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/categories/%E8%B0%83%E7%A0%94%E6%8A%A5%E5%91%8A/","section":"Categories","summary":"","title":"调研报告","type":"categories"},{"content":"","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/tags/%E8%B0%83%E7%A0%94%E6%8A%A5%E5%91%8A/","section":"Tags","summary":"","title":"调研报告","type":"tags"},{"content":"","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/tags/%E5%8A%A8%E7%94%BB/","section":"Tags","summary":"","title":"动画","type":"tags"},{"content":"我是刘卓琪，AI Agent 架构师。帮企业把 AI 从 Demo 做成产品。\n我做的事情不是调 API 套壳——而是从零设计 Agent 系统架构：记忆层设计、多 Agent 编排、上下文工程、RAG 管道、工具调用协议、评估体系。能写 Java / Python / Go 后端，前端 React / Vue / Angular / Svelte 全栈通吃，还持有 CKS（Certified Kubernetes Security Specialist） 认证，基础设施从 OpenStack 到 Ceph 都摸过。简单说——从模型到生产，一个人能走通。\n为什么选我 # Agent 架构师视角，不是 Prompt 工程师。我关注的是：记忆层怎么设计（Mem0 / Zep / Letta）、多 Agent 之间怎么通信和编排、上下文窗口怎么利用才不浪费 token、工具调用的安全边界在哪。 安全基因。CKS 认证 + 多年基础设施安全经验。我知道 prompt injection 的攻击面在哪，知道怎么给 Agent 的工具调用做权限隔离，知道怎么在合规约束下设计数据流。 全栈落地能力。能写 Java 微服务，也能写 Python Agent runtime，还能用 Go 写高性能中间件。前端 React / Vue / Angular / Svelte 都能上手。 专业能力 # Agent \u0026amp; AI 工程 Multi-Agent 编排 · 记忆层架构（Mem0 / Zep / Letta / MemGPT） · RAG 管道设计与优化 · 上下文工程与 Cache 策略 · MCP 协议与工具调用 · Prompt Injection 防护 · Agent 评估体系 · LLM 部署与推理优化\n后端与基础设施 Java / Spring Boot · Python / FastAPI · Go · Node.js · PostgreSQL · Redis · RabbitMQ / Kafka · Docker / Kubernetes（CKS） · OpenStack · Ceph · GitHub Actions CI/CD\n前端 React · Vue · Angular · Svelte · Next.js · Nuxt · Astro · TypeScript · Tailwind CSS · UnoCSS\n安全 CKS 认证 · 容器安全 · API 安全 · AI 安全（Prompt Injection / Jailbreak / 数据泄露防护） · GDPR / 数据合规\n代表作 # 大模型为什么没有记忆 — 用 Exa / Tavily / Context7 / WebSearch 四源交叉验证，覆盖 Anthropic / OpenAI / Google / Cursor 官方文档，Karpathy / LeCun / Raschka 等研究者原文，以及 MemGPT / Titans / Mamba-2 / Mem0 等关键论文。67 条一手资料的交叉验证调研。\n联系方式 # GitHub: github.com/YouToco\nX / Twitter: x.com/busygod9527\nTelegram: t.me/happyforyou0\n微信: 查看二维码\n有 Agent 系统集成、架构设计或安全审计的需求，通过以上方式联系我。\n","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/about/","section":"卓琪的开发笔记","summary":"AI Agent 架构师刘卓琪的个人介绍 —— 全栈 AI 工程能力 + 安全 + 云基础设施","title":"关于我","type":"page"},{"content":" 为什么选 Hugo # 做个人博客选框架，我的第一标准是维护成本低——不想三个月后因为 npm 依赖地狱放弃写作。\nHugo 是单二进制文件，无需 Node.js，构建几千篇文章只需 1-2 秒，Blowfish 主题开箱就有暗色模式、全文搜索、多语言、RSS、Open Graph、阅读时间估算。日常写作只需碰 Markdown。\n整体架构 # 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ┌─────────────────────────────┐ │ DNS 分线路解析 │ │ (阿里云云解析 GeoDB) │ └──────┬──────────────┬────────┘ │ │ 国内访客 ▼ 国际访客 ▼ ┌──────────────────┐ ┌─────────────────┐ │ 阿里云 CDN │ │ Cloudflare Pages │ │ ↓ │ │ (免费，全球CDN) │ │ 阿里云 OSS │ └─────────────────┘ │ (静态托管) │ └──────────────────┘ ↑ GitHub Actions 自动构建 \u0026amp; 双栈推送 这套方案全年花费约 ¥212：\n域名 zhuoqidev.com：¥85/年（已买 3 年） 函数计算资源包（ICP 备案载体）：¥101/年（¥126 年包叠加 8 折优惠） 阿里云 CDN 100GB 流量包：¥20/年 OSS 存储：~¥6/年 Cloudflare Pages：¥0 ICP 备案那些事 # 国内域名备案需要\u0026quot;备案载体\u0026quot;（服务器 IP）。不买服务器的话，阿里云函数计算资源包（¥101/年）可以作为备案载体，拿到备案服务码。\n备案周期：阿里云初审 1-5 个工作日 + 管局审核 10-20 个工作日，整体约 3-6 周。等备案期间正好把网站搭完。\nDNS 分线路解析 # 阿里云云解析免费版支持\u0026quot;境内/境外\u0026quot;两条线路：\n境内 → 阿里云 CDN CNAME 境外（默认）→ Cloudflare Pages CNAME 这样国内用户走备案过的阿里云节点，海外用户走 Cloudflare 免费全球 CDN，一套域名两套加速。\n部署流程 # 推送到 GitHub → Actions 自动 hugo build → 并行上传到 OSS 和 Cloudflare Pages。\n整个流程大约 2-3 分钟，文章发布基本无感。\n后续文章会深入 Agent 架构设计、记忆层选型、多 Agent 编排等话题。\n","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/posts/hello-world/","section":"文章","summary":"为什么选 Hugo # 做个人博客选框架，我的第一标准是维护成本低——不想三个月后因为 npm 依赖地狱放弃写作。\nHugo 是单二进制文件，无需 Node.js，构建几千篇文章只需 1-2 秒，Blowfish 主题开箱就有暗色模式、全文搜索、多语言、RSS、Open Graph、阅读时间估算。日常写作只需碰 Markdown。\n整体架构 # 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ┌─────────────────────────────┐ │ DNS 分线路解析 │ │ (阿里云云解析 GeoDB) │ └──────┬──────────────┬────────┘ │ │ 国内访客 ▼ 国际访客 ▼ ┌──────────────────┐ ┌─────────────────┐ │ 阿里云 CDN │ │ Cloudflare Pages │ │ ↓ │ │ (免费，全球CDN) │ │ 阿里云 OSS │ └─────────────────┘ │ (静态托管) │ └──────────────────┘ ↑ GitHub Actions 自动构建 \u0026 双栈推送 这套方案全年花费约 ¥212：\n","title":"用 Hugo 和双栈 CDN 搭建个人网站","type":"posts"},{"content":"Hugo 用 shortcode 可以很优雅地内嵌代码演示。这里展示三种方式：\n1. 内联 CSS demo（无需外部服务） # 直接在文章里跑一个旋转加载动画：\n纯 CSS 旋转加载器\n一个渐变色文字动画：\nCSS 渐变文字\nZhuoQi Dev 2. 嵌入 CodePen # 如果已有 CodePen 作品，用一行 shortcode 嵌入：\n1 {{\u0026lt; codepen id=\u0026#34;你的PenID\u0026#34; height=\u0026#34;400\u0026#34; tab=\u0026#34;result\u0026#34; \u0026gt;}} 3. 嵌入 CodeSandbox # React / Vue 组件用 CodeSandbox：\n1 {{\u0026lt; codesandbox id=\u0026#34;你的沙盒ID\u0026#34; height=\u0026#34;450\u0026#34; view=\u0026#34;preview\u0026#34; \u0026gt;}} 这三个 shortcode 覆盖了大多数代码展示场景，写博客基本不需要其他工具了。\n","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/posts/css-animation-demo/","section":"文章","summary":"Hugo 用 shortcode 可以很优雅地内嵌代码演示。这里展示三种方式：\n1. 内联 CSS demo（无需外部服务） # 直接在文章里跑一个旋转加载动画：\n纯 CSS 旋转加载器\n一个渐变色文字动画：\n","title":"在 Hugo 文章里内嵌 CSS 动画 Demo","type":"posts"},{"content":"","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/categories/%E6%8A%98%E8%85%BE%E8%AE%B0%E5%BD%95/","section":"Categories","summary":"","title":"折腾记录","type":"categories"},{"content":"","date":"2026-05-04","externalUrl":null,"language":"zh","permalink":"/projects/","section":"作品","summary":"","title":"作品","type":"projects"}]