feat(run): execute multi-phase pipelines (RunnableAgent.Phases)
The kernel carried RunnableAgent.Phases as a DTO but never executed it —
Run always ran a single agent loop with ra.SystemPrompt, so a phased agent
(mort's deepresearch/research) silently ran one loop with the base prompt
instead of its pipeline. This implements the phase loop, ported from mort's
agentexec pipeline but reusing the kernel's own machinery.
- run/phases.go: runPhases / runOnePhase. Phases run sequentially; each is a
fresh agent loop (or a bare LLM call for IsRunFunc phases) with its own
template-expanded system prompt ({{.Query}} + {{.<PhaseName>}}), model
tier, step cap, and tool subset. Outputs thread into later phases; the
final phase's output is the run output. Optional phases swallow errors and
substitute FallbackMessage; a non-optional phase that merely exhausts its
step/tool budget salvages its partial transcript and continues (a hard
error still aborts); per-phase tier-resolve failures fall back with a WARN.
- run/agent.go: Phase gains IsRunFunc + FallbackMessage (the kernel Phase
struct previously omitted them).
- run/executor.go: Run factors the shared agent options (tool-error limits,
step observer, compactor) and branches — single loop (critic's dynamic
step ceiling) vs the phase runner (fixed per-phase caps; the run-level
critic's steer + hard deadline still apply across phases). systemPrompt
now delegates to systemPromptWithBody so each phase keeps the platform
header. The same step observer feeds audit/steps/critic across all phases.
Tests (run/phases_test.go): sequential output threading + template
expansion, Optional-failure → FallbackMessage continues, hard-error abort,
IsRunFunc bare call, per-phase SystemHeader, filterToolbox subset, template
expansion. Full ./... suite green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
+15
-3
@@ -55,15 +55,27 @@ type RunnableAgent struct {
|
||||
}
|
||||
|
||||
// Phase is one step of a multi-step run: its own system prompt, model tier,
|
||||
// iteration cap, and tool subset. Optional phases may be skipped by the
|
||||
// pipeline when their precondition isn't met.
|
||||
// iteration cap, and tool subset. Phase prompts are Go text/template strings
|
||||
// expanded against {{.Query}} (the original input) and {{.<PhaseName>}} (a
|
||||
// prior phase's output) before the phase runs, so a phase can consume earlier
|
||||
// work. The final phase's output is the run's output.
|
||||
type Phase struct {
|
||||
Name string
|
||||
SystemPrompt string
|
||||
ModelTier string
|
||||
MaxIterations int
|
||||
Tools []string
|
||||
Optional bool
|
||||
// Optional swallows a phase's error and substitutes FallbackMessage (or a
|
||||
// generated note) as its output, so a non-critical phase failing does not
|
||||
// abort the pipeline.
|
||||
Optional bool
|
||||
// FallbackMessage is the substitute output when an Optional phase fails.
|
||||
// Empty → a generated "(phase %q encountered an error…)" note.
|
||||
FallbackMessage string
|
||||
// IsRunFunc marks a phase as a single bare LLM call (no tool loop, no tools
|
||||
// array) — a deterministic transform step (plan/synthesize) rather than an
|
||||
// agentic loop. Its Tools/MaxIterations are ignored.
|
||||
IsRunFunc bool
|
||||
}
|
||||
|
||||
// CriticConfig configures the optional run-critic. Enabled gates whether a
|
||||
|
||||
Reference in New Issue
Block a user