对话记录所有权

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

问题

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

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

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

决定

规则1：文字记录与聊天内容相符

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

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

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

规则 2：作业在聊天中或在后台运行

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

一位业主

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

考虑的选项

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

状态和订单

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

在步骤2之前检查的风险

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