Agent Loadout 装配背包

Agent Loadout 装配背包

本节摘要:资产被审核分享后,还要「配装」给具体的 Agent 才能被它用上——这就是 Agent Loadout(装备背包)。本节讲清 Loadout 的核心思想「不同角色不同装备,少给噪音多给所需」,以及如何在控制台给 Agent 绑定资产、调整优先级与使用方式。Loadout 是第 3 章 Fixed Binding 机制的操作面,也是第 11 章「组一支会成长的队伍」的核心操作。

一、Loadout 的核心思想:少给噪音多给所需

Loadout 借用自角色扮演游戏——不同角色配不同装备。在 Agent 记忆里,这意味着每个 Agent 只带「它完成职责真正需要的」记忆,不带无关的:

Loadout 的对比(以「一人公司」为例)
  🔭 Scout(查资料)
     ├─ 用户访谈 Chat Memory
     ├─ 市场研究 Wiki
     └─ 竞品分析 Skill
     (不带:发布检查单、项目 CodeGraph —— 对查资料是噪音)
  
  🛠 Builder(写代码)
     ├─ 产品 Wiki
     ├─ 项目 CodeGraph
     └─ Feature Delivery Skill
     (不带:竞品分析、发布检查单 —— 对写代码是噪音)
  
  🧪 Reviewer(测试挑毛病)
     ├─ 历史事故 Chat Memory
     ├─ 项目 CodeGraph
     └─ Release Checklist Skill
     (不带:市场研究、竞品分析 —— 对测试是噪音)
​

关键概念:为什么强调「少给」?因为上下文窗口有限,给一条无关记忆就挤掉一条相关的。「少给噪音多给所需」不是吝啬,是让有限的上下文窗口发挥最大价值。这就是第 4 章召回预算思想在装配层的体现——预算从「配装什么」就开始省了。

二、Loadout 的操作:绑定、优先级、使用方式

在控制台给 Agent 配 Loadout,涉及三个动作:

一个 Loadout 的配置(概念)
  Builder Agent 的装备:
    ├─ 产品 Wiki          优先级:高  方式:toolize(按需查)
    ├─ 项目 CodeGraph     优先级:高  方式:toolize(按需查)
    ├─ Feature Delivery Skill 优先级:中 方式:inject(注入)
    └─ 团队约定 Chat Memory   优先级:低 方式:inject(注入)
​

优先级决定「召回预算不够时,先保留谁」;使用方式(inject/toolize)决定「这条记忆是常驻 system prompt,还是作为工具按需调用」——后者是第 8 章的核心,这里你只需知道有这个选项。

💡 技巧:配 Loadout 时,稳定且每次都要的(如 Skill、团队约定)用 inject(常驻),量大且按需的(如 Wiki、CodeGraph)用 toolize(按需查)。这样的搭配能让稳定部分命中 KV cache、易变部分不反复刷新 cache——性能最优。详见第 8 章。

三、Loadout 与召回的关系

Loadout 是召回「过滤」环节的一环——只有被绑定到当前 Agent 的资产,才会进入候选集:

召回时的 Loadout 过滤(接第 3 章装配机制)
  全部资产
    ├─ Team 过滤
    ├─ User 过滤
    ├─ Agent 过滤(就是 Loadout 绑定)  ← 这里
    ├─ 可见性过滤
    ├─ 生命周期过滤
    ▼
  候选集 → 检索 → 召回
​

所以 Loadout 直接决定「这个 Agent 能看到哪些资产」。没绑定的资产,即使可见性允许、状态可用,也不会被该 Agent 召回。这让 Loadout 成为「精准投喂」的工具——给 Builder 的不让 Reviewer 看到(除非也绑定给 Reviewer)。

四、Loadout 设计的三个原则

给 Agent 设计 Loadout,遵循三个原则能避免常见坑:

原则一:按职责配,不按「有什么都给」
  → Scout 配查资料相关,不配写代码相关
  → 反面:把所有资产都绑给一个 Agent = 噪音爆炸

原则二:按频率分 inject/toolize
  → 每次都用的(Skill、团队约定)→ inject
  → 量大按需的(Wiki、CodeGraph)→ toolize
  → 反面:把 Wiki 全 inject = 撑爆 system prompt

原则三:定期审视,淘汰过时
  → 项目结束后,把该项目专属资产从 Agent 解绑
  → 反面:Loadout 只加不减 = 越积越多
​

⚠️ 注意:Loadout 不是「配一次就永远对」。项目演进、Agent 职责调整,Loadout 都要跟着变。定期审视(比如每月)淘汰过时绑定,是保持 Loadout 精准的必要动作。一个臃肿的 Loadout(绑了一堆不再用的)和没配 Loadout 一样有害——都会让召回变差。

五、Loadout 与「换 Agent 不重训」的工程红利

Loadout 还带来一个重要的工程红利(第 3 章讲过):换 Agent 或换框架,只需重新配 Loadout,不必重新训练。

换 Agent 的两种方式对比
  传统(重新训练):
    换 Agent → 重新喂数据训练 → 成本极高
  
  Loadout(重新装配):
    换 Agent → 在控制台给它配新 Loadout → 即时生效
    资产不动,只是「谁带哪些」变了
​

这让「跨框架迁移」「试不同 Agent」都变得低成本——你想从 Claude Code 换到另一个 Agent,只要新 Agent 能接入,给它配上同样的 Loadout,它立刻拥有等价记忆。这是「记忆资产与 Agent 框架解耦」最直观的收益。

本节要点回顾

1. 核心思想:不同角色不同装备,少给噪音多给所需——上下文有限,无关记忆挤掉相关的。
2. 三个动作:绑定(带上)、优先级(排序)、使用方式(inject/toolize)。
3. 与召回的关系:Loadout 是召回过滤的一环,没绑定的不会被召回——精准投喂的工具。
4. 三原则:按职责配(不贪多)、按频率分方式(稳定 inject/按需 toolize)、定期淘汰(防臃肿)。
5. 换 Agent 不重训:重新配 Loadout 即时生效,记忆资产与框架解耦的直观收益。

Loadout 让资产到达 Agent,下一节看资产从哪来——Knowledge 工坊如何构建 Wiki 与 CodeGraph 这两类知识资产。