Puede utilizar ToolSimulator, un marco de simulación de herramientas basado en LLM dentro de Strands Evals, para probar de forma exhaustiva y segura agentes de IA que dependen de herramientas externas, a escala. En lugar de arriesgarse a realizar llamadas API en vivo que exponen información de identificación personal (PII), desencadenar acciones no deseadas o conformarse con simulaciones estáticas que interrumpen los flujos de trabajo de múltiples turnos, puede utilizar las simulaciones basadas en el modelo de lenguaje grande (LLM) de ToolSimulator para validar a sus agentes. Disponible hoy como parte del kit de desarrollo de software (SDK) de Strands Evals, ToolSimulator lo ayuda a detectar errores de integración de manera temprana, probar casos extremos de manera integral y enviar agentes listos para producción con confianza.
En esta publicación, aprenderá a: Configurar ToolSimulator y registrar herramientas para simulación Configurar simulaciones de herramientas con estado para flujos de trabajo de agentes de múltiples turnos Aplicar esquemas de respuesta con modelos Pydantic Integrar ToolSimulator en un proceso completo de evaluación de Strands Evals Aplicar las mejores prácticas para la evaluación de agentes basada en simulación
Requisitos previos
Antes de comenzar, asegúrese de tener lo siguiente:
Python 3.10 o posterior instalado en su entorno SDK de Strands Evals instalado: pip install strands-evals Familiaridad básica con Python, incluidos decoradores y sugerencias de tipo Familiaridad con agentes de IA y conceptos de llamada de herramientas (llamadas API, esquemas de funciones) El conocimiento de Pydantic es útil para los ejemplos de esquemas avanzados, pero no es necesario para comenzar No se requiere una cuenta de AWS para ejecutar ToolSimulator localmente
Por qué las pruebas de herramientas desafían su flujo de trabajo de desarrollo
Los agentes de IA modernos no sólo razonan. Llaman a API, consultan bases de datos, invocan servicios de Model Context Protocol (MCP) e interactúan con sistemas externos para completar tareas. El comportamiento de su agente depende no sólo de su razonamiento, sino también de lo que le devuelven esas herramientas. Cuando prueba estos agentes con API activas, se enfrenta a tres desafíos que lo ralentizan y ponen en riesgo sus sistemas.
Tres desafíos que crean las API en vivo:
Las dependencias externas te frenan. Las API en vivo imponen límites de velocidad, experimentan tiempo de inactividad y requieren conectividad de red. Cuando se ejecutan cientos de casos de prueba, estas restricciones hacen que las pruebas exhaustivas no sean prácticas. El aislamiento de prueba se vuelve riesgoso. Las llamadas a herramientas reales desencadenan efectos secundarios reales. Corre el riesgo de enviar correos electrónicos reales, modificar bases de datos de producción o reservar vuelos reales durante las pruebas. Las pruebas de su agente no deberían interactuar con los sistemas contra los que están probando. La privacidad y la seguridad crean barreras. Muchas herramientas manejan datos confidenciales, incluidos registros de usuarios, información financiera y PII. La ejecución de pruebas en sistemas activos expone innecesariamente esos datos y crea riesgos de cumplimiento.
Por qué los simulacros estáticos se quedan cortos
Podrías considerar simulacros estáticos como alternativa. Los simulacros estáticos funcionan en escenarios sencillos y predecibles, pero requieren un mantenimiento constante a medida que sus API evolucionan. Más importante aún, se descomponen en los flujos de trabajo con estado y de múltiples turnos que realizan los agentes reales.
Considere un agente de reservas de vuelos. Busca vuelos con una llamada de herramienta y luego verifica el estado de la reserva con otra. La segunda respuesta debería depender de lo que hizo la primera llamada. Una respuesta codificada no puede reflejar una base de datos que cambia de estado entre llamadas. Las simulaciones estáticas no pueden capturar esto.
¿Qué hace que ToolSimulator sea diferente?
ToolSimulator resuelve estos desafíos con tres capacidades esenciales que trabajan juntas para brindarle pruebas de agentes seguras y escalables sin sacrificar el realismo.
Generación de respuesta adaptativa. Los resultados de la herramienta reflejan lo que su agente realmente solicitó, no una plantilla fija. Cuando su agente llama para buscar vuelos de Seattle a Nueva York, ToolSimulator le devuelve opciones plausibles con precios y horarios realistas, no un marcador de posición genérico. Soporte de flujo de trabajo con estado. Muchas herramientas del mundo real mantienen el estado entre las llamadas. Una operación de escritura debería afectar las lecturas posteriores. ToolSimulator mantiene un estado compartido consistente en todas las llamadas de herramientas, lo que hace que sea seguro probar interacciones de bases de datos, flujos de trabajo de reserva y procesos de varios pasos sin tocar los sistemas de producción. Aplicación del esquema. Los desarrolladores suelen agregar una capa de posprocesamiento que analiza la salida sin procesar de la herramienta en un formato estructurado. Cuando una herramienta devuelve una respuesta con formato incorrecto, esta capa se rompe. ToolSimulator valida las respuestas frente a los esquemas de Pydantic que usted define, detectando respuestas con formato incorrecto antes de que lleguen a su agente.
Cómo funciona ToolSimulator
Figura 1: ToolSimulator (TS) intercepta llamadas a herramientas y las enruta a un generador de respuestas basado en LLM
ToolSimulator intercepta llamadas a sus herramientas registradas y las enruta a un generador de respuestas basado en LLM. El generador utiliza el esquema de la herramienta, la entrada de su agente y el estado actual de la simulación para producir una respuesta realista y apropiada para el contexto. No se requieren accesorios escritos a mano.
Su flujo de trabajo sigue tres pasos: decorar y registrar sus herramientas, opcionalmente dirigir la simulación con contexto y luego dejar que ToolSimulator se burle de las respuestas de la herramienta cuando se ejecute su agente.
Figura 2: El flujo de trabajo de tres pasos de ToolSimulator (TS): decorar y registrar, dirigir, simular
Empezando con ToolSimulator
Las siguientes secciones lo guiarán a través de cada paso del flujo de trabajo de ToolSimulator, desde la configuración inicial hasta la ejecución de su primera simulación.
Paso 1: Decora y registra
Cree una instancia de ToolSimulator, luego ajuste la función de su herramienta con el decorador @simulator.tool() para registrarla para la simulación. El cuerpo de la función real puede permanecer vacío. ToolSimulator intercepta las llamadas antes de que lleguen a la implementación:
from strands_evals.simulation.tool_simulator import ToolSimulator tool_simulator = ToolSimulator() @tool_simulator.tool() def search_flights(origen: str, destino: str, fecha: str) -> dict: """Buscar vuelos disponibles entre dos aeropuertos en una fecha determinada.""" pass # La implementación real nunca se llama durante la simulación
Paso 2: Dirigir (configuración opcional)
De forma predeterminada, ToolSimulator infiere automáticamente cómo debe comportarse cada herramienta a partir de su esquema y cadena de documentación. No se necesita ninguna configuración adicional para comenzar. Cuando necesite más control, puede utilizar estos tres parámetros opcionales para personalizar el comportamiento de la simulación:
share_state_id: vincula herramientas que comparten el mismo backend bajo una clave de estado común. Los cambios de estado realizados por una herramienta (por ejemplo, un definidor) son inmediatamente visibles para llamadas posteriores de otra (por ejemplo, un captador). initial_state_description: inicia la simulación con una descripción en lenguaje natural del estado preexistente. Un contexto más rico produce respuestas más realistas y consistentes. esquema_salida: un modelo de Pydantic que define la estructura de respuesta esperada. ToolSimulator genera respuestas que se ajustan estrictamente a este esquema.
Paso 3: simulacro
Cuando su agente llama a una herramienta registrada, el contenedor ToolSimulator intercepta la llamada y la enruta al generador de respuesta dinámica. El generador valida los parámetros del agente con el esquema de la herramienta, produce una respuesta que coincide con el esquema_salida y actualiza el registro de estado para que las llamadas a la herramienta posteriores vean un mundo coherente.
Figura 3: El flujo de simulación de ToolSimulator (TS) cuando el agente llama a una herramienta registrada
El siguiente ejemplo simula una herramienta de búsqueda de vuelos adjunta a un asistente de búsqueda de vuelos:
from strands import Agente de strands_evals.simulation.tool_simulator import ToolSimulator # 1. Cree una instancia de simulador tool_simulator = ToolSimulator() # 2. Registre una herramienta para simulación con contexto de estado inicial @tool_simulator.tool(inicial_state_description="Base de datos de vuelos: SEA->Vuelos JFK disponibles a las 8 a. m., 12 p. m. y 6 p. m.. Los precios oscilan entre $ 180 y $420.", ) def search_flights(origen: str, destino: str, fecha: str) -> dict: """Buscar vuelos disponibles entre dos aeropuertos en una fecha determinada.""" pass # 3. Cree un agente con la herramienta simulada y ejecútela Flight_tool = tool_simulator.get_tool("search_flights") agente = Agente( system_prompt="Usted es un asistente de búsqueda de vuelos.", herramientas=[flight_tool], ) respuesta = agente ("Búsqueme vuelos de Seattle a Nueva York el 15 de marzo") print(respuesta) # Resultado esperado: una lista estructurada de vuelos SEA->JFK simulados con horarios # y precios consistentes con la descripción_estado_inicial que proporcionó.
Uso avanzado de ToolSimulator
Las siguientes secciones cubren tres capacidades avanzadas que le brindan más control sobre el comportamiento de la simulación: ejecutar instancias independientes para pruebas en paralelo, configurar el estado compartido para flujos de trabajo de varios turnos y aplicar esquemas de respuesta personalizados.
Ejecute instancias de simulador independientes
Puede crear varias instancias de ToolSimulator una al lado de la otra. Cada instancia mantiene su propio registro y estado de herramientas, por lo que puede ejecutar configuraciones de experimentos en paralelo en la misma base de código:
Simulator_a = ToolSimulator() Simulator_b = ToolSimulator() # Cada instancia tiene un registro y estado de herramienta independiente – # ideal para comparar el comportamiento del agente entre diferentes configuraciones de herramientas.
Configurar el estado compartido para flujos de trabajo de varios turnos
Para herramientas con estado, como captadores y configuradores de bases de datos, ToolSimulator mantiene un estado compartido consistente entre las llamadas a herramientas. Utilice share_state_id para vincular herramientas que operan en el mismo backend e inicial_state_description para inicializar la simulación con un contexto preexistente:
@tool_simulator.tool( share_state_id="flight_booking", inicial_state_description="Sistema de reserva de vuelos: SEA->Vuelos JFK disponibles a las 8 a. m., 12 p. m. y 6 p. m. No hay reservas activas actualmente.", ) def search_flights(origen: str, destino: str, fecha: str) -> dict: """Buscar vuelos disponibles entre dos aeropuertos en una fecha determinada.""" pass @tool_simulator.tool( share_state_id="flight_booking", ) def get_booking_status(booking_id: str) -> dict: """Recuperar el estado actual de una reserva de vuelo mediante ID de reserva.""" pass # Ambas herramientas comparten el estado "flight_booking". # Cuando se llama a search_flights, get_booking_status ve los mismos # datos de disponibilidad de vuelos en llamadas posteriores.
Inspeccione el estado antes y después de la ejecución del agente para validar que las interacciones de las herramientas produjeron los cambios esperados:
estado_inicial = tool_simulator.get_state("flight_booking") # … ejecuta el agente… final_state = tool_simulator.get_state("flight_booking") # Verifica no solo el resultado final, sino también la secuencia completa de interacciones de la herramienta.
Consejo: estado inicial a partir de datos reales
Debido a que initial_state_description acepta lenguaje natural, puedes ser creativo a la hora de generar contexto. Para herramientas que interactúan con datos tabulares, utilice una llamada a DataFrame.describe() para generar resúmenes estadísticos y pasar esas estadísticas directamente como descripción del estado. ToolSimulator generará respuestas que reflejen distribuciones de datos realistas, sin tener que acceder a los datos reales.
Aplicar un esquema de respuesta personalizado
De forma predeterminada, ToolSimulator infiere una estructura de respuesta a partir de la cadena de documentación y las sugerencias de tipo de la herramienta. Para herramientas que siguen especificaciones estrictas, como esquemas OpenAPI o MCP, defina la respuesta esperada como un modelo Pydantic y páselo usando output_schema:
de pydantic import BaseModel, clase de campo FlightSearchResponse(BaseModel): vuelos: lista[dict] = Campo( …, descripción="Lista de vuelos disponibles con número de vuelo, hora de salida y precio" ) origen: str = Campo(…, descripción="Código de aeropuerto de origen") destino: str = Campo(…, descripción="Código de aeropuerto de destino") estado: str = Campo(default="éxito", descripción="Estado de operación de búsqueda") mensaje: str = Field(default="", descripción="Mensaje de estado adicional") @tool_simulator.tool(output_schema=FlightSearchResponse) def search_flights(origen: str, destino: str, fecha: str) -> dict: """Buscar vuelos disponibles entre dos aeropuertos en una fecha determinada.""" pass # ToolSimulator valida los parámetros estrictamente y devuelve solo respuestas JSON # válidas que se ajusten al esquema FlightSearchResponse.
Integración con canales de evaluación de Strands
ToolSimulator encaja naturalmente en el marco de evaluación de Strands Evals. El siguiente ejemplo muestra un proceso completo, desde la configuración de la simulación hasta el informe del experimento, utilizando GoalSuccessRateEvaluator para calificar el desempeño del agente en tareas de llamada de herramientas:
desde escribir importar Cualquiera desde pydantic importar BaseModel, Campo desde strands importar Agente desde strands_evals importar Caso, Experimento desde strands_evals.evaluators importar GoalSuccessRateEvaluator desde strands_evals.simulation.tool_simulator importar ToolSimulator desde strands_evals.mappers importar StrandsInMemorySessionMapper desde strands_evals.telemetry importar StrandsEvalsTelemetry # Configurar telemetría y simulador de herramientas telemetría = StrandsEvalsTelemetry().setup_in_memory_exporter() memoria_exporter = telemetry.in_memory_exporter tool_simulator = ToolSimulator() # Definir la clase de esquema de respuesta FlightSearchResponse(BaseModel): vuelos: lista[dict] = Campo( …, descripción="Vuelos disponibles con número, hora de salida y precio" ) origen: str = Campo(…, descripción="Código de aeropuerto de origen") destino: str = Campo(…, descripción="Código de aeropuerto de destino") estado: str = Campo(default="éxito", descripción="Estado de operación de búsqueda") mensaje: str = Campo(default="", descripción="Mensaje de estado adicional") # Registrar herramientas para simulación @tool_simulator.tool( share_state_id="flight_booking", inicial_state_description="Sistema de reserva de vuelos: SEA->Vuelos JFK en 8 a. m., 12 p. m. y 6 p. m. No hay reservas activas actualmente.", output_schema=FlightSearchResponse, ) def search_flights(origen: str, destino: str, fecha: str) -> dict[str, Any]: """Buscar vuelos disponibles entre dos aeropuertos en una fecha determinada.""" pass @tool_simulator.tool(share_state_id="flight_booking") def. get_booking_status(booking_id: str) -> dict[str, Any]: """Recuperar el estado actual de una reserva de vuelo mediante ID de reserva.""" pass # Definir la tarea de evaluación def user_task_function(case: Case) -> dict:initial_state = tool_simulator.get_state("flight_booking") print(f"[State before]: {initial_state.get('initial_state')}") search_tool = tool_simulator.get_tool("search_flights") status_tool = tool_simulator.get_tool("get_booking_status") agente = Agente( trace_attributes={ "gen_ai.conversation.id": case.session_id, "session.id": case.session_id }, system_prompt="Usted es un asistente de reserva de vuelos.", herramientas=[search_tool, status_tool], callback_handler=Ninguno, ) agent_response = agente(case.input) print(f"[Usuario]: {case.input}") print(f"[Agente]: {agent_response}") final_state = tool_simulator.get_state("flight_booking") print(f"[Estado después de]: {final_state.get('previous_calls',[])}") Finish_spans = Memory_exporter.get_finished_spans() mapper = StrandsInMemorySessionMapper() session = mapper.map_to_session(finished_spans, session_id=case.session_id) return {"output": str(agent_response), "trajectory": session} # Definir casos de prueba, ejecutar el experimento y mostrar el informe test_cases = [ Case( name="flight_search", input="Encuéntrame vuelos de Seattle a Nueva York el 15 de marzo.", metadata={"category": "flight_booking"}, ), ] experiment = Experiment[str, str]( cases=test_cases, evaluators=[GoalSuccessRateEvaluator()] ) reports = experiment.run_evaluaciones(user_task_function) reportes[0].run_display()
La función de tarea recupera las herramientas simuladas, crea un agente, ejecuta la interacción y devuelve tanto la salida del agente como la trayectoria de telemetría completa. La trayectoria brinda a evaluadores como GoalSuccessRateEvaluator acceso a la secuencia completa de llamadas a herramientas e invocaciones de modelos, no solo a la respuesta final.
Mejores prácticas para la evaluación basada en simulación
Las siguientes prácticas le ayudarán a aprovechar al máximo ToolSimulator en los flujos de trabajo de desarrollo y evaluación:
Comience con la configuración predeterminada para una cobertura amplia. Agregue anulaciones de configuración solo para los entornos de herramientas específicos que desee controlar con precisión. Los valores predeterminados de ToolSimulator están diseñados para producir un comportamiento realista sin necesidad de configuración. Proporcione valores enriquecidos de descripción_estado_inicial para herramientas con estado. Cuanto más contexto plantee, más realistas y consistentes serán las respuestas simuladas. Incluya rangos de datos, recuentos de entidades y contexto de relación. Utilice share_state_id para herramientas que interactúan con el mismo backend, de modo que las operaciones de escritura sean visibles para lecturas posteriores. Esto es esencial para probar flujos de trabajo de varios turnos, como reservas, gestión de carritos o actualizaciones de bases de datos. Aplique output_schema para herramientas que sigan especificaciones estrictas, como esquemas OpenAPI o MCP. La aplicación de esquemas detecta respuestas con formato incorrecto antes de que lleguen a su agente y rompan su capa de posprocesamiento. Valide las secuencias de interacción de las herramientas, no solo los resultados finales. Inspeccione los cambios de estado antes y después de la ejecución del agente para confirmar que las llamadas a las herramientas se produjeron en el orden correcto y produjeron las transiciones de estado correctas. Empiece poco a poco y amplíese. Comience con los escenarios de interacción de herramientas más comunes y luego amplíe a casos extremos a medida que madure su práctica de evaluación. Complemente las pruebas basadas en simulación con pruebas API en vivo específicas para rutas de producción críticas.
Conclusión
ToolSimulator transforma la forma en que se prueban los agentes de IA al reemplazar las llamadas API riesgosas en vivo con simulaciones inteligentes y adaptables. Ahora puede validar de forma segura flujos de trabajo complejos y con estado a escala, detectando errores de integración tempranamente y enviando agentes listos para producción con confianza. La combinación de ToolSimulator con los canales de evaluación de Strands Evals le brinda visibilidad total del comportamiento de los agentes sin administrar la infraestructura de pruebas ni arriesgarse a efectos secundarios en el mundo real.
Próximos pasos
Comience a probar sus agentes de IA de forma segura hoy. Instale ToolSimulator con el siguiente comando:
pip instalar hebras-evaluaciones
Para continuar explorando ToolSimulator y Strands Evals, siga estos siguientes pasos:
Lea la documentación de Strands Evals para explorar todas las opciones de configuración, incluida la gestión de estado avanzada y los evaluadores personalizados. Pruebe el ejemplo para ver ToolSimulator en acción. Amplíe el ejemplo agregando más herramientas y probando flujos de trabajo de agentes de varios pasos. Explore Amazon Bedrock para conocer las opciones de backend de LLM que impulsan la generación de respuestas de ToolSimulator. Obtenga información sobre AWS Lambda para estrategias de implementación de agentes sin servidor que combinan bien con las pruebas basadas en ToolSimulator. Únase a los foros de la comunidad de Strands para hacer preguntas, compartir sus configuraciones de evaluación y conectarse con otros agentes desarrolladores. Comparte tus comentarios. Nos encantaría saber cómo estás usando ToolSimulator. Comparta sus comentarios, informe problemas y sugiera funciones a través del repositorio de Strands Evals GitHub o los foros de la comunidad.
Acerca de los autores
Darren Wang
Darren Wang es ingeniero de investigación en Amazon Web Services, donde une sistemas de producción e investigación de IA de vanguardia. Con un doctorado. Con experiencia en reconocimiento de voz y cinco años de experiencia en ingeniería antispam de correo electrónico, Darren transforma la investigación de aprendizaje automático en etapas iniciales en soluciones escalables y listas para producción que brindan un impacto mensurable en el cliente. Especializado en marcos de simulación y evaluación de agentes, capacita a los desarrolladores para crear agentes de IA más confiables y comprobables a través de una infraestructura de prueba sólida. Fuera del trabajo, le gusta hacer búlder, tocar el violín y todo lo relacionado con los gatos.
xuan qi
Xuan Qi es científica aplicada en Amazon Web Services, donde aplica su experiencia en física para abordar desafíos complejos en aprendizaje automático e inteligencia artificial. Especializado en modelado y simulación de aprendizaje automático, a Xuan le apasiona traducir conceptos científicos en aplicaciones prácticas que impulsen avances tecnológicos significativos. Su trabajo se centra en desarrollar sistemas de inteligencia artificial más intuitivos y eficientes que puedan comprender e interactuar mejor con el mundo. Fuera de sus actividades profesionales, Xuan encuentra el equilibrio y la creatividad bailando y tocando el violín, incorporando la precisión y armonía de estas artes a sus esfuerzos científicos.
Smeet Dhakecha
Smeet Dhakecha es ingeniero de investigación en Amazon Web Services y trabaja dentro del equipo de Agentic AI Science. Su trabajo abarca sistemas de simulación y evaluación de agentes, así como el diseño e implementación de procesos de transformación de datos y el apoyo a investigaciones científicas de rápido avance para el posentrenamiento de modelos y el entrenamiento de RL.
Vinayak Arannil
Vinayak es científico aplicado sénior en Amazon Web Services. Con varios años de experiencia, ha trabajado en varios dominios de la IA, como visión por computadora, procesamiento del lenguaje natural, sistemas de recomendación, etc. Actualmente, Vinayak ayuda a desarrollar nuevas capacidades en AgentCore y Strands, lo que permite a los clientes evaluar sus aplicaciones Agentic con facilidad, precisión y eficiencia.