I. Background: The Agent Bottleneck is Shifting from “Generation” to “Retrieval”

Recently, AI Agents have significantly improved their completion rates in tasks such as code generation, research report drafting, security auditing, and IT operations troubleshooting. Many tasks that required human intervention and iterative refinement a few months ago can now be autonomously completed by agents with minimal interference. However, in practical deployments, an inconspicuous component is becoming the new bottleneck: search and information retrieval.

Traditional search engines are primarily designed for humans, emphasizing web page ranking and summary presentation. In contrast, Agents require machine-readable, verifiable, and orchestrable information. If you ask an Agent to query a company’s equity structure, it might only return the official website’s brief introduction. If you ask it to find a production-grade code implementation, it might return a beginner’s tutorial. If you ask it to analyze threat intelligence for a suspicious IP, it might only find general science articles. The problem is not that the Agent “cannot summarize,” but that the retrieval layer does not provide sufficiently credible, structured, and traceable information.

Therefore, a search infrastructure built for AI Agents should not be understood as “web search plus summarization.” Instead, it should be designed as a unified, high-quality retrieval gateway. It needs to understand task intent, select appropriate data sources, extract structured fields, fuse multi-source evidence, output citation chains, and balance permissions, security, latency, and cost.

II. Design Principles: From “Returning Web Pages” to “Returning Evidence”

When building a retrieval infrastructure for Agents, the following principles are recommended:

1. Task Intent Priority: Query planning should identify the Agent’s current task type (e.g., code implementation, enterprise information verification, security intelligence analysis, log troubleshooting). Different tasks correspond to different source strategies and output schemas.
2. Multi-Source over Single-Source: Public web pages, community forums, code repositories, enterprise knowledge bases, databases, security intelligence sources, and log/monitoring systems should be integrated through a unified abstraction.
3. Structured Output: Beyond summary text, the system should return fielded results, confidence scores, timestamps, source types, and citation snippets.
4. Traceable Evidence: Every key conclusion should be accompanied by verifiable citations, facilitating review by Agents or humans.
5. Built-in Security and Compliance: Retrieved content must be treated as untrusted input, requiring prompt injection protection, permission inheritance, data masking, and auditing.
6. Engineering Observability: Metrics should be established for query planning, source routing, retrieval latency, cache hits, and failure degradation.

III. Reference Architecture for a Unified Search Layer

A deployable unified search layer can be divided into six layers:

• Access Layer: Provides API/SDK or tool invocation interfaces to receive Agent queries, context, permission identifiers, and output schemas.
• Query Planning Layer: Handles intent recognition, entity extraction, time constraints, authority requirements, source selection, and query rewriting.
• Retrieval Execution Layer: Calls multiple data source adapters in parallel, handling timeouts, retries, rate limiting, and degradation.
• Structured Extraction Layer: Extracts web pages, documents, code snippets, and database records into unified fields and annotates evidence.
• Fusion Ranking Layer: Performs fusion ranking based on authority, timeliness, relevance, completeness, and consistency, handling conflicting information.
• Governance and Observability Layer: Manages permissions, auditing, caching, quotas, logging, monitoring alerts, and quality evaluation.

Illustrative pseudocode:

def agent_search(query, context, permission, output_schema):
    plan = plan_query(query, context, output_schema)
    candidates = []
    for source in route_sources(plan):
        result = search_source(source, plan, permission)
        candidates.extend(normalize(source, result))
    evidence = extract_structured(candidates, output_schema)
    fused = fuse_and_rank(evidence, plan)
    return build_response(fused, citations=True, confidence=True)

IV. Key Module 1: Query Planning and Source Routing

Query planning determines the subsequent retrieval quality. Agent queries often carry task context, such as “Find a production-grade implementation of an interface and specify the license,” “Verify the equity structure of an entity,” or “Analyze recent threat intelligence for an IP.” The system should extract entities, constraints, output fields, and timeliness requirements from these queries to select data sources.

Source routing can adopt a combination of rules and models: rules handle hard constraints (e.g., permissions, region, timeliness, source availability), while models handle soft judgments (e.g., intent classification and source preference). The routing results should be explainable for troubleshooting.

{
  "intent": "code_implementation",
  "entities": ["interface_name"],
  "sources": ["public_web", "code_repository", "enterprise_knowledge_base"],
  "schema": ["implementation_snippet", "version", "license", "citation"],
  "constraints": {
    "freshness": "recent",
    "authority": "high",
    "permission": "inherited_from_caller"
  }
}

V. Key Module 2: Structured Extraction and Evidence Chains

Agents do not need a piece of text that “looks relevant”; they need fields consumable by programs. The structured extraction layer should work around the output schema, normalizing multi-source results into fields, values, confidence scores, timestamps, and citation snippets. For conflicting fields, multiple candidates should be retained and annotated with their sources rather than being forcefully merged.

An evidence chain is recommended to include: source type, source identifier, fetch or query time, citation snippet hash, field-level confidence, and license or usage restrictions. This allows the Agent to attach citations when generating conclusions, and humans to quickly verify them.

{
  "field": "license",
  "value": "candidate_value",
  "confidence": "high",
  "citations": [
    {
      "source_type": "code_repository",
      "timestamp": "query_time",
      "snippet_hash": "snippet_hash"
    }
  ],
  "conflicts": []
}

VI. Key Module 3: Fusion Ranking, Caching, and Degradation

Multi-source results require fusion ranking. Ranking should not solely look at text relevance but also consider authority, timeliness, structural completeness, field consistency, and task match. For multiple candidate values of the same field, a strategy of “authoritative source priority, timely source supplementation, and explicit conflict retention” can be adopted.

Engineering-wise, caching can significantly reduce the cost of repeated queries, but different strategies must be set based on query intent, permissions, and timeliness. Retrieval execution should support parallelism, timeouts, retries, circuit breaking, and degradation: when a certain source is unavailable, the system should return existing evidence and annotate missing items rather than letting the Agent draw unsourced, speculative conclusions.

Recommended observable metrics include: query planning hit rate, source routing accuracy, structured extraction success rate, citation verifiability rate, task completion rate, P95 latency, cost per query, cache hit rate, security interception rate, and failure degradation rate. Evaluation should combine offline benchmarks with online A/B testing to avoid relying solely on single demonstration effects.

VII. Security, Compliance, and Agent Integration

Retrieved content may contain malicious instructions, sensitive data, or outdated information. The system should treat retrieved content as untrusted data, separating instructions from data, and protecting against prompt injection, unauthorized access, and sensitive field leakage. Permissions should inherit the caller’s identity, and audit logs should record queries, source access, returned fields, and citation chains.

During Agent integration, it is recommended to encapsulate the unified search layer as a tool invocation: the Agent is responsible for stating its information needs, and the search layer is responsible for returning structured evidence and citations. The generation layer should answer based solely on the evidence and explicitly state when evidence is insufficient. For deployment, this can be combined with general cloud capabilities such as Baidu AI Cloud’s object storage, logging services, monitoring alerts, and container platforms to build an elastically scalable, observable, and auditable retrieval service.

VIII. Conclusion

The core of a search infrastructure built for AI Agents is not “searching the web and summarizing,” but rather governing fragmented, heterogeneous, and variably credible data sources into a unified gateway that outputs structured, traceable, and orchestrable evidence. Developers should focus on source governance, query planning, structured extraction, evidence chains, security compliance, and observability. Only when the retrieval layer is sufficiently reliable can Agents evolve from “being able to generate” to “connecting with the real world and completing tasks.”