停止构建反应式代理：为何你的架构需要 System 1 和 System 2

Source: Dev.to

如果你最近构建了一个 LLM 代理，你可能已经碰到了“自主性墙”。
你给代理一个网页搜索工具，一个“帮助他人”的提示，以及一个任务。前两轮看起来像是魔法。到了第三轮，它就掉进了维基百科的兔子洞。到了第十轮，它卡在一个无限循环中，试图修复一个它根本没有下载的文件的语法错误。

大多数开发者会尝试通过在系统提示中塞入更多指令来解决这个问题：“绝不要重复同一个动作两次！一步一步思考！”
但问题不在提示，而在架构。你正强迫单一的执行循环去完成两种完全不同的工作：对话/行动（低延迟、高带宽）和规划（慢速、深思熟虑的推理）。

对响应式代理的难题

标准代理（例如，朴素的 ReAct 循环）以平铺的序列运行：

Observe → Think → Act → Observe → Think → Act …

当代理在“思考”时，它试图决定要对用户说什么以及它的长期策略应该是什么。由于大语言模型是自回归的，直接上下文（最近的用户话语或最近的 API 错误）会压倒性地主导其注意力。

如果代理唯一的“规划器”就是正在执行工作的同一个循环，就会出现两种失败模式：

• 浅层探索 – 代理过于专注于眼前任务，导致从未发现新的子目标。
• 失控探索 – 代理完全忘记了最初的目标，因而永远无法完成任务。

双过程架构

受 Daniel Kahneman 的《思考，快与慢》启发，我们可以将 执行者 与 规划者 分离。

快速（系统 1）循环

• 反应式且低延迟。
• 查看当前情境并执行下一个战术步骤。
• 在面试情境中，它只会提出下一个问题，决定是否进一步探查，或转向新话题。
• 不 考虑全局策略。

深思熟虑（系统 2）循环

• 异步在后台运行（例如，每 k 回合一次）。
• 检视整个交互历史，放大视角，优化整体轨迹。
• 通过 模拟 rollout 运作：生成假设的未来情景，根据效用函数（例如，最大化新信息获取同时最小化 token 成本）进行打分，并更新共享的 “Agenda”，供系统 1 读取。

SparkMe: 案例研究

最近斯坦福的一篇论文，SparkMe: Adaptive Semi‑Structured Interviewing for Qualitative Insight Discovery（arXiv:2602.21136），展示了该架构的实际应用。作者将他们的智能体拆分为两个独立的系统：

1. 快速反应循环 – 提出问题并处理即时探查。
2. 深思规划器 – 定期模拟访谈轨迹，选择高效用路径，并更新议程。

Paper link:

解耦执行与规划的好处

要点

• 停止尝试构建一个必须在当下完美行动并同时进行四维棋局的“上帝提示”。
• 让快速代理执行操作，让慢速代理模拟未来。

如果你喜欢这种架构笔记，可以关注 Telegram 频道：