Appearance
📰 概要
长时运行的AI Agent，累积的聊天记录会成为问题——上下文窗口有硬性上限，填满了响应质量就下降。
Slack工程师的解决方案是：放弃累积聊天记录，转向结构化记忆。
2026年4月29日，InfoQ报道了Slack高级软件工程师Dominic Marks分享的实践：Slack一款多智能体应用可跨越数百次请求，生成数兆字节的输出。
🔍 解读
这不是"给AI加记忆"的老生常谈，是具体的架构方案。
三类通道各有分工。Director日志存储结构化工作记忆，作为中央决策的核心依据。
Critic的角色特别有意思：它会对Expert的结论进行核验，因为"部分结论可能存在编造或严重曲解了数据"。这是把事实核查内嵌到Agent架构里，而不是依赖模型本身的准确性。
💎 深挖
为什么上下文管理在长时运行中变得关键
智能体框架在API调用之间累积消息历史来解决状态管理，但这会填满上下文窗口。当消息历史接近上限，响应质量就会下降。
Slack的测试场景：跨越数百次请求，生成数兆字节输出。这是真实的企业级场景，不只是Demo。
三类通道的具体作用
Director日志：存储发现、观察、决策、问题与假设。提供统一的叙事脉络，确保其他Agent始终保持正确的工作方向。
Critic评审：作为事实过滤器，使用证据核查工具构建按可信度加权的结论列表。Expert被严格要求"仅针对提交的各项结论作出判断"，不是生成内容而是评估内容。
Critic时间线：按时间排序关键信息，标注可信度评分。便于事后追溯和验证决策过程。
Critic评分系统的价值
Critic的核心功能是创建评分系统，用于筛选经多方信息交叉验证的结果。不是所有结论都一样可信——通过可信度加权，只有经过验证的高置信度结论才会被接受。
这个设计直接针对的是LLM幻觉问题。不是让模型"更准"，而是在架构层面建立核查机制。
为什么值得关注
不是新模型、新工具，是AI系统架构层面的实践分享。
当AI Agent从实验走向生产，长时运行的上下文管理会成为共性挑战。Slack的方案提供了具体的参考架构：结构化记忆优于累积聊天记录，事实核查内嵌于Agent流程。
对于构建多智能体系统的团队，这个实践值得参考。
什么情况不建议用
如果你的Agent只需要短时单轮对话，累积聊天记录完全够用，不需要上这套架构。这套方案的复杂度不适合简单场景。
如果你的团队没有足够的工程能力维护Critic的事实核查机制，Director/Critic的分工反而会成为新的维护负担。先评估工程资源再决定是否引入。
