Skip to main content

Crate scx_forge_agent

Crate scx_forge_agent 

Source
Expand description

scx-forge-agent: an LLM-driven optimizer for sched_ext schedulers.

Hybrid loop: deterministic code owns build/validate/keep-revert/stop; the LLM is called only to propose one coherent policy experiment per round (and to fix build errors). The reward function is the built-in validation harness (validate.rs). The target scheduler is whatever [scheduler].package in the spec names (any scheds/rust/<name> crate); the agent modifies that crate in place. See tools/scx_forge_agent/README.md.

ModulesΒ§

agent_cli πŸ”’
Subprocess backends: drive a round’s edits by shelling out to the claude, opencode, codex, or cursor-agent CLI in non-interactive mode, run with the scheduler crate directory as the cwd so the CLI’s own tools edit the files in place. The controller then builds/validates the resulting diff exactly as it does for the built-in openai backend, so keep/revert/dedup work unchanged.
api πŸ”’
OpenAI-compatible /chat/completions client with a tool-calling loop.
color πŸ”’
Minimal ANSI coloring for live terminal progress.
config πŸ”’
Model configuration from the spec and SCX_FORGE_* environment variables, and the backend the agent uses to drive edits.
git πŸ”’
In-place checkpoint/revert for the optimization loop, using the git index.
http πŸ”’
HTTP client for an OpenAI-compatible inference endpoint: large request bodies and long server think times.
interrupt πŸ”’
model_timeout πŸ”’
progress πŸ”’
TTY-only progress spinners for local blocking phases.
report πŸ”’
Optimization run report: per-round history table, markdown and JSON renderers.
spec πŸ”’
Validation spec model (parsed from the TOML the agent points the harness at).
sudo πŸ”’
Resolve how the harness gains root to load the scheduler, and build the privileged commands. Ported from the Python harness’s setup_sudo.
tools πŸ”’
Sandboxed tools exposed to the model as OpenAI function calls. Target-crate tools (read_file, list_dir, grep, optional rg, web_fetch, and gated edit_file) resolve paths relative to the scheduler crate or public URLs; comparison tools read other schedulers under scheds/rust but never write them. Host-topology tools run fixed read-only commands or read fixed sysfs CPU cache metadata paths. Absolute paths and .. are rejected, and canonicalized targets must stay inside their configured roots.
usage πŸ”’
Token-usage accounting summed across the whole optimization run, plus the one-line footer (prompt:24.3k tokens:515) printed at the bottom of the output. The footer shape mirrors boro’s progress UI.
validate πŸ”’
Native validation harness: the agent’s reward function.

StructsΒ§

ActiveModelPrinter πŸ”’
AttemptTags πŸ”’
OptimizeArgs πŸ”’
OptimizeOutcome πŸ”’

EnumsΒ§

Phase πŸ”’
Two stages of the optimization: tune the scheduler’s existing configuration knobs first, then propose new mechanisms. The model drives the transition by emitting the completion sentinel; both phases share the [ai].rounds budget.

ConstantsΒ§

KNOB_MD πŸ”’
KNOB_PHASE_DONE_SENTINEL πŸ”’
Sentinel a knob-phase planner emits when no untested knob value looks promising any more, telling the controller to move on to code changes.
OPTIMIZER_MD πŸ”’
SKILL_MD πŸ”’
The resource markdown files are embedded at compile time so prompt edits stay close to the domain text instead of the Rust control flow.

FunctionsΒ§

agent_dim πŸ”’
agent_error πŸ”’
agent_info πŸ”’
agent_log πŸ”’
agent_success πŸ”’
agent_warn πŸ”’
append_attempt_summary πŸ”’
attempt_memory_for_prompt πŸ”’
attempt_summary_line πŸ”’
base_system πŸ”’
bpf_const_volatile_initializer_name πŸ”’
bpf_const_volatile_initializer_only_vars πŸ”’
build_keep_running_scheduler πŸ”’
build_with_fix_loop πŸ”’
cargo_build πŸ”’
Build the scheduler crate. Returns Err(combined output) on failure.
cargo_build_with_progress πŸ”’
cargo_program πŸ”’
classify_attempt πŸ”’
classify_policy_area πŸ”’
coding_system_prompt πŸ”’
configure_sudo_from_spec πŸ”’
contains_any πŸ”’
diff_file_path πŸ”’
direction_stopword πŸ”’
edit_prompt πŸ”’
The coder is handed exactly the planner’s plan - nothing else. Build-fix and runtime-fix rounds have no plan, so they fall back to the round context plus the failure to repair.
expand_glob_path πŸ”’
expand_sudo_password_file πŸ”’
history_table πŸ”’
home_dir πŸ”’
ineffective_round_edit_reason πŸ”’
ineffective_round_note πŸ”’
install_ctrl_c_handler πŸ”’
interrupted_requested πŸ”’
knob_edit_prompt πŸ”’
Knob-phase coder prompt. With a planner plan (openai backend) it just asks the coder to apply that one-line default change. Without a plan (subprocess backends, which have no separate planner) it carries the round context plus the knob inventory so the coder can pick and apply a knob itself.
knob_inventory πŸ”’
Assemble the scheduler-agnostic knob inventory the knob-phase model tunes from: the binary’s --help (every option, its default, and - for enums - its possible values, rendered by clap). This needs no per-scheduler hand-maintenance, works for any scheds/rust/<package> crate, and can never go stale relative to the options the scheduler actually exposes.
knob_phase_complete πŸ”’
True if a knob-phase planner reply signals the knob space is exhausted.
knob_planner_prompt πŸ”’
Knob-phase planner prompt: the round context plus an instruction to pick one option to retune (or end the phase). The available options live in the knob-phase system prompt, not here.
knob_system_prompt πŸ”’
System prompt for the KNOB-TUNING phase: the model picks one existing option per round and changes its default to a single untested value, or signals the phase is done. It never writes new logic here.
main πŸ”’
model_backend_label πŸ”’
Backend label for the model footer: just the backend name for the subprocess CLIs, and openai @ <base_url> for the built-in HTTP backend so the endpoint is visible.
model_display_name πŸ”’
normalize_attempt_summary πŸ”’
normalize_diff πŸ”’
Normalize a git diff for dedup: drop the index <hash>..<hash> lines whose blob hashes are noise, so two textually identical changes compare equal.
normalized_improvement πŸ”’
optimize πŸ”’
optimize_loop πŸ”’
planner_plan_rejection_reason πŸ”’
planner_prompt πŸ”’
planner_recovery_note πŸ”’
planner_system_prompt πŸ”’
prefix_at_char_boundary πŸ”’
print_final_report πŸ”’
read_attempt_memory πŸ”’
record_interrupted_round πŸ”’
record_model_timeout_round πŸ”’
resolve_repo_root πŸ”’
round_context_prompt πŸ”’
round_record πŸ”’
run_attempt_summary πŸ”’
run_coding_turn πŸ”’
scheduler_help_text πŸ”’
Capture the scheduler’s --help output so the planner can see which CLI options (knobs) already exist. This is the always-current, zero-maintenance source of truth for what the sweep has tuned - no hand-kept signatures. Returns None if the binary is missing or errors.
should_try_runtime_fix πŸ”’
spec_sudo_password_file πŸ”’
start_keep_running_scheduler πŸ”’
suffix_at_char_boundary πŸ”’
validation_failure_feedback πŸ”’