我在尝试为不同会话中的不同代理确保上下文连续性中学到的东西

我一直在研究一个在使用编码代理处理真实软件项目时反复出现的问题：**代理会在会话之间丢失线索，尤其是在不同代理之间切换时更是如此。** 一个新的 Codex / Claude Code / Copilot 会话常常不得不重新发现：* 仓库结构；* 哪些文件重要；* 已经做出的决策；* 已经失败的指令；* 当前任务状态；* 已经通过或仍需运行的验证步骤。我最终构建了一个开源、免费使用的编码代理连续性运行时，并在一个巨大的 Ruby 单体应用中进行了测试。核心流程（无论是通过 MCP 工具还是 CLI）：`aictx resume` -> 代理工作 -> `aictx finalize`。AICTX 不修改模型或代理。它充当一个外部的、仓库本地的连续性层。如果代理遵循这个协议，它就能从结构化的操作状态开始，而不是从 README、聊天记录和大范围的仓库探索中冷启动。 # 1. AICTX 是什么 AICTX 是一个仓库本地的编码代理上下文持久化层。它将相关的操作状态存储在磁盘上的 `.aictx/` 目录下，并在下一个任务开始时通过 `aictx resume` 重新加载。目标不是给代理一个巨大的隐藏记忆，而是保留一个小的、可检查的连续性层：* 正在处理什么；* 什么发生了变化；* 什么失败了；* 什么被验证了；* 做出了哪些决策；* 什么被放弃了；* 下一个会话应该做什么。下一个代理应该从实际发生的事情中恢复，而不是从头开始重新推断一切。 # 2. 有价值的持久化架构 AICTX 在 `.aictx/` 下保持多个仓库本地工件。高层来看，包括： | 工件 | 目的 | |:-|:-| | 当前交接 | 最新工作摘要和建议的下一步 | | 交接历史 | 跨会话和代理的追加式连续性日志 | | 决策 | 随时间记录的明确技术决策 | | 仓库地图 | 可选的文件和符号结构索引 | | 恢复胶囊 | 最新恢复生成的结构化上下文 | | 工作状态 | 活动任务状态和提示之间的延续 | | 执行合约 | 预期的下一步行动、编辑范围、验证路径和最终指令 | | 报告 | Markdown / Mermaid 连续性视图 | | 指标 | 本地连续性使用计数器 | 最大的不同在于，连续性与仓库共存，而不仅仅存在于某个聊天会话或某个供应商的上下文窗口中。 >**在超过 20 个会话中测试后，这里有一些值得强调的方面：** # 3. 令牌和上下文影响 ## 3.1 每次提示的开销 典型的 `aictx resume` 返回一个有限大小的 JSON 负载。在我的使用中，这通常只有几 KB，具体取决于活跃连续性的数量。粗略来说，一个正常提示可能支付的开销为： | 组件 | 近似输入令牌数 | |:-|:-| | 恢复上下文 | ~1,500–3,000 | | 最终负载 / 响应 | ~800–1,500 | | 总连续性开销 | ~2,300–4,500 | 这并非免费。对于小型的一次性任务，这可能是不必要的开销。它开始体现价值的地方在于：任务持续多个提示、跨越多个会话，或者在不同代理之间切换。 ## 3.2 它避免了什么 如果没有持久化连续性，每个新会话往往会花费上下文来恢复方向： | 重复探索 | 近似避免的令牌数 | |:-|:-| | 检查 git 状态 / diff 来了解方向 | ~500–1,000 | | 搜索相关文件 | ~1,000–4,000 | | 阅读错误的候选文件 | ~2,000–6,000 | | 重新推导之前的决策 | ~500–2,000 | | 向用户询问之前的上下文 | 低令牌成本，高工作流摩擦 | | 每个提示避免的总探索量 | ~4,000 – 13,000 | **每个提示的净平衡**：在实现任务中，AICTX 节省了其自身开销的 **2 到 4 倍**，同时减少了可能导致错误的错误路径探索。在较长的实现任务中，连续性层通过避免重复发现和错误路径探索，可以收回成本。我不会将这些数字作为通用基准，它们是实际使用中的粗略实践估算。具体平衡在很大程度上取决于仓库大小、任务类型、代理行为以及任务是否足够长以从连续性中获益。 ## 3.3 在上下文压缩中幸存 这是仓库本地连续性变得特别有用的地方。长代理会话经常被聊天系统压缩或总结。一旦发生这种情况，重要细节可能会消失：* 选择了哪个实现模式；* 哪些测试通过了；* 哪些假设被放弃了；* 哪些文件已经被检查过；* 做出了哪些架构决策。有了 AICTX，这些连续性被持久化在聊天上下文之外，并在下一次 `resume` 时显式重新加载。在长期运行的工作、多会话功能或你在不同代理之间切换的工作流中，其价值变得更加明显。 ## 3.4 价值曲线 大致模式如下： AICTX 投资回报率 │ │ ████████████████ │ ████ │ ████ │ █ │█ └────────────────────────────→ 提示 / 会话 1 3 5 10 15+ ← 负 →│← 正 → ~3 个提示 * **1–2 个提示**：通常不值得。 * **3–7 个提示**：盈亏平衡区。 * **7 个以上提示 / 多会话工作**：连续性变得日益有价值。 * **跨代理工作**：最强用例之一。 # 4. 仓库地图和结构提示 AICTX 可以维护一个可选的仓库地图，结合文件路径、符号和语言元数据。目标不是完美理解代码库，而是给下一个代理更好的起点。在实践中，这可以减少不必要的文件打开，并帮助代理更接近仓库的相关区域。它仍然不完美。对于分析、文档或宽泛的架构问题，仓库地图提示可能会产生误报。这就是为什么 AICTX 将它们视为方向提示，而非事实。 # 5. 执行合约 每次恢复都可以包含一个针对下一个代理的紧凑执行合约。合约可能包括：* 建议的第一个行动；* 预期的编辑范围；* 验证命令；* 预期的证据；* 最终指令。目标不仅是记住上下文，还要安全地引导下一次执行。合约应充当护栏，而非死板的障碍。如果代理违反了合约，AICTX 可以将其记录为一个信号： | 违规 | 典型原因 | 影响 | |:-|:-|:-| | 缺少第一个行动 | 非代码或探索性任务 | 通常低 | | 未观察到预期的验证 | 文档/分析任务，或缺少测试报告 | 低到中 | | 编辑超出预期范围 | 范围蔓延或合法的发现 | 中 | | 缺少最终化 | 代理忘了关闭循环 | 高 | 一个有用的经验是：合约必须对任务有意识。严格的第一个文件规则可能对修复 bug 有帮助，但对于调查、文档或说明任务可能会产生噪音。 # 6. 连续性质量 AICTX 可以为仓库本地连续性打分并添加注释，这样代理就不会盲目信任旧记忆。连续性可以是：* 新鲜；* 陈旧；* 缺少验证证据；* 未验证；* 降级；* 过时；* 被后来工作所矛盾。这很重要，因为“记忆”并非事实。陈旧或未经验证的交接应被视为背景证据，而非盲目遵循的指令。 出处方面已成为我思考这个问题的核心。代理编写的摘要是有用的，但它们比运行时观察到的事实要弱：* 一个命令实际运行了；* 一个文件改变了；* git 状态改变了；* 测试被观察到了；* 用户纠正了代理；* 一个失败路径被记录了；* 一个被放弃的假设被显式标记了。连续性的更强版本不是“代理记住了这个”，而是“运行时观察到了这个，代理声称了这个，验证支持了这个，而这一部分仍然未经证实”。 # 7. AICTX 何时有用 | 场景 | 使用 AICTX？ | 原因 | |:-|:-|:-| | 一次性任务，1–2 个提示 | 通常不用 | 开销可能超过收益 | | 跨多个提示的功能性工作 | 是 | 减少重新发现 | | 跨几天的多会话工作 | 强烈建议 | 保持连续性 |