---
summary: "建议的文字记录条目单一所有者：每条可见消息都在其聊天模型历史记录中一次"
read_when:
  - "更改自动化结果、消息工具发送或警报写入会话记录的位置"
  - "添加将消息发布到聊天中的新路径"
  - "检查 cron 会话目标或传送路由"
title: "对话记录所有权"
---

# <a id="conversation-transcript-ownership"></a> 对话记录所有权

**提案，部分实现。** 聊天的模型可见记录是聊天显示内容的日志。一位所有者为每条出站消息写入该日志。预定作业可以在聊天中运行，也可以在后台运行；他们从不两者兼而有之。第 1 步以 [#168996](https://github.com/openclaw/openclaw/pull/168996) 形式发货。

## <a id="problem"></a> 问题

用户回复他们可以看到的消息。在 #168996 之前，聊天显示的许多消息并不在该聊天的模型历史记录中，并且模型历史记录中的某些条目从未显示：

- 发送到另一个聊天的 Cron 结果仅作为仅转录的镜像或 `System:` 意识注释到达收件人。发送到创建聊天的 Cron 结果使用了单独的规范编写器。
- 作业使用 `message` 工具发送的消息作为仅转录镜像存储在接收聊天中。提供程序重播会跳过它们 （[#168683](https://github.com/openclaw/openclaw/issues/168683)）。
- 故障警报已发送，但未写入任何记录 （[#168684](https://github.com/openclaw/openclaw/issues/168684)）。
- A 作业与 `sessionTarget: "session:<key>"` 传递到不同的聊天，将其整个运行添加到 `<key>` 对话中，但没有显示任何内容。

每条路径都有自己的规则，因此每种边缘情况都需要自己的修复。

## <a id="decision"></a> 决定

### <a id="rule-1%3A-the-transcript-matches-the-chat"></a><a id="rule-1-the-transcript-matches-the-chat"></a> 规则1：文字记录与聊天内容相符

当且仅当 C 显示消息时，该消息才处于对话 C 的模型可见历史记录中。在通道确认传送后，它会被写入一次，与显示的消息相同。

允许的异常，每个异常记录为 `warn` 运行诊断：

- 目标聊天绑定到不同的座席。消息已发送；没有智能体的成绩单得到它。
- 有效负载仅是本机的（例如，没有文本的 Discord 嵌入）。消息已发送；没有诚实的文字可写。

### <a id="rule-2%3A-a-job-runs-in-a-chat%2C-or-in-the-background"></a><a id="rule-2-a-job-runs-in-a-chat-or-in-the-background"></a> 规则 2：作业在聊天中或在后台运行

| 模式           | 用户意图                     | 运行住在                         | 结果显示在      |
| -------------- | ------------------------------- | ------------------------------------ | -------------------- |
| **在聊天**    | “每天都到我这里来查看”   | 聊天中的正常转折           | 仅限同一个聊天   |
| **背景** | “每天给我发送一份预算报告” | 它自己的作业会话（允许内存） | 一次目标聊天 |

聊天中的作业无法交付给另一个聊天。后台作业永远不会将其运行情况写入聊天记录中；只有其结果通过规则1到达目标。 今天的目标图如下： `main` 正在聊天； `isolated`和`current`是背景（`current`添加了创建聊天的快照）； `session:<key>` 在向 `<key>` 投递时处于聊天状态，而在向其他地方投递时必须成为具有自己会话的后台作业。

### <a id="one-owner"></a> 一位业主

出站发送所有者为每个已确认的可见发送写入脚本条目：自动化结果、故障警报、`message`-tool 发送和子代理公告。仅当发送是同一对话中运行的回合的回复时，它才会跳过写入，因为该回合已经写入了它。这个跳过是 [#99470](https://github.com/openclaw/openclaw/issues/99470) 中的传递镜像变成仅转录的原因：没有它，重播会显示每个答案两次。 Cron 不保留自己的转录代码。

## <a id="considered-options"></a> 考虑的选项

- **选择继续，如 Hermes Agent。** Hermes 在新会话中运行每个作业，并默认提供“即发即忘”功能。 `cron.mirror_delivery` 或每个作业 `attach_to_session` 将带标签的用户消息添加到目标会话。默认拒绝：对已传递消息的回复无需配置即可工作，并且每个作业的切换是用户必须发现的设置。
- **也始终写入创建聊天。** 已拒绝：创建聊天将保留从未显示的消息，因此代理可以引用用户没有看到的内容。运行历史记录已经回答“该作业发送了什么？”。
- **保留收件人镜像和意识注释。** 被拒绝：多个作者，尽力而为，无需等待主动转向，无幂等性，并且模型看到有关消息的注释而不是自己的消息。

## <a id="status-and-order"></a> 状态和订单

1. **Done （[#168996](https://github.com/openclaw/openclaw/pull/168996)）.** Cron结果去目标聊天一次，通过规范编写器（`src/sessions/background-session-result.ts`），确认交付后。镜子和意识笔记被移除。
2. **将写入器移至出站发送所有者。** Cron、`message` 工具、警报和子代理公告使用它；删除 cron 特定路径。关闭 #168683 和 #168684。
3. **两种作业模式。** Doctor迁移现有作业。在其他地方交付的 `session:<key>` 作业将成为具有自己的会话的后台作业。该作业丢失了 `<key>` 对话作为上下文，因此 Doctor 报告了每个迁移的作业。
4. **向模型显示发布作业** （[#168685](https://github.com/openclaw/openclaw/issues/168685)），因此在已传递的消息上“停止此”不需要查找。

## <a id="risks-to-check-before-step-2"></a> 在步骤2之前检查的风险

- **重复助理轮流。** 在聊天的最后一个助理回复后附加的结果创建两个相邻的助理消息。自 #126860 以来，这已经为 `current` 作业发货，没有已知的故障，但 Hermes 打破了相同的模式（[hermes-agent#2221](https://github.com/NousResearch/hermes-agent/issues/2221)）。为每个受支持的提供程序系列添加提供程序重放测试。
- **Session key parity.** 写入必须位于入站回复使用的确切会话中。 X 存在已知的不匹配 （[#168686](https://github.com/openclaw/openclaw/issues/168686)）。
- **创建聊天的重置。** 重置后隐式路由结果仍然无法关闭（[#169258](https://github.com/openclaw/openclaw/issues/169258)）。根据规则 1，重置聊天是相同的聊天；这需要一个产品决策。
- **Prompt 缓存。** 条目附加在末尾，并且不会重写早期历史记录，因此缓存的前缀保持有效。