mcpField
L
latent-briefing

latent-briefing

github.com/guanyangAgent 工作流982237 次安装2 天前更新
代码仓库

关于 latent-briefing

Latent Briefing 是用于设计多 Agent 系统的技能,介绍如何向 worker 传递 orchestrator 状态。它通过任务条件化的 KV 缓存压缩减少重复文本传递,但要求能够访问 worker 推理运行时。

主要功能

  1. 01按任务引导 KV 缓存评分
  2. 02跨注意力头共享令牌掩码
  3. 03采用稳健的 MAD 阈值
  4. 04说明运行时与模型空间前提

适用场景

  1. 01设计 orchestrator-worker 状态交接
  2. 02评估摘要或 RAG 的替代方案
  3. 03诊断重复上下文导致的令牌增长

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/guanyang/open-agent-hub --skill latent-briefing

安装后在 Claude Code 中输入/latent-briefing确认已加载。

附带文件references/attention-matching-formulation.md

详细介绍

潜在简报与 KV 缓存记忆共享

分层多 Agent 系统往往会为相同的上下文重复付费。编排器积累了漫长的推理轨迹,但每个工作 Agent 通常只会收到范围狭窄的文本交接内容,例如子任务提示词加上原始文档片段。传递完整轨迹可以确保信息覆盖,但会让每次调用工作 Agent 的令牌成本都大幅上升。摘要会引入延迟并造成信息损失。检索有助于访问文档,但无法保留编排器不断演进的推理状态。

潜在简报通过在表示层面而非文本层面共享记忆来解决这一问题。核心思路是在工作 Agent 模型的 KV 缓存中压缩编排器轨迹,保留与当前工作 Agent 任务最相关的位置。此方法基于注意力匹配(AM) KV 缓存压缩,并针对推理时的多 Agent 交接进行调整,采用任务引导查询、跨注意力头共享的令牌掩码以及稳健阈值处理。

何时启用

在以下情况下启用此技能:

  • 设计编排器-工作 Agent 或主管-专家系统,且工作 Agent 需要访问编排器的先前状态,但无需以文本形式重放完整轨迹
  • 评估 LLM 摘要或 RAG 在跨 Agent 状态传递方面的替代方案
  • 将KV 缓存压缩作为一等推理原语来实现或研究,而不仅仅是对相同提示词进行前缀缓存
  • 调试递归式、分层式或工具密集型 Agent 图中的令牌爆炸问题
  • 解读同时报告工作 Agent 令牌节省、总令牌节省、压缩开销和准确率的基准测试

以下相邻工作由其他技能负责,不要为其启用此技能:

  • 无法访问内部 KV 张量的纯 API 技术栈:使用 context-compression、memory-systems 或 multi-agent-patterns。
  • 常规持久化记忆、实体追踪或图检索:使用 memory-systems。
  • 不涉及表示层状态共享的通用多 Agent 拓扑:使用 multi-agent-patterns。
  • 不转换 KV 状态的前缀缓存、掩码或预算策略:使用 context-optimization。

核心概念

令牌爆炸模式。 在递归式或 REPL 风格的系统中,编排器会反复调用工作 Agent,以检查证据、验证假设或回答子问题。编排器的轨迹会随着阶段性结论、死胡同、工具输出和先前工作 Agent 的响应不断增长。如果每次调用工作 Agent 时都传入完整轨迹,成本就会迅速累积。

表示层共享。 系统不会将轨迹总结成自然语言,而是直接处理工作 Agent 模型的KV 缓存。它保留工作 Agent 针对当前任务会关注的位置,并舍弃其余部分。这比常规前缀缓存更进一步:前缀缓存会复用相同的前缀,而潜在简报还会在复用的轨迹中进行任务条件式选择性保留。

以注意力匹配作为压缩引擎。 AM 旨在找到更小的缓存,使其注意力输出近似于完整缓存。潜在简报通过改变评分信号和批处理策略来调整 AM,以用于多 Agent 推理:

  1. 使用从当前工作 Agent 提示词推导的任务引导查询向量。
  2. 将分数汇总为全局共享掩码,而不是为每个注意力头分别选择子集。
  3. 使用稳健阈值,例如 median + tau * MAD,而不是为每个注意力头设定固定的 top-k。

参考结果概况。 公开报告显示,在长文档问答工作负载中,工作 Agent 令牌数大幅减少,总令牌数显著节省,压缩开销则为数秒以内(claim-latent-briefing-public-results)。这些数据仅可作为特定工作负载的证据,不应视为普遍保证。

详细主题

仅针对文本的缓解方法为何效果有限
方法主要弱点
LLM 摘要延迟高、抽象有损,而且无法保证摘要保留下一项子任务所需的信息
检索 / RAG依赖分块和嵌入;可能遗漏跨块或跨步骤的依赖关系
传递完整轨迹成本随每次工作器调用而增长,无关上下文还可能降低工作器的质量

当瓶颈不在于文档检索本身,而在于如何高效、精准地将编排器状态传递给工作器时,潜在简报会很有用。

递归式编排器-工作器模式

Recursive Language Models 等框架将长上下文视为环境,并在其中递归处理:编排器拆解工作并委派给工作器。若编排器已构建出应当为工作器提供信息的任务专属状态,但将该状态重新序列化为文本的成本过高或会引入噪声,潜在简报就能弥补这一缺口。

理想情况下,工作器会为编排器轨迹维护持久化 KV 状态。新的轨迹词元会扩展该状态,然后在针对当前子任务生成内容之前执行压缩。

推理时的三项改动
  1. 任务引导的查询向量。 使用当前工作器任务提示词中的查询,而非从上下文中抽取通用样本。将轨迹与当前任务一并输入工作器模型执行前向传播,然后根据任务对各轨迹位置的关注程度为其评分。

  2. 共享词元选择。 将各层和各注意力头的分数汇总为每个位置的单一分数。使用一个共享掩码即可支持批处理操作,并避免数百次彼此不兼容的逐注意力头求解。

  3. MAD 阈值处理。 保留高于稳健离群值阈值的位置,例如 median + tau * MAD。tau 越高,压缩越激进。最佳设置取决于任务类型、轨迹质量和文档长度。

基础设施前提

只有在系统能够充分控制工作器推理运行时,以便检查或转换 KV 状态时,潜在简报才切实可行。对于无法访问内部 KV 张量、只能使用 API 的技术栈,它并不是合适的默认方案。此外,它还假设编排器轨迹能够表示在工作器的模型空间中。如果编排器和工作器在分词器、架构或注意力布局方面存在显著差异,直接共享表示可能并不可行。

决策框架

选择与瓶颈相匹配的机制:

需求优先选择原因
稳定重复的前缀,且尽量少改动逻辑前缀缓存成本最低的优化;不会丢失信息
可供人阅读和审计的跨步骤状态结构化笔记或摘要易于检查和存储
在大型外部语料库中进行稀疏查找检索 / RAG高效查找文档
工作器需要编排器状态中的任务专属片段,且可以访问运行时潜在简报无需重放全部文本即可传递相关潜在状态

潜在简报并非摘要或检索的通用替代方案。它是一种专用优化,适用于已经运行可控的编排器-工作器技术栈的系统。

阈值区间

已报告的长文档问答结果表明:

  • 文档较长: 较轻的压缩可以在节省词元的同时保留更广泛的证据覆盖面。
  • 问题较难: 当编排器轨迹包含推测性或价值较低的分支时,更激进的压缩可能会有所帮助。
  • 上下文较短且较容易: 适度压缩可以去除冗余,同时不丢失必要证据。

这些只是调优假设,并非可直接套用的规律。请在目标工作负载上重新测量。

实用指导

  • 先定义共享记忆边界。 明确哪些内容会进入轨迹缓存:先前的工作者回复、工具输出、思维链,还是仅选定的产物。压缩质量取决于一开始允许哪些内容进入缓存。
  • 基于验证数据进行调优,而非依赖个例。 一并跟踪任务准确率、工作者令牌数、总令牌数、保留率和压缩开销。
  • 测量端到端延迟。 只有当压缩加生成的耗时低于相同质量目标下表现最佳的文本层替代方案时,压缩才有价值。
  • 使用强基线。 与前缀缓存、结构化笔记、检索和选择性文本交接进行比较,而不只是与“全部发送”比较。
  • 考虑编排器的波动。 如果分解策略每次运行都有变化,就要进行足够多次试验取平均,以区分压缩效果和编排器噪声。

示例

场景:编排器轨迹在多次工作者调用中不断增长

Call 1: trajectory T1 -> worker answers subquestion A
Call 2: trajectory T2 = T1 + new reasoning + reply A
        compact KV(T2) using the task prompt for B
        worker answers subquestion B

B 的任务提示词决定了 T2 中哪些部分会保留在压缩后的工作者状态中。

反例:仅限 API 的工作者

如果工作者运行在托管式文本生成 API 后端,而该 API 不提供 KV 张量,就无法直接实现 Latent Briefing。请改用 context-compression 中的结构化文本交接,或从 memory-systems 中检索状态。

指南

  1. 当主要浪费来自向工作者重放编排器状态,而非检索源文档时,优先使用 Latent Briefing。
  2. 当可审计性、可移植性或闭源模型 API 比令牌效率更重要时,优先使用纯文本交接。
  3. 将压缩与评估协同设计。质量略有下降,就可能抵消大量令牌节省。
  4. 将压缩力度作为受控参数公开,而不是隐藏的常量。

注意事项

  1. 基础设施访问是首要门槛。 如果运行时无法检查并改写工作者的 KV 状态,那么 Latent Briefing 就只是一个研究构想,而非可部署的技术。
  2. 共享模型空间很重要。 KV 压缩是在特定模型的注意力空间中定义的。不要假设潜在状态交接能在彼此无关的模型系列之间顺利实现。
  3. 阈值取决于工作负载。 同一个全局 tau 很少能同时适用于长短上下文和难易不同的任务。压缩过于激进时,准确率可能会骤降。
  4. 基准测试范围较窄。 公开结果聚焦于长文档问答。代码生成、数学和多文档综合任务的表现可能有所不同。
  5. 编排器波动可能掩盖信号。 随机性编排器可能大幅改变轨迹,从而淹没压缩带来的小幅增益或损失。
  6. 薄弱的基线会夸大表面优势。 宣称系统级优势前,先与强有力的文本层替代方案进行比较。

集成

  • context-optimization - 前缀缓存和观测屏蔽仍是默认的首选优化;对于兼容的编排器—工作者架构,Latent Briefing 是更专门的优化方案。
  • multi-agent-patterns - 适用于多 Agent 令牌开销主要由重放监督者轨迹驱动,而非仅由协调开销驱动的场景。
  • context-compression - 当人类可读状态、可移植性或审计日志很重要时,文本层摘要仍是更优选择。
  • memory-systems - 有助于判断应将跨步骤状态保存在外部记忆中,还是保存在工作者的潜在状态中。
  • tool-design - 工作者调用形式和任务提示词决定了压缩过程中哪些令牌会获得较高评分。

参考资料

内部参考:

本集合中的相关技能:

  • context-optimization - 适用场景:主要需求是前缀缓存、观察掩码或文本层压缩,而非工作器 KV 操作
  • multi-agent-patterns - 适用场景:需要决定架构是否应采用编排器-工作器模式
  • context-compression - 适用场景:可读摘要可能比潜在表示传输更合适
  • memory-systems - 适用场景:需要比较模型内潜在状态与外部持久化记忆

外部资源:


技能元数据

创建时间:2026-04-14 最后更新:2026-05-15 作者:Agent Skills for Context Engineering Contributors;主要技术来源 Ramp Labs(公开文章) 版本:1.2.0

评论

支持 Markdown