Lo que quería que hiciera mi agente y por qué...
Paso la mayor parte de mi tiempo creando herramientas de trading. La principal es un asistente de Python que monitorea Binance Futures, puntúa cada operación sobre 100 y me dice COMPRAR, VENDER o ESPERAR con el razonamiento completo detrás. Cruce de EMA, posición respecto al VWAP, volumen, confirmación de ruptura, ATR, niveles cercanos, patrones de velas. Cada criterio vale sus puntos o no vale ninguno.
Tiene una limitación deliberada. No se le permite colocar órdenes.
Eso no fue una omisión. Lo escribí así porque no confiaba en mí mismo con un bot que pudiera actuar mientras yo dormía, y tampoco quería entregar una clave API sin procesar con permisos de trading a un código que todavía estaba cambiando cada semana.
Así que mi bot estuvo ahí durante meses, estando en lo correcto, estando equivocado, y sin poder hacer nada al respecto en ninguno de los dos casos.
BinanceAgentOS cambió el cálculo. En lugar de incrustar una clave de API con permisos de trading dentro de mi propio código, el agente pasa por una puerta de enlace oficial donde yo establezco los permisos y puedo revocarlos en cualquier momento. Así que me puse un solo trabajo: conectar mi motor de análisis con Agent OS, dejar que coloque sus propias operaciones en una configuración aislada (sandbox) y descubrir qué se rompe.
Se rompió un montón. Esa es la parte interesante.
Cómo lo hice
Paso 1: Mira antes de tocar cualquier cosa 🧐
Antes de escribir una sola línea, conecté Agent OS a Claude y le hice una pregunta: ¿qué es lo que realmente puedo hacer?
👉 wallet.getApiKeyPermission
La respuesta fue lo primero que valía la pena escribir:
{
"enableReading": true,
"enableSpotAndMarginTrading": true,
"enableFutures": true,
"enableWithdrawals": false,
"enableInternalTransfer": false,
"permitsUniversalTransfer": true,
"ipRestrict": false
}
Los retiros están desactivados. Bien, ese es el límite que todos revisan primero.
Pero permitsUniversalTransfer es verdadero. Mi agente no puede sacar dinero de Binance, pero sí puede mover fondos entre mis propias cuentas. Ese es un modelo de amenaza muy diferente de "solo puede operar con lo que le financio", y por eso importa la subcuenta dedicada más que ser una mejor práctica opcional.
No lo leí en ningún sitio. Lo encontré llamando al endpoint y mirando la respuesta.
Paso 2: Construye una capa que no se preocupe de qué mercado golpea.
Quería tanto Spot como USDT-M Futures, intercambiables mientras se ejecuta. Así que mi motor de puntuación emite una orden independiente de la sede, y un router decide dónde aterriza:
router(.)use(Venue.SPOT)
router(.)place(intent)
router(.)toggle() ahora USDT-M Futures
router(.)place(intent) mismo intent, mercado diferente
Los dos mercados son menos similares de lo que sugieren los documentos. Spot no tiene apalancamiento, no tiene reduce-only, y sus salidas son órdenes STOP_LOSS_LIMIT separadas que venden el activo de vuelta. Futures necesita que el apalancamiento esté configurado antes de la entrada, y las salidas usan STOP_MARKET y closePosition. Un adaptador cada uno, y todo lo de arriba deja de importar.
El router también se niega a cambiar de sede (venue) mientras todavía haya una posición abierta en la sede activa. Alejarte de una posición futures desatendida para ir a operar spot es una forma muy rápida de perder dinero.
Paso 3: Límites de seguridad (guardrails), porque la subcuenta es solo la primera capa.
La respuesta propia de Binance a un agente comprometido es el límite de subcuenta. Eso protege el resto de tu dinero. Pero no protege el dinero dentro de la subcuenta. Entonces añadí una segunda capa antes de que cualquier cosa llegue al exchange: tope nocional, tope de apalancamiento, órdenes por hora, lista blanca de símbolos, stop loss obligatorio en cada orden de apertura y un interruptor de apagado (kill switch) que detiene ambos entornos a la vez.
El dry run es el modo predeterminado. Las lecturas pasan, cada escritura se rechaza y se registra. Hice toda la construcción en ese modo.
Qué pasó realmente
La función estrella de IA no devolvió nada
analysis.getTokenAiReport → {''code'':''000000" ''success'':true,''data'':null}
Lo mismo para $BTC. Lo mismo para $BNB. Éxito, sin datos. Puede ser un despliegue en progreso, puede ser algo regional. De cualquier forma, si construyes un flujo de trabajo que depende del informe de Token AI hoy, revisa el payload en lugar del campo de estado.
Un error de serialización que te cuesta diez minutos
Solicitar varios tickers en una sola llamada falla:
spot.ticker24hr symbols=["BTCUSDT", "BNBUSDT"]
→ -1100 Caracteres ilegales encontrados en el parámetro 'symbols'
El espacio después de la coma es el problema. Un símbolo por llamada funciona bien. Un detalle pequeño, pero es el tipo de cosa que solo aprendes al golpearla (encontrarla en la práctica).
No hay una clave de API para pegar, y aun así construí mi configuración alrededor de una
Esta fue mi suposición incorrecta más grande. Diseñé un campo de configuración llamado auth_token, porque así es como funciona cada integración de exchange que he escrito.
#AgentOS no funciona así. Los datos públicos del mercado no necesitan autenticación en absoluto, así que mi bot podría leer precios, tamaños de tick y libros de órdenes antes de que configurara cualquier cosa. El acceso a la cuenta y el trading pasan por un flujo de autorización desde un cliente compatible, donde asignas una subcuenta y estableces permisos que luego puedes revocar. El punto completo es que nunca almacenas una clave del exchange localmente.
Reescribí el transporte con tres modos: sin auth para datos de mercado, OAuth para la cuenta y un token bearer manual para casos borde. La configuración pasó de "pega tu clave aquí" a "elige qué puede alcanzar este agente".
Esa inversión es la diferencia real de diseño, y solo la entendí equivocándome primero.
El SDK renombró la función bajo mi control.
SDK de MCP 1.x
streamablehttp_client(url, headers=..., auth=...)
SDK de MCP 2.x
streamable_http_client(url, http_client=create_mcp_http_client(auth=...))
Nombre diferente, firma diferente. Si copias un fragmento de un tutorial escrito hace unos meses, falla en una instalación nueva. Mi transporte ahora revisa por ambos.
El descubrimiento de apalancamiento que realmente importaba
Mi panel ahora tiene un control deslizante de apalancamiento de 1 a 150. Probarlo es donde aprendí lo más útil de toda la construcción.
El apalancamiento no cambia tu riesgo mientras tu stop loss se mantenga. Cambia tu margen y tu distancia de liquidación. En margen aislado, aproximadamente:
liquidation_distance ≈ (1 / leverage) - maintenance_margin_rate
A 150x, eso es ~0.67% antes del margen de mantenimiento. Mi stop típico está alrededor de 0.5% desde la entrada. Esos dos números están lo bastante cerca como para que una mecha, financiación o comisiones inviertan la orden entre ellos, y si la liquidación llega primero, el exchange me cierra antes de que se active mi propia protección. Pierdo el margen en lugar de los 10 USDT que planeaba perder.
Así que el ejecutor ahora rechaza la orden de inmediato cuando la liquidación estimada ocurre antes que el stop, y advierte cuando están a menos de 1.5x entre sí. No se envía nada, ni siquiera la configuración de apalancamiento. No planeé construir eso. El control deslizante (slider) forzó la pregunta.
¿Seguiría usándolo?
Lo que puedo decir de la construcción en sí:
Lo que me gusta es que el límite es donde debería estar. Mis guardrails son míos, los permisos de @binance son de Binance, y las dos partes no tienen que confiar entre sí. En comparación con incrustar una clave de API habilitada para trading en mi propio repositorio, esto es una mejora genuina, y lo digo como alguien que no estaba dispuesto a hacer la versión con clave en absoluto.
Lo que cambiaría: el resumen de permisos debería resaltar con más fuerza permitsUniversalTransfer, porque "retiros deshabilitados" suena más seguro de lo que realmente es. Y me gustaría que el endpoint del informe de la IA devolviera una razón explícita en lugar de un payload nulo con un código de éxito.
El resumen honesto: mi bot pasó meses siendo una opinión. Tardó como un día en convertirlo en una acción con Binance Agent OS, y la mayor parte de ese día se invirtió construyendo las razones para que dijera que no.
Quiero reiterar que no soy desarrollador, pero me tomé el tiempo para estudiar el código, y Claude fue mi mejor compañero. Construí todo esto gracias a Claude y Binance.
Todo lo anterior se ejecutó contra mi propia cuenta en modo de simulación (dry-run) antes de una sola orden real. Este bot es simplemente una herramienta de análisis que se puede integrar con tus herramientas existentes; no es una cura mágica ni una máquina para hacer dinero. Solo es para fines informativos; por favor, siempre haz tu propia investigación primero. NFA
