DeepSeek 发布官方 Agent ——DeepSeek Harness后很快引起了业界广泛关注GitHub Star 短短几天便超过 15 万。Litefuse 第一时间开发了 DeepSeek Harness 插件 dsh-litefuse-plugin为 DeepSeek Harness 提供 Agent 可观测能力。接入后用户可以在 Litefuse 中查看 Agent 的完整执行过程包括每一步调用轨迹、上下文、Token 与成本消耗以及 Subagent 多层嵌套等复杂调用结构。除了 Agent TracingLitefuse 还可以进一步结合 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 APIpk-lf-…/sk-lf-…https://litefuse.cloud拉取了 traceff30cb31feb7b791fad914812199f722的完整数据并对照了本会话 DSH 的 Trajectory 视图dsh-client-ui-trajectory包的数据模型。先说一个关键事实这两个页面观测的是同一次运行。该 trace 就是上一轮的 subagent 演示scope.name dsh-litefuse-plugin、resourceAttributes.service.name deepseek-harnesssessionId正是我当前会话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核心优势可以浓缩为五点层级 Agent 的调用图可视化DSH 账本按时间把一切拍平而 litefuse 用AGENT/GENERATION/TOOL三类 span 的父子关系把主 agent → subagent 1 → subagent 2/3的委派链、每层耗时与 token 独立拆出来——这正是agent 可观测相对单次 LLM 调用可观测的本质区别。成本是第一位公民每个 span 有独立单价和calculatedTotalCost自动向上汇总。比如 Turn 1 里最贵的 span 是主 agent 第一次plan$0.00068整体 $0.0026DSH 只给 token 数无法回答这一轮花了多少钱、钱花在哪一步。计费级 token 明细output_reasoning_tokens思维链 token与cache_read_input_tokensKV 缓存命中单独列账直接对应真实计费口径DSH 虽记了 think/cache 数但不与价格联动、不参与成本归因。标准化 可编程 可持久化OTel 语义service.name/version、scope可与其他观测栈互通有htmlPath深链可分享、公开 API 和 CLI 可程序化查询trace 持久在云端可跨会话聚合DSH 是本地一次性账本README 明确无导出入口。评估与提示词版本闭环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-plugin2在 Litefuse Cloud 注册账号创建 API Key写入配置文件 ~/.dsh/.env 中LITEFUSE_PUBLIC_KEYpk-lf-… LITEFUSE_SECRET_KEYsk-lf-…3启动 DeepSeek Harnessnpx 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每次工具调用映射为 Toolrun_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 用户试用并反馈实际使用中的问题。