Supongamos que tu producto recibe tickets de soporte y quieres que Claude escriba una respuesta para cada uno. Antes de construir nada, elige cuánto construir. Una construcción más grande suele dar mejores resultados, pero también tiende a costar más y a hacer esperar más a tus clientes.
Puedes enviar una sola solicitud, ejecutar un flujo de trabajo de varias solicitudes en un orden que define tu código, o usar un agente que elige sus propios pasos. Empieza por lo más simple y pasa a lo siguiente solo cuando una prueba muestre que lo simple no es suficiente.
Pregúntate quién decide el siguiente paso
Las tres opciones difieren en quién decide qué sucede después de que Claude responde.
- Con una sola solicitud, no sucede nada después, y la respuesta de Claude es el resultado.
- En un flujo de trabajo, tu código decide. Envía la siguiente solicitud, en un orden que escribiste de antemano.
- Con un agente, Claude decide. Elige cada siguiente paso y qué herramientas usar.
Para elegir entre las tres opciones, primero anota cómo se ve un buen resultado. Para los tickets de soporte, una buena respuesta podría ser aquella que responde la pregunta del cliente, sigue tu política de reembolsos y necesita solo ediciones ligeras antes de enviarse. Con eso anotado, puedes probar la opción más simple frente a ese criterio y ver si no es suficiente.
Estás planeando una función que redacta notas de versión a partir de pull requests fusionados. Aún no has construido nada. ¿Qué anotas antes de decidir cuánto construir?
Empieza con una sola solicitud
Una sola solicitud es una solicitud a la Messages API, con una respuesta de vuelta. Junto con el ticket, puede llevar los artículos de ayuda que tu código busca para ese ticket y algunas respuestas anteriores que te gustaron, como ejemplos a seguir. Para muchas funciones, una sola solicitud construida así suele ser suficiente.
Para ver si una sola solicitud es suficiente para tus tickets, ejecútala con tickets reales del mes pasado. Califica cada respuesta frente a lo que anotaste como un buen resultado. Luego lee las respuestas que fallaron y observa qué tipos de tickets respondieron. Una prueba como esta, con entradas reales y una forma de calificar lo que se obtiene, se llama eval.
Si las respuestas coinciden con lo que anotaste, lanza la solicitud única y detente ahí. Donde fallen, mejora las instrucciones, los artículos y los ejemplos de la solicitud antes de pasar al siguiente nivel.
Una señal de que una sola solicitud no es suficiente es que una corrección para un tipo de ticket empeora otro tipo. Por ejemplo, agregas tus reglas de reembolso al prompt, y las respuestas a las preguntas técnicas empeoran. Cuando sigues intercambiando una corrección por otra de esta manera, prueba un flujo de trabajo.
Una sola solicitud redacta notas de versión a partir de pull requests fusionados. La ejecutas con los lanzamientos del mes pasado y calificas cada nota. ¿Qué resultado te indica que debes probar un flujo de trabajo?
Pasa a un flujo de trabajo cuando puedas enumerar los pasos
Una vez que una sola solicitud no sea suficiente, elige un flujo de trabajo si puedes escribir los pasos antes de que llegue el primer ticket. Un flujo de trabajo encaja en una tarea que se divide claramente en pasos fijos.
Un flujo de trabajo para los tickets de soporte podría ejecutarse en dos pasos:
- Una primera solicitud clasifica el ticket en uno de tres tipos: reembolso, pregunta técnica o pregunta general.
- Tu código envía el ticket en una segunda solicitud, con el prompt y los artículos de ayuda correspondientes a ese tipo de ticket.
Cada tipo de ticket tiene ahora su propio prompt, así que un cambio en el prompt de reembolso no afecta las respuestas técnicas.
Dividir una tarea en solicitudes también te permite ver qué sale entre los pasos. Cada paso es su propia solicitud, así que puedes registrarlo, calificarlo y verificarlo antes de que se ejecute el siguiente. Por ejemplo, tu código puede comprobar que la primera solicitud devolvió uno de los tres tipos, y enviar cualquier otra respuesta a una persona.
Este flujo de trabajo hace que tus clientes esperen más tiempo, porque la segunda solicitud no puede comenzar hasta que termine la primera. Aceptas esa espera para obtener respuestas más precisas, y tu prueba tiene que demostrar que las obtienes.
Un flujo de trabajo ya no encaja cuando no puedes escribir los pasos de antemano. Por ejemplo, una respuesta requiere que Claude busque el pedido del cliente, y lo que revisa a continuación depende de lo que encuentra ahí.
Pasa a un agente solo cuando no tengas otra opción
Elige un agente solo para una tarea abierta, donde Claude tiene que elegir cada siguiente paso con las herramientas que le das. Abierta significa que es difícil o imposible predecir cuántos pasos necesita la tarea, y no puedes escribir los pasos de antemano.
Por ejemplo, un cliente escribe que su paquete nunca llegó. Claude busca primero el historial de pedidos y descubre que el paquete fue enviado a una dirección antigua. Entonces Claude lee a continuación tus artículos de política sobre direcciones incorrectas. Luego emite un reembolso o actualiza el ticket.
Un agente cuesta más, y sus errores pueden acumularse unos sobre otros. La libertad de elegir que hace útil a un agente también hace que sea más difícil de probar. Puede ejecutarse durante muchos pasos, así que necesitas cierta confianza en sus decisiones.
Antes de elegir un agente, responde estas preguntas sobre la tarea:
- ¿Vale la pena un mejor resultado el mayor costo y la espera más larga?
- ¿Claude realiza bien este tipo de tarea?
- ¿Se puede detectar y recuperar un paso equivocado, con pruebas, una revisión o una reversión?
Si la respuesta a alguna de ellas es no, quédate con un flujo de trabajo o una sola solicitud. Para los tickets de soporte, eso significa que mantienes el flujo de trabajo para los tipos de tickets cuyos pasos puedes enumerar, y envías el resto a una persona.
Un agente encaja solo en los tickets donde el orden de las búsquedas y los reembolsos cambia de ticket en ticket. Una persona aprueba cada reembolso, así que la respuesta a la tercera pregunta es sí.
Tu flujo de trabajo de notas de versión maneja lanzamientos rutinarios, pero algunos necesitan pasos que no puedes enumerar de antemano. Un agente publicaría directamente a los clientes, sin revisión y sin forma de retirar una nota. ¿Qué haces con esos lanzamientos?
Pruébalo con algunas ideas de funciones
Prueba cada idea de función con las tres opciones para ver qué sucede con ella.
Hacia dónde ir a continuación
Antes de construir cualquier función en Claude, anota cómo se ve un buen resultado, empieza con una sola solicitud y pasa al siguiente nivel solo cuando una prueba muestre que no es suficiente. Haz la misma elección ahora para la función que estás planeando. Para verificar tu elección, identifica quién decide el siguiente paso en tu función y el resultado de la prueba que te haría pasar al siguiente nivel.
La prueba que te indica cuándo pasar al siguiente nivel es un eval. A continuación, toma Introducción a los evals(se abre en una pestaña nueva) para construir un pequeño eval con tus propios datos.
Dos páginas más te ayudarán una vez que hayas elegido. Si tu función le da herramientas a Claude, Uso de herramientas con la Messages API(se abre en una pestaña nueva) muestra cómo hacer que el uso de herramientas sea confiable, receptivo y más económico de ejecutar. Si eliges un agente, ¿Qué son los Claude Managed Agents?(se abre en una pestaña nueva) cubre un entorno administrado que ejecuta el agente y sus herramientas, para que no tengas que construir esa parte tú mismo.