Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#1,169 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@auberginewly ya está trabajando en esto.

Desde el 27/10/2026.

  • #1402 de @auberginewly — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
markdown
Área
ai, frontend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
3.7k
Forks
231
Merge medio
16 h 38 min
PR fusionados (30 d)
327

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de getopenscreen/openscreen

Todos los issues de getopenscreen/openscreen

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.