为了在长时间运行的智能体系统中保持效率，Slack 工程师放弃了累积聊天记录的做法，转而采用结构化记忆、验证与蒸馏事实的方式来维持长时间运行智能体系统的连贯性与准确性。

虽然短时间的 LLM 会话通常不需要显式的上下文管理，但在长时间运行的会话中，要保持会话连贯性，上下文管理就变得至关重要——因为随着消息历史不断增加，每次请求都附带完整上下文会变得不切实际：

智能体框架会在 API 调用之间累积消息历史，以此为用户解决状态管理问题。但这会占用并填满智能体的上下文窗口，而上下文窗口对智能体可处理的信息总量存在硬性上限。即便只是接近上下文窗口的容量上限，也可能降低响应质量。

正如 Slack 高级软件工程师 Dominic Marks 所介绍的，Slack 的一款多智能体应用可跨越数百次请求，并生成数兆字节的输出。为应对这类复杂场景，他们采用了由三类互补上下文通道组成的方案：Director 日志（用于存储 Director 的结构化工作记忆）、Critic 评审（用于存储附带可信度评分的注释与结论报告）和 Critic 时间线（用于存储按时间排序、标注可信度评分的关键信息）。

Slack 采用了协调器/调度器式多智能体设计，中央协调器作为决策核心，负责接收各类请求，并将任务分派至下游智能体，也就是专家（Expert）与评审员（Critic）。

Critic 会对 Expert 的工作进行评估，因为部分结论“可能存在编造或严重曲解了数据”。他们接收 Expert 提交的摘要报告并核验报告中的相关依据。这一个评估工作是创建评分系统的基础，用于筛选出经多方信息交叉验证的结果。

Director 日志包含发现、观察、决策、问题与假设，并“提供统一的叙事脉络，确保其他智能体始终保持正确的工作方向”。

Critic 评审作为事实过滤器，使用证据核查工具来构建按可信度加权的结论列表。为了降低幻觉风险，Expert 被严格要求“仅针对提交的各项结论作出判断”。

最后，Critic 时间线基于 Director 日志、最新的 Critic 评审以及过往时间线内容构建连贯叙事，只保留可信证据，剔除重复信息，并通过优先采信高可信度来源来解决内容冲突。

虽然 Slack 的这套方案与其自身系统严格绑定，但它揭示了一个具有普适性的原则：与其在每一步交互中传递全部信息，不如搭建结构化摘要，让智能体能够根据已有内容稳定持续运行。这三个通道：

三者协同配合，在多轮交互之间维持整体连贯性，同时保留各类专业智能体的角色优势。Director 能够做出合理的战略决策，Expert 可以基于先前的理解继续工作，Critic 则能对各项结论进行客观评估。

Marks 表示，这种方法已被证实能够有效解决长时间运行的复杂智能体应用所存在的局限。如需了解完整的细节和示例，可查阅原文。

【声明：本文由 InfoQ 翻译，未经许可禁止转载。】

查看英文原文：https://www.infoq.com/news/2026/04/slack-agent-context-management/