Files
agentic-mobile-control/openspec/changes/apex-agent-mvp/specs/agent-runtime/spec.md
T

3.0 KiB

ADDED Requirements

Requirement: Observe-Think-Act-Observe execution loop

The system SHALL execute a task as a repeating loop: observe the current Scene, decide the next step, act via a capability tool call, then observe the resulting Scene again, continuing until the goal is met, a failure ceiling is hit, or the task is cancelled.

Scenario: Loop continues until goal is met

  • WHEN a task with a natural-language goal (e.g. "open Taobao and search Mac mini") is started
  • THEN the runtime repeats observe→think→act until the Planner/Executor determines the goal has been reached, then marks the task complete

Scenario: Loop stops after max steps

  • WHEN a task exceeds a configured maximum number of steps without reaching its goal
  • THEN the runtime stops the loop and marks the task as failed with a reason, instead of looping indefinitely

Requirement: Planner produces a step plan from goal and current Scene

The system SHALL provide a Planner that, given a goal and the current Scene, produces an ordered list of intended next steps (e.g. "find search box", "tap it", "type query").

Scenario: Planner emits steps for a new goal

  • WHEN the Planner is invoked with a goal and the current Scene at the start of a task
  • THEN it returns a non-empty ordered list of intended steps for the Executor to attempt

Scenario: Planner re-plans after unexpected Scene

  • WHEN the Executor reports that the Scene after an action does not match what the current step expected
  • THEN the Planner is invoked again with the updated Scene to produce a revised step (or remaining steps)

Requirement: Executor performs retry and wait handling around tool calls

The system SHALL provide an Executor that translates a planned step into one or more capability tool calls, and SHALL retry with backoff and/or wait-for-element behavior when a step's expected result is not immediately observed, up to a configured retry ceiling.

Scenario: Executor retries a transient failure

  • WHEN a tool call (e.g. tap) does not produce the expected Scene change on the first attempt
  • THEN the Executor retries the step up to a configured number of attempts before treating it as failed

Scenario: Executor gives up after retry ceiling

  • WHEN a step has failed for the configured maximum number of retries
  • THEN the Executor records the step as failed and surfaces this to the Planner/task result instead of retrying forever

Requirement: Task context/memory available during a run

The system SHALL maintain an in-run context (recent Scene history, executed steps, and their results) accessible to the Planner and Executor for the duration of a task, so re-planning decisions can reference what has already been tried.

Scenario: Re-planning uses prior step history

  • WHEN the Planner is re-invoked mid-task
  • THEN it has access to the steps already attempted in this task and their outcomes, not just the current Scene in isolation