Lightweight observability for local development

[BruceWayne4]

DeerFlow currently integrates with tools like Langfuse for observability. While working locally, I found that for simple development and debugging workflows, this setup can feel a bit heavy.

I was wondering if there’s interest in supporting a more lightweight, built-in way to inspect execution flows—especially for:

• understanding how tasks are broken down across agents
• debugging intermediate steps and failures
• improving the local development experience

Curious if this is something already considered in the roadmap, or if there are preferred approaches for lightweight tracing/debugging within DeerFlow.

Happy to explore this further or contribute in this area if it aligns.

[DaoyuanLi2816]

This use case now has a possible extension-based path: the current host exposes caller-scoped RunEvidenceReader APIs and full-stack plugin surfaces. I'd like to help implement a small, optional read-only diagnostic plugin, rather than add an observability service to the default deployment.

One concrete workflow would be: after a run fails or is interrupted, a user selects that run and inspects its authoritative status plus a paginated timeline of persisted events, including an explicit indication when evidence is missing. The existing evidence-reader tests pass on main 63e399f2 (23 tests); that validates the foundation, not a completed plugin.

The initial scope would exclude evaluation suites, LLM judging, automatic retries, global/admin visibility, external telemetry export, and another subagent step UI. Subtask cards already provide their own step timelines. It would reuse request-scoped readers for the authenticated user's runs, avoid exposing raw payloads under an assumption of complete redaction, and not equate collected events with successful task completion.

This should remain distinct from #4070/#4083's evaluation effort: no new eval orchestration or runtime subsystem. A small integration spike would first verify the route/browser-page contract before proposing any host changes.

Are you still pursuing the original proposal, or would this be a useful slice to collaborate on? @AnnaSuSu @Vanzeren Would an optional plugin example fit the intended extension boundary, or would you prefer adjacent CLI tooling? I'm willing to take a focused implementation once the scope and existing ownership are agreed.

[AnnaSuSu]

An optional read-only diagnostic plugin looks like a reasonable starting point to me. LLM Space, DeerFlow's sister project, would be a useful reference for the Trace / Debug interaction: selecting a historical run, inspecting model messages and tool arguments/results, and stepping through the recorded execution to locate a failure.

Its core concepts documentation already lists DeerFlow run-event JSONL as a supported import format. For the initial spike, I'd suggest importing a real failed or interrupted DeerFlow run to see how much the existing workflow covers and identify what the in-app plugin should add. Import support alone does not establish complete event coverage or a live connection.

For the first version, I'd keep the plugin focused on the authenticated user's authoritative run status, a paginated timeline of persisted events, and clear indications of evidence availability or known gaps. That fits the small diagnostic scope you outlined. Your proposed route/browser-page integration spike would be a useful next step before considering any host changes.

[BruceWayne4]

Hey @DaoyuanLi2816, this approach seems like a good starting point. I'm up for collaboration with @AnnaSuSu and @Vanzeren.
Though this will be my first open source contribution, I may need initial help in collaboration process.

Thanks

[BruceWayne4]

Hey @AnnaSuSu and @Vanzeren , Have you started on this?

Thanks

[AnnaSuSu]

@BruceWayne4 Please go ahead and take the lead on this as an optional DeerFlow plugin. My earlier reply was guidance on the direction and scope; I'm happy to review your PR when it's ready.

DeepSeek Harness and LLM Space are useful references to explore. Please build against DeerFlow's existing plugin interfaces and start with the small read-only diagnostic scope discussed above: run status, a paginated event timeline, and clear indications of missing evidence.

@DaoyuanLi2816 also offered to help implement this, so please coordinate here on the split of work to avoid overlap. Feel free to post any concrete questions as you get started.