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

Feature Request: decode `Response.StreamPart` without toolkit provided

クローズ
  • 何か問題がありますか？
#7,152 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

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

2026年9月20日 から。

  • #9674 @effect-bot による — マージ済み

評価

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

調査の方向性

Start by reading ai/Response.ts, especially ToolCallPart(), and compare its required toolkit and literal tool-name schema with the dynamic-tool model in ai/Tool.ts. The work is complete when encoded stream parts can be decoded without a toolkit, accepting dynamically named tools and JSON parameters while preserving the existing strict path.

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

説明

enhancement
What is the problem this feature would solve?

I wrote a transform function that converts ACP (agent client protocol) SessionUpdate stream into Response.StreamPartEncoded stream, and then sends it to the frontend via SSE for UI display.
However, I ran into trouble when I needed to decode the data into Response.StreamPart, because the toolkit parameter is mandatory.
The ACP protocol does not report the tools the agent uses, nor the corresponding input/output schemas.
In fact, in the ACP stream, tool names and input/output data appear dynamically and no dedicated schema is ever provided, which makes it impossible to define a toolkit.
On the other hand, I don't actually need a strict schema to decode the inputs and outputs of these tools, because for UI display I only need to treat them as ordinary JSON objects.

I noticed that Tool.dynamic is provided in ai/Tool.ts to represent scenarios where the schema is determined at runtime.
But this design cannot solve the case where even the tool name is unknown, because in ai/Response.ts the Schema generated by ToolCallPart() is:

Schema.Struct({
  name: Schema.Literal(name),
  params: someParametersSchema,
});

This means it will always reject dynamic tool names.

What is the feature you are proposing to solve the problem?

Specifically, this problem shows up when the toolset of an AI system that uses the current effect ai message model cannot be predetermined. This can happen in cases such as:

  • Merely using the effect ai message model as an intermediate layer for external message models, as in the case I described above;
    • Currently effect only ships providers for OpenAI, Anthropic, and OpenRouter; if more providers are supported in the future, the situation where the toolset cannot be predetermined will become more common;
  • Tools are not defined on the client, but are implicitly provided to the AI system, such as server-side executed tools like the OpenAI Response computer-use;

For these cases, I think a loose Schema that does not require a specific toolkit would be very convenient and also acceptable in terms of real usage:

// tool call part schema that will accept any tool
const AnyToolCallPart = Schema.Struct({
  name: Schema.String,
  params: Schema.Json,
});
What alternatives have you considered?
Build toolkit on the fly

I came up with a hacky way to read the tool name of the encoded tool-call part, and then build a toolkit on the fly with a dynamic tool definition. Can work but not ideal:

const toolkitFor = (name: string): Toolkit.Any =>
  Toolkit.make(
    Tool.make(name, {
      parameters: Schema.Unknown,
      success: Schema.Unknown,
      failure: Schema.Unknown,
    }),
  );
ai SDK

The AI SDK also keeps a strict schema-based path for registered tools, but keeps an escape hatch for tools that were not registered. It falls back to a bare JSON parse with no validation.

// ...
} catch (error) {
  const parsedInput = await safeParseJSON({ text: toolCall.input }); // just json parse, no schema validation
  return { type: 'tool-call', toolCallId, toolName, input, dynamic: true, invalid: true, error };
}
AI SDK community provider: acp-ai-provider

The tool-call emitted in the stream of acp-ai-provider never uses the agent's real tool name; instead it uniformly uses a placeholder Provider tool:

import { tool, jsonSchema } from "ai";

export const ACP_PROVIDER_AGENT_DYNAMIC_TOOL_NAME = "acp.acp_provider_agent_dynamic_tool";

export function getACPDynamicTool() {
  return {
    [ACP_PROVIDER_AGENT_DYNAMIC_TOOL_NAME]: tool({
      type: "provider",
      id: ACP_PROVIDER_AGENT_DYNAMIC_TOOL_NAME,
      args: {},
      inputSchema: jsonSchema({}),
    }),
  };
}

The real information is packed into a wrapper object:

import { z } from "zod";

export type ProviderAgentDynamicToolInput = {
  toolCallId: string;
  toolName: string;
  args: Record<string, unknown>;
};

export const providerAgentDynamicToolSchema = z.object({
  toolCallId: z.string(),
  toolName: z.string(),
  args: z.record(z.unknown()),
});
主要言語
TypeScript
スター
16.7k
フォーク
808
平均マージ
10時間 33分
マージ済み PR（30日）
830

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

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

Effect-TS/effect のほかの issue

Effect-TS/effect の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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