injection 策略:inject 注入 vs toolize 工具化

injection 策略:inject 注入 vs toolize 工具化

本节摘要:这是第 8 章的核心节,也是全书最精巧的设计之一。injection(第 4 步)要把记忆塞进请求,但不是所有记忆都用同一种方式——系统区分两种策略:稳定的 L2/L3/Skill/工具指南走 inject(拼进 system prompt,命中 KV cache),易变的 L0/L1 走 toolize(作为只读工具按需调用,避免 cache 失效)。这种区分是对「KV cache」这一 LLM 性能关键特性的精细优化。本节讲清两种策略的适用内容、性能权衡,以及为什么这个区分能让记忆「既丰富又快」。

一、为什么要分两种策略:KV cache 的约束

先理解一个 LLM 性能关键——KV cache。当 system prompt 不变时,LLM 能复用之前算的 KV cache,推理快;一旦 system prompt 变了,cache 失效,要重算,推理慢:

KV cache 的影响
  system prompt 不变 → cache 命中 → 推理快
  system prompt 变了  → cache 失效 → 推理慢(要重算 prompt)
  
  → 频繁变的内容若进 system prompt,每轮都让 cache 失效 → 慢
​

记忆内容恰好分两类:一类是「稳定的」(persona、团队约定),几乎不变;一类是「易变的」(L0 最新对话、L1 新抽事实),每轮都可能变。如果都塞进 system prompt,易变部分会让 cache 频繁失效——这就是 injection 要分两种策略的根因。

关键概念:inject vs toolize 的区分,本质是对 KV cache 的优化。稳定内容进 system prompt 享受 cache,易变内容作为工具按需调用不干扰 cache。这是「让记忆既丰富又快」的精细工程设计。

二、inject:稳定内容拼进 system prompt

inject 策略适用于「稳定、每次都要」的记忆,把它们拼进 system prompt:

inject 策略
  适用:L2 场景、L3 persona、Skill、工具使用指南
  特点:稳定(不每轮变)、每次都要
  
  做法:拼进 system prompt
    "你是助手...
     [L3 persona: 用户是资深后端,重可读性]
     [L2 场景: 当前在鉴权模块,有这些约束]
     [Skill: 排障步骤]
     [工具指南: 可用 wiki_search 等工具]"
  
  → 这些内容稳定,命中 KV cache,推理快
​

inject 的核心收益:这些内容「常驻」system prompt,LLM 每轮都能看到,且因为稳定所以命中 cache——既保证了「Agent 时刻带着这些记忆」,又不拖慢推理。

三、toolize:易变内容作为工具按需调用

toolize 策略适用于「易变、量大」的记忆,把它们作为「只读工具」暴露,Agent 需要时才调用:

toolize 策略
  适用:L0 最新对话、L1 新抽事实、Wiki、CodeGraph
  特点:易变(每轮可能变)、量大
  
  做法:作为只读工具暴露(不进 system prompt)
    Agent 看到工具:recall_recent_memory、wiki_search、code_impact
    需要时才 call 取回片段
    
  → 不进 system prompt,不干扰 cache
  → 每轮只在「需要时」取一小片
​

toolize 的核心收益:易变内容不占 system prompt,既不让 cache 失效,又能让 Agent 按需取用——这是「知识无限、占用可控」的实现(第 7 章讲的 /v3/tools 机制)。

四、两种策略的对照与权衡

把两种策略对照看,分工的逻辑更清晰:

injection 的分流(一次请求)
  召回的记忆(经装配过滤+检索+预算)
    ├─ 稳定部分 → inject 进 system prompt
    └─ 易变部分 → toolize 暴露为工具
    
  → 同一次请求,两种策略并用,各取所长
​

💡 技巧:配 Loadout 时(第 5 章),「使用方式」字段(inject/toolize)的选择就基于这个区分。判断标准很简单:这条记忆「稳定且每次都要」吗?是 → inject;「易变或量大」吗?是 → toolize。比如团队约定 Skill 每次 inject,项目 CodeGraph 量大 toolize。

五、为什么这个区分是「精巧」的

inject/toolize 的区分之所以精巧,在于它同时满足了三个看似矛盾的需求:

三个矛盾的 demands
  ① 记忆要丰富(多种内容都要带)
  ② 推理要快(cache 要命中)
  ③ 上下文有限(不能全塞)
  
  单一策略无法同时满足:
    全 inject → 违反 ③(撑爆)且易变内容违反 ②(cache 失效)
    全 toolize → 违反 ①(稳定内容每次 call 慢)
  
  inject/toolize 分流:
    稳定的 inject 满足 ①②(丰富+cache)
    易变的 toolize 满足 ③(按需,不撑)
    → 三者兼顾
​

这种「按内容特性分流策略」的设计,是工程上「精细化优化」的典范——不是一刀切,而是识别不同内容的特性,用最适合的方式处理。这也是为什么 inject/toolize 被称为全书「最精巧的一笔」之一。

⚠️ 注意:toolize 不是「免费」——每次 call 是一次工具调用,有延迟。所以「该 inject 的别 toolize」(如团队约定,inject 进 prompt 比每轮 call 快)。反之「该 toolize 的别 inject」(如 CodeGraph,inject 会撑爆 prompt)。错误的选择会让 Agent 变慢或上下文爆炸,第 9 章 SDK 会讲同样的权衡。

本节要点回顾

1. 根因 KV cache:稳定 prompt 命中 cache 快,易变 prompt 失效 cache 慢——分策略的根因。
2. inject:稳定内容(L2/L3/Skill/工具指南)拼进 system prompt,享受 cache,每轮都在。
3. toolize:易变/量大内容(L0/L1/Wiki/CG)作为工具按需调用,不干扰 cache,占用可控。
4. 分流逻辑:稳定且每次都要→inject;易变或量大→toolize;同次请求两种并用。
5. 精巧在兼顾:丰富(都带)+ 快(cache)+ 有限(不撑)三矛盾,靠分流同时满足。

核心的 injection 讲完了,下一节看执行与收尾段——rateLimit + forward + extract,限流、转发与对话回写。