From Foundation Models to Agents: The Evolution of LLM Technology and Production Practice

1. Background: LLM Competition Enters a Dual-Track Phase of “Reasoning Enhancement + Agent Delivery”

If one sentence could summarize the paradigm shift in the LLM industry in 2025, it would be this: the center of competition has moved from “pretraining parameter scale” to the combination of “reasoning depth” and “agent delivery capability.” Leading teams commonly adopt a dual-version release cadence of “foundation model + thinking-based reasoning model”: the former represents the bedrock of general knowledge and language capability, while the latter forges multi-step reasoning ability through reinforcement learning on verifiable tasks such as math and code, and generalizes this “slow thinking” capability to open-domain tasks.

In parallel, product form is also migrating. Models are no longer delivered only as “chat boxes” but as agents that take on real work tasks: autonomously decomposing goals, invoking tools, iterating through trial and error, and producing structured results. High-frequency scenarios such as deep research, repository-level code engineering, and complex document and presentation generation have become the touchstones for testing a model’s real productivity. The dual-track evolution of technology and product together defines the basic framework for evaluating and commercializing LLM capabilities today.

2. Foundation Models and Reasoning Models: A Dual-Track Technical Architecture

2.1 Foundation Models: The Bedrock of Intelligent Systems

The quality of the foundation model determines the capability ceiling of the entire system. It is widely recognized that the pretraining stage contributes the vast majority of a model’s world knowledge and language intuition. Key elements include:

• Data engineering: Deduplication, mixing ratios, quality grading, and curriculum-based ordering of corpora often influence model performance more than raw token count alone;
• Architectural efficiency: Sparse designs such as Mixture-of-Experts (MoE) allow models to carry larger parameter capacity at the same inference cost;
• Long context: Context windows ranging from tens of thousands to millions of tokens are a prerequisite for agents to handle long documents and long conversations.

2.2 Reasoning Models: The Second Growth Curve

The core idea of reasoning models is to treat the “thinking process” itself as an object of optimization. Through reinforcement learning, models are repeatedly trained on tasks with clear right-or-wrong signals—such as mathematical proofs, code generation, and bug fixing—learning to self-verify, backtrack, and divide-and-conquer. Their technical characteristics can be summarized in three points:

1. Verifiable rewards: Using objective signals such as unit test pass rates and answer correctness as rewards, avoiding the noise introduced by human preference annotation;
2. Test-time compute: Allowing models to perform longer chain-of-thought reasoning before answering, trading inference compute for answer quality;
3. Capability generalization: Planning, reflection, and self-correction patterns learned on verifiable tasks can transfer to open-ended tasks such as research, writing, and engineering.

2.3 The Relationship: Inheritance, Not Replacement

It is worth emphasizing that reasoning models are not a negation of foundation models. All “slow thinking” builds on the foundation’s knowledge reserves and language capabilities; the stronger the foundation, the greater the reasoning potential that reinforcement learning can “distill” from it. This is why mature teams keep both iterating in sync—the foundation raises the ceiling, and post-training fills the space beneath it.

3. The Agent Capability Stack: From “Can Chat” to “Can Work”

3.1 Four-Layer Capability Stack

An agent that can reliably deliver on real tasks typically requires four layers of stacked capabilities:

• Tool invocation layer: Encapsulating search, code execution, file read/write, API access, and other capabilities as structured interfaces for the model to call on demand;
• Planning and decomposition layer: Breaking vague goals into executable, verifiable subtask sequences, with dynamic adjustment during execution;
• Memory and context management layer: Maintaining task state across turns, compressing and retrieving over long contexts;
• Reflection and self-repair layer: Identifying errors based on execution feedback, retrying, or switching strategies.

3.2 Technical Commonalities Across Typical Scenarios

• Deep research: Multi-round “retrieve—read—question—supplement” loops, ultimately producing comprehensive reports with cited sources, testing long-horizon planning and information synthesis;
• Code engineering: Localization, modification, testing, and iteration against real repositories, testing toolchain coordination and test-driven repair;
• Structured content: Generation of documents, spreadsheets, and presentations, testing adherence to format constraints and output “taste.”

Below is illustrative code for a typical agent execution loop:

# Agent main loop (illustrative)
history = []
while not task.is_done():
    observation = env.get_state()                     # Perceive environment
    thought = llm.reason(observation, history)        # Chain-of-thought reasoning
    action = llm.plan(thought, tool_schemas)          # Generate tool calls
    result = tools.execute(action)                    # Execute and collect feedback
    history.append((observation, thought, action, result))
    if llm.self_check(result):                        # Reflection and retry
        task.mark_subtask_done(action)

This pseudocode reveals the essential difference between agents and ordinary chat applications: the subject of control flow shifts from “the user” to “the model,” and the engineering challenges—state management, failure retry, cost control—shift accordingly to the developer’s side.

4. The Next Leg of Scaling: An Order-of-Magnitude Leap in Equivalent Compute

Leading teams commonly set “an order-of-magnitude increase in equivalent compute” as their next-stage goal. “Equivalent FLOPs” here does not simply mean stacking more compute, but rather the combined effect of architecture, data, and training strategy:

• Pretraining side: Through better data mixing and curriculum design, more efficient sparse architectures and attention implementations, extracting more “effective learning” per unit of compute;
• Post-training side: Shifting a larger proportion of compute from supervised fine-tuning to reinforcement learning, especially cross-domain training on verifiable tasks;
• Inference side: Dynamically allocating thinking budgets for requests of varying difficulty, achieving Pareto improvements in quality and cost.

For users, this trend means: when evaluating models, one should not look only at parameter scale or benchmark scores, but should measure “task completion rate per unit cost” on one’s own real task distribution.

5. Vertical Integration: Co-Designing Model Training and Product Taste

Another important methodological shift in 2025 is that the boundary between “model teams” and “product teams” is being broken down. Under the traditional division of labor, model teams deliver APIs and product teams wrap interfaces, and the two sides lack a common language for “what constitutes good task completion,” easily leading to capability mismatch—the model trains on A while users want B.

The vertical integration approach is to bring the task distribution from real products directly into the training and evaluation loop, making “product taste” part of the training objective. Its flywheel effect manifests in three stages: product usage generates real task data; the data is cleaned and evaluated before flowing back into the training pipeline; and the new model’s capabilities unlock product forms that previously could not be supported. From publicly available industry information, after agent features were launched intensively, API call volume and subscription payments for model services grew several-fold within months—an outward manifestation of this flywheel in motion.

6. Commercialization Observations: The Dual Engine of API and Subscription

From a business structure perspective, LLM capability monetization has two main engines:

1. Consumer subscriptions: Driving payment conversion through high-frequency, high-value agent features, where users pay for “task completion” rather than “number of conversations”;
2. Enterprise APIs: Reasoning models significantly raise token consumption per task—deep thinking, tool calls, and multi-round retries all amplify usage, forming a revenue curve positively correlated with task complexity.

For enterprises planning to build their own agent applications, this structure can serve as a reference: prioritize scenarios with clear willingness to pay and verifiable delivery outcomes, then gradually expand task boundaries. At the engineering implementation level, mainstream cloud platforms already provide relatively complete general-purpose capability stacks—for example, platforms such as Baidu AI Cloud commonly offer model services, agent orchestration, knowledge base retrieval, monitoring and alerting, and logging services as foundational components, allowing developers to avoid building inference infrastructure from scratch and focus on task design and evaluation systems.

7. Practical Recommendations for Developers and Enterprises

1. Layered model selection: Evaluate “foundation capability” and “reasoning capability” separately—the former for breadth of knowledge and instruction following, the latter for end-to-end completion rate on multi-step tasks;
2. Make thinking budgets explicit: Configure different reasoning depths and tool-call limits for different task tiers to avoid the cost waste of “overthinking simple problems”;
3. Build task-level evaluation sets: Extract 50–200 end-to-end tasks from real business scenarios as a regression testing baseline for model upgrades and prompt iteration;
4. The cost engineering trio: Result caching, small-model distillation routing, and difficulty-based routing can typically significantly reduce inference overhead without sacrificing experience;
5. Embrace vertical integration: Even with limited team size, product feedback should flow directly into the training/fine-tuning data pipeline to build your own data flywheel.

Conclusion

LLM competition has evolved from point-by-point technical contests into a contest of systematic capabilities: the pretraining foundation determines the lower bound, reinforcement learning reasoning determines the upper bound, and agent products determine the efficiency of value realization. For developers, understanding the division of labor and synergy across the “foundation—reasoning—agent” three-layer architecture is more valuable long-term than chasing a single benchmark ranking. It is foreseeable that as equivalent compute continues to leap forward and vertical integration deepens, the conversion chain between model capability and productivity value will become increasingly short—and that is precisely the most anticipated part of this round of technological change.