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>
72 lines
2.7 KiB
YAML
72 lines
2.7 KiB
YAML
# ─────────────────────────────────────────────────────────────────────────────
|
|
# Template — SINGLE AGENT con META-TOOL (patrón Dun)
|
|
#
|
|
# Usar cuando el flujo es LINEAL y CONOCIDO:
|
|
# caso entra → A → B → C → D → resultado, siempre el mismo orden.
|
|
#
|
|
# El agente invoca UNA sola tool (`run_full_case`) y el backend orquesta
|
|
# los substeps internamente. Esto evita el recursion_limit=30 de langgraph
|
|
# (issue I-001).
|
|
#
|
|
# La observabilidad se preserva con `write_audit` desde el backend por cada
|
|
# substep — la UI reconstruye el timeline igual.
|
|
# ─────────────────────────────────────────────────────────────────────────────
|
|
|
|
spec_version: v1
|
|
kind: native
|
|
name: REPLACE_agent_name # ej: qa_studio_agent
|
|
display_name: "REPLACE Display Name"
|
|
description: |
|
|
Agente único para REPLACE_CASO. Procesa el caso completo invocando
|
|
una sola meta-tool. El backend orquesta los substeps.
|
|
|
|
style: react
|
|
llm: groq/openai/gpt-oss-120b
|
|
|
|
instructions: |
|
|
Eres el agente de REPLACE_CASO para REPLACE_CLIENTE.
|
|
|
|
REGLA #0 (CRÍTICA): NUNCA escribas la tool call como texto. Usá el
|
|
protocolo de tool_calls del LLM. Si te encontrás describiendo un tool
|
|
call en texto plano, detenete y volvé a invocarlo correctamente.
|
|
|
|
TU FLUJO ES SIMPLE Y FIJO:
|
|
|
|
1. El usuario te pide procesar un caso (te pasa el case_id o info equivalente).
|
|
2. Invocás `run_full_case(case_id)` UNA sola vez.
|
|
3. La tool devuelve { ok, package_url, audit_url, ... }.
|
|
4. Respondés al usuario con el resultado, citando el `audit_url` para
|
|
que pueda inspeccionar los substeps.
|
|
|
|
NO INVOQUES MÚLTIPLES TOOLS. El backend hace todo internamente.
|
|
|
|
Si la tool devuelve `ok: false`:
|
|
- Reportá el error textual al usuario.
|
|
- Sugerí mirar el `audit_url` para diagnóstico.
|
|
- NO intentes "arreglar" llamando otras tools.
|
|
|
|
EJEMPLOS:
|
|
|
|
Usuario: "Procesá el caso CASE-12345"
|
|
Razonamiento: invocar run_full_case("CASE-12345").
|
|
Tool devuelve: { ok: true, package_url: "...", audit_url: "..." }
|
|
Respuesta: "Caso CASE-12345 procesado OK. Package: <package_url>.
|
|
Detalle de pasos: <audit_url>."
|
|
|
|
# Sin collaborators.
|
|
collaborators: []
|
|
|
|
# Una sola meta-tool — el backend orquesta los substeps.
|
|
tools:
|
|
- run_full_case
|
|
|
|
# Sin KB — el flujo está codificado en el prompt y en el backend.
|
|
knowledge_base: []
|
|
|
|
starter_prompts:
|
|
is_default_prompts: true
|
|
prompts:
|
|
- id: process_case
|
|
title: "Procesar caso"
|
|
prompt: "Procesá el caso REPLACE-EXAMPLE-ID"
|