Por qué probar agentes es diferente
No determinismo, coste de los LLM y motivos por los que las pruebas unitarias estándar no son suficientes.
Por qué probar agentes es diferente es una lección gratuita de AI Agents en CoddyKit. Esta es la lección 1 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de AI Agents, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de AI Agents incluye 4 lecciones en total.
Pruebas de software frente a pruebas de agentes
El software tradicional es determinista: con la misma entrada, obtiene la misma salida. Las pruebas unitarias dependen de esta propiedad para comprobar valores esperados exactos.
Los agentes de IA rompen este supuesto. El mismo prompt puede producir salidas diferentes en cada ejecución, por lo que los enfoques de pruebas estándar no son suficientes por sí solos.
No determinismo: misma entrada, distinta salida
Los LLM son probabilísticos por naturaleza. El parámetro temperature controla la aleatoriedad; incluso con temperature=0, las salidas pueden variar entre versiones del modelo o debido a cambios en la infraestructura.
Esto significa que una prueba del agente que hoy funciona puede fallar mañana sin que haya cambios en el código.
import openai
client = openai.OpenAI(api_key='YOUR_API_KEY')
# Same prompt, potentially different outputs each run
for i in range(3):
response = client.chat.completions.create(
model='gpt-4o-mini',
messages=[{'role': 'user', 'content': 'Name a planet.'}],
temperature=0.9 # High randomness
)
print(f'Run {i+1}: {response.choices[0].message.content}')
# Run 1: Mars
# Run 2: Jupiter
# Run 3: SaturnEl problema del coste: las llamadas reales a LLM son caras
Ejecutar un conjunto de pruebas que realice llamadas reales a las API de OpenAI o Anthropic puede costar varios dólares por ejecución. Una canalización de CI que ejecute 100 pruebas × 10 iteraciones podría costar cientos de dólares al mes.
Esto hace poco práctico probar los agentes del mismo modo que las pruebas unitarias; necesita estrategias para controlar los costes.
# A test that calls the real API costs tokens every run
# 100 tests x 500 tokens each x 10 CI runs/day = 500,000 tokens/day
# At $0.15/1M tokens (gpt-4o-mini): ~$0.075/day = ~$27/year for a tiny suite
# For gpt-4o: 15x more expensive = ~$400/year
# This is why mocking and recording API responses is essential
print('Real API calls in tests = expensive and slow')
print('Solution: Mock or record LLM responses in unit tests')
print('Reserve real calls for scheduled integration tests')El problema de la latencia
Las llamadas reales a las API de LLM suelen tardar entre 2 y 20 segundos. Un conjunto de pruebas con 50 pruebas tardaría entre 100 y 1000 segundos en ejecutarse. Esto perjudica la productividad de los desarrolladores; la respuesta rápida es un valor fundamental de unas buenas pruebas.
Simular las llamadas a LLM hace que las pruebas se ejecuten en milisegundos.
import time
# Simulating what a test suite looks like with real vs mocked calls
num_tests = 50
# Real API calls
real_time = num_tests * 5 # avg 5 seconds per call
print(f'With real API calls: {real_time}s = {real_time/60:.1f} minutes')
# Mocked calls
mock_time = num_tests * 0.001 # <1ms per mock
print(f'With mocked calls: {mock_time:.3f}s = nearly instant')
# Conclusion: mock in unit tests, use real calls in integration testsDependencias externas en las pruebas de agentes
Los agentes suelen llamar a herramientas externas: API de búsqueda, bases de datos, sistemas de archivos y scrapers web. En las pruebas, estas dependencias pueden:
- No estar disponibles (interrupción de red, caída de una API)
- Devolver datos diferentes en cada ejecución
- Tener límites de frecuencia que bloqueen las canalizaciones de CI
Debe controlar o simular estas dependencias en las pruebas unitarias.
# An agent might call multiple external services
# Each is a potential test failure point
def agent_pipeline(query: str) -> str:
search_results = search_web(query) # External: Tavily/Serper API
documents = fetch_documents(search_results) # External: HTTP calls
answer = llm_summarize(documents) # External: OpenAI API
saved = database_store(answer) # External: PostgreSQL
return answer
# In unit tests: mock ALL of these
# In integration tests: use sandboxed versions of real services
print('Each external call is a test reliability risk')Qué suponen las pruebas unitarias estándar
Los frameworks de pruebas unitarias estándar, como pytest, suponen lo siguiente:
- Las pruebas son rápidas (milisegundos)
- Las pruebas son deterministas
- Las pruebas no tienen efectos secundarios externos
- Las pruebas pueden ejecutarse en cualquier orden
Las pruebas de agentes incumplen estos cuatro supuestos a menos que diseñe explícitamente el sistema teniendo en cuenta estas diferencias.
# Standard unit test — works perfectly for deterministic code
def add(a, b):
return a + b
def test_add():
assert add(2, 3) == 5 # Always passes — deterministic
# Agent 'unit test' that calls a real LLM — problematic
# def test_agent_answers_question():
# response = agent.run('What is 2+2?')
# assert response == '4' # Might return 'The answer is 4' or 'Four'
print('Exact string matching fails for LLM outputs')
print('Need structural or semantic assertions instead')La pirámide de pruebas para agentes
Una estrategia práctica de pruebas para agentes sigue una estructura piramidal:
- Pruebas unitarias (muchas y rápidas): prueban herramientas y funciones individuales con llamadas a LLM simuladas
- Pruebas de integración (menos y más lentas): prueban el flujo del agente de extremo a extremo con servicios en un entorno aislado
- Pruebas de evaluación (pocas y costosas): comprueban la calidad de la salida con llamadas reales a LLM y una puntuación al estilo humano
Aserciones estructurales frente a semánticas
En lugar de comparar cadenas exactas, las pruebas de agentes deben usar aserciones estructurales (¿el agente llamó a la herramienta correcta?) o comprobaciones semánticas (¿la salida contiene el concepto relevante?).
# Fragile: exact string match
# assert response.content == 'The capital of France is Paris.'
# Better: structural assertion
# assert response.tool_calls[0]['function']['name'] == 'search_web'
# Better: semantic check
def test_capital_in_response(response_text: str) -> bool:
key_words = ['paris', 'france', 'capital']
lower = response_text.lower()
return all(word in lower for word in key_words)
response = 'Paris is the capital city of France.'
print(test_capital_in_response(response)) # TrueHarnesses de evaluación y LLM-as-judge
Para evaluar la calidad, el sector utiliza el enfoque LLM-as-judge: pide a un segundo LLM que puntúe la salida del agente. Frameworks como DeepEval y RAGAS automatizan este patrón.
Se reserva para ejecuciones de evaluación costosas, no para la CI rutinaria.
import openai
client = openai.OpenAI(api_key='YOUR_API_KEY')
def llm_judge(question: str, answer: str) -> dict:
prompt = f'Question: {question}\nAnswer: {answer}\nRate the answer 1-5 for accuracy. Reply with only a number.'
response = client.chat.completions.create(
model='gpt-4o-mini',
messages=[{'role': 'user', 'content': prompt}]
)
score = int(response.choices[0].message.content.strip())
return {'score': score, 'pass': score >= 4}
# result = llm_judge('What is the capital of France?', 'Paris')
# print(result) # {'score': 5, 'pass': True}Pruebas de regresión para agentes
Cuando actualice un prompt o cambie la lógica del agente, las pruebas de regresión verifican que no haya roto el comportamiento existente. Registre ejemplos de referencia (entrada → estructura esperada) y ejecútelos automáticamente en cada commit.
# golden_examples.py
GOLDEN_EXAMPLES = [
{
'input': 'Search for the weather in Paris',
'expected_tool': 'get_weather',
'expected_args': {'city': 'Paris'}
},
{
'input': 'Calculate 15% tip on $45',
'expected_tool': 'calculate',
'expected_args': {'expression': '45 * 0.15'}
}
]
def run_regressions(agent, examples: list) -> int:
failures = 0
for ex in examples:
result = agent.plan(ex['input']) # mocked LLM
if result['tool'] != ex['expected_tool']:
print(f'FAIL: expected {ex["expected_tool"]}, got {result["tool"]}')
failures += 1
return failures
# --- demo: a stub agent whose .plan() mimics an LLM's tool choice ---
class _StubAgent:
def plan(self, text):
if 'weather' in text.lower():
return {'tool': 'get_weather'}
if 'tip' in text.lower() or 'calculate' in text.lower():
return {'tool': 'wrong_tool'} # simulate a regression
return {'tool': 'unknown'}
failures = run_regressions(_StubAgent(), GOLDEN_EXAMPLES)
print(f'{failures} of {len(GOLDEN_EXAMPLES)} golden examples failed')
Configuración de un archivo de pruebas básico para un agente
Esta es una estructura mínima de archivo de pruebas de pytest para un agente. Separa las pruebas unitarias rápidas (con mocks) de las pruebas de integración lentas (con llamadas reales), lo que le permite ejecutar solo lo que necesita.
# tests/test_agent.py
import pytest
# Fast unit tests — run on every commit
class TestAgentTools:
def test_tool_returns_dict(self, mock_llm):
result = my_tool(query='test')
assert isinstance(result, dict)
assert 'data' in result
def test_agent_selects_correct_tool(self, mock_llm):
response = agent.run('Search for Python tutorials')
assert response['tool_used'] == 'web_search'
# Slow integration tests — run nightly or on release
@pytest.mark.integration
class TestAgentIntegration:
def test_full_pipeline_with_real_api(self):
# Uses real OpenAI + sandboxed services
result = agent.run('Summarize the Python docs')
assert len(result['answer']) > 50Comprobación de conocimientos: por qué las pruebas de agentes son diferentes
Compruebe sus conocimientos sobre los desafíos específicos de probar agentes de IA.
Recapitulación: por qué las pruebas de agentes son diferentes
Las pruebas de agentes de IA requieren un enfoque diferente al de las pruebas unitarias convencionales:
- No determinismo: La misma entrada puede producir diferentes resultados válidos
- Coste: Las llamadas reales a LLM son costosas; simúlelas en las pruebas unitarias
- Latencia: Las llamadas reales a las API tardan segundos; los mocks se ejecutan en milisegundos
- Dependencias externas: Las herramientas y las API deben estar controladas en las pruebas
- Aserciones: Use comprobaciones estructurales y semánticas, no coincidencias exactas de cadenas
Use una pirámide de pruebas: muchas pruebas unitarias económicas con mocks y menos pruebas de integración costosas con llamadas reales.
Preguntas frecuentes
¿La lección «Por qué probar agentes es diferente» es gratis?
Sí — el texto completo de «Por qué probar agentes es diferente» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de AI Agents, actualiza a CoddyKit PRO. El curso de AI Agents incluye 4 lecciones en total.
¿Qué aprenderé en «Por qué probar agentes es diferente»?
No determinismo, coste de los LLM y motivos por los que las pruebas unitarias estándar no son suficientes. Practicas AI Agents con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar AI Agents?
No se requiere experiencia previa. AI Agents en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 1 de 4.
¿Cuánto tiempo toma la lección «Por qué probar agentes es diferente»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de AI Agents?
Sí. Cada lección de AI Agents incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Por qué probar agentes es diferente
- Simulación de llamadas a LLM en pruebas
- Pruebas de agentes basadas en aserciones
- Pruebas de integración para pipelines de agentes