Testing y observabilidad de Agentforce: evaluar al agente donde vive

Echá mano del testing y la observabilidad de Agentforce cuando el agente que estás evaluando corre en Agentforce, dentro del modelo de seguridad de Salesforce, sobre Data 360. Este es el build nativo de la plataforma del loop de eval que plantea qué es evaluación — definir criterios de éxito, armar un eval set, calificar, iterar — salvo que la superficie de calificación y el trace de producción son parte de la plataforma sobre la que ya corrés el agente. La razón para elegirlo es encaje, no lealtad: cuando el agente vive en Agentforce, lo testeás y lo mirás donde vive, la eval hereda el modelo de seguridad por construcción, y el trace cae al lado de los datos sobre los que el agente actuó.

Esta página es cómo se arma esa evaluación — la mitad de antes de deployar y la de después — y qué es tuyo y qué es de la plataforma. Vos escribís los casos de test y leés los traces; la plataforma corre los casos contra el agente, los califica, y emite el trace de producción en un formato estándar. Es un instrumento, no el kit entero: al mismo agente muchas veces se lo testea en Testing Center, se lo califica en la capa del modelo con un LLM-as-judge, y se lo trazea fuera de plataforma en LangSmith, cada superficie haciendo la parte para la que está construida. El vocabulario de acá — eval set, ground truth, regresión, online frente a offline — es el vocabulario de qué es evaluación; esta página lo asume y muestra dónde cae cada pieza en Agentforce.

Antes de deployar: Testing Center

Testing Center es la superficie para testear un agente de Agentforce antes de que salga — la eval offline de qué es evaluación, corrida contra el agente en tu org de desarrollo en vez de en un laboratorio. Le das un set de casos de test, cada uno emparejando un utterance que el usuario podría mandar con cómo se ve una respuesta correcta, y corre el agente sobre ellos y califica el resultado. Es testing de regresión para un agente: cambiá un topic, una action o una instrucción, recorré los casos, y mirá si el score se mantuvo antes de exponer a ningún usuario.

Hay tres formas de entrar, y mapean a tres audiencias — la misma escalera de low-code a pro-code que ofrece el resto de la plataforma.

La UI de Testing Center es el camino low-code: armá y corré casos de test en Setup, sin código, la superficie que usa un admin o agent-builder para testear el agente que configuró. También puede generarte casos de test a partir de los propios subagents, actions y knowledge sources del agente, así el eval set no arranca de una página en blanco.
Agentforce DX es el camino pro-code, y Salesforce lo encuadra como el equivalente pro-code de la UI de Testing Center. Generás un test spec — un archivo YAML local que describe los casos de test — con el comando CLI agent generate test-spec, lo personalizás en tu editor, después agent test create para registrarlo en la org de desarrollo y agent test run para ejecutarlo. El spec vive en control de versiones al lado del resto de la metadata del agente, que es el punto: el eval set se revisa, se diffea y se shippea como código, no se mantiene a mano en una UI.
La Testing API es el camino programático — una REST API para armar tests que automatizan la evaluación y evalúan muchos requests en poco tiempo. Es la superficie a la que echás mano cuando el eval set es lo bastante grande como para que importen las corridas batch, o cuando el testing tiene que correr desde CI en vez de una persona haciendo clic por Setup. (Salesforce también documenta correr tests a través de la Connect API como un camino relacionado.)

Las tres son la misma eval, configurada para tres contextos: la UI cuando un builder es dueño del agente, DX cuando el eval set pertenece a control de versiones, la API cuando tiene que correr en un pipeline. Echá mano de la más angosta que encaje, igual que elegirías un retriever no-code antes que uno custom del lado de grounding.

Las tres cosas que chequea un caso de test

Un caso de test no solo pregunta "¿estuvo buena la respuesta?" — chequea tres cosas específicas, cada una aislando una etapa distinta de lo que hizo el agente. Esto es lo que hace que un test de agente sea diagnóstico en vez de un vibe check: cuando un caso falla, el tipo que falló te dice dónde se rompió.

Tipo de test	Qué chequea	Pasa cuando
Topic	¿El agente ruteó al topic esperado — el área correcta de sus instrucciones para este utterance?	El agente selecciona el topic (subagent) que el caso espera.
Action	¿El agente invocó la(s) action(s) esperada(s) — las tools correctas, en el lugar correcto?	El agente llama a la(s) action(s) que el caso nombra, por su API name.
Outcome	¿El outcome real matchea con el esperado — una descripción en lenguaje natural del resultado?	La respuesta real matchea con el sentido del outcome esperado, evaluado semánticamente — así pasa aun cuando la redacción difiera.

La división importa porque las tres fallan de forma independiente y por razones distintas. Un fallo de Topic significa que el ruteo salió mal — el agente eligió el área equivocada de sus instrucciones antes de hacer nada, la falla que debugging de agentes trazea primero. Un fallo de Action significa que ruteó correcto pero invocó la tool equivocada, o se salteó una que debería haber llamado — la capa de tools y actions. Un fallo de Outcome significa que ruteó y actuó correcto pero la respuesta igual estuvo mal. Calificar el outcome por su sentido en lenguaje natural en vez de por un string exacto es lo que deja que el test sobreviva a una reformulación inofensiva — la misma razón por la que existe LLM-as-judge para la prosa que un chequeo determinista no puede calificar. Cuando sí necesitás un chequeo exacto — un string o número específico que tiene que aparecer textual — el test spec lleva un campo custom evaluation opcional aparte para eso, al lado del outcome semántico.

Esa separación es todo el valor de una eval con forma de agente. "La respuesta estuvo mal" es una queja; "el Topic estuvo bien, la Action estuvo bien, el Outcome falló" es un diagnóstico sobre el que podés actuar.

Después de deployar: Observabilidad de Agentforce

Testing Center prueba que el agente es seguro de shippear. No puede decirte si se mantuvo bueno una vez que le pegó tráfico real — el problema del degrade silencioso que qué es evaluación nombra como el trabajo de la evaluación online. Eso es la Observabilidad de Agentforce: la mitad de después de deployar, mirando lo que el agente realmente hace en producción en vez de lo que hizo contra un set curado.

La base es el trace de sesión — la repetición de una sesión real de producción, exportada a través de la Agentforce Session Trace OTel API en formato OpenTelemetry (OTLP), el estándar abierto que las plataformas de observabilidad y los collectors de OTLP ya hablan. Un trace captura la anatomía completa de una sesión: turns, messages, llamadas al LLM, actions, scores de métricas y feedback — cada paso desde el utterance del usuario, pasando por las llamadas al modelo y las invocaciones de tools, hasta la respuesta, con los scores y el feedback adjuntos. Este es el principio 11 hecho concreto en la plataforma — no podés debuggear, ni evaluar, lo que no podés repetir — y el trace es exactamente esa repetición, en un formato que podés meter en el tooling de observabilidad que ya corrés.

Los traces se almacenan en Data 360, y la API los consulta con Data 360 SQL. Esa ubicación es la ventaja silenciosa de la plataforma: el registro de producción de lo que hizo el agente cae en el mismo store unificado sobre el que el agente groundea a través de sus retrievers, así que el trace de una respuesta queda al lado de los datos con los que se armó esa respuesta. Encima del trace, la Observabilidad surfacea scores de calidad y flags para topics de bajo rendimiento — la señal de eval online que te apunta a qué parte del agente está derivando, no solo a que algo lo está. Las superficies viven en Setup, bajo Einstein — audit, analytics y monitoring — el hogar de la plataforma para lo que el agente está haciendo ahora frente a lo que los casos de test dijeron que debería.

El punto de composición: Testing Center acá, la capa del modelo y LangSmith allá

El testing y la observabilidad de Agentforce son un instrumento, y el encuadre honesto es composición, no elección (principio 7). El camino nativo de la plataforma es el correcto cuando el agente corre en Agentforce dentro del modelo de seguridad — lo testeás donde los builders son dueños, la eval hereda el modelo de seguridad, y el trace de producción cae en Data 360 al lado de los datos sobre los que el agente actúa. La capa del modelo es donde calificás el comportamiento crudo del modelo independiente de dónde esté embebido — el loop de definir-criterios-y-después-calificar con un LLM-as-judge para todo lo que un chequeo determinista no alcanza. LangSmith es la superficie cuando el sistema corre fuera de plataforma sobre un control loop custom — datasets, eval offline y eval online sobre traces en vivo, en un solo lugar fuera de la plataforma.

Un sistema real muchas veces usa más de una. Un agente groundeado sobre Data 360 y orquestado en parte fuera de plataforma podría testearse en Testing Center, calificarse en la capa del modelo con un juez LLM, y trazearse en LangSmith — cada superficie haciendo la parte para la que está construida, igual que un retriever de Agentforce y un pipeline de RAG externo componen detrás de un agente. La habilidad es hacer encajar la superficie de eval con dónde corre el agente, no defender el instrumento.

Y la precondición es la que eval datasets y métricas fija en todos lados: Testing Center corre los casos que sea que le des, así que el test es tan honesto como el eval set que tiene debajo. Un puñado de utterances que inventaste en un escritorio es el vibe check con una UI puesta; los casos que vale la pena correr son los sacados de fallas reales — los topics que se mis-rutearon, las actions que se saltearon, los outcomes de los que un usuario se quejó. La plataforma corre el test y emite el trace; vos seguís siendo dueño de si los casos valen la pena correrlos. (Mirá evaluation gotchas para los modos de falla que una eval nativa igual hereda, tracing y monitoring para el trace que esta página exporta leído en profundidad, debugging de evals para cuando la eval misma te confunde, y el Style Guide de evaluación para la vara que una eval pasa antes de que confíes en ella.)

El hilo

El testing y la observabilidad de Agentforce son la mitad nativa de la plataforma del espinazo de eval. Antes de deployar: Testing Center corre casos contra el agente — por la UI low-code, el camino pro-code de Agentforce DX con un test spec en YAML generado por agent generate test-spec, o la Testing API para corridas batch — y cada caso chequea tres cosas: el topic esperado, las actions esperadas, y el outcome esperado como match en lenguaje natural. Después de deployar: la Observabilidad exporta el trace de sesión en formato OpenTelemetry (OTLP) — turns, messages, llamadas al LLM, actions, scores de métricas, feedback — lo almacena en Data 360, y flaggea topics de bajo rendimiento. Vos sos dueño de los casos y de la lectura de los traces; la plataforma corre los casos, los califica, y emite el trace dentro del modelo de seguridad en el que el agente ya corre. Esa división es el atractivo y el límite: cuando el agente vive en Agentforce, es el camino más directo a una eval gobernada al lado de los datos; cuando el sistema corre fuera de plataforma, esa es la señal para calificar en la capa del modelo y trazear en LangSmith. La habilidad es saber dónde corre el agente, no defender la superficie.

What is evaluation — el loop de eval que esta página arma en términos de Agentforce, y la división offline/online que aterriza en la plataforma
Eval datasets and metrics — el eval set que corre Testing Center, y por qué es tan honesto como los casos que tiene debajo
LLM-as-judge — la calificación semántica que usa el chequeo de Outcome, y la superficie de capa-de-modelo con la que esta página compone
Tracing and monitoring — el trace de sesión que esta página exporta, leído en profundidad como base de la evaluación online
Debugging evals — cuando la eval misma te confunde: un juez que califica mal, un set que derivó
Evaluation gotchas — los modos de falla que una eval nativa igual hereda
Evaluation Style Guide — la vara que una eval pasa antes de que confíes en sus scores
Agentforce retrievers — el grounding del que toma el agente bajo test, y dónde caen sus traces de producción en Data 360
Debugging agents — trazar una corrida cuando sale mal, la misma repetición de la que depende la observabilidad
Tools and actions — las actions que el tipo de test Action chequea que el agente invocó
AI Engineering principles — si no podés evaluarlo no podés shippearlo (3), trazeá todo (11), componé el toolkit (7)

Reference:

Antes de deployar: Testing Center

Las tres cosas que chequea un caso de test

Después de deployar: Observabilidad de Agentforce

El punto de composición: Testing Center acá, la capa del modelo y LangSmith allá

El hilo

Related