Documentation
¶
Overview ¶
Package harness defines a common execution boundary and lifecycle hooks for interacting with agents, planners, or external gRPC services.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func DrainStream ¶
func DrainStream(ctx context.Context, stream proto.HarnessService_ConnectClient, execID string, handler Handler) error
DrainStream reads from the harness gRPC stream until io.EOF, dispatching messages to the handler, and returns the final execution status.
Types ¶
type Execution ¶
type Execution interface {
// Run executes the session and streams events to the provided Handler.
// It blocks until the current turn completes or fails.
Run(ctx context.Context, handler Handler) error
// Queue enqueues new input messages to be processed in the next turn.
Queue(ctx context.Context, msg ...*proto.Message) error
// ID returns the unique execution session ID.
ID() string
// Close cleanly releases all resources associated with the execution session.
Close(ctx context.Context) error
}
Execution represents an active interactive session with an agent or planner.
type Handler ¶
type Handler interface {
// OnMessage is invoked when the agent generates output content during its turn.
OnMessage(ctx context.Context, execID string, msg *proto.Message) error
// OnComplete is invoked when the agent finishes its current execution turn.
OnComplete(ctx context.Context, execID string) error
}
Handler defines the streaming event hook callbacks for an execution turn.
type Harness ¶
type Harness interface {
// Start initializes a new Execution session for a conversation. harnessConfig
// carries optional per-request harness configuration; it is opaque to the
// controller and interpreted by the harness implementation.
Start(ctx context.Context, conversationID string, harnessConfig []byte) (Execution, error)
}
Harness represents a service capable of starting execution sessions.
Single-writer expectation: the controller must ensure that at most one Execution exists per conversation id at a time. Harness implementations rely on this invariant -- for example, a harness that durably persists per-conversation state may use a last-write-wins store without compare-and-swap, which is correct only because there is a single writer per conversation.
Source Files
Directories