长周期 AI Agent 应用如何管理上下文
背景
在复杂、长时间运行的 Agent 系统中，要让多个智能体持续保持一致的目标、清晰的推理链和有效协作，并不是简单地把历史消息全部塞进提示词就能解决的。
这篇文章讨论的是一个面向安全告警调查的多 Agent 服务：
- Director：负责组织调查，决定要问什么问题、调度哪些专家、何时结束调查；
- Experts：负责从不同专业角度收集证据；
- Critic：负责审查专家发现，并对结论进行评估。
调查过程由多个阶段组成，每个阶段可能包含多轮交互。调查没有预设轮数上限，而是由 Director 判断何时可以结束。
长周期 Agent 的核心问题：上下文一致性
语言模型 API 本身是无状态的。为了让模型在多次请求之间保持连续性，调用方通常需要在每次请求时提供完整消息历史。很多 Agent 框架会自动累积消息历史，从而替用户管理状态。
但这会带来一个直接问题：上下文窗口会被不断填满。
对于短周期应用，这通常不是大问题；但复杂安全调查可能跨越数百次推理请求，并产生大量输出，需要额外的上下文管理机制。即便尚未触达上下文窗口上限，接近上限时也可能影响回复质量。
在多 Agent 场景中，问题更复杂：
- 每个 Agent 都需要看到适合自己角色的调查状态；
- 如果信息太少，Agent 会脱离团队整体方向，导致调查割裂；
- 如果信息太多，又可能压制创造性，增加确认偏误。
因此，关键不是“共享全部信息”，而是为不同角色提供经过设计的上下文视图。
三类互补的上下文通道
该系统使用了三类上下文通道，分别承担不同职责：
- Director’s Journal：Director 的结构化工作记忆
- Critic’s Review：带有可信度评分的发现评审报告
- Critic’s Timeline：按时间顺序整合、并带有可信度评分的发现时间线
这些通道共同目标是：在不压垮任何 Agent 的前提下，让每个 Agent 获得完成自身任务所需的上下文。
Director’s Journal：让团队保持方向感
Director 负责统筹调查，因此需要记住已经发现了什么、做过哪些决定、还有哪些问题未解决。
系统为 Director 提供了一个日志工具。提示词会鼓励 Director 经常更新日志，并使用简短记录。日志用于捕捉：
- 决策
- 观察
- 假设
- 待解决问题
- 后续动作
- 已确认发现
它相当于 Director 的工作记忆。
日志条目类型
Director’s Journal 支持六类条目：
| 类型 | 用途 | 示例 |
|---|---|---|
decision |
战略选择 | 将调查重点放在认证异常，而不是网络活动 |
observation |
观察到的模式 | 多次登录失败发生在一次成功认证之前 |
finding |
已确认事实 | 用户从不在历史基线中的 IP 地址完成认证 |
question |
未解决问题 | VPN 连接是在可疑活动之前还是之后建立的？ |
action |
已采取或计划采取的步骤 | 请求云专家检查实例活动 |
hypothesis |
工作假设 | 该模式更像凭证填充，而不是账户被完全攻陷 |
除了类型分类，Director 还可以为条目设置优先级、列出后续动作，并加入指向证据材料的引用。每条日志还会自动带上调查上下文，例如阶段、轮次和时间戳。
日志工具本身并不做复杂处理，只负责累积条目。
日志如何帮助多 Agent 对齐
每个 Agent 都会在提示词中看到当前的 Director’s Journal，通常以时间顺序呈现。相关系统提示还会解释：
- Director 的角色是什么；
- 当前 Agent 与 Director 的关系是什么；
- Journal 的目的是什么；
- 应该如何理解这些记录。
这种设计让 Director 可以：
- 推动调查走向结论；
- 观察和衡量调查进展；
- 识别无效方向；
- 根据新证据修正调查路线。
同时，它也为其他 Agent 提供了共同叙事，避免不同 Agent 各自沿着不一致的方向深入。
一个经过泛化的调查片段
文中使用了一个真实调查中经过编辑和泛化的示例。该告警由一次内核模块加载事件触发。最终调查结果显示，这是一个误报：开发者在开发环境中安装软件包，触发了过于敏感的检测规则。
示例日志中，Director 记录了类似信息：
- 事件被识别为终端进程启动；
- 用户在开发工作站上以 root 身份运行；
- 命令来自软件包 hook 脚本，而不是直接执行
modprobe； - 需要进一步确认用户角色、主机类型和可用日志源；
- 识别出多个需要参与的专家领域，例如终端遥测、身份与访问、配置等。
这些记录并不是最终结论本身，而是帮助后续 Agent 理解调查进展和方向的结构化上下文。
设计取舍：连续性与创造性之间的平衡
长周期 Agent 系统需要连续性，否则会遗忘前文、重复工作或做出互相矛盾的判断。但过度共享上下文也有风险：
- Agent 可能被既有判断过度锚定；
- 专家可能倾向于确认已有假设；
- 上下文过载会降低模型响应质量；
- 不同角色看到同样信息，反而削弱分工价值。
因此，这套设计的重点在于构建多个互补的上下文通道，而不是只依赖一条完整聊天记录。
Director’s Journal 提供调查方向和工作记忆；Critic’s Review 对发现进行审查并标注可信度；Critic’s Timeline 将发现整合到时间线上。三者结合，既帮助团队维持一致，也尽量保留不同 Agent 独立判断的空间。
对工程实践的启发
对于长周期、多 Agent 应用，简单累积消息历史通常不够。更可行的方向是：
- 为不同 Agent 设计不同上下文视图；
- 用结构化记录替代无差别历史堆叠；
- 区分“事实”“假设”“问题”和“行动”；
- 在共享上下文时控制粒度，避免信息过载；
- 让评审与时间线机制补充主控 Agent 的工作记忆。
这类机制并不只适用于安全调查，也适合其他需要多轮、多角色、长时间协作的 Agent 系统。