Uma Resposta 200 Não Prova que a Busca Funcionou

TL;DR

• HTTP 200 prova que um servidor aceitou uma solicitação e retornou uma resposta. Não prova que o filtro solicitado foi aplicado, que a evidência era atual, que a ferramenta esperada foi executada, que a resposta foi suportada, que o trabalho foi interrompido ou que o custo foi zero.
• O conjunto de evidências contém 153 casos padronizados ou diretos em AgentCore Web Search, Exa, Parallel e Perplexity. O trabalho de testes de MCP e ciclo de vida separa a descoberta de ferramentas, monitoramento, webhooks, execuções em segundo plano, cancelamento e limpeza. Este é um inventário de execução, não uma classificação de qualidade universal.
• Uma busca de página bem-sucedida contém dados de versão do PostgreSQL desatualizados. Uma chamada bem-sucedida da API do Perplexity Agent com a Pesquisa de Pessoas habilitada não registra nenhuma invocação; um prompt explícito de pesquisa de pessoas registra uma. Respostas geradas com sucesso introduzem uma alegação não suportada de 501 Not Implemented no padrão de fatos sendo testado.
• Uma aparente lacuna de filtro do AgentCore pertence à versão do adaptador local e do conector, não ao serviço. A falha está no caminho de avaliação.
• Custo desconhecido não é uso gratuito. Metadados de cobrança ausentes permanecem desconhecidos até que uma taxa defensável ou fatura a estabeleça.

O sucesso do HTTP é evidência de transporte. A qualidade da pesquisa requer evidência além do transporte.

Essa distinção parece óbvia até que uma avaliação conte cada resposta 2xx como um sucesso. Produtos de pesquisa de agentes combinam recuperação, extração de páginas, modelos, ferramentas, trabalhos em segundo plano, monitores e servidores MCP remotos. Cada camada pode retornar uma resposta tecnicamente bem-sucedida enquanto falha no motivo pelo qual foi chamada.

O contrato de avaliação, portanto, precisa de seis provas separadas:

Um único status verde não pode colapsar essas camadas em um único resultado.

153 casos, sem um quadro de liderança de 153 células

A contagem de execução direta nos conjuntos específicos do provedor é 153:

Esses casos não formam um único benchmark intercambiável. O AgentCore contribui com 47 casos de recuperação. O Exa contribui com 41 casos em pesquisa, extração e respostas geradas. O Parallel e o Perplexity cobrem superfícies de produtos mais amplas. Os conjuntos estabelecem quais contratos e modos de falha recebem evidência direta.

As sessões de MCP, execuções de pesquisa profunda, grupos de tarefas, monitores, verificação de webhook, cancelamento em segundo plano e outros controles de ciclo de vida permanecem separados. Combiná-los nos 153 inflacionaria o número sem tornar a comparação mais útil.

A via de recuperação usa 30 perguntas fixas, quatro provedores e 1.200 resultados. Mede a evidência recuperada sob condições fixas. Não estabelece um vencedor de qualidade de resposta universal.

Uma busca bem-sucedida pode retornar evidências desatualizadas

O controle de busca de página envia os mesmos quatro URLs através de dois produtos de extração. Cada solicitação é bem-sucedida. Cada URL retornado corresponde. Cada corpo não está vazio e permanece dentro do limite de caracteres configurado.

Um resultado demonstra evidência desatualizada.

Para a página de versionamento do PostgreSQL, uma cópia buscada relata PostgreSQL 18.4 e 17.10. A outra relata 18.6 e 17.11, correspondendo à página oficial na verificação de referência congelada. A resposta desatualizada tem texto válido, uma URL válida e um status bem-sucedido.

Transporte: sucesso. Conteúdo: falha.

Isso muda o teste mínimo para busca de página. Texto não vazio é apenas uma afirmação estrutural. A extração sensível à frescura também precisa de um fato de referência datado, uma comparação de fonte ao vivo ou um experimento de controle de cache. Um produto de busca pode satisfazer seu contrato de API enquanto retorna evidência que não satisfaz mais a pergunta do usuário.

Habilitar uma ferramenta não prova que a ferramenta foi executada

APIs de agentes adicionam outra lacuna entre configuração e execução. Perplexity documenta que as ferramentas devem ser configuradas na solicitação, e o modelo decide quando invocá-las a partir do prompt e das instruções.

Essa distinção aparece no caso da Pesquisa de Pessoas. Uma solicitação habilita a Pesquisa de Pessoas e é concluída com sucesso, mas seu registro de uso não mostra nenhuma invocação de Pesquisa de Pessoas. O prompt é um pedido plausível de pesquisa de pessoas, no entanto, o modelo responde sem a ferramenta especializada.

O controle explícito nomeia a tarefa de pesquisa de pessoas. Seu registro de uso contém uma invocação de search_people, correspondendo ao campo de uso de Pesquisa de Pessoas documentado pela Perplexity.

Ambas as solicitações foram concluídas. Apenas uma provou a capacidade pretendida.

Avaliações de ferramentas precisam de três afirmações:

1. A ferramenta está presente na solicitação ou descoberta através do MCP.
2. A resposta registra que a ferramenta foi invocada.
3. A saída contém evidência produzida por essa invocação.

A disponibilidade da ferramenta é evidência de configuração. A telemetria da chamada da ferramenta é evidência de execução.

Respostas geradas podem ter sucesso e adicionar fatos não suportados

Endpoints de respostas geradas expõem outro tipo de falso positivo. A resposta pode ser fluente, citada e estruturalmente válida enquanto adiciona uma alegação que sua fonte citada não suporta para a operação testada.

A pergunta congelada pergunta sobre gravações condicionais do Amazon S3 usando If-None-Match e If-Match. A documentação oficial...