DeepSeek Harness 接入 Litefuse：完善 Agent 可观测与评估能力

DeepSeek 发布官方 Agent ------ DeepSeek Harness 后，很快引起了业界广泛关注，GitHub Star 短短几天便超过 15 万。

Litefuse 第一时间开发了 DeepSeek Harness 插件 dsh-litefuse-plugin，为 DeepSeek Harness 提供 Agent 可观测能力。接入后，用户可以在 Litefuse 中查看 Agent 的完整执行过程，包括每一步调用轨迹、上下文、Token 与成本消耗，以及 Subagent 多层嵌套等复杂调用结构。

除了 Agent Tracing，Litefuse 还可以进一步结合 Agent Evals，对不同运行结果进行效果评估，帮助开发者持续优化 Prompt、上下文管理以及 Agent 编排策略。

为什么还需要对接 Litefuse 可观测

DeepSeek Harness 本身已经提供了 Trajectory 能力。通过 Trajectory，开发者可以查看一次 Agent 运行中的输入、LLM 调用、工具调用，以及 Token、耗时等信息。对于单次会话调试来说，这套能力已经比较完整。

Litefuse 团队在适配过程中更关心的是另一个问题：当 Agent 开始调用 Subagent，甚至出现多层 Subagent 嵌套之后，能否在现有 Trajectory 基础上，进一步把调用层级、Token、成本和后续评估串起来，实现更全面、完整的 Agent 可观测。

基于 DeepSeek Harness "everything is a plugin" 的设计理念，以及 Litefuse 提供的面向 Agent 集成的 SKILL，使得两边的接入比较便捷简单。

通过下面的 Prompt，就可以让 Agent 按照 Litefuse 的集成规范完成插件开发：

参考 SKILL https://litefuse.ai/SKILL.md 为 DeepSeek Harness 开发 Litefuse Agent 可观测插件。

经过几轮交互后，dsh-litefuse-plugin 完成对 DeepSeek Harness Session/Event 的接入。

DeepSeek Harness 接入 Litefuse 的可观测效果

下面使用一个多层 Subagent 调用作为例子。

主 Agent 首先调用一个 Subagent，这个 Subagent 又继续调用两个 Subagent。接入 Litefuse 后，可以直接看到完整的嵌套关系。

为了进一步对比两套能力，我们让 DeepSeek Harness 自己读取同一次运行的 Trajectory 和 Litefuse Trace，并分析两者的区别。它给出的结论比较清晰、有参考价值。

DeepSeek Harness 的回答：（回答较长，可直接下滑到结尾看总结）

我已通过 litefuse 的 REST API（pk-lf-.../sk-lf-... + https://litefuse.cloud）拉取了 trace ff30cb31feb7b791fad914812199f722 的完整数据，并对照了本会话 DSH 的 Trajectory 视图（dsh-client-ui-trajectory 包）的数据模型。

先说一个关键事实：这两个页面观测的是同一次运行。 该 trace 就是上一轮的 subagent 演示，scope.name = "dsh-litefuse-plugin"、resourceAttributes.service.name = "deepseek-harness"，sessionId 正是我当前会话 session-ba23a65c-...。所以这是同一份 agent 行为，走了两套观测管线------一套是 DSH 自带的本地 Trajectory 视图，一套是 litefuse 的云上 trace。

我的 Trajectory 页面（DSH） ：一个按 turn 平铺的事件账本 ，行类型为 system / user / context / compacted / message / tool / subtool，主列只有 #序号 / 事件 / 内容摘要，点选后弹本地 inspector 看 token、耗时、Input/Output/Thinking；顶部有 Chrome-Network 式时间轴（TTFT/decode 分段、hover 精确到毫秒、拖拽聚焦）；支持折叠、搜索、Request 用量合计。数据来自本地 session.jsonl（我数了下，本轮 984 行事件，含 487 个 reasoning-chunks、194 个 assistant/chunk、144 个 tool-call-chunks 等底层流事件）。

litefuse trace ：同一个 turn 被建模成 1 个 trace + 16 个 span 的嵌套树，完整还原了层级委派：

1a4b6d53 AGENT  DeepSeek Harness --- Turn 1       30.281s  (root)
├─ ec8da246 GENERATION plan (2 tools) #1        17.57s   10139 tok  ttft 0.82s
├─ 5e9b5e27 TOOL      todo_write #2
├─ e2067712 TOOL      tool (1 subagent) #3      6.07s
│  └─ 9c02c0f7 AGENT   subagent (subagent 1)    6.05s
│     ├─ cb2b63d1 GENERATION plan (2 tools) #1  2.36s    8274 tok
│     ├─ 1b6ffbff TOOL    tool (1 subagent) #2  1.32s
│     │  └─ 62a3bcae AGENT subagent (subagent 2) 1.28s
│     │     └─ c4591ebd GENERATION subagent response 7852 tok
│     ├─ a83f6373 TOOL    tool (1 subagent) #3  1.49s
│     │  └─ 8e14ed17 AGENT subagent (subagent 3) 1.45s
│     │     └─ 407d78a0 GENERATION subagent response 7861 tok
│     └─ 77944cdb GENERATION subagent response  2.14s   8512 tok
├─ c69ecbdb GENERATION plan (1 tool) #4         1.74s
├─ 4e6b4135 TOOL      todo_write #5
└─ a071a1fd GENERATION response                 4.80s   10962 tok  ttft 1.34s

核心优势可以浓缩为五点：

1. 层级 Agent 的调用图可视化 ：DSH 账本按时间把一切拍平，而 litefuse 用 AGENT/GENERATION/TOOL 三类 span 的父子关系，把 主 agent → subagent 1 → subagent 2/3 的委派链、每层耗时与 token 独立拆出来------这正是"agent 可观测"相对"单次 LLM 调用可观测"的本质区别。
2. 成本是第一位公民 ：每个 span 有独立单价和 calculatedTotalCost，自动向上汇总。比如 Turn 1 里最贵的 span 是主 agent 第一次 plan（ $0.00068），整体0.00068），整体$ 0.00068），整体0.0026；DSH 只给 token 数，无法回答"这一轮花了多少钱、钱花在哪一步"。
3. 计费级 token 明细 ：output_reasoning_tokens（思维链 token）与 cache_read_input_tokens（KV 缓存命中）单独列账，直接对应真实计费口径；DSH 虽记了 think/cache 数，但不与价格联动、不参与成本归因。
4. 标准化 + 可编程 + 可持久化 ：OTel 语义（service.name/version、scope）可与其他观测栈互通；有 htmlPath 深链可分享、公开 API 和 CLI 可程序化查询；trace 持久在云端可跨会话聚合（DSH 是本地一次性账本，README 明确"无导出入口"）。
5. 评估与提示词版本闭环：trace 上能挂 scores、关联 datasets/prompt 版本，形成"运行→评估→迭代"的闭环，这是纯前端账本做不到的。

一句话总结：DSH Trajectory 是面向调试的单会话事件回放器 （好在其 token/TTFT/thinking 细节很全），litefuse 是面向 agent 系统的完整可观测平台------把一次 agent 运行结构化成可计费、可聚合、可评估、可分享的嵌套 span 图，差距主要在「层级调用图、成本归因、跨会话聚合与评估闭环」这四件事上。

我们结合上方信息进行一个综合性的总结，以给读者清晰直接的参考：

正如 DeepSeek Harness 在对比中总结的，Litefuse 在其原生 Trajectory 基础上，进一步补充了多层 Agent 调用关系、Token 与成本归因、完整上下文以及跨会话分析能力，可视化效果更丰富，并可以基于 Trace 数据继续进行 Agent Evals，为后续效果评估和迭代优化提供支撑。

如何快速使用

如果你也在使用 DeepSeek Harness，通过下面简单几步，就可以快速接入 Litefuse。

1）安装 dsh-litefuse-plugin 插件

npx @deepseek-ai/dsh plugin --profile web add -w dsh-litefuse-plugin

2）在 Litefuse Cloud 注册账号，创建 API Key，写入配置文件 ~/.dsh/.env 中

LITEFUSE_PUBLIC_KEY=pk-lf-...
LITEFUSE_SECRET_KEY=sk-lf-...

3）启动 DeepSeek Harness

npx @deepseek-ai/dsh web

完成以上 3 步，后续在 DeepSeek Harness 中的每一次对话，都会在 Litefuse Tracing 页面看到 Agent 执行过程。

实现原理

DeepSeek Harness 提供了插件机制，Litefuse 插件通过订阅 session/event 会话事件流，获取模型调用耗时、TTFT、Tool 执行时长、Cache 读写，以及实际发送给模型的上下文。

插件接下来需要完成的是，将这些原本按时间产生的事件重新组织成 Trace Tree。turn/start 到 turn/end 对应一条 Trace 及其根节点，每次模型调用映射为 Generation，每次工具调用映射为 Tool，run_code 内部触发的调用则作为嵌套 Span。普通 Generation 和 Tool 保持同层，真正产生层级的是 Subagent，因此 Litefuse 中 Trace Tree 的深度基本对应实际的 Agent 委派深度。

实现中更关键的是确定 Subagent 的父调用。Harness 为子会话提供新的 session_id 和父会话信息，但不会直接标明它由哪一次调用创建，而并发委派又比较常见。插件利用委派时原样传递到子会话中的 description 和 prompt 建立关联，并尽早完成父子绑定。因为 OTel Span 一旦导出，Parent 关系就不能再修改，父子关系如果一开始判断错误，后续 Trace Tree 也会随之失真。

在对接 Claude Code、Codex、Hermes、OpenClaw、Kimi Code 等多个 Agent 的过程中，Litefuse 团队进一步总结了一套 Agent Trace 规范：https://litefuse.ai/litefuse-agent-trace-spec.md。开发者可以基于这套规范接入 Litefuse，也可以直接让 Agent 参考 https://litefuse.ai/SKILL.md 完成插件开发。

加入开源社区

dsh-litefuse-plugin 第一个版本已经开源并发布到 npm ，欢迎 DeepSeek Harness 用户试用并反馈实际使用中的问题。