OpenClaw 这类 AI Agent 的价值在于能持续理解上下文：用户上一轮说了项目位置，下一轮只说“记住它们”，模型也应该知道“它们”指什么。接入 DeepAI API 中转站 或其他 OpenAI-compatible 网关时，如果请求体里的 messages 丢失历史上下文，模型就会表现得像“失忆”一样。
GitHub Issue 背景：Trajectory 有 15 条消息，实际请求只有当前消息
OpenClaw GitHub 仓库中有一个已关闭且标记为 completed 的 Issue：用户通过 Telegram 和 OpenAI-compatible Provider 使用 OpenClaw。OpenClaw 的 trajectory/debug UI 里记录了完整会话上下文，例如 messagesLen: 15，但模型网关抓到的原始请求体里只有两条：system message 和当前 user message。
这个问题的影响很直接：模型无法理解代词和上下文追问，工具调用续接会失败，甚至可能出现 tool result 没有对应 assistant tool call 的结构性错误。更麻烦的是，调试 UI 看起来“上下文是完整的”，容易让人误以为是模型能力差或中转站丢包。
为什么这不是模型忘记，而是请求体缺消息
遇到上下文丢失时，很多人第一反应是“模型不聪明”或“上下文窗口太短”。但这个 Issue 的关键证据是：OpenClaw 内部记录的 session 是完整的，发给 OpenAI-compatible Provider 的请求却只包含当前消息。也就是说，模型在生成之前根本没看到历史对话。
对于 DeepAI API 中转站用户来说，这类问题要从请求体排查，而不是从模型参数排查。你需要确认最终到达中转站或上游模型的 JSON 里，messages 是否包含历史 user、assistant、tool call 和 tool result。
正确的 OpenAI-compatible 请求应该包含什么
多轮对话和工具调用场景里，请求体不应该只有当前用户消息。一个更合理的结构通常包括：
- system prompt：Agent 的规则、工具约束和安全要求。
- 历史 user messages：用户之前提供的目标、路径、偏好和约束。
- 历史 assistant messages：模型之前的计划、回答和 tool_calls。
- tool messages：工具执行结果，并且要能对应前面的 tool_call_id。
- 当前 user message：本轮真正的新输入。
如果请求只剩 system 和当前 user，模型就不可能知道“它们”“刚才那个文件夹”“继续上一步”等词指向什么。
DeepAI API 中转站里的排查方法
当 OpenClaw 通过 DeepAI API 中转站调用模型时，建议按下面顺序排查：
- 在 OpenClaw trajectory 或 debug UI 里确认 session 是否包含完整历史。
- 在 DeepAI API 中转站后台查看同一时间段的请求日志，确认请求是否到达。
- 如果可以查看请求摘要，重点看
messages数量，而不是只看状态码。 - 检查 OpenClaw 到中转站之间是否还有 model-gateway、proxy、router 或自定义 transport。
- 对比 OpenClaw 内部记录的 messages 数量和上游请求体里的 messages 数量。
工具续接失败时要检查 tool_calls 对应关系
上下文丢失不只影响普通聊天，还会影响工具调用。OpenAI-compatible 工具调用通常要求 tool result 必须对应前面的 assistant tool call。如果请求体里只剩当前 tool message，却没有之前的 assistant tool_calls，模型或上游 API 可能会报结构错误，或者无法继续执行工具链。
- 有 tool result 但没有 tool_call：说明历史 assistant 消息可能被截断。
- 工具继续执行失败：先看请求体结构，不要只看工具本身。
- 模型回答“不知道上文”：检查 messages 数量，而不是马上换模型。
- debug UI 显示完整：仍要抓最终 Provider 请求，因为 UI 记录和发出的请求可能不是同一份数据。
常见误判：不是 API 中转站丢上下文
API 中转站通常只负责接收客户端请求、记录日志、鉴权、计费、路由和转发。它不会凭空补齐客户端没有发送的历史 messages。如果 OpenClaw 或中间 model-gateway 发送的请求体本来就只有当前消息，中转站无法知道前面发生过什么。
所以排查时要建立一个清晰链路：OpenClaw session → OpenClaw transport → 本地/自建 model-gateway → DeepAI API 中转站 → 上游模型。在哪一层 messages 数量从 15 变成 2，问题就在哪里。
如何降低再次发生的风险
- 升级 OpenClaw 到包含相关修复的版本。
- 保留请求 ID 或 correlation id，方便跨 OpenClaw、网关和 DeepAI 后台对照。
- 给多轮会话和工具调用写最小回归测试：第二轮必须能看到第一轮信息。
- 开启日志时避免记录完整敏感内容，但至少记录 messages count、roles 和 tool_call 对应关系。
- 为 OpenClaw 单独创建 DeepAI API Key，方便按 Key 过滤请求日志。
DeepAI API 中转站的价值
在 OpenClaw 这类 Agent 场景里，DeepAI API 中转站不只是“换一个 Base URL”。它可以帮助你统一模型入口、观察请求状态、控制额度、排查 401/404/429/5xx，并把不同客户端的调用集中到一套日志里。尤其是上下文丢失这种问题，只有把客户端日志和中转站日志对起来，才能快速判断问题发生在哪一层。
参考资料
- OpenClaw GitHub 仓库
- OpenClaw Issue #75799：OpenAI-compatible provider request 只发送当前消息
- DeepAI API 中转站教程导航
- OpenAI Compatible API 教程合集
总结
OpenClaw 接入 DeepAI API 中转站时，如果模型突然忘记上文，先不要急着换模型或换 Key。真正要检查的是最终 OpenAI-compatible 请求体里的 messages：它是否包含历史对话、assistant tool_calls 和 tool results。调试 UI 显示完整上下文只是第一层证据，最终到达中转站和上游模型的请求体才决定模型能看到什么。把 messages 数量、请求 ID 和工具调用链路对齐，才能准确定位上下文丢失问题。
