From Answering Questions to Executing Tasks: The Evolution and Practice of Long-Horizon AI Agents

1. The Shift in Focus: Post-Training Compute as the New Watershed

Over the past two years, the AI industry’s attention has centered on parameter scale and context length. Now that leading models have generally entered the trillion-parameter, million-token context range, these two metrics have degraded from “highlights” to mere “entry tickets.” The true differentiator has shifted to the post-training phase.

Observing recent releases from multiple vendors reveals a common path: without significant leaps in pre-training scale, there is a substantial increase in compute allocated to post-training. Furthermore, Reinforcement Learning (RL) is being expanded from single-domain rewards like math and code to hundreds of downstream task areas—including programming, financial research, 3D content creation, and multi-step tool invocation. The underlying assumption is that the marginal utility of model capabilities increasingly depends on the scale of “trial and error in real task environments with verifiable feedback,” rather than the sheer volume of static corpora.

The evaluation criteria have also changed. Previously, the question was “Is this answer correct?” Now, it is “Can this agent work continuously for hours and deliver a result?” This is not a minor tweak in evaluation metrics but a redefinition of the model paradigm: models are evolving from “one-time responders” into “execution units for long-horizon tasks.”

2. Multi-Domain RL: From Answering Questions to Getting Things Done

Expanding RL to hundreds of domains sounds straightforward, but in practice, it presents three layers of challenges.

The first layer is the verifiability of reward signals. Code can be verified via unit tests, financial research via backtesting, and 3D creation via rendering consistency checks. Only when rewards are computable and reproducible can RL form effective gradients. Domains with non-verifiable outcomes (like open-ended writing) are difficult to incorporate directly into this paradigm, which structurally explains why models exhibit “uneven capabilities” across different fields.

The second layer is task diversity and overfitting control. The broader the task distribution, the harder it is for the model to “cheat” the reward function by memorizing specific patterns, thereby genuinely training its generalization capabilities. Mixed training across hundreds of domains essentially trades task diversity for policy robustness.

The third layer is the training system itself. Supporting this scale of joint training requires systemic overhauls to the underlying training infrastructure, typically including:

• RL Framework: Supports large-scale parallel rollout and multi-domain mixed scheduling.
• Long-context Inference: Repeatedly performing long-sequence reasoning during training places far higher demands on memory, KV cache, and compute scheduling than standard fine-tuning.
• Sandbox Infrastructure: Allows agents to execute code, invoke tools, and generate real feedback in controlled, real-world environments.
• Scheduling System: Mixes short tasks with long-horizon rollouts lasting several hours, involving priority management, preemption, and fault tolerance.
• Environment Quality Assurance Platform: Configuration drift in environments directly pollutes reward signals. It is crucial to continuously verify the reproducibility of each task environment before training.

Among these five items, the first two dictate “how fast you can train,” and the latter three dictate “whether you train correctly.” Many teams focus solely on the former. In reality, when environment quality is compromised, the more compute you burn, the further the model deviates.

3. The Engineering Foundation of Long-Horizon Agents: The Model is Just One Link

For an agent capable of continuous work, model intelligence accounts for at most half of the equation. The other half is the operational framework surrounding the model, known as the Harness. A typical execution chain looks like this:

Task Input
  -> Plan and Decompose (Plan)
  -> Tool Invocation / Sandbox Execution (Act)
  -> Observe and Reflect (Observe & Reflect)
  -> Failure Retry / Self-Correction (Retry)
  -> Checkpoint Persistence (Checkpoint)
  -> Deliver and Audit (Deliver & Audit)

There are three key engineering points worth elaborating on:

Sandbox Isolation: The code executed by the agent must run in an isolated environment with restricted resources, controlled network access, and snapshot-able file systems. Execution timeouts, memory limits, and network whitelists are basic configurations. Without them, a single runaway loop could crash the entire task pipeline.

Checkpoint and Recovery: Long-horizon tasks run for hours, and interruptions are inevitable. Persisting intermediate states (completed sub-tasks, retrieved context, decision logs) is the prerequisite for turning “24/7 operation” from a slogan into reality.

Idempotency and Retry: Tool invocations must feature idempotent design. In real-world business scenarios, retrying a payment deduction twice versus executing it twice are entirely different outcomes.

4. How to Scientifically Evaluate “Actually Getting Things Done”

For code and long-horizon capabilities, evaluation methodology is more important than leaderboard rankings. Three principles apply:

First, prioritize real environments. Let the model execute hands-on in a resource-constrained real terminal, setting up specific verification tests for each task, rather than asking it to “verbally describe” the solution. Explaining a solution clearly and having code that actually runs are two distinct capabilities.

Second, cover the long-horizon dimension. Focus on multi-step execution, tool invocation chains, and end-to-end problem-solving. The key observation is whether the model can maintain goal consistency after dozens of steps, and whether early minor errors are self-corrected or compound exponentially.

Third, ensure reproducibility and prevent contamination. Keep environments fixed, random seeds fixed, and rotate evaluation sets regularly. Once an evaluation set leaks into the training data, the scores lose all meaning.

Looking at the current landscape, on real-terminal programming benchmarks, leading models generally score over 60%, with the gap between them narrowing to just a few percentage points. On long-horizon code evaluations, new-generation models typically show about a five-percentage-point improvement over their predecessors. The flip side of this narrowing gap is that the reference value of a single leaderboard ranking is declining, while the importance of alignment between the evaluation set and one’s own business workloads is increasing.

Therefore, a more pragmatic approach is for enterprises to build their own evaluation sets: sampling from real tickets and private code repositories, covering the true distribution of “high-frequency simple tasks + low-frequency complex tasks,” and validating with canary traffic, rather than betting on any public leaderboard.

5. The Economics of Inference: Three Ledgers of Speed, Caching, and Budgets

Approaching the level of leading closed-source models in capability does not mean they are affordable. The cost of long-horizon agents requires calculating three ledgers.

Speed Ledger: A common industry practice is to offer a high-speed version with the same intelligence level but 2 to 3 times faster output speed, priced at about twice the standard version. This is suitable for interactive programming and the high-frequency “read-decide” phases of agents; for offline batch processing, it is a waste—since no one is waiting.

Caching Ledger: Taking common industry pricing structures as an example, the input unit price when context caching hits is often only about a tenth of a miss. The system prompts, tool definitions, and code repository context of long-horizon agents are highly repetitive across turns, yielding massive caching benefits. The corresponding engineering practice is stable prefix design—placing static content at the front of the prompt and dynamic content at the back:

messages = [
    {"role": "system", "content": STATIC_PROMPT + TOOLS_SPEC},   # Stable prefix, optimized for cache hits
    {"role": "user", "content": f"Current task: {dynamic_task}"}, # Dynamic suffix
]

Budget Ledger: This is the most easily overlooked ledger. The token consumption of a single long-horizon agent task can be hundreds or thousands of times that of a standard chat scenario—“burning through your quota in minutes” is not an exaggeration, but the norm for this workload. High throughput does not equal low cost; you must implement a budget guard:

class BudgetGuard:
    def __init__(self, max_input_tokens, max_output_tokens):
        self.budget = max_input_tokens * 0.3 + max_output_tokens * 0.7  # Weighted by unit price
        self.used = 0
    def check(self, usage):
        self.used += usage.input_tokens * 0.3 + usage.output_tokens * 0.7
        if self.used > self.budget:
            raise BudgetExceeded("Budget limit triggered, degrading task")

Combined with output length constraints and mid-way stop-loss strategies (e.g., circuit breaking and alerting after N consecutive failed steps), costs can be kept within a predictable range.

6. Managed Agents: Harness as Infrastructure

Another noteworthy trend is servitization: offering the harness that supports long-running agents as a cloud-hosted capability, supporting 24/7 long-horizon tasks and multi-agent collaboration. For enterprises, this is equivalent to outsourcing the heavy lifting—state management, scheduling, sandboxing—required to “keep agents working” to the platform.

When evaluating such services (or deciding to build in-house), focus on five core aspects: state persistence and recovery capabilities, task idempotency and retry semantics, multi-agent orchestration mechanisms (role division and message passing), observability (logging, monitoring, and alerting), and permission and operation auditing. If choosing to build in-house, leveraging general infrastructure provided by cloud platforms like Baidu AI Cloud—such as container platforms, object storage, message queues, and logging/monitoring services—can significantly shorten the foundation setup cycle. However, orchestration logic and security boundaries should remain firmly in your own hands.

7. A Rational View: Three Unsolved Problems

First, capability imbalance. A model approaching the strongest closed-source level on code benchmarks does not mean it is equally balanced in planning, writing, or multilingual knowledge. Validating against your own scenarios always takes precedence over relying on general reputation.

Second, verbosity. The expansion of reasoning chains and output text directly drives up costs (keep in mind output unit prices are usually several times that of input). Constraining output is essentially saving money.

Third, long-tail failures. In long-horizon tasks, minor early errors are compounded by the number of steps. Where you set up checkpoints, rollback mechanisms, and human intervention thresholds often determines delivery quality more than the model’s own capability.

Conclusion: The essence of this technological evolution is directing more post-training compute toward “execution environments that can work continuously,” rather than simply boosting static Q&A scores. For developers, the real work lies not in leaderboard rankings, but in three pragmatic tasks: evaluation consistency, cost budgeting, and the engineering foundation.