"我的 Agent Demo 跑得挺顺的,一上生产就各种出问题。"

这句话我在不同场合听过太多次了。包括我自己最早写 Agent 的时候也是这样——一个简单的 ReAct 循环,本地测得好好的,放到真实场景里不是上下文爆了就是死循环,偶尔还给你来个"无限重试把 API 额度刷光"的惊喜。

后来花了不少时间梳理 Agent Loop 设计这块的东西,从范式选择到上下文管理到失败处理,踩了一些坑也想明白了一些事。这篇把这些整理出来,希望能帮你少走点弯路。

文中涉及的代码和场景均为示意性示例,用于说明设计思路。

---

一、先说 Loop 范式:ReAct 不是万能的

ReAct(Yao et al., 2022)是最经典的 Agent Loop 范式[1],核心很简单:

Thought → Action → Observation → Thought → Action → ...

入门写 Agent,基本都从 ReAct 开始。但当你真拿它去做稍微复杂一点的任务,很快就会发现几个问题:

1. 它是贪心的。每一步的决策只看上一步的 Observation,没有全局规划。任务一复杂,Agent 就容易在某个分支上越走越偏,撞墙了也不知道回头。

2. Token 烧得快。每一步都把完整的 Thought-Action-Observation 历史塞回 Prompt,跑到第 10 步上下文就快满了。

3. 出错后容易雪崩。中间某一步 Action 失败,Agent 拿到一个错误的 Observation,后面的推理就全歪了。

所以 ReAct 适合短链路、确定性高的简单任务。面对更复杂的场景,通常需要别的范式来补:

Plan-and-Execute

LangChain 在 2023 年提出并实现了这个模式[2],灵感来自 Plan-and-Solve Prompting 和 BabyAGI 项目。先让 LLM 生成一个完整的多步骤计划,再逐步执行。

优势:规划集中做一次,执行阶段不用每步都重新推理,Token 成本可控。但计划一旦不靠谱,后面全完——所以必须加 Replan(重规划) 机制,允许执行到某步发现不对时回头改计划。

Reflexion

Shinn 等人 2023 年提出[3]。核心思路是:执行完一轮后,让 LLM 对结果做语言化的自我反思,把反思存进 Episodic Memory,下一轮试错时参考——不更新权重,靠"反思笔记"来积累经验。

论文报告在 HumanEval 编码任务上 pass@1 达到 91%[3]。但有个前提:任务得有明确的成败信号(比如代码能不能跑通)。缺乏客观反馈的开放任务上,反思的可靠性就成了问题——你让一个犯错的人反思自己为什么犯错,他反思出来的东西未必靠谱。

多 Agent 分工

把规划和执行拆给不同的 Agent,上层做调度、下层做执行,Agent 之间通过消息协作。Wang 等人在综述中对这种模式有较系统的归纳[4]。

工程上的实际选择

说句实在话:没有哪个范式是银弹。真实项目里通常是混着用:

• 简单查询 → ReAct,够用
• 多步骤任务 → Plan-and-Execute + Replan
• 代码生成、数学推理等可验证场景 → 加 Reflexion 做自校验
• 复杂协同 → 多 Agent 分工

关键不是"选哪个范式",而是根据任务特征做取舍。

---

二、上下文管理:Agent 跑久了脑子会炸

Loop 跑得越久,上下文越容易膨胀。这是一个非常工程化的问题——直接截断会丢关键信息,不截断又超出窗口。

分层管理

一种在工程实践中被广泛参考的思路,概念上借鉴了认知心理学中工作记忆与长期记忆的区分[5]:

• 近期原文(Working Memory) :最近几轮对话完整保留,确保 LLM 有足够的局部上下文
• 中期摘要(Episodic Memory) :更早的对话压缩成事件级摘要,保留"做了什么、结果怎样、状态变了什么"
• 长期事实(Semantic Memory) :从摘要中析出的稳定事实,存到向量库或 KV 存储,按需检索

需要说明的是,"Working/Episodic/Semantic"这个三层命名不是行业标准,不同框架有各自的术语。这里只是为了讨论方便做的一种抽象。

伪代码示意

class ContextManager:
    """示意性实现,仅用于说明分层管理的设计思路"""

    def __init__(self, working_size=5):
        self.working = deque(maxlen=working_size)  # 近期原文
        self.episodic = []                          # 中期摘要
        self.semantic_store = SemanticStore()        # 长期事实

    def add(self, turn):
        # 工作记忆满了,最老的一轮做摘要后降级
        if len(self.working) == self.working.maxlen:
            evicted = self.working[0]
            episode = self.summarize(evicted)
            self.episodic.append(episode)
            self.extract_facts(episode)
        self.working.append(turn)

    def build_prompt(self, query):
        # 从长期事实库检索相关内容
        related = self.semantic_store.search(query, k=5)
        return assemble(
            facts=related,
            episodes=self.episodic[-10:],
            working=list(self.working),
            query=query,
        )

核心逻辑:最近的原文留着,稍远的压缩成摘要,很久以前只保留关键事实。这样上下文长度大致可控,关键信息又不丢。

几个容易踩的坑

• 摘要丢骨架信息:LLM 做摘要时倾向于保留叙事,丢掉数字、ID、时间戳这些"骨架"。可以在摘要前先把关键实体抽出来单独存,再让 LLM 处理叙事部分。
• 向量检索召回不稳:直接拿原始 Query 去向量库搜,经常搜不到想要的事实。常见做法是先让 LLM 做一次 Query 改写,生成几个不同角度的检索意图,并行搜索再合并去重。
• 工具返回值太大:一次工具调用可能返回几千 Token 的结果,全塞上下文就爆了。可以只保留"结果摘要 + 引用 ID",需要原文时按 ID 回查。

---

三、终止条件:别只靠 max_steps

很多教程里终止条件就是一行 if step > max_steps: break。Demo 阶段够了,但生产环境这样做会漏掉大量本可以更优雅处理的信号。

一个相对完整的终止判断应该覆盖多个维度:

维度	触发条件	处理方式
任务完成	LLM 输出"完成"标记	进入结果汇总
步数上限	step ≥ max_steps	强制中止 + 摘要返回
时间上限	duration ≥ max_time	强制中止 + 摘要返回
死循环检测	相同 Action 连续出现 N 次	触发 Replan 或上报
Token 预算	total_tokens ≥ budget	压缩上下文或终止
不可恢复错误	关键 Action 抛出致命异常	停止并上报人工

尤其要注意最后一行——Agent 在遇到权限拒绝后反复尝试绕路是最灾难的情况之一。日志刷得又快又乱,关键是它还不会停。正确做法是:不可恢复的错误,早停,把决策权交回给人。

失败分类

class FailureHandler:
    """示意性分类,具体策略需结合业务"""

    def handle(self, action, error):
        if error.is_transient():
            # 临时性:网络抖动、限流、超时
            return RetryStrategy(backoff="exponential", max=3)
        elif error.is_recoverable():
            # 可降级:切换备用模型/工具
            return FallbackStrategy(alternative=self.find_alt(action))
        else:
            # 致命:权限不足、参数非法、依赖缺失
            return EscalateStrategy(target="human")

三类失败,三种处理:

• 临时性 → 指数退避重试。别傻等,也别狂刷。
• 可降级 → 换一条路走。搜索引擎 A 不可用就用搜索引擎 B,主模型超载就切备用模型。
• 致命 → 别挣扎了,上报。让 Agent 在权限被拒后疯狂尝试绕路,是最浪费 API 额度的行为。

状态持久化

如果你的 Agent 需要跑超过几分钟的任务,必须支持从中断点恢复。否则一次网络抖动、一次进程重启,用户等了半小时的结果全没了。

最小可行方案:每完成一个 Action,把 (step_id, state_snapshot, decision_log) 写一次持久化存储。重启时按 step_id 倒序找最近的有效快照恢复。代价是每次 Action 后的 IO 开销,以及 State Snapshot 的序列化复杂度——LLM 返回的非结构化内容不太容易干净地序列化,这块需要单独设计。

---

四、一张 Checklist

把上面说的收成一张表,方便自查:

检查项	你的 Agent 做了吗
Loop 范式按任务特征选择,而非一律 ReAct
有 Replan 或重规划机制
上下文做了分层管理(不是一股脑全塞)
摘要前先提取关键实体,避免丢骨架信息
终止条件覆盖多个维度,不只有 max_steps
有死循环检测(相同 Action 连续出现)
失败分三类:临时/可降级/致命,分别处理
致命错误早停上报,不让 Agent 乱试
长任务支持状态持久化与断点恢复

如果全打了勾,你的 Agent 至少在工程层面已经比大多数 Demo 级实现靠谱了。

---

五、参考

[1] Yao, S. et al. (2022). ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629. https://arxiv.org/abs/2210.03629

[2] LangChain Blog (2023). Plan-and-Execute Agents. https://www.langchain.com/blog/plan-and-execute-agents

[3] Shinn, N. et al. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv:2303.11366. https://arxiv.org/abs/2303.11366

[4] Wang, L. et al. (2024). A Survey on Large Language Model based Autonomous Agents. arXiv:2308.11432. https://arxiv.org/abs/2308.11432

[5] Atkinson, R. C. & Shiffrin, R. M. (1968). Human memory: A proposed system and its control processes. Psychology of Learning and Motivation, 2, 89-195.

---

顺便提一句,最近翻了本《OpenClaw觉醒:基于AI智能体的超级生产力构建指南》(人民邮电出版社),作者是业界的艾长青（@acedar）和吴家迪。目录里第 3 章对 Agent 生命周期、上下文管理、多智能体路由有展开讨论,第 4 章涉及沙箱与安全模型,和本文的几个话题有交集。手边刚好有几本样书,抽一位送出去。

---

送书福利

抽 1 本《OpenClaw觉醒:基于AI智能体的超级生产力构建指南》。

参与方式:

1. 关注我的 CSDN 账号
2. 评论区聊聊你写 Agent 遇到过最头疼的问题是什么?

我会从评论里挑 1 位送出。

【活动截止日期】5月27日

中奖结果在截止后一周内公布,通过 CSDN 站内私信通知,书由出版社直接寄出。