Skip to main content
电梯演讲
您提议进行什么更改？
我们提议添加恢复现有会话的能力。这类似于 “session/load”，
除了它不返回以前的消息。
今天的事情是如何运作的，这导致了什么问题？我们为什么要改变？
虽然规范提供了 “session/load” 命令，但并非所有编码代理都实现了它。
这意味着，一旦您关闭编辑器、浏览器等，您就无法恢复对话。
对于不直接实现 ACP 的代理来说，这尤其是一个问题，
而该功能是通过包装器实现的。在这种情况下，它们可能提供恢复（不带历史记录）的能力，
我们希望能够挂接到这个功能。不仅如此，恢复可以用作代理和适配器库来模拟 “session/load” 的机制。
我们提议对此做什么
您提议如何改善情况？
添加 “session/resume” 命令和功能 { session: { resume: {} }。
美好的未来
一旦这个功能存在，事情将如何发展？
我们将能够恢复现有对话，提供更好的用户体验。
不仅如此，如果代理没有实现 “session/load” 但实现了
“session/resume”，现在可以实现一个拦截代理消息的代理/适配器并将其写入磁盘。现在当客户端发出 “session/load” 时，代理/适配器将其转换为 “session/resume”，然后返回存储的消息。
实施细节和计划
告诉我更多关于您的实施。您的详细实施计划是什么？
常见问题
在编写本文档的过程中或随后的讨论中出现了哪些问题？
我们应该引入新操作（session/resume）还是添加选项到（session/load）？
一个单独的方法提供了一些好处：
- 对于无论如何不想要历史记录的客户端，它们可以只恢复
- 对于只能提供恢复的代理，其上的代理可以提供基于其上的负载，但代理仍然清楚地知道它支持什么
- 对于同时支持两者的代理，使用相同的恢复功能应该是微不足道的，它们只是重放事件或不重放
您考虑了哪些替代方法，为什么选择这一个？
最大的问题是同时支持 “session/load” 和 “session/resume” 是否有意义。
当我们通过 ACP 启动一个新会话时，我们会引入自定义 MCP 工具和配置。
这意味着，虽然我们可以使用 “session/load” 来加载我们自己的聊天记录，但加载
第三方聊天可能会导致有缺陷的用户体验，因为我们的工具将不可用。并且根据 ACP 实现，
甚至可能不会尊重功能（因为加载第三方会话不会在其历史记录中包含我们的功能，误导代理）。
因此，如果我们假设 “session/load” 是用于加载由客户端自己开始的会话，那么 “session/resume” 实际上是 “session/load” 的一个子集，与存储机制解耦。如果代理实现了 “session/load”，那么它可以直接使用，但如果它没有实现，代理或适配器可以在 “session/resume” 之上提供合理的回退。这论证了 “session/resume” 是 “session/load” 所构建的基本原语。
修订历史
- 2025-11-24：更新 FAQ 以提及 session/resume 与 session/load
