为何比什么更难 | AI生成和翻译
两个问题都切中了实际痛点。
What 与 Why — “Why” 更难追溯。
“What”会留下痕迹：工具调用被记录、文件有差异、终端输出被捕获在会话消息中。你可以从会话数据库中重建操作序列。
“Why”是转瞬即逝的。模型的推理发生在流式过程中——reasoning_content 可能存储在消息中，但通常并未完全持久化；而影响决策的上下文（为何选择方案 A 而非 B、为何选定那个文件路径、为何决定先重构再修复）会在多轮对话后丢失，尤其是在 /compress 之后。工具调用显示的是 write_file(path, content)，而非“我选择这个结构是因为三轮前在那条错误消息中看到了什么”。
正因如此，Hermes 会保存轨迹（save_trajectories=True）——它们捕获了包括工具结果在内的完整消息链。但即使轨迹也只展示了模型的输出，而非产生这些输出的潜在推理过程。
实用的缓解措施：
- 详细的工具输出有帮助（“为什么”有时会出现在工具调用之前的模型文本中）
- 会话搜索可以恢复决策周围的上下文
- 先编写计划（
/plan模式）将“为什么”外部化为一个 Markdown 文件
任务中途中断——三种场景：
-
用户中断（Ctrl+C / /stop）： 在迭代边界和流式处理过程中，代理会检查
_interrupt_requested。进行中的 API 调用的连接会被终止。工具执行（例如正在运行的终端命令）可能完成，也可能部分留下。会话会持久化到最后一个完成的轮次。 -
网络/提供商故障： 重试循环会处理这种情况（正如我们之前讨论的）。如果重试耗尽，会话会持久化并包含一条错误消息。你可以继续——模型会在历史中看到错误并继续执行。
-
进程崩溃/超时： 会话数据库（SQLite）会在每个轮次边界持久化消息。中途崩溃会丢失该轮次的工作，但之前的所有内容都会保留。
/resume会从数据库重新加载。
真正的危险在于部分副作用：子代理写入半份文件、终端命令修改状态后代理崩溃、Git 提交已完成但后续修复未执行。没有事务性回滚机制。这就是为什么长时间任务受益于：
- 频繁提交（这样你可以
git diff/git stash） - 将计划作为检查点（
.hermes/plans/） - 将工作拆分为子代理（每个子代理近似原子化——要么整体成功，要么整体失败）