Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

[Feature]: Show reasoning and tool execution as separate agent steps

Aberta
  • Algo errado?
#1,169 2 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

@auberginewly já está trabalhando nisso.

Desde 27/10/2026.

  • #1402 de @auberginewly — aberto

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
20/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
markdown
Domínio
ai, frontend

Direção de pesquisa

Start by finding where the existing thinking, toolStart and toolEnd events are emitted and where the chat panel consumes them, since the proposal reuses that flow. The issue asks for maintainer agreement on scope before any implementation, so the first step is a comment on the scope, not code. Done would mean an agreed split between the execution-steps view, persistence, and the Markdown work.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Search existing issues
  • I have searched the existing issues.
Is your feature request related to a problem?

When an AI edit takes several model and tool calls, it is difficult to tell whether the agent is reasoning, executing a tool, or waiting for a response. If a tool fails, the final response alone does not make it easy to see which step failed.

OpenScreen already has thinking, toolStart, and toolEnd events. The chat panel currently consumes thinking events live, while successful tool summaries appear with the completed reply. A unified, ordered view would make the existing execution lifecycle easier to follow.

Describe the solution you'd like

Add a collapsible execution-steps section for each agent turn, separate from the final answer and token usage summary:

  • Show provider-exposed reasoning separately from tool calls, preserving their observed order. Do not invent reasoning for providers that do not expose it.
  • Show each tool invocation with its name, a concise argument summary, running/succeeded/failed status, elapsed time, and a short result or error summary.
  • Distinguish repeated invocations of the same tool, and update concurrent calls independently using stable invocation IDs.
  • Keep the final assistant answer clearly separate from intermediate execution steps.
  • Retain completed and failed steps on the originating project/session/turn, including when the user switches sessions during execution; restore them after restarting the app.
  • Keep details collapsed by default and avoid storing raw provider payloads, credentials, or unrestricted tool output.

Example:

Execution steps
  Reasoning (expand, when provided)
  ✓ Read timeline          0.2s
  ✗ Detect silences        1.4s
    Audio file could not be read

Final answer
  Silence detection could not be completed...

Also support Markdown consistently for chat input and output:

  • Let users write or paste multiline Markdown in the composer, preserving line breaks, indentation, and fenced code blocks when sending.
  • Render user messages and final agent responses as Markdown, including headings, emphasis, lists, links, blockquotes, fenced code blocks, and tables.
  • Render exposed reasoning and human-readable tool summaries as Markdown where appropriate; keep structured arguments and raw tool data in clearly formatted code blocks.
  • Preserve the original Markdown source for copy actions and persistence rather than copying rendered markup.
  • Render safely, without executing embedded HTML or scripts.

Suggested acceptance checks:

  • A multi-call turn displays reasoning/tool steps separately from the final answer.
  • A running tool updates in place when it succeeds or fails.
  • Repeated and concurrent tool invocations are not conflated.
  • Providers without exposed reasoning still show useful tool progress.
  • Failed turns retain the completed steps and failure information.
  • Switching sessions does not move steps into another conversation; restarting restores saved steps.
  • Existing chat histories without execution steps remain readable.
  • Multiline Markdown survives composing, sending, copying, switching sessions, and restarting without losing source formatting.
  • User input and agent output render common Markdown elements consistently; code fences and tables remain readable.
  • Markdown rendering does not execute embedded HTML or scripts.
Describe alternatives you've considered

A single generic "Thinking" indicator is simple but does not explain tool progress or failures. A full debugging console with raw requests and responses would be much broader than this proposal; a compact, collapsible steps view should be sufficient for the first version.

Additional context

This is inspired by the separation of reasoning, tool execution, and final output in agent harness workflows, including DeepSeek Harness. It should remain provider-agnostic and reuse OpenScreen's existing event flow, without introducing a new agent runtime or dependency on DeepSeek Harness.

Related: #1096 covers per-turn token accounting and persistence. This proposal covers execution visibility and would be a separate contribution.

DeepSeek's reasoning/tool-call API documentation is one reference for the separation of these event types: https://api-docs.deepseek.com/guides/thinking_mode/

I'd like to implement this and submit a focused PR. Maintainer feedback on the proposed scope would be welcome before implementation.

Linguagem predominante
TypeScript
Estrelas
3.7k
Forks
231
Merge médio
16h 38min
PRs com merge (30d)
327

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de getopenscreen/openscreen

Todas as issues de getopenscreen/openscreen

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.