Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#1,169 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@auberginewly がすでに取り組んでいます。

2026年10月27日 から。

  • #1402 @auberginewly による — オープン

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
20/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
markdown
領域
ai, frontend

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
3.7k
フォーク
231
平均マージ
16時間 25分
マージ済み PR（30日）
331

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

getopenscreen/openscreen のほかの issue

getopenscreen/openscreen の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。