别让聊天记录充当 Agent 状态机

对话式界面是一种自然的交互方式：人们可以通过它发起远程工作请求，并在之后回来查看结果。对话记录为人提供了上下文连续性，但并不适合用来承载机器身份、任务生命周期、审批状态或执行证据。

消息描述的是交互过程。持久化的运行状态需要由界面之下明确的领域对象及状态转换来承载。

对话记录是一种呈现形式

对话把请求、决策和结果按照易于理解的顺序组织起来。它可以优先展示最新结果，同时保留先前的上下文以供查看。

但对话日志也可能包含重试、澄清、过时的表述和不完整的输出。根据最新一句话推断任务的当前状态会带来歧义。消息的先后顺序并不等同于状态转换契约。

分离不同的身份标识

机器标识对应执行环境，session 标识对应持续进行的交互，task 标识对应有明确边界的工作，而 message 标识则对应一次呈现事件。

这些对象的生命周期各不相同。重新连接后，可以继续向同一个 session 添加消息；对话仍在继续时，某个 task 可能已经完成；机器可能变得不可用，但此前的结果不应因此被改写。

对话记录可以引用这些身份标识，但不能取代它们。

对任务和审批的状态转换建模

排队中、执行中、等待中、已完成、失败和未解决等状态，都需要明确的证据以及受约束的状态转换。审批也是一道边界，必须与某个确切的操作或产物绑定。

对话中的说明可以解释为何审批仍处于等待状态，但具有权威性的凭证需要记录：审核的是哪个 revision，以及实际发生了哪次状态转换。如果内容发生变化，旧的审批结果不能悄无声息地沿用到新内容上。

将结果绑定到任务 revision

只有当输出能够归属于确切的任务 revision 和执行上下文时，它才能成为正式结果。带有明确边界的凭证可以防止迟到或重复的消息产生第二个终态结果。

如果证据缺失或不匹配，任务就应保持未解决状态。仅凭一条语气肯定的完成消息，并不足以证明任务已经完成。

根据状态重建界面

重新连接后，客户端应该读取具有权威性的 machine、session、task、approval 和 receipt 投影，再围绕这些状态渲染对话。它不应该重放不受约束的完整历史记录，然后猜测哪条消息才代表当前状态。

这样一来，呈现层就可以被替换。同一个 task 可以出现在对话、待处理队列或结果详情中，而不需要每个视图各自维护一套生命周期。

Chat 的价值在于，它能为人组织远程工作。只有当它用于呈现单一事实来源，而不是意外成为事实来源本身时，才具有可靠性。

正因如此，cmdop.com 将对话作为交互表层，同时把生命周期保留在对话之外的底层。对话记录只是工作的一个视图，绝不是工作的权威记录。

如果需要采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。