Experiments

背景 最近的 Gateway 网关日志显示重复的 cron.add 失败，参数无效（缺少 sessionTarget、wakeMode、payload，以及格式错误的 schedule）。这表明至少有一个客户端（可能是智能体工具调用路径）正在发送包装的或部分指定的任务负载。另外，TypeScript 中的 cron 提供商枚举、Gateway 网关 schema、CLI 标志和 UI 表单类型之间存在漂移，加上 cron.status 的 UI 不匹配（期望 jobCount 而 Gateway 网关返回 jobs）。 目标 通过规范化常见的包装负载并推断缺失的 kind 字段来停止 cron.add INVALID_REQUEST 垃圾。 在 Gateway 网关 schema、cron 类型、CLI 文档和 UI 表单之间对齐 cron 提供商列表。 使智能体 cron 工具 schema 明确，以便 LLM 生成正确的任务负载。 修复 Control UI cron 状态任务计数显示。 添加测试以覆盖规范化和工具行为。 非目标 更改 cron 调度语义或任务执行行为。 添加新的调度类型或 cron 表达式解析。 除了必要的字段修复外，不大改 cron 的 UI/UX。 发现（当前差距） Gateway 网关中的 CronPayloadSchema 排除了 signal + imessage，而 TS 类型包含它们。 Control UI CronStatus 期望 jobCount，但 Gateway 网关返回 jobs。 智能体 cron 工具 schema 允许任意 job 对象，导致格式错误的输入。 Gateway 网关严格验证 cron.add 而不进行规范化，因此包装的负载会失败。 变更内容 cron.add 和 cron.update 现在规范化常见的包装形式并推断缺失的 kind 字段。 智能体 cron 工具 schema 与 Gateway 网关 schema 匹配，减少无效负载。 提供商枚举在 Gateway 网关、CLI、UI 和 macOS 选择器之间对齐。 Control UI 使用 Gateway 网关的 jobs 计数字段显示状态。 当前行为 **规范化：**包装的 data/job 负载被解包；schedule.kind 和 payload.kind 在安全时被推断。 **默认值：**当缺失时，为 wakeMode 和 sessionTarget 应用安全默认值。 **提供商：**Discord/Slack/Signal/iMessage 现在在 CLI/UI 中一致显示。 参见 Cron 任务 了解规范化的形式和示例。 ...

背景 OpenClaw Gateway 网关目前在 /v1/chat/completions 暴露了一个最小的 OpenAI 兼容 Chat Completions 端点（参见 OpenAI Chat Completions）。 Open Responses 是基于 OpenAI Responses API 的开放推理标准。它专为智能体工作流设计，使用基于项目的输入加语义流式事件。OpenResponses 规范定义的是 /v1/responses，而不是 /v1/chat/completions。 目标 添加一个遵循 OpenResponses 语义的 /v1/responses 端点。 保留 Chat Completions 作为兼容层，易于禁用并最终移除。 使用隔离的、可复用的 schema 标准化验证和解析。 非目标 第一阶段完全实现 OpenResponses 功能（图片、文件、托管工具）。 替换内部智能体执行逻辑或工具编排。 在第一阶段更改现有的 /v1/chat/completions 行为。 研究摘要 来源：OpenResponses OpenAPI、OpenResponses 规范网站和 Hugging Face 博客文章。 提取的关键点： POST /v1/responses 接受 CreateResponseBody 字段，如 model、input（字符串或 ItemParam[]）、instructions、tools、tool_choice、stream、max_output_tokens 和 max_tool_calls。 ItemParam 是以下类型的可区分联合： 具有角色 system、developer、user、assistant 的 message 项 function_call 和 function_call_output reasoning item_reference 成功响应返回带有 object: "response"、status 和 output 项的 ResponseResource。 流式传输使用语义事件，如： response.created、response.in_progress、response.completed、response.failed response.output_item.added、response.output_item.done response.content_part.added、response.content_part.done response.output_text.delta、response.output_text.done 规范要求： Content-Type: text/event-stream event: 必须匹配 JSON type 字段 终止事件必须是字面量 [DONE] Reasoning 项可能暴露 content、encrypted_content 和 summary。 HF 示例在请求中包含 OpenResponses-Version: latest（可选头部）。 提议的架构 添加 src/gateway/open-responses.schema.ts，仅包含 Zod schema（无 gateway 导入）。 添加 src/gateway/openresponses-http.ts（或 open-responses-http.ts）用于 /v1/responses。 保持 src/gateway/openai-http.ts 不变，作为遗留兼容适配器。 添加配置 gateway.http.endpoints.responses.enabled（默认 false）。 保持 gateway.http.endpoints.chatCompletions.enabled 独立；允许两个端点分别切换。 当 Chat Completions 启用时发出启动警告，以表明其遗留状态。 Chat Completions 弃用路径 保持严格的模块边界：responses 和 chat completions 之间不共享 schema 类型。 通过配置使 Chat Completions 成为可选，这样无需代码更改即可禁用。 一旦 /v1/responses 稳定，更新文档将 Chat Completions 标记为遗留。 可选的未来步骤：将 Chat Completions 请求映射到 Responses 处理器，以便更简单地移除。 第一阶段支持子集 接受 input 为字符串或带有消息角色和 function_call_output 的 ItemParam[]。 将 system 和 developer 消息提取到 extraSystemPrompt 中。 使用最近的 user 或 function_call_output 作为智能体运行的当前消息。 对不支持的内容部分（图片/文件）返回 invalid_request_error 拒绝。 返回带有 output_text 内容的单个助手消息。 返回带有零值的 usage，直到 token 计数接入。 验证策略（无 SDK） 为以下支持子集实现 Zod schema： CreateResponseBody ItemParam + 消息内容部分联合 ResponseResource Gateway 网关使用的流式事件形状 将 schema 保存在单个隔离模块中，以避免漂移并允许未来代码生成。 流式实现（第一阶段） 带有 event: 和 data: 的 SSE 行。 所需序列（最小可行）： response.created response.output_item.added response.content_part.added response.output_text.delta（根据需要重复） response.output_text.done response.content_part.done response.completed [DONE] 测试和验证计划 为 /v1/responses 添加端到端覆盖： 需要认证 非流式响应形状 流式事件顺序和 [DONE] 使用头部和 user 的会话路由 保持 src/gateway/openai-http.e2e.test.ts 不变。 手动：用 stream: true curl /v1/responses 并验证事件顺序和终止 [DONE]。 文档更新（后续） 为 /v1/responses 使用和示例添加新文档页面。 更新 /gateway/openai-http-api，添加遗留说明和指向 /v1/responses 的指针。

日期：2026-01-05 状态：已完成 PR：#216 摘要 Telegram 允许列表现在不区分大小写地接受 telegram: 和 tg: 前缀，并容忍意外的空白。这使入站允许列表检查与出站发送规范化保持一致。 更改内容 前缀 telegram: 和 tg: 被同等对待（不区分大小写）。 允许列表条目会被修剪；空条目会被忽略。 示例 以下所有形式都被接受为同一 ID： telegram:123456 TG:123456 tg:123456 为什么重要 从日志或聊天 ID 复制/粘贴通常会包含前缀和空白。规范化可避免在决定是否在私信或群组中响应时出现误判。 相关文档 群聊 Telegram 提供商

目标：Clawd 风格的工作区（agents.defaults.workspace，默认 ~/.openclaw/workspace），其中"记忆"以每天一个 Markdown 文件（memory/YYYY-MM-DD.md）加上一小组稳定文件（例如 memory.md、SOUL.md）的形式存储。 本文档提出一种离线优先的记忆架构，保持 Markdown 作为规范的、可审查的数据源，但通过派生索引添加结构化回忆（搜索、实体摘要、置信度更新）。 为什么要改变？ 当前设置（每天一个文件）非常适合： “仅追加"式日志记录 人工编辑 git 支持的持久性 + 可审计性 低摩擦捕获（“直接写下来”） 但它在以下方面较弱： 高召回率检索（“我们对 X 做了什么决定？"、“上次我们尝试 Y 时？"） 以实体为中心的答案（“告诉我关于 Alice / The Castle / warelay 的信息”）而无需重读多个文件 观点/偏好稳定性（以及变化时的证据） 时间约束（“2025 年 11 月期间什么是真实的？"）和冲突解决 设计目标 离线：无需网络即可工作；可在笔记本电脑/Castle 上运行；无云依赖。 可解释：检索的项目应该可归因（文件 + 位置）并与推理分离。 低仪式感：每日日志保持 Markdown，无需繁重的 schema 工作。 增量式：v1 仅使用 FTS 就很有用；语义/向量和图是可选升级。 对智能体友好：使"在 token 预算内回忆"变得简单（返回小型事实包）。 北极星模型（Hindsight × Letta） 需要融合两个部分： Letta/MemGPT 风格的控制循环 保持一个小的"核心"始终在上下文中（角色 + 关键用户事实） 其他所有内容都在上下文之外，通过工具检索 记忆写入是显式的工具调用（append/replace/insert），持久化后在下一轮重新注入 Hindsight 风格的记忆基底 分离观察到的、相信的和总结的内容 支持 retain/recall/reflect 带有置信度的观点可以随证据演变 实体感知检索 + 时间查询（即使没有完整的知识图谱） 提议的架构（Markdown 数据源 + 派生索引） 规范存储（git 友好） 保持 ~/.openclaw/workspace 作为规范的人类可读记忆。 ...

目的：CLI、macOS 应用和 Web UI 之间共享的新手引导 + 配置界面。 组件 向导引擎（共享会话 + 提示 + 新手引导状态）。 CLI 新手引导使用与 UI 客户端相同的向导流程。 Gateway 网关 RPC 公开向导 + 配置模式端点。 macOS 新手引导使用向导步骤模型。 Web UI 从 JSON Schema + UI 提示渲染配置表单。 Gateway 网关 RPC wizard.start 参数：{ mode?: "local"|"remote", workspace?: string } wizard.next 参数：{ sessionId, answer?: { stepId, value? } } wizard.cancel 参数：{ sessionId } wizard.status 参数：{ sessionId } config.schema 参数：{} 响应（结构） 向导：{ sessionId, done, step?, status?, error? } 配置模式：{ schema, uiHints, version, generatedAt } UI 提示 uiHints 按路径键入；可选元数据（label/help/group/order/advanced/sensitive/placeholder）。 敏感字段渲染为密码输入；无脱敏层。 不支持的模式节点回退到原始 JSON 编辑器。 注意 本文档是跟踪新手引导/配置协议重构的唯一位置。

本文档记录了未来模型配置的构想。这不是正式的发布规范。如需了解当前行为，请参阅： 模型 模型故障转移 OAuth + 配置文件 动机 运营者希望： 每个提供商支持多个认证配置文件（个人 vs 工作）。 简单的 /model 选择，并具有可预测的回退行为。 文本模型与图像模型之间有清晰的分离。 可能的方向（高层级） 保持模型选择简洁：provider/model 加可选别名。 允许提供商拥有多个认证配置文件，并指定明确的顺序。 使用全局回退列表，使所有会话以一致的方式进行故障转移。 仅在明确配置时才覆盖图像路由。 待解决的问题 配置文件轮换应该按提供商还是按模型进行？ UI 应如何为会话展示配置文件选择？ 从旧版配置键迁移的最安全路径是什么？