跳过正文

AI Agent

Claude's Tool Calling Paradigm Shift: A Deep Dive into Programmatic Tool Calling and Dynamic Filtering

Background: The Cost Problem in Agent Tool Calling # In traditional agent tool-calling, every tool invocation requires a full cycle of “model inference → tool execution → result return → model re-inference.” This seemingly natural loop breaks down at scale in three ways: Context Pollution: Every tool result is injected verbatim into the context window. Fetch expense reports for 20 employees, and 2,000+ line items enter context — even though you only need to know “which 3 people exceeded their budget.” Inference Overhead: Each tool call demands a full model inference pass. Five tools = five inference passes, each costing hundreds of milliseconds to seconds. Noise Degrades Accuracy: When the context window is packed with intermediate results, the model must find signal in noise. Context Rot research shows LLM performance on complex tasks drops 50-70% as context grows. As Florian Bruniaux puts it in the Claude Code Architecture Guide: “The Outer Loop — everything outside the model: context management, tool invocation, verification, memory consolidation — increasingly determines system quality more than model inference itself.”

Claude 工具调用范式转移:Programmatic Tool Calling 与 Dynamic Filter 深度解读

背景: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 生产踩坑:当最先进的记忆系统遇到最静默的失败

为什么是 OpenClaw # 编程 Agent 的能力跃迁不只是"更强"–每次代际跃迁改变的是验证循环的归属权。Gen 1 补全时代(Copilot, 2021):人类写、AI 补、人类验证–验证完全在人手里。Gen 2 对话时代(Cursor, 2023):AI 生成代码块、人类审查 diff–验证仍以人为主,但 AI 开始做 lint/fix 的轻量自检。Gen 3 自治时代(Claude Code / Codex CLI / OpenClaw, 2025):AI 写代码、AI 跑测试、AI 看报错、AI 修–验证循环从人转移到 harness。整个 Outer Loop(模型外的一切:上下文管理、工具调用、验证、记忆巩固)开始比模型推理本身更决定系统质量。OpenClaw 是这个趋势里记忆侧最激进、但 harness 稳定性最不足的一个。 同一代内还有一条关键分岔:Vibe Coding(Bolt.new、Lovable、Replit)把验证也扔给用户–“生成即交付”;Engineering Rigor(Claude Code、Aider、OpenClaw)则把验证编码进 harness–测试跑不过就重试。两者的差距不在模型,在 outer loop 的设计哲学。 先看一眼 OpenClaw 的整体架构——用思维导图展示组件层级,后面所有踩坑都跟这些模块有关: mindmap 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 是 Gen 3 自治编程 Agent,跨模型 CLI,支持 DeepSeek / Anthropic / OpenAI 多后端。它最吸引我的一点是记忆系统——在当前所有生产可用的编程 Agent 中,它的记忆架构是最激进的:

什么时候用 RAG,什么时候用 LLM Wiki,什么时候用纯文本记忆——一个 Agent 记忆选型框架

做 Agent 系统的人迟早会撞上这个选择题:用户的数据往哪放,下次对话怎么记住? 目前工业界有三条主流路线——RAG(向量检索)、LLM Wiki(结构化知识注入)、纯文本上下文记忆(CLAUDE.md / Cursor Rules 模式)。三条路各有拥趸,但选错的代价很大:RAG 做轻了是噪音生成器,纯文本做重了是 token 焚化炉。 这篇给出一个可以直接用的决策框架。 三种方案一句话定义 # 方案 核心机制 代表产品/模式 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 关键区别不在于"存哪里",而在于检索方式和注入时机。

RAG vs LLM Wiki vs Plain Text — A Decision Framework for Agent Long-Term Memory

Every Agent builder hits this question eventually: where do I store user data so the agent remembers it next session? Three approaches dominate the landscape: RAG (vector retrieval), LLM Wiki (structured knowledge injection), and plain-text context memory (the CLAUDE.md / Cursor Rules pattern). Each has vocal advocates. But picking wrong is expensive — do RAG too light and it’s a noise generator; do plain text too heavy and it’s a token incinerator.

大模型为什么没有记忆——67 条一手资料的交叉验证调研

·1172 字· 6 分钟
一句话结论 # 所谓「大模型没有记忆」不是疏忽,而是 Transformer O(n²) 注意力 + KV cache 显存 + 权重纠缠(灾难性遗忘)+ GDPR 合规 四重约束的均衡解。ChatGPT / Claude / Cursor 的 “Memory” 本质都是把结构化文本塞回 system prompt,模型权重永远不动。Prompt Caching 只是性能优化,不是记忆。未来 1–3 年的主流是 「无状态 LLM 内核 + 有状态 Agent 记忆层」 混合架构。 计算复杂度 100M ctx 成本 Cache 价格 主流 TTL O(n²) 638×H100 0.1× 5min–24h 1. 为什么 LLM 被设计成无状态 # 四个独立约束叠加,每一个单独都不致命,叠在一起就只剩"无状态"这一种工程解——这个结论来自对 67 条一手资料的交叉验证。

大模型为什么没有记忆——67 条一手资料的交叉验证

这不是一篇"AI 科普"——这是一次用 Exa / Tavily / Context7 / WebSearch 四源交叉验证,覆盖 67 条一手资料 的硬核调研。如果你在给 Agent 系统设计记忆层,或者想搞清楚 ChatGPT Memory / Claude Memory / Cursor Rules 到底是怎么回事,这篇是你要看的东西。 → 完整报告(含 14 产品对比表、9 条工程结论、3 年范式演进地图) 一句话结论 # 所谓「大模型没有记忆」不是疏忽,而是 O(n²) 注意力 + KV Cache 显存 + 灾难性遗忘 + GDPR 合规 四重约束的均衡解。ChatGPT / Claude / Cursor 的 “Memory” 本质都是把结构化文本 塞回 system prompt,模型权重永远不动。未来 1–3 年的主流是 「无状态 LLM 内核 + 有状态 Agent 记忆层」 混合架构。

Why LLMs Have No Memory — A Research Report Covering 67 Primary Sources

This is not AI科普. This is a cross-validated research sprint backed by 67 primary sources — vendor docs, arXiv papers, and researcher interviews — on a question every Agent builder hits: why don’t LLMs remember anything? → Full report: 14-product comparison table, 9 engineering takeaways, 3-year paradigm roadmap The One-Liner # Four independent constraints — O(n²) attention + KV cache VRAM + catastrophic forgetting + GDPR right-to-be-forgotten — stacked together leave “stateless” as the only viable engineering solution. Every “Memory” feature you’ve seen (ChatGPT, Claude, Cursor) is structured text injected into the system prompt. Zero weight modification. The next 1–3 years belong to stateless LLM kernels + stateful Agent memory layers.

Why LLMs Have No Memory — A Cross-Validated Research Report with 67 Primary Sources

·1623 words· 8 min
1. Why LLMs Are Stateless # Four independent constraints — individually manageable, together they leave “stateless” as the only viable engineering solution. This conclusion is cross-validated across 67 primary sources. Architecture: O(n²) Attention # Self-attention scales at O(n²). A single 4096-token sequence needs 2 GB VRAM for KV cache; 32 concurrent sessions hit 64 GB — more than the model weights themselves. Llama 3.1 at 100M context requires 638 H100 GPUs ($5,400/hour) for KV cache alone.