Slack做多Agent系统踩过的坑：不塞更多上下文，而是更聪明地管理上下文

📰 概要

做多Agent系统，有个坑很多人都会踩：让Agent一直累积所有历史记录，直到上下文窗口被塞满。

Slack高级软件工程师Dominic Marks分享了他们的解决方案。

2026年5月1日，Slack发布了这套方案。Slack的一款多Agent应用可跨越数百次请求，并生成数兆字节的输出——这对上下文管理是巨大挑战。

他们的答案不是塞更多上下文，而是建立三种互补通道：Director日志记录结构化工作记忆、Critic评审过滤可信度、Critic时间线构建连贯叙事。

这事对做Agent系统的人来说很有参考价值。

传统做法是累积聊天记录：每次请求附带完整历史，模型根据上下文推理。短期有效，长期会出问题——上下文窗口有硬性上限，消息历史不断累积，每次请求的处理成本和响应延迟都会上升。

Slack的做法本质上是一种"信息蒸馏"：不是记录所有对话，而是提取关键信息，结构化存储，按需检索。

Critic评审这个环节尤其有意思：它专门负责核验Expert的结论，标记哪些可能是幻觉。这个设计把"幻觉过滤"变成了一条明确的工作流，而不是依赖模型自身的置信度判断。

Director日志负责记录结构化工作记忆：发现、观察、决策、问题、假设。它提供统一的叙事脉络，确保其他Agent始终保持正确的工作方向。

Critic评审负责对Expert的结论进行可信度评分。证据核查工具构建按可信度加权的结论列表，高可信度结论优先，存疑结论降权或丢弃。

Critic时间线负责在更长时间尺度上维护连贯性。它整合Director日志、Critic评审和过往时间线，构建跨轮次的叙事，只保留可信证据，剔除重复信息。

三个通道的设计背后有一个共同原则：与其在每一步交互中传递全部信息，不如搭建结构化摘要，让Agent能够根据已有内容稳定持续运行。

这和人类记忆的机制有些相似：你不会记住所有对话，只会记住关键结论和判断。多Agent系统需要类似的"记忆压缩"机制。

Slack的Critic专门对Expert说："你提交的结论里，有一部分可能是编造或严重曲解了数据。"

这个机制把幻觉检测从模型的隐式能力，变成了显式的工程流程。Expert被严格要求"仅针对提交的各项结论作出判断"，而不是在摘要中引入新的未核实信息。

短时会话（几十轮以内）不需要显式上下文管理，用累积聊天记录就够了。这套方案是给长时运行、多轮交互的系统准备的。

什么情况不建议用：如果你的Agent系统不需要跨越大量请求保持连贯性，这套方案的工程复杂度可能不值得。

如果你的系统需要长时运行，Slack的三通道架构值得参考。