Scientific Agent User Guide

Applies to Desktop 1.4.5 and Runtime 1.2.3. The Chinese edition is available at 简体中文.

Scientific Agent is a local workspace for computational research. By default, describe the outcome in one request and optionally attach data, a lattice, or solver source. Runtime selects this project's plugin capabilities and freezes derived acceptance, budget, and deliverables into an auditable Research Contract; the advanced path still exposes every field. The system organizes experiments, records evidence, invokes solvers or generated programs, and stops at explicit completion conditions. It is not an LLM -> shell chat box: Runtime independently validates and records research actions, permissions, budgets, artifacts, evaluation, and lifecycle state.

For the shortest path to a result, use the Desktop quickstart. For a server, script, or CI workflow, begin with the CLI quickstart.

System overview

Scientific Agent Desktop
  Tauri desktop shell
       │ starts and supervises
       ▼
Scientific Agent Runtime ── Control API ── React control surface
       │
       ├── Scientific Reasoner: chooses the next research action
       ├── Policy / Budget / Criteria: authorization, limits, acceptance
       ├── Model Plane: reasoning, code generation, code repair
       ├── Plugin Runtime: domain solving, analysis, evaluation, reports, execution
       └── Event Log + Artifact Store: recoverable state and immutable outputs

Scientific Agent Benchmark Suite
       └── evaluates Runtime externally under frozen protocols
  • Desktop is the installable distribution; end users do not need Python, Node.js, a repository, or a fixed localhost port. It starts a bundled Runtime on a random loopback port and authenticates the UI with an ephemeral launch credential.
  • Runtime is the scientific control core. Desktop, CLI, and Control API workflows share the same state, policy, budgets, acceptance engine, and artifact rules.
  • Plugins own concrete scientific capabilities. Xsuite tracking, three-body solving, trusted evaluation, scientific analysis, knowledge objects, and reporting remain outside the core loop.
  • Benchmark Suite is an external measurement product. Runtime does not know when it is being evaluated, so benchmark logic cannot become ordinary research behavior.

Influences and implementation building blocks

“Influence” here means an architectural pattern or mature component, not a claim that the product is a copy of one framework:

  • Event sourcing: important changes are appended as events and current state is rebuilt by replay, preserving history and enabling crash recovery.
  • Control-plane / execution-plane separation: the Reasoner proposes what to do, Runtime decides whether it is allowed, code models implement bounded requests, and executors own processes.
  • Reproducible computation and data provenance: datasets, models, figures, and reports are immutable artifacts with SHA-256 identities, creators, and parent relationships in a provenance DAG.
  • Capability-oriented plugins: a Research Contract authorizes stable capabilities rather than a Python implementation class, so providers can change without obscuring the permission boundary.
  • Frozen evaluation protocols: the Benchmark Suite fixes specifications and private dataset identities before live runs, then performs holdout checks after research success.
  • The product uses Tauri 2, React, FastAPI, React Flow, and Dagre for its desktop/API/UI layers, and Xsuite for the accelerator example. Those components do not own scientific authority.

Distinctive properties

  1. One request, then contract before execution. A connected Scientific Reasoner produces a non-authorizing structured draft from the goal and static attachment profiles; deterministic Runtime control compiles capabilities, provider pins, acceptance, budget, and deliverables. Advanced mode exposes every field, and both planning provenance and the final contract remain inspectable.
  2. Evidence decides success. CriteriaEngine evaluates recorded metrics; criteria may require a trusted evaluator, and completion may additionally require declared scientific artifacts.
  3. Everything important is inspectable. Timeline, model calls, jobs, budget, resources, evidence, claims, hypotheses, verification, reports, and lineage all have dedicated read models.
  4. Human control remains auditable. Pause, resume, budget changes, and research notes are finite directives recorded as events. Ask is read-only with respect to ResearchState.
  5. Local first. Durable data defaults to Documents/ScientificAgent; Desktop credentials use the operating-system credential store. Development servers should remain on 127.0.0.1.
  6. Core-independent extension. A self-contained directory or ZIP with a manifest and one class can add a new domain capability.
  7. Research and evaluation stay separate. Hidden holdouts, replications, and statistical reports belong to Benchmark Suite and are not exposed to the ordinary research loop.

Reading paths

  • Desktop operator: quickstart → create a run → Control Room → lineage → settings.
  • Server or automation operator: CLI quickstart → command reference → configuration → headless API.
  • Plugin author: CLI quickstart → using plugins → build a plugin → SDK reference.
  • Model-strategy evaluator: scientific workflow → Benchmark Suite → data and security.

Current boundary

Desktop 1.4.5 targets one trusted user on a local machine. It does not provide remote accounts, cloud sync, HPC/Slurm scheduling, or multi-tenant isolation. Generated local execution and managed project plugins retain the current user's filesystem and network authority; workspace/process isolation is not an OS sandbox. In-app updates are not configured. Never expose the development Control API directly to the public internet.

Next: Desktop quickstart or CLI quickstart.

results matching ""

    No results matching ""