AI Agent长对话失控？工作交接Prompt重塑高效工作流

最近看到一个很实用的小技巧，我觉得只要你平时用 Codex、Claude Code、Gemini CLI 这类 AI Agent 工具，基本都能用上。

一句话总结就是：对话太长的时候，别硬聊，先让 AI 做工作交接，再开一个新会话。

听起来很简单，但这个思路真能解决一个很实际的问题：很多复杂任务不是做不下去，而是上下文越堆越长之后，AI 开始越来越不稳定。

前面还像个懂行的同事，后面慢慢就容易记混、跑偏、重复分析，甚至把已经确认过的结论又推翻一遍。你越补充，它越容易把旧上下文搅在一起。最浪费时间的，往往不是它不会做，而是你们俩一起在一团旧上下文里兜圈子。

为什么一到长对话，AI 就容易变笨

这个问题，其实很多重度用户都遇到过。尤其是下面几种场景，特别明显：

1. 排查链路很长的 bug

前面看了日志，改了配置，试了几个方向，确认了 2 个不是根因，最后准备继续往下排。

这时候上下文已经很长了。AI 如果继续在老会话里工作，很容易出现几个问题：

• 把“已经排除的方向”又拿出来重新分析
• 忘记哪些文件改过，哪些结论已经确认
• 把用户刚刚的新要求，和前面旧要求混到一起

你会发现，它不是完全不会做，而是局部还挺聪明，整体开始乱。

2. 代码改了很多轮

尤其是那种一边讨论一边改、来来回回修十几轮的任务。

到后面，AI 很容易开始“带着历史包袱写代码”。它会受前面几轮思路影响，明明当前方案已经变了，它还在沿着旧决策惯性往前写。

说个现实的问题，人自己都会这样，更别说模型了。

3. 需求本身就在演化

很多任务不是一开始就定义得很清楚，而是边做边收敛。

前面可能是“先修能跑”，后面变成“顺手把结构也收拾一下”，再后来用户又说“别动这个模块，先保守一点”。

如果这些约束散落在一大串上下文里，AI 后面经常会抓错重点。

所以我现在越来越觉得，复杂任务做到后面，管理上下文比继续补上下文更重要。

我看到的这个解法：继任者 Prompt

这个技巧的核心，不是什么“神 Prompt”，而是一个工作方式。

如果当前会话已经很长，或者你明显感觉到 AI 开始乱了，就不要再硬撑。直接准备开一个新会话。

但开新会话之前，让当前这个 Agent 先做一件事：写一份交接文档，给下一位接手的 Agent 看。

这个 Prompt 的大致意思是：

当前上下文已经过长，我将开启一个新的会话继续这项工作。请你输出一份写给下一位 AI Agent 的交接摘要，让它即使看不到当前完整上下文，也能尽快理解现状并继续推进工作。

重点不在于这句话本身，而在于后面的结构要求。

它不是让 AI 随便“总结一下”，而是要求它按交接文档的方式来写，通常会包括这些部分：

1. 当前任务目标
2. 当前进展
3. 关键上下文
4. 关键发现
5. 未完成事项
6. 建议接手路径
7. 风险与注意事项

最后再补一句：下一位 Agent 的第一步建议。

不得不说，这个设计挺聪明的。

因为它默认了一个现实：下一位 Agent 看不到你现在这段完整上下文。
那就不要写成“给用户看的总结”，而要写成“给接手同事看的交接单”。

这个视角一换，产出的东西质量会差很多。

这类 Prompt 真正解决了什么问题

我自己看完这个思路，最大的感受是：它解决的不是“怎么把 Prompt 写得更复杂”，而是“怎么把上下文里的有效信息留下来”。

很多人以为开新会话的损失很大，因为历史记录没了。

但说白了，真正有价值的，往往不是那几千上万字对话本身，而是下面这些东西：

• 这次任务到底要交付什么
• 哪些方向已经验证过，别再重复试
• 哪些文件、模块、命令最关键
• 哪些假设成立，哪些假设已经被推翻
• 下一步最该先做什么

如果这些东西能被压成一份高质量 handoff，其实你丢掉的是“杂讯”，保住的是“状态”。

这就有点像写代码时做上下文压缩。
不是把内容硬删掉，而是把真正关键的信息提炼出来，方便后面继续推进。

为什么我觉得它很适合 Agent 场景

普通聊天里，这个技巧未必那么刚需。

但在 Agent 场景下，它特别有用。原因很简单：Agent 干的是连续任务，不是一问一答。

比如：

• 改一个真实项目里的 bug
• 重构一段已经跑起来的代码
• 接着前面的分析继续做方案设计
• 查日志、跑命令、验证几个互相影响的假设

这类任务最怕的，不是单次答错，而是做了一半开始失忆。

一旦发生这种情况，最伤的不是结果，而是节奏。

你前面好不容易和它一起建立起来的工作状态，一下又被打回去了。然后你还得再解释一遍前因后果，重新提醒它哪些东西别碰、哪些结论已经有了。重复几次，人也会烦。

所以我觉得，这个 Prompt 的价值就在这里：
它把“重开会话”从一种无奈补救，变成了一种主动的工作流。

不是聊崩了才逃，而是当你判断上下文开始变脏的时候，主动切换到下一局。

一个好的交接文档，应该写到什么程度

这里也有个容易踩的坑。

很多人以为交接就是“总结一下刚才干了什么”。这其实不够。

如果我是下一位接手的 Agent，我最想看到的不是一堆过程回放，而是：

1. 任务边界到底是什么

这次到底要修 bug、补功能，还是只做分析？
哪些事情不要碰？完成标准是什么？

这比“前面聊了什么”更重要。

2. 现在哪些结论是确定的

比如：

• 根因大概率在哪
• 哪个方向已经验证失败
• 哪个方案已经被用户否掉
• 当前代码处于什么状态

如果这些不写清楚，下一位 Agent 很容易重新走回头路。

3. 下一步应该先看什么

比如具体文件路径、日志位置、命令、模块名、接口名。

交接文档里最好直接点名：

• 先看哪个文件
• 先跑哪个命令
• 先验证哪个假设
• 哪些地方不要浪费时间

这才叫能接着干。

4. 哪些风险最容易误判

这点也很关键。

比如有些问题表面看是前端 bug，实际根因在接口；
有些问题看着像权限问题，实际是缓存；
有些地方用户已经改过，别顺手覆盖。

这些坑，往往比“做了什么”更值得交接。

这件事背后，其实是上下文治理

我现在越来越觉得，AI 工具用到后面，拼的已经不只是模型能力了。

还包括你会不会：

• 控制上下文长度
• 及时丢掉脏信息
• 把关键信息结构化保存
• 在合适的时候重开会话

这不是贩卖焦虑，这就是实操。

很多人觉得“我都用上最强模型了，为什么效果还是不稳定”。
说白了，问题不一定出在模型，也可能出在你的工作流。

一个 80 分的模型，配一个干净的上下文和清晰的交接，往往比一个 100 分的模型泡在一堆脏上下文里更好用。

懂的都懂。

我自己的判断

我挺认可这个思路，而且我觉得它不是那种“看起来很高级，实际用不上”的 Prompt 花活。

它很朴素，但很实用。

尤其是你已经开始拿 Agent 做正经活的时候，这招几乎是早晚会用上的。

因为复杂任务做到后面，你迟早会面对两个选择：

1. 继续在老会话里硬撑
2. 做一次像样的交接，然后重开

以前很多人会选前者，因为觉得重新开太麻烦。

但现在看，真正麻烦的，其实是你在一段越来越乱的上下文里不断返工。

写在最后

如果你最近已经重度在用 Codex、Claude Code、Gemini CLI，我建议你把“继任者 Prompt”存进自己的常用模板里。

不是每次都要用。

但一旦你发现：

• 会话已经很长了
• AI 开始重复自己
• 前面的结论记不稳了
• 任务还没做完

那就别犹豫，直接交接，开新会话。

说白了，AI 协作做到后面，真正重要的不是一口气聊到天荒地老，而是能不能在正确的时候，体面地换人接着干。

这件事看起来小，实际很影响效率。对于这类工作流的探索和实践，也常常是技术社区里最有价值的讨论，你可以在像 云栈社区 这样的开发者论坛里找到更多灵感。