问题不在说了什么，而在传了什么

多 Agent 系统的默认通信方式是自然语言：一个 Agent 把中间结论写出来，另一个 Agent 接着用。这样的好处是可读、可审计，坏处是啰嗦、损耗信息，也会暴露推理过程。

近期研究开始讨论 latent communication，尤其是通过 transformer 的 key-value cache 共享中间状态。它可以更高效，也可能保留比自然语言摘要更完整的任务上下文。LCGuard 抓住的风险是：KV cache 不是空白缓存，它可能编码了用户输入、角色私有信息和中间推理状态。

如果这些 cache 在 Agent 之间流动，系统表面上没有发送敏感文本，实际却可能把敏感内容藏在表示里传走。传统「检查输出文本是否泄密」的做法，在这里会失效。

LCGuard 的核心做法

论文把共享 KV cache 定义为 latent working memory。判断它是否安全，看攻击者能否从共享 cache 中重构 agent-specific sensitive inputs。这个定义很务实：泄漏重点是可恢复信息。

LCGuard 使用表示层变换，在 cache 传给其他 Agent 前做处理。训练时引入对抗式目标：攻击者学习从 cache 里恢复敏感输入，LCGuard 则学习降低这种可恢复性，同时保留任务相关语义。

论文称，在多个模型家族和多 Agent benchmark 上，LCGuard 能降低 reconstruction-based leakage 和 attack success rate，并保持有竞争力的任务表现。它是在隐私和协作效率之间找平衡。

为什么对产品重要

很多多 Agent 产品现在把风险主要放在文本层：prompt injection、越权调用、工具输出污染、消息路由错误。LCGuard 提醒我们，随着系统为了效率共享更多内部状态，隐式通道会变成新的攻击面。

这对企业场景尤其重要。不同 Agent 可能代表不同部门、权限、客户或数据域。即便它们协同完成同一任务，也不意味着所有中间状态都可以共享。权限边界必须覆盖文本、工具调用、文件、向量库，也包括模型内部状态和 cache artifact。

如果未来 Agent runtime 支持 KV reuse、prefix cache、latent handoff 或跨 Agent memory，安全设计就不能停在「别把敏感文本写出来」。系统需要知道什么状态被共享、共享给谁、是否可逆、能否审计。

谨慎看待这条路线

LCGuard 的局限也明显。表示层隐私保护很难给普通工程团队调试；「降低可重构性」不等于绝对不泄漏；不同模型架构、cache 格式和任务分布变化后，效果也需要重新验证。

另外，把安全压到表示变换层，不能替代权限系统。生产边界仍然需要最小权限、隔离执行、数据分级、审计日志和外部策略控制。

但这篇论文的价值在于提前指出一个方向：Agent 的安全对象正在从文本扩展到状态。越是追求低延迟和深协作的多 Agent 系统，越不能忽视这些看不见的通道。