AI Agent 上下文管理：基于搭叩的七大原则与实践

作者｜朱少飞

1、前言

搭叩是心流旗下一个面向小白和初级开发者的一站式AI Development 产品，它的每个任务都跑在一个独立的容器内，能一站式的帮助用户完成调研，编码，调试和系统部署；支持前端，后端甚至安卓应用的开发和调试。

搭叩这种异步的长链路任务的 Agent 存在Tools多，任务的复杂度更高场景更丰富，执行步骤多等特点；我们发现长时间、复杂任务的执行面临着一个核心挑战：上下文窗口限制。随着对话轮次的增加，历史消息、工具调用结果、环境状态信息等内容会迅速累积，导致token消耗呈指数级增长。当上下文超出模型的处理能力时，系统要么截断历史信息导致"失忆"，要么直接崩溃无法继续工作。

这不仅仅是一个技术限制问题，更关乎AI Agent能否真正承担起复杂的、需要长期规划和执行的任务。一个真正实用的AI Agent系统，必须能够在有限的上下文窗口内，既保留关键历史信息，又能持续获取最新的环境状态，还要支持多Agent协作和能力动态扩展。

搭叩(Dakou)在实践中总结并开创了一套系统化的解决方案，包含上下文压缩、上下文替换、上下文保留、上下文锚定、上下文合并、上下文共享和工具动态扩展七大核心优化策略。这些策略并非简单的组合，而是相互协同，共同构建了一个高效、可靠的上下文管理体系，其中多项关键设计均为业界首次提出。本文将深入剖析这七大策略背后的问题、思路、竞品调研和方案选择的理由，希望能为AI Agent的开发者提供参考和启发。

2、上下文压缩 - 过长自动压缩上下文

2.1 遇到的问题

在实际应用中，我们发现AI Agent在执行复杂任务时，对话历史会迅速累积：

• Token快速增长：一个涉及代码开发的任务，可能在10-20轮对话后就产生数万token的历史记录

• 信息截断困境：简单截断最早的消息会导致Agent"遗忘"任务目标、已完成的工作和重要的上下文信息

• 执行连续性受损：当Agent无法访问完整历史时，容易出现重复执行已完成的操作、忘记用户的特殊要求等问题

这些问题在长时间任务中尤为突出。比如一个需要修改多个文件、运行测试、调试错误的开发任务，如果中途因为上下文超限而丢失了前期的修改记录，Agent可能会做出错误的决策。

2.2 解决思路

我们采用了智能压缩而非简单截断的策略：

1. LLM驱动的语义压缩：使用大语言模型本身来理解和压缩历史对话，提取关键信息而非机械地删除或总结

2. 分批递归处理：当单次压缩的内容仍然超过模型限制时，自动进行分批压缩，先压缩前半部分，再将压缩结果与后半部分合并后继续压缩

3. 场景化压缩策略：

   • 任务进行中：保留任务概览、已执行步骤、当前状态、下一步计划等关键信息

   • 任务完成时：侧重整体执行流程、关键发现、最终状态和任务结果的完整总结

4. 热缓存机制：不是压缩全部历史，而是保留最近的对话（特别是最后一次工具调用及其结果）作为"热缓存"，确保Agent能够清晰地了解最新情况

5. 异步压缩机制：当检测到token接近限制时，启动异步压缩goroutine，主流程使用条件变量等待压缩完成，避免阻塞用户交互

6. 多模态内容过滤：压缩前提取图片引用信息，非多模态模型自动过滤ContentItems中的image_url，压缩完成后还原图片到正确位置

主压缩流程图：

异步压缩机制流程图：

多模态内容过滤流程图：

2.3 竞品调研

我们调研了业界主流的记忆管理方案：

• LangChain的ConversationSummaryMemory：使用LLM定期总结对话历史，但总结较为粗糙，容易丢失技术细节

• AutoGPT的滚动窗口：采用固定大小的滑动窗口，超出部分直接丢弃，简单但会丢失早期重要信息

• Microsoft Semantic Kernel：将记忆分为短期和长期，但两者的切换和检索机制较为复杂

这些方案各有优劣，但都存在一些不足：

• 简单总结难以保留技术细节和执行脉络

• 固定窗口无法适应不同任务的复杂度

• 复杂的检索机制增加了系统开销

2.4 方案选择原因

我们最终选择了热缓存+智能压缩的混合策略，原因如下：

1. 平衡信息完整性和效率：热缓存保证最新信息不经压缩直接可用，压缩历史则用语义浓缩的方式保留关键内容

2. 定制化压缩质量：针对任务完成和进行中两种状态设计不同的压缩prompt，确保提取的信息符合当前需求。比如任务进行中强调"下一步计划"，任务完成时强调"整体总结"

3. 多模态信息保留：特别设计了图片引用的提取和还原机制，确保包含截图、图表等多模态信息的任务不会丢失这些关键内容

4. 递归压缩兜底：当单次压缩仍然超限时，自动启动分批递归压缩，确保系统在极端情况下仍能正常工作

5. 结构化输出：压缩结果采用XML结构化格式，包含任务概览、执行步骤、文件操作、命令执行等明确分类的信息，便于后续解析和利用

这种方案在实践中取得了良好效果，能够将数万token的历史压缩到几千token，同时保留80-90%的关键信息。

3、上下文保留 - Dashboard固定区域减少检索

3.1 遇到的问题

我们发现Agent在执行任务时，经常需要"回头看"自己做了什么：

• 状态查询频繁：Agent每隔几轮就会调用"查看编辑历史"、"列出当前会话"等工具，消耗额外的token和推理时间

• 信息分散：文件编辑记录在某条消息中，终端输出在另一条消息中，Agent需要"翻阅"大量历史才能建立完整认知

• 决策依据不足：没有集中的状态展示，Agent可能忘记自己已经做过某件事，导致重复操作

比如，Agent修改了文件A、B、C后去运行测试，测试失败后它可能不记得已经修改过哪些文件，又去调用工具查询，这种重复查询在长任务中非常常见。

3.2 解决思路

我们引入了Dashboard固定区域的概念：

1. 实时状态聚合：系统维护了多个管理器（FileHistoryManager、TerminalManager、BrowserManager），实时统计和追踪各类操作

2. 固定位置展示：在每次最新的用户消息中，固定添加一个

   • 当前时间

   • 最近执行的操作

   • IDE状态（编辑了哪些文件、多少次、最后操作时间）

   • 终端状态（活跃会话、当前目录、最近命令）

   • 浏览器状态（打开的标签页、当前URL）

3. 操作指引：dashboard中还包含Operation Guidance，提醒Agent要用中文回复、要报告上一步动作、要并行执行独立操作等最佳实践

3.3 竞品调研

我们借鉴了两个产品的理念：

• IDE编辑器页面：IDE的界面通常左侧有一个环境面板，显示文件树、下方显示终端等信息，这给了我们启发——将环境状态集中展示

• Replit Agent的状态展示：Replit Agent在对话中会插入状态卡片，展示当前的开发环境信息

这些产品验证了"集中展示环境状态"的价值，但它们的实现方式各有特点：

• Devin依赖复杂的UI组件

• Replit Agent的状态卡片更新频率和内容较为固定

3.4 方案选择原因

我们选择了纯文本的结构化Dashboard，原因包括：

1. 减少工具调用：Agent不再需要频繁调用工具查询状态，直接从dashboard中获取信息，每次任务可减少5-10次工具调用

2. 认知负担降低：所有关键状态在一个位置呈现，Agent建立"局势感知"的成本大幅降低

3. 实现简单高效：不依赖复杂的UI，纯文本的XML格式在任何接口（CLI、Web、API）中都能使用

4. 内容动态性：dashboard内容完全自动生成，无需手动维护，随着操作的发生实时更新

5. 指引作用：通过Operation Guidance，可以"教育"模型形成良好的工作习惯，比如并行执行、及时报告等

实践表明，引入Dashboard后，Agent的任务执行效率提升了约20-30%，无效的状态查询减少了50%以上。

4、上下文替换 - 将工具结果删除仅保留最新

4.1 遇到的问题

在Agent执行过程中，我们观察到一个明显的token浪费现象：

• Dashboard信息冗余：每次对话都会在用户消息中附带当前环境状态（文件编辑历史、终端会话、时间等），但历史消息中的dashboard已经过时，却仍然占用大量token

• 工具结果重复：某些工具（如查看文件、列出目录）可能在不同时刻被重复调用，产生大量相似的输出

• 实时性问题：Agent需要看到的是"此时此刻"的环境状态，而不是历史快照

举个例子，如果Agent在第5轮对话时看到"当前时间是10:00，编辑了3个文件"，到了第20轮时，这些信息早已过时，但仍然在上下文中占据位置。

4.2 解决思路

我们设计了一套动态替换机制：

1. 定位最新用户消息：系统会自动找到最新的用户消息位置

2. 清理历史dashboard：遍历之前的所有用户消息，使用正则表达式移除其中的<dashboard>...</dashboard>内容

3. 注入最新dashboard：在最新用户消息末尾添加实时生成的dashboard

4. ContentReplace机制：为了保留审计和调试能力，我们在消息对象中保存了原始内容（Content）和替换内容（ContentReplace），在压缩时使用替换内容，但日志中保留原始内容

4.3 竞品调研

我们特别关注了两个产品的设计：

• Devin的Dashboard设计：Devin在界面上有独立的环境面板，但这是UI层面的隔离，在发送给模型的prompt中如何处理并不透明

• Cursor的Context Management：Cursor会动态管理可见的上下文，但主要依赖用户手动控制哪些文件进入上下文

与这些方案相比：

• Devin的方案更侧重UI展示，没有解决底层prompt冗余问题

• Cursor的方案需要用户参与，不适合全自动的Agent场景

4.4 方案选择原因

我们选择在消息层面做替换，而非UI层面隔离，原因是：

1. 确保实时性：Agent每次推理时都能看到最新的环境状态，避免基于过时信息做决策

2. 节省token：历史消息中删除过时的dashboard，可以节省数百到数千token

3. 保持审计能力：通过ContentReplace机制，既优化了发送给模型的内容，又保留了完整的历史记录用于调试

4. XML结构化：使用<dashboard>标签明确标识这部分内容，便于精确定位和替换

5. 对模型透明：模型只需要正常处理用户消息，不需要理解特殊的上下文管理机制

这种方案实现简单、效果明显，在实际使用中显著减少了无效token的占用。

5、 上下文锚定 - ChatDashboard收集关键信息节点防止目标漂移

5.1 遇到的问题

在长时间、多轮次的任务执行中，我们发现了一个严重的"关键信息分散"问题：

• 关键节点丢失：用户的初始任务、计划更新、Agent的重要发现等关键节点信息，散落在大量的对话历史中

• 压缩参考缺失：进行历史压缩时，缺少一个清晰的"关键信息摘要"来指导LLM判断什么是重要的

• 多Agent协作困难：不同Agent之间缺少一个统一的"任务上下文"视图，难以理解任务的整体脉络

• 知识整合困难：检索到的知识、生成的计划、Agent的思考等信息没有统一的组织形式

• 上下文不可见：Agent的仅有部分上下文对用户可见，Agent在执行过程中因为不可见上下文会忘记自己回答了用户什么问题

例如，一个任务经过20轮对话后，包含了最初的任务描述、2次计划更新、5条Agent的重要发现、3段检索的知识。这些信息散落在历史消息中，压缩时LLM难以快速定位和评估这些关键信息的重要性。

目标漂移问题场景：

5.2 解决思路

我们引入了上下文锚定（ChatDashboard）机制，它是一个关键信息收集器：

1. 多类型消息收集：系统维护一个全局的GlobalChatBoard，收集整个任务过程中的关键信息：

   • Task类型：初始任务描述（通过SetContent设置）

   • Plan类型：任务计划和计划更新（通过AppendContent追加）

   • Agent类型：Agent的重要消息和发现（带AgentID和时间戳）

   • Knowledge类型：检索到的相关知识

   • TaskDone类型：任务完成的总结（带任务名称）

2. 结构化存储：将收集的消息按类型格式化为XML结构，例如：

   • <task>任务描述</task>

   • <agent id='coder' time='10:30:15'>重要发现</agent>

   • <task_done_summary task='认证系统'>完成总结</task_done_summary>

3. 压缩时作为上下文：调用GetCurrentTask()获取格式化的XML字符串，作为ChatDashBoard参数传入压缩请求，提供给LLM作为<conversation_context>参考

4. 多Agent共享：在MemoryShareEvent中同时传递ChatDashboard内容，确保接手的Agent也能看到完整的任务上下文

5. 自动维护：系统在关键节点自动调用AddMessage添加信息，无需手动管理

上下文锚定数据结构示例：

<!-- ToString()生成的XML格式 -->
<task>开发一个用户认证系统，支持JWT token和会话管理</task>

<plan>
执行计划：
1. 设计用户表结构
2. 实现JWT生成和验证
3. 开发登录/登出接口
</plan>

<agent id='coder' time='2024-10-14 10:30:15'>
发现需要使用bcrypt进行密码加密，确保安全性
</agent>

<knowledge>
JWT最佳实践：
- 使用HS256算法签名
- 设置合理的过期时间
- 在header中传递token
</knowledge>

<agent id='coder' time='2024-10-14 11:15:22'>
计划调整：增加token刷新机制
</agent>

<task_done_summary task='用户认证系统' time='2024-10-14 12:00:00'>
已完成用户认证系统，包含注册、登录、登出、token刷新功能
</task_done_summary>

架构流程图：

5.3 竞品调研

我们研究了业界在"关键信息组织"方面的实践：

• LangChain的Memory机制：提供了多种Memory类型（ConversationBufferMemory、SummaryMemory等），但都是线性的对话历史，缺少对关键节点的特殊标记

• AutoGen的Agent Message：Agent之间通过消息传递，但缺少对关键消息的分类和汇总机制

• Devin的Session Context：维护会话上下文，但主要是状态信息，没有对不同类型信息的结构化组织

这些方案的局限性：

• 缺少对不同类型信息（任务、计划、发现、知识）的分类管理

• 没有统一的格式化输出机制

• 与压缩和共享机制的集成度不够

5.4 方案选择原因

我们选择了GlobalChatBoard这种分类收集和结构化输出的方案，原因包括：

1. 分类收集：将不同类型的关键信息（任务、计划、Agent消息、知识、完成总结）分类收集，便于后续组织和检索

2. 自动维护：系统在关键事件点（任务接收、计划更新、知识检索、任务完成）自动添加消息，无需手动管理

3. 结构化输出：ToString()方法将收集的信息格式化为清晰的XML结构，便于LLM理解和解析

4. 压缩指导：作为conversation_context提供给LLM，清晰标识哪些是任务描述、哪些是计划、哪些是发现，让压缩更有针对性

5. 多场景复用：

   • 构建ModelRequest时作为初始用户消息

   • 压缩历史时作为参考上下文

   • 知识检索时作为查询上下文

   • 多Agent共享时传递完整任务脉络

6. 容量控制：最多保存1000条消息，超出时自动删除最旧的，避免无限增长

实践效果：

• 压缩精准度提升：有ChatDashboard指导的压缩，关键节点信息保留率接近90%

• 知识检索更准：提供结构化的任务上下文，检索相关性提高35%

• 多Agent协作顺畅：新Agent接手时能快速理解任务全貌，减少50%的上下文理解时间

• Token效率提升：相比保留完整历史，只占用500-2000 tokens，节省80%以上

6、上下文合并 - 合并相同工具结果减少Token

6.1 遇到的问题

即使有了压缩机制，我们仍然发现压缩后的内容中存在大量冗余：

• 文件操作重复：同一个文件被编辑了10次，每次都记录完整的操作信息，但实际上中间状态可能并不重要

• 命令执行冗余：某些探索性的命令（如多次尝试不同参数）全部被记录，但最终只有成功的那次有价值

• 状态快照过多：压缩后的记忆中保存了大量时间点的状态快照，但趋势和变化才是关键

例如，开发一个功能时，Agent可能修改某个文件5次才达到正确状态，如果这5次修改都完整保留，会占用大量token，但实际上只需要知道"这个文件从初始状态变为最终状态"即可。

6.2 解决思路

我们在压缩阶段引入了结构化解析和智能合并：

1. XML结构化存储：将文件操作解析为<file_operation path="..." action="...">的结构，命令执行解析为<command execution="..." status="...">，便于后续处理

2. 索引化管理：使用fileOp_0_path、fileOp_0_action、 cmd_1_text等索引化的key存储到缓存中，避免重复的完整内容

3. 优先级策略：在压缩prompt中明确告知LLM哪些信息优先级高（核心文件的最终状态、troubleshooting完整序列），哪些可以合并（临时文件、探索性命令）

4. 保留关键序列：特别强调保留"失败→解决→成功"的完整troubleshooting序列，因为这些是Agent学习和改进的关键信息

5. 工具结果分片：对于超长工具输出（>18000 tokens），自动分割成多个part，在分片间插入assistant确认消息，最多分割8个part后截断

6. 消息规范化：合并连续的相同角色消息，确保user/assistant严格交替，system消息统一置顶，避免消息序列混乱

主合并流程图：

工具结果分片流程图：

消息规范化流程图：

6.3 竞品调研

我们研究了几个相关的实现：

• LangChain的工具调用缓存：主要用于避免重复执行相同参数的工具，但不处理结果的合并

• AutoGen的结果去重机制：基于哈希值检测重复的工具输出，但无法处理"部分相同"的情况

这些方案主要解决的是"完全相同"的重复问题，而我们面临的是"部分相同、逐步演进"的场景，需要更智能的合并策略。

6.4 方案选择原因

我们最终选择了"LLM指导的结构化合并"方案，原因是：

1. 语义理解能力：LLM能够理解"修改文件A三次"的语义，知道只需要保留最终状态和关键中间步骤

2. 灵活性高：通过调整压缩prompt中的优先级策略，可以适应不同类型任务的需求

3. 保留完整性：对于troubleshooting序列等关键信息，明确要求完整保留，平衡了压缩和完整性

4. 结构化便于扩展：XML结构化存储使得后续如果需要程序化处理（如进一步去重、统计分析）变得容易

5. token效率提升：在实际测试中，这种合并策略可以额外减少30-40%的压缩后token

这个方案的关键在于"指导LLM如何合并"而不是"强制合并所有重复"，保持了灵活性和智能性的平衡。

7、上下文共享 - 多Agent共享记忆和工具结果

7.1 遇到的问题

在多Agent协作场景下，我们遇到了明显的信息孤岛问题：

• 独立上下文：每个Agent维护自己的对话历史和压缩记忆，彼此无法感知其他Agent的工作

• 重复探索：Agent A已经探索过项目结构、读取了关键文件，Agent B接手任务后又要重新做一遍

• 经验无法传递：Agent A解决了某个问题（如修复了编译错误），Agent B遇到类似问题时无法利用这个经验

例如，一个Clarifier Agent与用户交互明确了需求，生成了详细的任务规划，但当Coder Agent开始工作时，它只能通过任务描述了解需求，无法直接访问Clarifier Agent的完整上下文和思考过程。

7.2 解决思路

我们设计了基于事件总线的异步记忆共享机制：

1. MemoryShareEvent：定义了记忆共享事件，包含压缩后的记忆内容和chatDashboard

2. 任务完成时发布：当一个Agent完成任务并进行上下文压缩后，自动发布MemoryShareEvent到事件总线

3. 选择性订阅：其他Agent可以根据自己的需要订阅这些事件，获取共享的记忆

4. 压缩后传输：共享的是压缩后的记忆而非完整历史，控制了传输的数据量

7.3 竞品调研

多Agent协作是当前AI Agent领域的热点，我们重点研究了：

• Microsoft AutoGen的多Agent通信：Agent之间通过对话消息进行交互，可以转发历史消息，但这种方式会导致上下文快速膨胀

• CrewAI的团队记忆共享：引入了Crew级别的共享记忆，但更新机制较为集中化，需要显式管理

• LangGraph的状态共享：通过图状态节点在Agent间传递信息，但需要预先定义状态结构

这些方案各有特点：

• AutoGen的对话式共享最灵活，但效率较低

• CrewAI的集中式管理最可控，但灵活性受限

• LangGraph的状态共享最结构化，但需要预先设计

7.4 方案选择原因

我们选择了事件驱动的异步共享方案，原因如下：

1. 低耦合：Agent之间不需要直接引用或调用，通过事件总线解耦，一个Agent的故障不会影响其他Agent

2. 选择性订阅：不是所有Agent都需要所有记忆，通过订阅机制可以过滤无关信息，避免"信息过载"

3. 适中的数据量：共享的是压缩后的记忆（几千token），而不是完整历史（数万token），传输和存储成本可控

4. 时机恰当：在任务完成时发布，这个时机记忆已经被压缩和结构化，质量最高

5. 扩展性好：未来可以引入记忆检索、记忆评分等机制，在事件总线基础上演进

这种方案特别适合搭叩(Dakou)的场景：多个专业Agent（Clarifier、Planner、Coder、WebSearch等）在不同阶段工作，它们需要共享关键信息但又保持独立性。

8、工具动态扩展 - DAG管理减少Prompt同时动态增加能力

8.1 遇到的问题

随着搭叩(Dakou)功能的丰富，我们积累了100+个工具，这带来了严重的prompt管理问题：

• Prompt过长：如果在system prompt中列出所有工具的名称、描述和参数，会占用8000-10000 token，压缩了实际任务的空间

• 依赖关系混乱：某些工具依赖其他工具才有意义（如undo_edit依赖先有edit操作），但没有机制表达这种关系

• 能力固化：Agent在初始时就拥有所有工具，但实际上很多工具在任务早期根本用不上，却占用了prompt空间

• 学习曲线陡峭：过多的工具选择让Agent（尤其是能力较弱的模型）难以选择合适的工具

一个典型场景：初始阶段Agent只需要基本的文件读写、代码搜索等工具，但prompt中却包含了浏览器操作、云手机控制、三维建模等工具的描述，造成严重的"信息噪音"。

8.2 解决思路

我们构建了工具依赖DAG（有向无环图）管理系统：

1. 依赖关系定义：每个工具在注册时声明自己依赖哪些其他工具，形成依赖关系图

2. 初始基础集：系统启动时只启用没有依赖的基础工具（如file_read、terminal_run、message_user等）

3. 动态启用：当Agent使用了某个工具后，系统自动检查并启用依赖于这个工具的其他工具

4. 只增不删：工具一旦被启用就不会被移除，确保Agent的能力是单调递增的，不会突然"失能"

5. LeastOne特殊依赖：支持定义"至少使用过一个工具"这种特殊依赖，用于在Agent有过工具使用经验后再启用某些高级工具

8.3 竞品调研

工具管理是AI Agent系统的核心挑战之一，我们研究了：

• LangChain的Tool Calling机制：所有工具平铺在一个列表中，依赖Agent自己的智能来选择。对于工具数量较少（<20）的场景有效，但扩展性不足

• ToolLLM的工具检索：将工具向量化后存储，根据任务描述检索相关工具。这种方案能处理大规模工具，但检索准确性依赖embedding质量，且无法表达依赖关系

• Gorilla的API调用学习：通过微调模型让其学习工具调用模式，但这需要大量训练数据，且难以快速迭代新工具

这些方案的共同问题是：

• 缺乏对工具之间关系的建模

• 静态配置，无法根据任务进展动态调整

• 难以平衡初始简洁性和后期完整性

8.4 方案选择原因

我们选择DAG + 动态加载的方案，理由充分：

1. 依赖关系显式化：DAG结构清晰表达了工具之间的依赖关系，例如undo_edit必须在有过edit操作后才启用，这符合直觉且易于维护

2. 初始Prompt精简：只注入基础工具，初始prompt可以减少到2000-3000 token，为任务描述和思考留出更多空间

3. 渐进式复杂化：随着任务的推进，Agent逐步获得更多能力，这种"成长曲线"符合任务的自然演进，也降低了模型的选择负担

4. 能力单调性：只增不删的策略保证Agent不会因为某些机制突然"忘记"如何使用某个工具，提供了能力的确定性

5. DAG的可靠性保证：有向无环图确保不会出现循环依赖，系统在初始化时就能检测和拒绝不合理的依赖定义

6. 灵活的启用条件：LeastOne这种特殊依赖允许我们定义复杂的启用逻辑，例如"在Agent有过至少一次工具使用经验后，再给它提供并行执行工具"

实践中，这个方案带来了多重收益：

• 初始prompt减少60-70%

• 工具选择错误率降低约40%（因为选项更少、更相关）

• 系统启动时间减少（不需要预加载所有工具）

• 维护成本降低（依赖关系集中管理）

特别值得一提的是，这个方案为未来的演进留下了空间。我们可以在此基础上：

• 加入工具推荐机制（当检测到某种任务模式时，主动建议启用某些工具）

• 引入工具使用统计和学习（记录哪些工具组合最有效）

• 支持工具的热插拔（在运行时动态注册新工具到DAG）

9、协同效应与未来展望

以上七大策略并非孤立存在，而是协同工作，形成了一个完整的上下文管理体系：

9.1协同工作机制

• 压缩 + 替换 + 保留：压缩处理历史信息，替换更新过时内容，dashboard保留实时状态，三者配合确保上下文始终保持"精炼、准确、完整"

• 锚定 + 压缩：上下文锚定收集关键节点信息，为压缩提供明确的参考上下文，大幅提升压缩质量和准确性

• 锚定 + 共享：上下文锚定不仅指导压缩，还通过事件总线在多Agent间共享，确保任务脉络的一致性

• 合并 + 共享：合并减少单个Agent的上下文冗余，共享让多Agent能够利用彼此的工作成果，避免重复劳动

• 动态扩展 + 压缩：动态扩展控制初始prompt大小，为压缩后的记忆留出空间；反过来，压缩机制确保即使工具逐步增多，历史上下文也不会失控

这种协同产生的效果是：

• Token效率提升3-5倍：同样的任务，优化后的token消耗只有优化前的20-30%

• 任务执行时间缩短：减少无效的状态查询和重复操作，任务完成时间缩短20-40%

• 支持更长的任务周期：原本只能支持20-30轮对话的系统，现在可以稳定运行100+轮

9.2 实践价值

这套七大策略在搭叩(Dakou)的实际应用中验证了其价值：

1. 复杂开发任务：从需求分析、代码实现、测试调试到部署，完整流程可以在单个Agent会话中完成

2. 长时间运维任务：持续监控、问题诊断、修复验证等需要长周期执行的任务得以实现

3. 多Agent协作：Clarifier明确需求→Planner制定计划→Coder实现功能→WebSearch查找资料，各Agent通过上下文锚定和共享机制高效接力

4. 任务目标一致性：通过上下文锚定(ChatDashDoard)，即使经过多次压缩和多个Agent协作，仍能保持对用户原始需求的准确理解

5. 成本控制：Token消耗的减少直接降低了API调用成本，在大规模使用场景下节省显著

9.3 技术挑战与限制

当然，这套方案也并非完美，仍然存在一些挑战：

• 压缩质量依赖模型：智能压缩依赖LLM的理解能力，当模型能力不足时，可能丢失关键信息

• 事件总线开销：随着Agent数量增加，事件总线可能成为性能瓶颈，需要进一步优化

• DAG维护成本：随着工具数量增长，依赖关系的定义和维护需要团队的共识和规范

• 状态一致性：多Agent共享记忆时，如何确保状态的一致性和时效性仍需改进

9.4 未来优化方向

基于当前的实践和遇到的问题，我们规划了以下优化方向：

1. 自适应压缩：根据任务类型、模型能力、历史质量等因素，动态调整压缩策略和比例

2. 增量压缩：不是每次都重新压缩全部历史，而是对新增部分进行增量压缩，提升效率

3. 记忆检索：引入向量数据库，将压缩记忆向量化存储，支持语义检索历史信息

4. 工具推荐：基于任务描述和当前进展，智能推荐下一步可能需要的工具，主动扩展

5. 跨会话记忆：探索将某些通用知识（项目结构、编码规范等）持久化，在新会话中快速加载

6. 压缩质量评估：引入自动化机制评估压缩后记忆的质量，发现压缩不足或过度的情况

9.5 对AI Agent发展的启示

通过搭叩(Dakou)七大策略的实践，我们总结出一些对AI Agent上下文管理的普遍性认识：

1. 上下文是稀缺资源：在可预见的未来，上下文窗口仍然是限制AI Agent能力的关键因素，必须精心管理

2. 智能压缩优于简单截断：利用LLM自身的理解能力进行语义压缩，远比机械的截断或总结效果好

3. 结构化是关键：无论是dashboard、上下文锚定、压缩记忆还是工具描述，结构化的信息更容易管理和利用

4. 关键节点需要标记：在信息流中标记和收集关键节点（任务、计划、发现），为后续处理提供明确参考

5. 动态性胜过静态性：无论是工具集合还是上下文内容，动态调整和演进的系统更有生命力

6. 协同设计很重要：单一策略难以解决所有问题，需要多种机制协同工作

10. 结语

AI Agent的上下文管理是一个系统工程，需要在多个维度上进行优化。搭叩(Dakou)通过压缩、替换、保留、锚定、合并、共享、动态扩展七大策略，构建了一个高效、可靠、可扩展的上下文管理体系。

这些策略不是一蹴而就的，而是在实践中不断迭代、优化、演进的结果。它们也不是最终答案，随着LLM能力的提升、工程技术的进步，必然会有更好的方案出现。

但我们相信，这些实践经验和思考对于正在构建AI Agent系统的团队会有参考价值。核心的理念是：精心管理上下文，让AI Agent在有限的窗口中发挥最大的能力。

正是基于这套系统化的上下文管理策略，搭叩(Dakou)才得以自信地处理从官网首页开发到小游戏开发等各类复杂任务。压缩、替换与保留保证了任务执行的持久性；锚定与合并确保了目标的一致性；而共享与动态扩展则为多Agent的高效协作和能力的持续成长奠定了基础。

这些技术细节最终都服务于搭叩的核心目标：通过异步、安全、可复用的方式，将AI Agent的能力真正落地到实际的研发场景中。我们期望，搭叩可以让人人都能成为 AI 时代的创造者。

在未来，随着上下文窗口的扩大（如100万token、甚至无限上下文），这些优化的必要性可能会降低，但"高效利用资源"的工程思想永远不会过时。我们期待一起持续探索AI Agent的最佳实践，推动这项技术走向成熟和普及。