Tool Calls & Slash Commands

Jak Responses API reprezentuje narzędzia

Każdy krok typu function_call zawiera:

name - nazwa narzędzia
arguments - argumenty (JSON string)
call_id - unikalny identyfikator (np. toolu_01...)

Model oczekuje odpowiedzi z function_call_output i dopasowanym call_id:

{
  "type": "function_call_output",
  "call_id": "toolu_01...",
  "output": "{\"status\":\"ok\",\"data\":...}"
}

Mapowanie surface → narzędzia

Surface	Nazwa narzędzia	Output	Uwagi
Slash `/summary`	`vista.command.summary`	JSON z `subjective/objective/assessment/plan`	Lista w `responses-tools.json`
Slash `/order lab`	`vista.command.order_lab`	Payload zgodny z `tasksService.createTask`	`call_id` koreluje task → tool output
`@Patient` mention	`vista.context.lookup_patient`	JSON z `patient_id`, `visit_id`	`buildToolContextId` generuje `context_id`
AI Suggestions SOAP	`vista.soap.generate_section`	Tekst + metadane (`section: "assessment"`)	`sessionArchiveService` zapisuje `call_id`
Wizardy diagnostyczne	`vista.command.start_workflow::<name>`	`workflow_id`, `context_id`	Automations używają tej samej ścieżki

context_id

Własny identyfikator przechowywany w metadata lub argumentach narzędzia:

Surface	Format context_id
Slash commands	`slash:summary:vis_123`
`@` mentions	`mention:patient:pat_456`

Backend echo-uje metadata w response.output[].content[].annotations i w eventach.

Implementacja krok po kroku

sequenceDiagram
    participant UI
    participant TR as toolRegistry
    participant AI as UnifiedAI
    participant Model

    UI->>AI: input + tools
    AI->>Model: /v1/responses
    Model-->>AI: function_call (call_id)
    AI-->>UI: render placeholder

    alt Natychmiastowe (lookup_patient)
        UI->>UI: execute locally
    else Backend (SOAP, tasks)
        UI->>AI: create job
        AI-->>UI: job result
    end

    UI->>AI: function_call_output (call_id)
    AI->>Model: continue

1. Rejestr narzędzi

responses-tools.json + toolRegistry.ts:

Sortowanie, walidacja ToolId
Ta sama lista trafia do metadata.tools w /v1/responses

2. Emisja wywołania

Gdy model zwróci function_call:

Zapisujemy call_id w conversationHostSync + sessionArchiveService
Renderujemy placeholder w UI („Model wzywa narzędzie X”)

3. Asynchroniczne wykonanie

Typ	Przykład	Wykonanie
Natychmiastowe	`lookup_patient`	Frontend (`useAssistantToolCommands`)
Backend	SOAP, tasks	Job w Tauri (`voiceJobSync`, `tasksService`)

4. Odesłanie wyniku

{
  "type": "function_call_output",
  "call_id": "toolu_01...",
  "output": "{\"status\":\"ok\",\"data\":...}"
}

5. Obsługa błędów

Jeżeli wykonanie narzędzia się nie powiedzie:

{
  "type": "function_call_output",
  "call_id": "toolu_01...",
  "output": "{\"error\":{\"code\":\"...\",\"message\":\"...\"}}"
}

secure_logger loguje tool_call.failed wraz z call_id.

Diagnostyka

Narzędzie	Opis
`secure_logger`	Logi `tool_call.started/completed/failed`
`pnpm test:invoke`	Testy `conversationSync` / `voiceJobSync`
`aiTestsPanel.tsx`	Panel diagnostyczny - aktywne `call_id` + surface

Przyszłe rozszerzenia

code_interpreter - mechanizm identyczny (call_id wskazuje kontener CI)
web_search - ten sam flow z call_id