博客 · 教程
Trajectory 追踪：竞品隐藏的 killer feature
2026 年 8 月 14 日 · dshbase
DeepSeek Harness 反复被提及的最大差异化特性是：每次运行都可追踪。当 Agent 失败或死循环时，你能看到它具体在哪一步跑偏——而 OpenAI、Anthropic 把这类信息加密隐藏起来，不给你看。下面说说它到底是什么，更重要的是怎么真正用起来。下面每一条，都是在 dsh 0.1.0-rc.6 上调试时得出的。
轨迹追踪到底是什么
DSH 把会话存成只追加的事件日志。每个系统提示词、用户消息、推理步骤、工具调用和结果、权限变化、上下文注入、压缩、子 Agent 调度都成为事件。模型下一轮的历史是从这个日志重新推导的，而不是来自黑盒。轨迹视图让你按来源检查每次运行——所以你不只看到发生了什么，还能看到是哪个插件或工具发出的每个事件。完整拆解见日志里有什么。
为什么重要：竞品把信息加密藏起来了
美国模型（OpenAI、Anthropic）把这当作隐藏的内部状态——你看不到中间推理、工具调用，也不知道任务在哪一步跑偏。你只拿到一个最终答案，失败时就是一个含糊的报错。DSH 给你完整轨迹。对调试和研究来说，这是实打实的优势——也是「瞎猜失败原因」和「直接读到导致失败的那条事件」之间的差别。
用它来调试
- 定位跑偏点——打开轨迹视图按顺序走事件；失败几乎总是某个具体的工具调用或权限决策，而不是最后一行。
- 检查工具结果——答案错误往往是工具返回了坏数据，而不是模型出错。追溯工具的输出。
- 审查权限变化——如果 Agent 做了意外的事，权限事件会显示何时、为什么被允许。
这份日志还能把最常见的插件故障从「谜团」变成「读数」。我们反复撞上的三种，以及它们的日志特征：
- 插件永远不激活——日志显示包被加成了依赖，但没有 load 事件。这就是缺
dsh.bundle清单的特征。 ERR_REQUIRE_ESM——以精确的加载失败形式出现在日志里，说明插件被编译成 CommonJS、却依赖了 ESM-only 的包。cannot get property "systemPrompt" without inject——在插件代码读ctx.systemPrompt却没声明inject: ["systemPrompt"]的那一刻，作为一条错误事件浮现。
每种都有一行式修复，见排错指南。这里的关键是：有了轨迹视图，你能拿到精确的报错字符串，这让「修复」变成一次查表，而不是一次瞎猜。
我们测试里有个具体案例：一个用 dsh plugin add github:owner/repo 装的插件，在目录里看着好好的，Agent 却从不用它。按顺序走一遍轨迹，我们只看到一条「依赖已添加」事件，然后就没了动静——没有 load 事件。这个特征（有依赖、无 load）就是缺 dsh.bundle 的信号。读出来只要三十秒，直接指向修复；瞎猜要烧掉十分钟，还容易得出错误结论。
用它来省 token
轨迹日志也是一个成本分析器。每个事件显示什么进了上下文：
- 发现重复发送的上下文——同一大段内容反复出现，说明它被反复注入（也反复计费）。
- 找多余的工具往返——长长的读/搜索调用链可以合并成一次（这正是 PTC 模式的用途）。
- 检查压缩——看上下文何时被压缩、是否丢掉了有用的历史。
配合缓存友好的 harness 设计（最小工具集、只追加会话），你就能复现99.93% 缓存命中率的打法。两者是直接关联的：一份只追加日志同时也是一段稳定的请求前缀，而稳定的前缀正是让 DeepSeek 自动前缀缓存持续命中的关键。
结论
轨迹追踪把一个不透明的 Agent 变成可检查的 Agent。对认真跑 Agent 的人来说——调试失败或优化成本——它不是锦上添花，而是选择「不隐藏自己工作」的 harness 的理由。竞品收你的 token 费，还把账单加密；DSH 把账单一行一行递给你。
FAQ
轨迹追踪会拖慢 Agent 吗？不会——会话本来就以事件日志的形式存在，视图只是去读那个结构。你在读的是一手真相，不是额外开销。
能看到模型的隐藏推理吗？你能看到 harness 记录成事件的推理步骤（系统提示词、工具调用、结果），而不是模型私有的内部思维链——这也是所有厂商都守住的同一条边界。
怎么区分缺 dsh.bundle 和真正的崩溃？缺清单意味着插件被加为依赖、却不发 load 事件；崩溃会带着精确报错发出 error 事件。日志把两者分得很清楚。