10 · 结果核验与诊断

一次操作有没有真正完成，出现问题时又该从哪里查起？Northstar 将工具结果、文件变化、审批和运行记录保留下来，支持核对实际结果与定位失败环节。

从执行到完成，需要可检查的结果

运行进度来自实际状态与事件，工具调用保留输入、返回和失败信息。关键操作可以结合对应文档、目标版本与交付回执核对，让用户知道当前正在处理什么、哪一步需要继续。

例如一次文档修改，工具返回“成功”之后，还需要确认目标内容是否按预期写入。代码候选则通过约定的验收命令检查结果，相关机制见 外部 Agent 委派与交付。

受管文件工具写入后再读回

对声明了变更契约的受管文件工具，系统捕获写入前后的内容或摘要，保存变更回执，并按工具定义核验目标。写文件核对完整内容，替换文本核对替换结果，补丁工具检查声明目标的实际变化。

这些检查证明的是指定变更是否落地，业务效果还需要相应评审与测试。普通命令、外部工具和 MCP 调用的验证方式取决于各自契约，不能默认具备同样的文件回读保护。

检查反馈帮助继续补齐验证

执行后的反馈会检查工具结果和已有观察。如果写入缺少验证依据，会要求补充读取或检查；发现声明的成功与实际结果不符时，保留问题并引导后续处理。这个过程有轮数和能力边界，不能替代独立验收。

对支持撤销的受管文件操作，系统在执行撤销前会核对：所有目标是否仍保持原操作完成时的内容。如果文件已有后续修改，就拒绝直接覆盖，交由用户处理新的差异。

运行记录按用途组织

这些记录可以通过会话和执行身份关联。运行检查点用于保存执行上下文，产品恢复点 还涉及仓库和受管产品状态的恢复，两者服务于不同范围。

结果未知，也是一种需要保留的事实

明确这些状态，能帮助接手者判断应该查结果、补充材料还是重新执行。具体续接方式见 执行与失败恢复。

诊断基础与未来应用

Northstar 自身已有结构化运行记录和维护诊断工具，用于汇集状态、失败原因与执行证据，帮助定位运行或流程异常。诊断会保留无法确定的结果，能收集证据的范围取决于现有记录。

把这类能力扩展到用户产品的监控、日志、发布、代码和人员关系，是下一篇 线上问题定位与可靠性 的规划方向。它需要进一步的数据接入与关联建设。