Capability Leaps in Post-Training: Engineering Paths from Code Agents to 3D Spatial Reasoning

As parameter scaling in foundation models slows, the industry’s competitive focus is shifting from “pre-training brute force” to “post-training fine-tuning.” How to transform general capabilities into deployable specialized skills through data mixing, reinforcement learning strategies, and tool-chain design has become the central concern for developers and enterprise users. This article takes recent post-training capability gains in domestic models as a starting point to discuss technical priorities, cost governance approaches, and engineering recommendations across two main tracks: code agents and 3D content generation.

1. Why Post-Training Has Become the Main Engine of Capability Growth

Pre-training determines a model’s breadth of knowledge and language foundation; post-training determines its “usability” on specific tasks. For strongly interactive, strongly verifiable tasks like coding and modeling, the value of post-training manifests at three levels:

1. Behavior alignment: Teaching the model to follow a stable workflow of “plan first, execute next, verify last” rather than producing a one-shot answer. Terminal tasks especially depend on this multi-turn trial-and-error stability.
2. Shaping tool-use habits: The model must understand when to invoke external tools, how to construct parameters, how to parse returned results, and how to fall back on failure. These capabilities are difficult to acquire through pure text pre-training and must be reinforced through training samples with tool feedback.
3. Error recovery: In real engineering environments, command failures, path errors, and missing dependencies are the norm. Introducing noisy execution trajectories during post-training can significantly improve a model’s self-correction rate.

From public evaluation trends, models that undergo systematic post-training tend to show larger score gains on terminal-operation benchmarks than on general language benchmarks. This indicates that post-training yields greater marginal returns for “process-oriented tasks” and is more deserving of engineering investment.

2. Code Agents: Dual-Track Optimization of Capability and Cost for Terminal Tasks

2.1 What Terminal Tasks Evaluate

Terminal benchmarks typically simulate a real development environment: given a repository and a natural language requirement, the agent must complete environment exploration, file modification, dependency installation, and test execution through shell commands. Scoring dimensions include task completion rate, command correctness, and execution step efficiency. The difficulty of these evaluations lies not in the syntax of a single command, but in long-chain state management—the model must remember side effects produced by previous steps and adjust subsequent actions accordingly.

A typical agent execution loop can be abstracted as:

while not task_done:
    plan = model.plan(history, tool_specs)
    action = model.select_action(plan)
    result = sandbox.execute(action)      # execute in isolated environment
    history.append((action, result))
    if result.error:
        history.append(model.reflect(result.error))

The key to post-training is making the reflect step reliable enough: the model must be able to identify from error messages whether the issue is a path problem, a permission problem, or a dependency version problem—rather than blindly retrying.

2.2 Two Sources of Capability Improvement

First, quality filtering of trajectory data. Not all successful trajectories are worth learning from; trajectories with lengthy steps or dependence on偶然 environmental conditions introduce noise. In practice, trajectories are typically scored across three dimensions—“completion rate + step efficiency + command规范性”—and high-scoring trajectories are retained for supervised fine-tuning.

Second, reinforcement learning with verification. Terminal tasks are naturally verifiable—whether tests pass, whether files are generated, whether exit codes are zero—all serve as clear reward signals. Using verification results as rewards, combined with parallel sandbox sampling, can continuously improve a model’s multi-step decision-making capability without relying on human annotation.

2.3 Cost Structure Is the Real Deployment Barrier

Meeting capability requirements is only the first step; cost determines whether the solution can be used at scale. The cost of terminal tasks consists of three main components: token consumption for input context, cumulative call counts from multi-turn interaction, and sandbox environment resource usage. Optimization directions include:

• Context compression: Summarize historical command outputs, retaining only key error lines and file diffs, avoiding repeatedly feeding full logs into the model.
• Step budget control: Set step limits for each task category; when exceeded, trigger “ask for help” or “roll back to a known good state” to avoid无效 loops.
• Model-tier routing: Route simple command parsing to smaller models and complex planning to larger models, dynamically switching based on task difficulty.

From publicly available cost comparison data, the per-task cost of frontier models on terminal tasks can vary by several times, and cost advantages often come from the aforementioned engineering optimizations rather than单纯的 pricing strategies. For developers, when choosing a solution, they should focus on both “per-task cost” and “first-pass rate”—the product of the two is the true expense.

3. 3D Content Generation: From Conversational Invocation to Scripted Modeling

3.1 Why Spatial Reasoning Is Difficult

3D modeling tasks require the model to understand geometric relationships, material properties, and layout constraints. Unlike 2D image generation, the correctness of 3D assets must satisfy physical and topological consistency: faces must not self-intersect, normals must be unified, and materials must match geometry. This places higher demands on a model’s spatial reasoning capability.

In tool-dependent evaluations, the model must call interfaces of professional modeling software to complete modeling, refinement, and layout adjustments. Scoring for such benchmarks typically includes geometric accuracy, material plausibility, and script executability.

3.2 Direct Scripting Path Without Intermediate Protocols

Early approaches mostly used general tool-calling protocols as intermediaries, resulting in long chains and high debugging costs. A more direct approach is to have the model generate native scripts for the target software, executed by the host environment. Taking a modeling script as an example:

import modeling_api as m
scene = m.new_scene()
base = m.create_mesh("cube", size=(2, 1, 0.2))
base = m.bevel(base, width=0.02, segments=3)
mat = m.create_material(base_color=(0.8, 0.8, 0.82), roughness=0.4)
m.assign_material(base, mat)
m.place(base, location=(0, 0, 0.1))
scene.export("asset.glb")

The model needs to understand API semantics, parameter value ranges, and call-order constraints. During post-training, through large numbers of “requirement–script–execution result” triplet samples, the model learns to express design intent at the script level and, when execution fails, to modify variables based on returned information rather than starting over.

3.3 Capability Boundaries and Engineering Recommendations

The advantage of the scripting path lies in controllability and reproducibility: generated scripts can be incorporated into version management as assets, facilitating review and secondary modification. For engineering deployment, the following are recommended:

1. Establish parameter whitelists: Apply constraint validation on material colors, dimension ranges, etc., to prevent out-of-bounds parameters from causing execution failures.
2. Segmented execution and snapshots: Split long scripts into modeling, refinement, and layout segments; save snapshots after each segment so failures can be rolled back from the most recent snapshot.
3. Result consistency checks: After export, validate face counts, bounding box dimensions, and material slots as automated acceptance steps.

4. Evaluation Methodology: How to Interpret Scores Objectively

Public leaderboard scores are easily misread; engineering teams should build their own evaluation sets when selecting solutions:

• Task distribution aligned with business: Terminal tasks should cover the real dependencies and toolchains of target repositories, not generic examples.
• Multiple samples for stable values: Single runs are heavily influenced by randomness; it is recommended to sample each task 5 or more times and report pass-rate distributions rather than maximum scores.
• Include cost in metrics: Record average call counts and token consumption per task to form a “capability–cost” two-dimensional profile.

Also note that tool-dependent evaluation scores and “tool-free pure generation” scores cannot be directly compared; the former measures agent orchestration capability, while the latter measures the model’s intrinsic knowledge. They correspond to different application scenarios.

5. Recommended Deployment Roadmap

For teams planning to adopt these capabilities, the following phases are recommended:

1. Validation phase: Select 20–50 real tasks to build a private evaluation set, comparing first-pass rates and per-unit costs across different solutions.
2. Integration phase: Connect the agent to an isolated sandbox, configure step limits, timeouts, and resource quotas, and establish a failure-sample feedback mechanism.
3. Optimization phase: Based on feedback samples, perform targeted post-training or prompt strategy adjustments, focusing on high-frequency failure modes.
4. Scaling phase: Introduce model-tier routing and context compression to bring per-task costs within budget.

Conclusion

Capability improvements in the post-training stage are essentially about turning a model that “can talk” into an agent that “can work.” Code terminal tasks test long-chain state management and error recovery; 3D modeling tasks test spatial reasoning and script expression. Both point to the same conclusion: tool-chain design, data quality filtering, and cost governance are just as important as the model itself. For developers, the key to真正 landing the technology lies in rationally interpreting leaderboard scores, building private evaluations aligned with business needs, and incorporating cost into decision-making.