Slack 工程师公开了一份架构说明 —— InfoQ 于 4 月 28 日跟进报道 —— 介绍他们如何在长期多 agent 系统中管理上下文。在他们的场景里,一个应用可以横跨数百次请求,产生数兆位输出。标准 agent 框架在每次调用之间累积聊天历史,但在长期生产会话中,这种做法会撞上 context window 的天花板,且在硬上限之前就让回答质量明显下滑。Slack 资深工程师 Dominic Marks 描述了替代方案:用结构化的记忆通道、专门的 critic agents、以及一条贯穿全程的蒸馏 timeline,替换"累积聊天日志"。
整体架构是 coordinator/dispatcher 模式。中央 coordinator 接收请求,并把它们分派给下游的专门 agent —— 由 experts 做实际工作,由 critics 评估 experts 的输出。critics 是必需的,因为(用 Slack 自己的话)expert 的部分发现"要么是凭空编造,要么是对数据的严重误读"。三条结构化的上下文通道承载运行时状态,而不是无界的聊天日志。director's journal 存放 director 的结构化工作记忆 —— 发现、观察、决策、悬而未决的问题、假设 —— 它被形容为"让其他 agent 不偏离主线的共同叙事"。critic's review 是一份带可信度评分的发现报告,由 critics 撰写,指令被收紧到"只对所提交的发现作判断"—— 不漂移、不臆造。critic's timeline 则从 director's journal、最新的 critic's review 与上一个 timeline 出发,构建一条连贯的叙事:去重、并按可信度加权的证据来解决冲突。
这套模式之所以重要,是因为对短的、单 agent 互动有效的"累积聊天日志"策略,无法扩展到多步生产工作流。Slack 的设计已经暗示了三件如今对长期 agent 是产业常识的事:必须有 critic agent —— 因为 expert agent 的幻觉率不容忽视;结构化记忆胜过原始聊天历史 —— 因为它强制做摘要与可信度评分;以及按时间排序的叙事蒸馏 —— Slack 的"timeline"—— 是让 agent 在数百次请求里仍然连贯所必需的。该模式可推广:任何团队若运行的多 agent 工作流横跨分钟到小时而非秒级,都需要某种形式的 director/critic/timeline 划分,或与之相近的等价物。具体通道名称与结构会有差异,但三种角色 —— 叙事承载者、可信度评分者、timeline 构建者 —— 极可能在各框架间收敛。
对 builders 而言,三件具体事情。第一,如果你的 agentic 工作流跨越的状态超过单个聊天窗口,不要只累积消息历史 —— 从第一天起就把带可信度元数据的结构化记忆通道设计进来。事后改造这一模式会非常痛苦。第二,被严格限定为"只对所提交发现下判断"的 critic agents,是 Slack 找到的最便宜的反幻觉防线:窄范围 + 专职角色 + 可信度评分。把它做进你的多 agent 层,别指望 expert agent 能自己抓到自己的错误。第三,工程文化有讲究:Slack 把这套架构公开发表,意味着未来的开源框架很可能会以 coordinator/director/critic/timeline 为标杆收敛。留意 LangGraph、AutoGen 与 CrewAI 在未来数月里,把这种模式落成一等抽象。