Long-Horizon Agent Capabilities in Large Models: Engineering Practices from Code Generation to Persistent Task Execution

1. Background: From “Stronger Models” to “Tasks That Run to Completion”

In the latest round of large model capability upgrades, one notable shift stands out: evaluation focus is no longer limited to single-turn Q&A, text understanding, or simple code completion. Instead, it has moved toward long-horizon agentic tasks that more closely resemble real engineering environments.

Long-horizon agentic tasks typically share the following characteristics:

1. A single task requires multi-step reasoning;
2. The model must decompose goals on its own;
3. Execution involves calling terminals, file systems, browsers, code interpreters, or other tools;
4. Tasks may run for tens of minutes or even hours;
5. Failures, retries, environment changes, and context drift may occur mid-execution.

In the past, many models performed well on short-horizon benchmarks, but once placed in real terminal environments, resource-constrained environments, or scenarios requiring dozens of consecutive operations, they exposed problems such as unstable planning, chaotic tool invocation, error accumulation, and insufficient use of context.

As a result, the focus of new model upgrades has begun shifting from “parameter scale competition” to “long-horizon task stability, tool invocation reliability, and the balance between inference cost and speed.” This has become one of the key technical themes developers watch most closely after recent releases of several ultra-large parameter models.

2. Post-Training Expansion: RL Moves from Single Tasks to Hundreds of Downstream Domains

In improving long-horizon agent capabilities, simply increasing pre-training data is not enough to solve tool invocation and long-term planning problems. The more critical stage is post-training, especially the expansion of reinforcement learning across multiple downstream domains.

Traditional reinforcement learning training tends to concentrate on a few domains such as mathematical reasoning, code generation, or safety alignment. In contrast, newer models have begun expanding reinforcement learning to hundreds of downstream domains, including:

• Terminal command execution;
• File and directory operations;
• Code repository understanding and modification;
• Multi-round debugging and testing;
• Data processing and analysis;
• Report generation and citation verification;
• 3D scene parameter tuning and script generation;
• Financial data querying, modeling, and risk explanation;
• Multi-agent collaboration and task delegation.

This expansion brings significant engineering challenges. It is not just about adding reward signals—it requires a complete infrastructure to support large-scale joint training.

From an engineering practice perspective, several systems typically need significant rework.

2.1 Reinforcement Learning Framework

When the task domain expands from a few to hundreds, reward design, policy updates, sample replay, and training stability are all affected.

Common approaches include:

• Splitting reward functions into “process rewards” and “outcome rewards”;
• Using staged rewards for long tasks rather than only checking final completion;
• Adding penalties for failure paths while preserving some exploration space;
• Structurally validating tool invocation results rather than only comparing text similarity.

For example, in a terminal task, the model might execute 10 commands. The final result may be correct, but intermediate steps might involve accidentally deleting a temporary file and then recreating it. If only the final reward is given, the model may not learn a strategy of “reducing high-risk operations.” Therefore, process feedback is needed for command safety, directory switching correctness, file existence checks, and similar steps.

2.2 Long-Context Reasoning Training

Long-horizon tasks require the model to maintain attention across large amounts of historical actions, tool returns, and intermediate results. Many models in long contexts are prone to “forgetting early goals” or “repeatedly reading the same information.”

Engineering practices typically introduce the following training strategies:

• Constructing trajectory samples spanning thousands or even tens of thousands of tokens;
• Randomly inserting key constraints into trajectories to verify whether the model can consistently comply;
• Training the model to proactively compress intermediate results;
• Encouraging the model to form “state summaries” at key nodes to reduce subsequent redundant reads;
• Introducing memory read/write mechanisms that write important information into explicit state areas.

These approaches can reduce context drift in long tasks and improve consistency during multi-step execution.

2.3 Sandbox and Scheduling Systems

Large-scale reinforcement learning training requires running thousands of sandbox environments simultaneously. Model-generated commands must execute in a relatively isolated, rollback-capable, and observable environment.

Sandbox infrastructure typically needs the following capabilities:

• Fast environment creation and destruction;
• Network, disk, and process resource limits;
• Recording of stdout, stderr, and exit codes;
• File system snapshot and restore support;
• Ability to simulate different operating systems and terminal states;
• Interception or rewriting of dangerous commands.

The scheduling system needs to dynamically allocate resources based on training task priority, resource usage, and duration. Long-horizon task training especially tests scheduler stability, because a single task may run for ten minutes or longer.

2.4 Environment Quality Validation Platform

In multi-domain RL training, the quality of the environment itself directly determines the model’s ceiling. If tasks are ambiguous, test scripts are unstable, or sandbox initialization is inconsistent, the model will struggle to converge reliably.

Therefore, in practice, an independent environment quality validation platform is typically needed to run multiple dry runs for each task and check:

• Whether initial states are consistent;
• Whether test cases are reliable;
• Whether non-deterministic results exist;
• Whether hidden system dependencies exist;
• Whether the task description is sufficient to support correct model actions.

The value of such a platform is especially prominent in terminal-type benchmarks. A seemingly simple task may become completely different due to missing network access, insufficient permissions, or different environment variables.

3. Code Capabilities: Multi-Step Execution in Real Terminal Environments Becomes the Dividing Line

Code capability is one of the most closely watched metrics for large models. Many past leaderboards primarily evaluated single-completion ability, such as generating an implementation given a function signature, or generating a code snippet based on comments.

But real development work often does not look like that. Real development is closer to the following flow:

1. Enter an existing repository;
2. Read the directory structure and dependencies;
3. Run tests;
4. Analyze failure causes;
5. Modify multiple files;
6. Handle compatibility issues;
7. Run tests and static checks again;
8. Submit results.

Such tasks require the model to possess multi-step execution, tool invocation, and end-to-end problem-solving capabilities. Therefore, terminal benchmarks have gradually become an important means of evaluating coding agents.

These benchmarks typically include resource-constrained environments and specialized tests. The model cannot merely “understand code”—it must complete goals in a real terminal. For example:

Initial environment:
- A project containing 3 submodules
- Some test cases failing
- A dependency version issue present
- Dependencies can only be installed from local cache
Task goals:
- Fix failing tests
- Do not introduce additional external network requests
- Keep public APIs unchanged

In this scenario, the model needs to:

• Execute test commands;
• Read tracebacks;
• Check current dependency versions;
• Find compatible version combinations;
• Modify lock files;
• Run tests again.

Looking only at single-turn code generation scores makes it hard to reflect this capability. In practice, some models perform well on single-turn code completion but show a clear drop in scores once placed in terminal environments. This indicates a large gap between “being able to write code” and “being able to get tasks running in real environments.”

Therefore, when evaluating model code capabilities, developers should not only look at generation speed or single-completion accuracy, but also focus on the following dimensions:

• Whether command selection is restrained;
• Whether operations are executed in the wrong directory;
• Whether test output is correctly parsed;
• Whether the same command is repeatedly executed;
• Whether strategy is adjusted based on failure information;
• Whether additional dependencies are introduced unnecessarily.

4. Engineering Trade-offs Behind High-Speed Inference

Beyond capability improvements, model output speed is also an important metric for large model deployment. High-speed versions of models can typically increase output speed by roughly 2 to 3 times while maintaining similar intelligence levels.

But high-speed inference is not without cost. From an engineering perspective, the following trade-offs are typically involved.

4.1 Compute Resources and Scheduling Strategy

High-speed inference typically means higher concurrency, more aggressive batching strategies, or more aggressive attention pruning. This can increase per-unit-time compute costs.

As a result, high-speed model versions are often priced higher. Enterprises need to determine whether their scenarios truly require low latency.

For example:

• For user-facing conversational scenarios, low latency is important;
• For batch offline processing tasks, standard-speed models can reduce unit costs;
• When a large number of tests must be completed in a short time, high-speed models can improve throughput;
• In long-horizon agentic tasks, generation speed is not the only bottleneck—tool execution time is equally critical.

4.2 Non-Linear Relationship Between Quality and Speed

On certain tasks, faster decoding strategies may introduce quality fluctuations. For example, complex code generation, long-chain reasoning, and precise format output are more sensitive to sampling strategies.

Therefore, in production environments, the following is typically recommended:

• Keep lower-temperature stable configurations for critical tasks;
• Use high-speed mode for simple tasks;
• Use staged invocation for complex long tasks;
• In agent systems, combine “fast models” with “strong models.”

For example, high-speed models can be used for summarization, format organization, simple classification, and intermediate steps, while strong models are used for final solution design, complex debugging, and risk judgment.

This hybrid scheduling strategy is very common in engineering practice and can achieve a better balance between cost and effectiveness.

5. Managed Agents: From Calling Models to Running Long-Term Tasks

Another important signal in this capability upgrade is that models are beginning to be bound with “managed agent services.”

In the past, when developers called large model APIs, they typically had to build their own agent runtime, including:

• Loop control;
• Tool registration and authentication;
• Execution environment management;
• State persistence;
• Task timeout and retry;
• Multi-agent communication.

While this self-built approach is flexible, it carries high development costs, especially when supporting 24/7 long-horizon tasks, where numerous stability issues arise.

Managed agent services provide the runtime environment as a cloud infrastructure, allowing developers to focus on task definition and result evaluation.

Such services typically offer the following capabilities:

5.1 Continuous Operation and State Preservation

Tasks are no longer limited by single-request duration and can run continuously in the cloud. Application scenarios include:

• Long-duration data collection;
• Periodic report generation;
• Continuous monitoring and alert handling;
• Automated code repository maintenance;
• Financial information tracking and summarization.

5.2 Multi-Agent Collaboration

Long-horizon tasks often require multiple roles working together. For example, a research task can involve:

• An information retrieval agent responsible for collecting materials;
• A data analysis agent responsible for processing data;
• A report generation agent responsible for summarizing output;
• A verification agent responsible for checking citations and factual consistency.

The managed environment needs to provide message passing, task allocation, state sharing, and conflict handling mechanisms.

5.3 Observability and Recovery

Long-running tasks must have good observability; otherwise, once problems arise, it becomes difficult to determine whether the cause is model reasoning errors, tool failures, or environment anomalies.

Typically, the following need to be recorded:

• Model input and output at each step;
• Tool invocation parameters and returns;
• Task state transitions;
• Resource usage;
• Error types and retry counts.

For failed tasks, recovery from checkpoints should also be supported rather than starting over entirely.

6. Deployment Recommendations: How to Evaluate and Use Such Models

For enterprise developers and technical teams, the focus should not be on single-point benchmark scores alone, but on building a long-horizon task evaluation system suited to their own business needs.

6.1 Define Task Cards First

It is recommended to write a “task card” for each candidate scenario, containing:

• Task goals;
• Input and output specifications;
• Available tool list;
• Resource constraints;
• Time constraints;
• Success criteria;
• Failure case examples.

This is more informative than directly using general-purpose leaderboards.

6.2 Build Layered Evaluation

Evaluation can be divided into three layers:

Layer 1: Single-step capabilities

• Function completion;
• Simple SQL or script generation;
• Structured text output.

Layer 2: Multi-step capabilities

• Modifying multiple files;
• Running tests and locating problems;
• Adjusting plans based on tool feedback.

Layer 3: Long-horizon tasks

• Multi-hour execution;
• Multi-agent collaboration;
• Continuous state preservation;
• Automatic recovery and retry.

Different layers reflect different capabilities and cannot substitute for one another.

6.3 Focus on Cost Structure

In long-horizon agentic tasks, cost is not just input and output tokens. It also requires calculating:

• Number of tool invocations;
• Cache hit rates;
• Repeated read costs;
• Cost of mixing high-speed and standard models;
• Managed runtime duration costs.

In many scenarios, reducing repeated input through caching, compressing intermediate states, and avoiding unnecessary tool invocations can significantly lower overall costs.

6.4 Integrate Models into the Software Engineering System

No matter how capable a model is, it cannot replace engineering discipline. It is recommended to combine agent systems with the following capabilities:

• Version control systems;
• CI/CD pipelines;
• Logging and monitoring alerts;
• Permission and audit systems;
• Canary releases and rollback mechanisms.

For example, in an automated code maintenance task, agent-generated changes should pass code review, test suites, and static checks before being merged. This controls risk while gradually building up model capabilities.

7. Future Direction: From “What It Can Do” to “What It Can Do Reliably”

As ultra-large parameter models enter the long-horizon agent era, the metrics the industry focuses on are changing.

In the past, the focus was on:

• Single-turn response quality;
• Code completion accuracy;
• Text generation fluency;
• Instruction-following scores.

Now, increasing attention is being paid to:

• Success rates for long-duration execution;
• Completion rates for multi-step tasks;
• Tool invocation stability;
• Recovery capability after failure;
• Multi-agent collaboration efficiency;
• Comprehensive cost per unit task.

This shift means model capability evaluation is moving from the laboratory back into real production environments.

For developers, the most worthwhile investment is not chasing the benchmark scores of a particular version, but building an internal system that can continuously evaluate, track, and optimize long-horizon agentic tasks. Only by truly embedding models into actual workflows can you determine whether they deliver measurable efficiency gains.

In the future, as open-weight models become more widespread, enterprises will be able to deploy such models in their own environments or on cloud platforms, and combine them with general cloud infrastructure such as object storage, container platforms, logging services, and monitoring alerts to build long-term task execution systems for their own business needs.

In this process, what truly creates differentiation is often not the model’s single-point capability, but the engineering capabilities built around the model: task abstraction, environment management, state persistence, cost control, permission governance, and continuous optimization.

This is also the biggest insight that this new generation of model capability upgrades brings to engineering teams: the boundaries of a model often depend on the runtime environment you can build for it.