mirror of
https://github.com/coder/coder.git
synced 2026-09-24 15:04:27 +08:00
Kyle Carberry
b969d66978
Adds client-executed dynamic tools to the chat API. Dynamic tools are
declared by the client at chat creation time, presented to the LLM
alongside built-in tools, but executed by the client rather than chatd.
This enables external systems (Slack bots, IDE extensions, Discord bots,
CI/CD integrations) to plug custom tools into the LLM chat loop without
modifying chatd's built-in tool set.
Modeled after OpenAI's Assistants API: the chat pauses with
`requires_action` status when the LLM calls a dynamic tool, the client
POSTs results back via `POST /chats/{id}/tool-results`, and the chat
resumes.
See [this example](https://github.com/coder/coder-slackbot-poc) as a
reference for how this is used. It's highly-configurable, which would
enable creating chats from webhooks, periodically polling, or running as
a Slackbot.
<details>
<summary>Design context</summary>
### Architecture
The chatloop **exits** when it encounters dynamic tools and
**re-enters** when results arrive. No blocking channels, no pubsub for
tool results, no in-memory registry. The DB is the only coordination
mechanism.
```
Phase 1 (chatloop):
LLM response → execute built-in tools only →
Persist(assistant + built-in results) →
status = requires_action → chatloop exits
Phase 2 (POST /tool-results):
Persist(dynamic tool results) →
status = pending → wakeCh → chatloop re-enters
```
### Validation (POST /tool-results)
1. Chat status must be `requires_action` (409 if not)
2. Read chat's `dynamic_tools` → set of dynamic tool names
3. Read last assistant message → extract tool-call parts matching
dynamic tool names
4. Submitted tool_call_ids must match exactly (400 for missing/extra)
5. Persist tool-result message parts, set status to `pending`, signal
wake
### Idempotency
Tool call IDs scoped per LLM step. State machine (`requires_action` →
`pending`) is the guard. First POST wins, subsequent get 409.
### Mixed tool calls
When the LLM calls both built-in and dynamic tools in one step, built-in
tools execute immediately. Their results are persisted in phase 1.
Dynamic tool results arrive via POST in phase 2. The LLM sees all
results when the chatloop resumes.
</details>
> 🤖 Generated by Coder Agents
50 lines
1.3 KiB
Go
50 lines
1.3 KiB
Go
package pubsub
|
|
|
|
import (
|
|
"context"
|
|
"encoding/json"
|
|
"fmt"
|
|
|
|
"github.com/google/uuid"
|
|
"golang.org/x/xerrors"
|
|
|
|
"github.com/coder/coder/v2/codersdk"
|
|
)
|
|
|
|
func ChatEventChannel(ownerID uuid.UUID) string {
|
|
return fmt.Sprintf("chat:owner:%s", ownerID)
|
|
}
|
|
|
|
func HandleChatEvent(cb func(ctx context.Context, payload ChatEvent, err error)) func(ctx context.Context, message []byte, err error) {
|
|
return func(ctx context.Context, message []byte, err error) {
|
|
if err != nil {
|
|
cb(ctx, ChatEvent{}, xerrors.Errorf("chat event pubsub: %w", err))
|
|
return
|
|
}
|
|
var payload ChatEvent
|
|
if err := json.Unmarshal(message, &payload); err != nil {
|
|
cb(ctx, ChatEvent{}, xerrors.Errorf("unmarshal chat event: %w", err))
|
|
return
|
|
}
|
|
|
|
cb(ctx, payload, err)
|
|
}
|
|
}
|
|
|
|
type ChatEvent struct {
|
|
Kind ChatEventKind `json:"kind"`
|
|
Chat codersdk.Chat `json:"chat"`
|
|
ToolCalls []codersdk.ChatStreamToolCall `json:"tool_calls,omitempty"`
|
|
}
|
|
|
|
type ChatEventKind string
|
|
|
|
const (
|
|
ChatEventKindStatusChange ChatEventKind = "status_change"
|
|
ChatEventKindTitleChange ChatEventKind = "title_change"
|
|
ChatEventKindCreated ChatEventKind = "created"
|
|
ChatEventKindDeleted ChatEventKind = "deleted"
|
|
ChatEventKindDiffStatusChange ChatEventKind = "diff_status_change"
|
|
ChatEventKindActionRequired ChatEventKind = "action_required"
|
|
)
|