博客 · 分析

隐藏的开发者福利：只追加的会话日志

2026 年 8 月 14 日 · dshbase

DeepSeek Harness 对开发者最友好、也最容易被忽视的特性之一，是它把会话存成只追加的事件日志。大多数 Agent 只给你一个最终答案，失败时给一句模糊的报错。DSH 给你整条轨迹——我们对着它排了一周插件的问题，现在能说清楚这份东西到底值多少。

日志里有什么

模型看到和做的一切都成为事件：

模型下一轮看到的历史是从这份日志重新推导出来的——不是来自一个黑盒状态。正是这个设计让一切都可以被检查：不存在日志会与之脱节的黑盒状态，因为日志本身就是真相的来源。每一轮都是它之前事件的纯函数。

大多数 Agent 失败时，你只能看到「任务失败」或无限循环——根本不知道它在哪一步跑偏。DeepSeek Harness 的轨迹视图可以按来源查看每一次运行。对开发者意味着：

这对研究和调试生产环境里的 Agent 都极有价值。但理论只有在真实故障上兑现才算数——对我们来说，它兑现了。

在 dsh 0.1.0-rc.6 上为插件目录实测 101 个社区插件时，会话日志就是「这插件坏了」和「坏在具体哪一行」之间的差别。三类反复出现的故障，因为有了日志而变得一眼可查：

ERR_REQUIRE_ESM——日志显示插件模块因被编译成 CommonJS、却依赖了 ESM-only 包而加载失败。失败事件直指模块本身，而不是我们的环境。
cannot get property "systemPrompt" without inject——日志捕获到插件调了 ctx.systemPrompt 却没声明 inject: ["systemPrompt"]。没有事件轨迹，这是一次莫名崩溃；有了它，就是发给插件作者的一句话报告。
静默失效的插件——没有 dsh.bundle 清单的包只当普通依赖装上、永远不加载。日志让「没加载」这件事变得可见：没有插件初始化事件、没有报错，只有「缺席」。

最后一条是最微妙的胜利。黑盒 Agent 会什么都不显示——插件「就是不能用」。事件日志能让你看到某个事件的缺席，这本身就是诊断信息。这些的一行修复都在我们的排错指南里。

同一份日志还能当成本剖析器用。每个事件都显示进了什么上下文，于是你可以：

把可检查的日志和缓存友好的请求形态结合起来，你就拿到了99.93% 缓存命中率的那套打法。可观测性和成本，其实是同一特性的两面。

只追加的设计，也是让Codex 对比里的「可重建会话」不止是一句说辞的原因。因为下一轮历史是从事件重新推导的，会话可以恢复、重放、分叉而不丢轨迹——一份能从事件重建的会话日志，是一份你信得过、能当调试记录用的日志，而不只是一份聊天记录。

不是。聊天记录是用户看到的。事件日志包含模型内部看到的一切——推理、工具结果、权限变化、注入——而且它是下一轮历史重新推导的来源。

能。因为下一轮是从日志重新推导的，从事件重放一次运行能复现相同状态——对复现 bug 和研究都很有用。

恰恰是它最帮得上忙的地方。静默失效不报错，但日志会显示「预期事件缺席」——插件从没初始化——把你引向缺失的 dsh.bundle 清单。

两者都把中间状态藏着。DSH 把整条轨迹作为一等数据暴露出来，这是它和闭源 harness 之间最大的可观测性差异。