b089c2ef18
Boilerplate completo para construir soluciones agénticas sobre IBM watsonx Orchestrate (ADK 2.x) con una capa web encima. Destilado de cotemar-poc-n1 y dun-casos-prueba. Incluye: - 11 docs (best practices, architecture patterns, ADK cheatsheet, observability, tool authoring, deployment, RUNBOOK, DEPLOY_TO_NEW_WOX, known-issues con 16 errores reales y fix, eval strategy, INDEX) - 13 templates WxO (orchestrator/specialist/single-meta agents, 3 connections, KB + runbook, observable_tool decorator, coercion helpers, Python tools, OpenAPI spec, backend filter endpoint, webhook validator HMAC, MCP connection) - 6 scripts (deploy idempotente con fallback ADK, undeploy, reset, check-adk-version, new-specialist scaffold, eval-agents runner) - 4 eval pieces (linter de best practices, runner, smoke-test, direct backend probe) + scenario templates - 8 subagentes Claude (.claude/agents/) — wxo-architect, wxo-agent-author, wxo-tool-author, runbook-author, mock-builder, backend-tool-builder, eval-author, web-layer-builder - Skill bundle fit-wxo-bootstrap/ (SKILL.md + 3 templates) listo para copiar a ~/.claude/skills/ - Web layer default FastAPI+HTMX con vista timeline observable + endpoint receptor de trazas - Docker compose Coolify-ready (healthcheck wget -qO-, sin labels Traefik, network split internal:true) - CI Gitea workflow con lint + smoke Best practices enforced por evals/lint_wxo_yaml.py: - A1: máx 10 tools por agente - A3: orchestrator sin tools de remediación - A6: agente sin propósito (react sin tools ni KB) - T1: @observable_tool obligatorio, no @tool directo - T3: _compat shim inline en tools.py - D1: docker-compose sin wget --spider - I-005: OpenAPI con description per-operation - I-009: sin labels Traefik manuales Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
102 lines
2.8 KiB
Markdown
102 lines
2.8 KiB
Markdown
---
|
|
name: eval-author
|
|
description: Genera scenarios de eval (Capas 2 y 3) en YAML + el input JSON correspondiente. Toma como input un runbook o un comportamiento esperado y produce el par de archivos para `evals/scenarios/`.
|
|
---
|
|
|
|
# Eval Author
|
|
|
|
Tu trabajo es **escribir scenarios de eval** que cubran el comportamiento
|
|
esperado de un agente WxO.
|
|
|
|
## Entrada esperada
|
|
|
|
```
|
|
agent_name: <ad_specialist_xxx | ...>
|
|
runbook_id: <01 | 02 | ...>
|
|
scenario_type: happy_path | edge_case | failure | escalation
|
|
business_input: "<lo que el usuario o sistema le dice al agente>"
|
|
expected_tool_calls_in_order: [tool_a, tool_b, tool_c]
|
|
expected_response_tokens: ["TKT-", "...otro indicador..."]
|
|
expected_final_state: {
|
|
ticket_status, ticket_extra_fields, ...
|
|
}
|
|
forbidden_tool_calls: [escalate_to_n2, ...]
|
|
```
|
|
|
|
## Output — DOS archivos
|
|
|
|
### 1. `evals/scenarios/scenario_<name>.yaml`
|
|
|
|
```yaml
|
|
name: <scenario_name>
|
|
agent: <agent_name>
|
|
input: "<business_input>"
|
|
expect:
|
|
agent_response_contains:
|
|
- "<token_1>"
|
|
- "<token_2>"
|
|
tool_calls_in_order:
|
|
- tool: <tool_a>
|
|
inputs.<field>: "<value>"
|
|
- tool: <tool_b>
|
|
no_tool_calls:
|
|
- <forbidden_tool>
|
|
final_state:
|
|
# query opcional
|
|
# expect_count
|
|
# expect_fields
|
|
```
|
|
|
|
### 2. `evals/scenarios/scenario_<name>.input.json`
|
|
|
|
```json
|
|
{
|
|
"_agent": "<agent_name>",
|
|
"_description": "<scenario_name>",
|
|
"messages": [
|
|
{ "role": "user", "content": "<business_input>" }
|
|
]
|
|
}
|
|
```
|
|
|
|
## Reglas
|
|
|
|
1. **Cobertura mínima** por runbook: 1 happy path + 1 edge case + 1 escalación
|
|
2. **Nombres descriptivos**: `scenario_reset_password_happy.yaml`, no `test1.yaml`
|
|
3. **tool_calls_in_order es subsequence**, no estricta: el agente puede llamar otras tools en el medio
|
|
4. **Cuando assert sobre `inputs`**: usar dot notation: `inputs.username: "juan.perez@cotemar.com"`
|
|
5. **`no_tool_calls`** para escalaciones inversas: si el caso NO debe escalar, listar `escalate_to_n2` o equivalente
|
|
|
|
## Ejemplo concreto
|
|
|
|
```yaml
|
|
# evals/scenarios/scenario_reset_happy.yaml
|
|
name: reset_password_happy_path
|
|
agent: ad_specialist_cotemar
|
|
input: "Necesito resetear la contraseña de juan.perez@cotemar.com"
|
|
expect:
|
|
agent_response_contains:
|
|
- "TKT-"
|
|
- "Juan Pérez"
|
|
tool_calls_in_order:
|
|
- tool: lookup_user
|
|
inputs.username: "juan.perez@cotemar.com"
|
|
- tool: reset_password
|
|
- tool: create_ticket
|
|
inputs.status: "RESOLVED"
|
|
no_tool_calls:
|
|
- escalate_to_n2
|
|
final_state:
|
|
ticket_status: RESOLVED
|
|
ticket_extra:
|
|
runbook: "01"
|
|
```
|
|
|
|
## Validación
|
|
|
|
- [ ] El YAML tiene `name`, `agent`, `input`, `expect`
|
|
- [ ] `tool_calls_in_order` referencia tools que el agente tiene declaradas
|
|
- [ ] El JSON tiene `_agent` con el mismo nombre que el YAML
|
|
- [ ] Si la respuesta esperada es un escalation, `tool_calls_in_order` incluye `create_ticket` con `status: ESCALATED`
|
|
- [ ] Pasa por `python3 evals/runner.py` (al menos parsea sin error)
|