Baidu Create 2026: AI Agent Evolution and the DAA Metric

At the recent Baidu Create 2026 AI Developer Conference, Baidu introduced two key directions for AI agent deployment that developers should pay attention to: “self-evolution” and DAA (Daily Active Agents). The former discusses how agents transition from “being able to converse” to “being able to work and becoming more proficient.” The latter explores how to use a metric closer to business delivery to measure the prosperity of an agent platform and ecosystem. For developers, this is not merely a conceptual update but a systemic change involving task modeling, evaluation loops, engineering governance, and metric design.

1. From “Conversation” to “Delivery”: The Changing Evaluation Scale of Agents

Over the past few years, the core interaction format for large model applications has been conversation. Developers focused on prompt engineering, context length, API call counts, and response quality. In the agent era, the application goal is no longer just generating a block of text, but completing a task: understanding the goal, decomposing steps, calling tools, handling intermediate states, verifying results, and recovering or escalating to humans upon failure. The evaluation scale changes accordingly: it is no longer just about whether the model “sounds right,” but whether the agent “gets it done.”

During his presentation at the conference, Baidu founder Robin Li mentioned that in the agent era, measuring the prosperity of a platform and ecosystem should focus on how many agents are actually doing work and delivering results for humans, which is much closer to real value than simple token consumption. This insight offers direct implications for developers: the design goals of an agent system should shift from “call volume” to “task completion rate, result availability, and continuous operation capacity.” An agent called thousands of times a day but rarely delivering valid results does not constitute true productivity.

2. The Three Layers of “Self-Evolution”

The “self-evolution” proposed at the conference can be broken down into three layers. The first layer is the agent itself becoming stronger: optimizing task planning, tool selection, parameter configuration, and failure recovery strategies through real task feedback. The second layer is individuals becoming stronger through AI: developers or business personnel no longer perform all repetitive operations manually, but focus on requirement expression, process supervision, and result acceptance. The third layer is organizations becoming stronger through human-machine collaboration: processes, permissions, knowledge bases, and review mechanisms are redesigned around “humans and machines completing tasks together.”

These three layers correspond to different engineering challenges. Agent self-evolution requires evaluation sets, regression testing, and a feedback data loop. Individual enhancement requires low-barrier task orchestration and explainable execution traces. Organizational collaboration requires observability, auditing, permission isolation, and human-in-the-loop review nodes. Missing any of these layers means that “self-evolution” will likely remain stuck at the demo stage.

3. The DAA Metric: From User Activity and Token Consumption to “Getting Work Done”

In the mobile internet era, DAU (Daily Active Users) was commonly used to measure user stickiness, focusing on whether users were online and active. In the large model era, the industry focused on the Token dimension, reflecting model call intensity, but call volume does not necessarily equate to business value. The introduction of DAA signals a perspective shift: from “users” to “compute,” and then to “getting work done,” measuring how many agents are running stably, solving problems, and creating value in real business scenarios.

From an engineering perspective, DAA cannot simply be equated to “the number of agents that have been started.” A workable metric design should clarify at least four points:

• Active definition: There must be task execution and result delivery.
• Quality threshold: Results must pass automated acceptance or human confirmation.
• Deduplication logic: Statistics should be aggregated by business task or agent instance.
• Persistence: It should observe stable operation across days and weeks, rather than a one-time demonstration.

Developers can use DAA in combination with metrics like task completion rate, human takeover rate, average processing time, and failure recovery rate to prevent a single metric from being distorted by “call farming.”

4. Two Abstract Scenarios: Retail Guiding and Scientific Parameter Search

Two abstract scenarios were presented at the conference. One is a multi-language intelligent shopping guide agent for retail merchants: it needs to understand customer intent, answer product questions, conduct multi-language interactions, and take on customer operation responsibilities. The other is parameter search and experiment optimization in a scientific research scenario: research teams need to repeatedly try combinations of parameters like geometric models, flow field uniformity, and separation efficiency. An agent system can take on part of the trial-and-error and search work, compressing long-cycle explorations into shorter iterations.

These two scenarios seem distinct but share a similar technical structure: both have clear task goals, callable tools, evaluable results, and accumulatable feedback. The retail scenario emphasizes real-time interaction and business rule constraints, while the scientific research scenario emphasizes search space, evaluation functions, and experiment logs. Developers should abstract the four elements of “Task—Tool—Evaluation—Feedback” from scenarios, rather than piling up prompts for each individual scenario.

5. Developer Practice: Building an Evolvable Agent Loop

A minimal loop can be represented by the following pseudocode:

function run_agent(task, tools, policy, memory):
    plan = policy.plan(task, memory)
    result = execute(plan, tools)
    score = evaluate(result, task.acceptance_criteria)
    trace = record(plan, result, score)
    return result, score, trace
function evolve(policy, feedback_dataset):
    for batch in feedback_dataset:
        candidate = policy.propose_update(batch)
        if offline_eval(candidate) >= baseline:
            policy = candidate
    return policy

This pseudocode emphasizes three points: execution must leave observable traces; results must be evaluated against acceptance criteria; policy updates must go through offline evaluation and regression testing. In production, this should be supplemented with least-privilege access, data desensitization, tool call whitelisting, failure retries, and human escalation mechanisms. For high-risk tasks, set up human review nodes; for long-cycle tasks, design state persistence and checkpoint recovery; for multi-agent collaboration, clarify responsibility boundaries and conflict resolution strategies.

6. Metric Governance and Organizational Synergy

The value of DAA lies not just in the metric itself, but in driving organizations to focus on “whether agents are truly delivering.” Enterprises can establish layered dashboards: the task layer monitors completion rate and quality; the agent layer monitors activity and stability; the business layer monitors cost savings and response speed. At the same time, avoid turning DAA into a new vanity metric: activity without a quality threshold is meaningless, and delivery without human confirmation may mask errors. Developers should treat evaluation sets, logs, monitoring alerts, and audit records as infrastructure, ensuring that agent evolution is evidence-based.

Conclusion

The signals released at the Baidu AI Developer Conference can be summarized as follows: AI agents are moving from demonstrations to production, and evaluation standards are shifting from call volume to delivered results. Self-evolution requires developers to build a “Task—Tool—Evaluation—Feedback” loop, while DAA reminds teams to measure agent operations using metrics closer to real value. For developers, what is truly worth anticipating is not a single feature release, but a reusable set of methodologies formed around agent engineering: enabling agents to run stably in real tasks, continuously improve, and ultimately deliver verifiable results.