Año Uno de las Aplicaciones de IA: ¿Solo sabe decir "sí", ignorando los riesgos? El cuaderno de bitácora del desarrollo de software se abre por completo

marsbit發佈於 2026-06-16更新於 2026-06-16

文章摘要

El año de la IA aplicada: ¿Solo "sí" y sin considerar riesgos? El diario de navegación del desarrollo de software se abre por completo. El rápido aumento del uso de IA para generar código, con menos supervisión, introduce riesgos ocultos en código aparentemente correcto, lo que puede provocar pérdidas de datos o activos. El proyecto de código abierto **Narwhal AI Code Risks**, de Narwhal-Lab (Universidad de Pekín), recopila casos reales, señales tempranas y rutas de riesgo típicas para ayudar a los desarrolladores a identificar peligros. Un ejemplo claro es el incidente de configuración del oráculo cbETH de Moonwell, donde un error semántico en un precio (1.12 USD en lugar de ~2200 USD) pasó todas las revisiones y causó una pérdida de ~1.78 millones de dólares. El riesgo no siempre se muestra con errores; a menudo, el código funciona pero su semántica es errónea. La IA ya no solo completa código, sino que modifica configuraciones, gestiona dependencias y actúa mediante agentes, creando cadenas de acciones más largas y difíciles de rastrear. Los riesgos se clasifican en 7 categorías: cadena de suministro, vulnerabilidades a nivel de código, configuración de nube/infraestructura, riesgos de agentes, riesgos en dominios verticales, propiedad intelectual/cumplimiento y factores humanos. El proyecto organiza la información en tres niveles: `cases/` (eventos reales verificados), `inferred/` (señales tempranas por confirmar) y `scenarios/` (patrones de riesgo claros). Su objetiv...

Los riesgos de que la IA escriba código se esconden en código aparentemente correcto, pudiendo provocar fugas de datos o pérdida de activos. El proyecto de código abierto Narwhal AI Code Risks ha recopilado casos reales, señales tempranas y rutas de riesgo típicas para ayudar a los desarrolladores a identificar peligros con antelación y evitar cometer los mismos errores.

En 2026, el código se genera a un ritmo cada vez mayor, pero se despliega con cada vez menos revisión.

Cada vez más, los requisitos del usuario se introducen en un cuadro de diálogo, la IA lee el contexto, completa funciones, añade dependencias, ajusta configuraciones y genera pruebas de paso.

Cuando te das cuenta, ya hay un fragmento de código en el repositorio, esperando a ser fusionado.

Los usuarios ya han adquirido el nuevo hábito: primero dejar que la IA lo escriba y lo haga funcionar, y si hay problemas, entonces ver qué hay que cambiar.

Pero en el mundo del software, lo más peligroso suele ser el código que parece anodino: sintácticamente correcto, con interfaces legales, pruebas aprobadas, comentarios perfectos.

Sin embargo, aún puede introducir nombres de paquetes que no existen, abrir permisos excesivos, exponer bases de datos... o incluso permitir que un agente que puede llamar directamente a herramientas del sistema, bajo un ataque de inyección de prompt, saque datos sensibles de un sistema interno.

Lo realmente peligroso no es que se encienda una luz de error, sino que todos los indicadores de riesgo muestren normalidad.

Hasta ahora, los riesgos de que la IA escriba código estaban dispersos por todas partes: un caso escondido en un blog de seguridad, una pista registrada en un Issue. Cuando el siguiente equipo se enfrentaba a un problema similar, tenía que reconstruir desde cero el origen del riesgo y dedicar una enorme cantidad de tiempo y esfuerzo a realizar mediciones empíricas a gran escala del código.

El Narwhal AI Code Risks, recientemente abierto por el Narwhal-Lab de la Universidad de Pekín, ya ha organizado estos fragmentos de información, clasificándolos en tres tipos: eventos reales, señales tempranas y rutas de riesgo típicas, para que los investigadores puedan consultarlos.

Enlace del paper: https://github.com/Narwhal-Lab/Narwhal-aicode-risks

Cuando pasan las 28 comprobaciones, el sistema aún se desvía

La primera pista fue un Pull Request ya fusionado, cuyo campo de autoría mostraba claramente a Claude Opus 4.6 y Copilot, junto con cuatro desarrolladores humanos. Las 28 comprobaciones se aprobaron: nadie detectó el problema.

Luego, un bot de liquidación tardó unos minutos en tomar una garantía valorada en 1,778,044.83 dólares.

El precio de cbETH en el archivo de configuración se estableció en la tasa de conversión con ETH, aproximadamente 1.12 dólares, en lugar de su precio real cercano a los 2,200 dólares.

Así, un error semántico de precio atravesó todo el proceso de desarrollo, revisión y fusión, convirtiéndose finalmente en una pérdida real en el sistema financiero. Este es el aspecto más llamativo del incidente de configuración del oráculo de Moonwell cbETH.

El problema radica en que el código no presentaba errores de sintaxis y los desarrolladores humanos no bloquearon de inmediato el flujo anómalo. Al contrario, parecía completo, fluido, era una entrega de ingeniería normal.

Pero precisamente esta aparente normalidad bajo la superficie lo convierte en un ejemplo típico de incidente de seguridad.

El riesgo de la codificación con IA radica en que no siempre se manifiesta como un error.

Muchas veces, se viste con la apariencia de una respuesta correcta y entra silenciosamente en el flujo de ingeniería. El código funciona, las comprobaciones pasan, el PR se fusiona, pero la semántica del negocio ya se ha desviado del mundo real.

En proyectos de bajo riesgo, esta desviación semántica puede ser solo una reelaboración; pero en escenarios sensibles como finanzas o sistemas de datos empresariales, provocará directamente filtraciones de datos, exposición de permisos y pérdida de activos.

Cuando la IA participa escribiendo código, modificando configuraciones, haciendo revisiones, o incluso firmando conjuntamente en los PR, ¿tenemos la suficiente certeza de saber cómo ocurre cada desviación?

Señales verdes de paso que no iluminan todos los rincones

Al principio, la IA que ayudaba a escribir código se limitaba principalmente a completar fragmentos locales. Si la sintaxis era incorrecta, el compilador mostraba un error, las pruebas unitarias fallaban y el flujo de CI lo rechazaba.

Hoy en día, la codificación con IA va mucho más allá, mientras que la supervisión tarda en llegar.

Puede leer archivos, modificar configuraciones, instalar dependencias, generar scripts de infraestructura, y también, a través de agentes, planificar de forma autónoma entre múltiples tareas.

La IA ya no se limita a estar al lado pasando herramientas; ha comenzado a integrarse en cadenas más largas de la ingeniería de software.

Los límites originalmente claros en la ingeniería de software han sido reconectados por los agentes de IA en rutas más largas y difíciles de rastrear.

Registros dispersos que necesitan un cuaderno de bitácora público

Los incidentes de seguridad rara vez tienen conclusiones completas desde el principio. Algunos tienen pruebas suficientes y pueden entrar en el directorio como casos reales; otros se quedan en capturas de pantalla de la comunidad, discusiones entre investigadores o divulgaciones preliminares, y solo son adecuados para seguir observándolos; otros más no están vinculados a un solo evento real, pero ya han formado un patrón claro, adecuado para realizar simulaciones preventivas.

Narwhal AI Code Risks divide el material en tres capas: `cases/`, `inferred/` y `scenarios/`.

cases/ registra eventos reales con fuentes públicas y una cadena de evidencias que los respalda; inferred/ guarda señales tempranas que aún no están completamente confirmadas, pero que merecen un seguimiento continuo; scenarios/ organiza escenarios típicos que no están vinculados a un solo evento, pero cuya ruta de riesgo es lo suficientemente clara.

Sin un registro público como este, los riesgos de la codificación con IA pueden convertirse fácilmente en recuerdos a corto plazo en internet.

Hoy se recuerda un nombre de paquete, mañana se discute una exposición de datos, y en unos meses queda sepultado por la nueva ola de herramientas. Cuando surge un problema similar de nuevo, el equipo sigue entrando como una mosca ciega en zonas de navegación de riesgo desconocido.

Lo que hace Narwhal AI Code Risks es fijar estos fragmentos dispersos de riesgo, para que quienes vengan después puedan consultar la misma página.

Siguiendo siete tipos de índice, ver el camino del riesgo

Los problemas que trae la escritura de código por IA no están solo en el código. Están en las dependencias, en los permisos, en las llamadas a herramientas de los agentes, y aún más, en la forma en que los humanos confían en la salida de la IA.

Actualmente, Narwhal AI Code Risks divide los riesgos en 7 categorías: cadena de suministro (supply chain), vulnerabilidades a nivel de código, configuración de la nube e infraestructura, riesgos de agentes, riesgos de dominio vertical, riesgos de propiedad intelectual y cumplimiento normativo, y factores humanos.

En los riesgos de cadena de suministro, la IA puede recomendar dependencias que no existen. En las vulnerabilidades a nivel de código, la IA puede volver a introducir en el código de negocio problemas como el recorrido de rutas (path traversal), la falta de validación de entradas o problemas de autorización. En la configuración de la nube y la infraestructura, la IA puede otorgar permisos excesivos, buckets de almacenamiento públicos o puertos expuestos con tal de hacer funcionar el código. Los riesgos de los agentes son aún más complejos, ya que no solo generan texto, sino que comienzan a ejecutar acciones. Los artefactos generados por la IA están sembrando peligros en sistemas reales.

El motor de la IA está encendido, y el cuaderno de bitácora acaba de abrirse

Cuando la IA avanza paso a paso hacia el mundo real, la prevención y gestión de sus riesgos asociados no debería limitarse a análisis posteriores a los hechos o a discusiones dispersas.

Lo realmente importante de Narwhal AI Code Risks es convertir los casos de riesgo en conocimiento reutilizable.

Los desarrolladores pueden usarlo para identificar problemas similares; los investigadores en seguridad pueden tomarlo como una biblioteca de muestras; los fabricantes de herramientas pueden extraer de él reglas de detección y puntos de referencia para evaluaciones; la comunidad de código abierto también puede seguir complementándolo con nuevos casos, nuevas evidencias y nuevos tipos de riesgo.

El motor de la IA está rugiendo, y cada desviación también debería dejar sus coordenadas. El riesgo nunca desaparece por ser ignorado, pero la experiencia puede ser registrada y transmitida. Lo verdaderamente valioso no es descubrir una vulnerabilidad, sino evitar que quienes vengan después tengan que caer en la misma trampa.

Lo que Narwhal AI Code Risks está haciendo es dejar un cuaderno de bitácora de código abierto para el mundo del software en el Año Uno de las Aplicaciones de IA.

Referencias:

https://github.com/Narwhal-Lab/Narwhal-aicode-risks

Este artículo procede del WeChat público "新智元" (New Zhi Yuan), autor: LRST

相關問答

Q¿Cuál es el propósito principal del proyecto Narwhal AI Code Risks recién publicado?

AEl proyecto Narwhal AI Code Risks tiene como propósito recopilar y organizar casos reales, señales tempranas y rutas típicas de riesgo asociadas al código generado por IA. Sirve como un registro público y de código abierto (un "diario de navegación") para ayudar a los desarrolladores a identificar riesgos ocultos de manera temprana, evitar errores repetidos y convertir la experiencia en conocimiento reutilizable para la comunidad.

QSegún el artículo, ¿por qué el código generado por IA puede ser particularmente peligroso incluso cuando parece correcto?

AEl código generado por IA puede ser peligroso porque a menudo parece sintácticamente correcto, pasa las pruebas y las revisiones, pero puede contener errores semánticos sutiles, como configuraciones incorrectas (ej. precio de un activo), permisos excesivos, dependencias inexistentes o vulnerabilidades de seguridad. El riesgo no se manifiesta como un error de compilación, sino como una desviación funcional que puede causar pérdidas financieras, fugas de datos o exposiciones del sistema en escenarios críticos.

Q¿En qué consistió el incidente real de Moonwell cbETH mencionado como ejemplo en el texto?

AEl incidente de Moonwell cbETH fue un caso real en el que un Pull Request (creado con ayuda de IA como Claude y Copilot) que modificaba un archivo de configuración fue aprobado tras pasar 28 verificaciones. El error consistió en que el precio de cbETH se configuró incorrectamente en aproximadamente 1.12 dólares (la relación de conversión con ETH) en lugar de su valor real cercano a los 2,200 dólares. Este error semántico permitió que un bot de liquidación reclamara garantías por un valor de 1,778,044.83 dólares, demostrando cómo un fallo no sintáctico puede causar grandes pérdidas.

Q¿Cómo clasifica el proyecto Narwhal AI Code Risks los diferentes tipos de materiales o evidencias de riesgo?

AEl proyecto clasifica los materiales en tres categorías principales almacenadas en directorios distintos: 1) `cases/`: registra eventos reales con fuentes públicas y cadenas de evidencia sólidas. 2) `inferred/`: conserva señales tempranas que aún no están completamente confirmadas pero merecen seguimiento. 3) `scenarios/`: recopila escenarios típicos con rutas de riesgo claras, que no están vinculados a un único evento pero son representativos.

Q¿Cuáles son las siete categorías principales de riesgo identificadas por el proyecto Narwhal AI Code Risks?

ALas siete categorías principales de riesgo son: 1) Riesgos en la cadena de suministro (Supply Chain), 2) Vulnerabilidades a nivel de código, 3) Configuración de la nube e infraestructura, 4) Riesgos de Agent (agentes de IA que ejecutan acciones), 5) Riesgos en dominios verticales (como finanzas o salud), 6) Riesgos de propiedad intelectual y cumplimiento normativo, y 7) Factores humanos (como la confianza excesiva en la salida de la IA).

你可能也喜歡

XRP Ledger 发布 3.2.0 版本升级并启用 XRPLd 新品牌名

XRP Ledger发布了3.2.0版本,这是对其底层区块链基础设施的一次重要升级。本次更新的核心是将运行网络的软件名称从“rippled”更名为“xrpld”,以更好地反映整个项目生态。 与此前侧重于前端功能的版本不同,3.2.0版本优先进行了后端升级和效率提升,旨在增强网络性能并为未来的扩展做准备。关键改进包括内存优化措施,预计可节省高达40%的服务器内存使用。 此次升级引入了名为“fixCleanup3_2_0”的修改,为单资产金库、借贷协议、权限系统、去中心化交易所、多用途代币和权限域等多个模块带来了安全性增强。开发团队还新增了不变性检查,以确保已删除账户不会在账本上留下不一致的数据,从而加强整个网络的完整性和可靠性。 对于开发者而言,新版本增加了一项重要功能:应用程序无需连接服务器即可检索XRP Ledger协议和服务器定义信息,这将极大便利钱包、区块链浏览器和API等的开发工作。 在可扩展性和稳定性方面,更新包括可配置的区块大小、通过nuDB实现的高效数据库存储,以及将gRPC服务器的TLS/双向TLS支持改为可选,以提升企业用户的性能和连接性。此外,默认对等端口从51235更改为2459,并修复了涉及自动做市商、支付、代币托管、多用途代币、订单簿和RPC等多个方面的问题。出于性能考虑,3.2.0版本暂时禁用了交易不变性检查,但开发团队表示这不会构成安全威胁。

TheNewsCrypto7 小時前

XRP Ledger 发布 3.2.0 版本升级并启用 XRPLd 新品牌名

TheNewsCrypto7 小時前

交易

現貨
合約

熱門文章

什麼是 $S$

理解 SPERO:全面概述 SPERO 簡介 隨著創新領域的不斷演變,web3 技術和加密貨幣項目的出現在塑造數字未來中扮演著關鍵角色。在這個動態領域中,SPERO(標記為 SPERO,$$s$)是一個引起關注的項目。本文旨在收集並呈現有關 SPERO 的詳細信息,以幫助愛好者和投資者理解其基礎、目標和在 web3 和加密領域內的創新。 SPERO,$$s$ 是什麼? SPERO,$$s$ 是加密空間中的一個獨特項目,旨在利用去中心化和區塊鏈技術的原則,創建一個促進參與、實用性和金融包容性的生態系統。該項目旨在以新的方式促進點對點互動,為用戶提供創新的金融解決方案和服務。 SPERO,$$s$ 的核心目標是通過提供增強用戶體驗的工具和平台來賦能個人。這包括使交易方式更加靈活、促進社區驅動的倡議,以及通過去中心化應用程序(dApps)創造金融機會的途徑。SPERO,$$s$ 的基本願景圍繞包容性展開,旨在彌合傳統金融中的差距,同時利用區塊鏈技術的優勢。 誰是 SPERO,$$s$ 的創建者? SPERO,$$s$ 的創建者身份仍然有些模糊,因為公開可用的資源對其創始人提供的詳細背景信息有限。這種缺乏透明度可能源於該項目對去中心化的承諾——這是一種許多 web3 項目所共享的精神,優先考慮集體貢獻而非個人認可。 通過將討論重心放在社區及其共同目標上,SPERO,$$s$ 體現了賦能的本質,而不特別突出某些個體。因此,理解 SPERO 的精神和使命比識別單一創建者更為重要。 誰是 SPERO,$$s$ 的投資者? SPERO,$$s$ 得到了來自風險投資家到天使投資者的多樣化投資者的支持,他們致力於促進加密領域的創新。這些投資者的關注點通常與 SPERO 的使命一致——優先考慮那些承諾社會技術進步、金融包容性和去中心化治理的項目。 這些投資者通常對不僅提供創新產品,還對區塊鏈社區及其生態系統做出積極貢獻的項目感興趣。這些投資者的支持強化了 SPERO,$$s$ 作為快速發展的加密項目領域中的一個重要競爭者。 SPERO,$$s$ 如何運作? SPERO,$$s$ 採用多面向的框架,使其與傳統的加密貨幣項目區別開來。以下是一些突顯其獨特性和創新的關鍵特徵: 去中心化治理:SPERO,$$s$ 整合了去中心化治理模型,賦予用戶積極參與決策過程的權力,關於項目的未來。這種方法促進了社區成員之間的擁有感和責任感。 代幣實用性:SPERO,$$s$ 使用其自己的加密貨幣代幣,旨在在生態系統內部提供多種功能。這些代幣使交易、獎勵和平台上提供的服務得以促進,增強了整體參與度和實用性。 分層架構:SPERO,$$s$ 的技術架構支持模塊化和可擴展性,允許在項目發展過程中無縫整合額外的功能和應用。這種適應性對於在不斷變化的加密環境中保持相關性至關重要。 社區參與:該項目強調社區驅動的倡議,採用激勵合作和反饋的機制。通過培養強大的社區,SPERO,$$s$ 能夠更好地滿足用戶需求並適應市場趨勢。 專注於包容性:通過提供低交易費用和用戶友好的界面,SPERO,$$s$ 旨在吸引多樣化的用戶群體,包括那些以前可能未曾參與加密領域的個體。這種對包容性的承諾與其通過可及性賦能的總體使命相一致。 SPERO,$$s$ 的時間線 理解一個項目的歷史提供了對其發展軌跡和里程碑的關鍵見解。以下是建議的時間線,映射 SPERO,$$s$ 演變中的重要事件: 概念化和構思階段:形成 SPERO,$$s$ 基礎的初步想法被提出,與區塊鏈行業內的去中心化和社區聚焦原則密切相關。 項目白皮書的發布:在概念階段之後,發布了一份全面的白皮書,詳細說明了 SPERO,$$s$ 的願景、目標和技術基礎設施,以吸引社區的興趣和反饋。 社區建設和早期參與:積極進行外展工作,建立早期採用者和潛在投資者的社區,促進圍繞項目目標的討論並獲得支持。 代幣生成事件:SPERO,$$s$ 進行了一次代幣生成事件(TGE),向早期支持者分發其原生代幣,並在生態系統內建立初步流動性。 首次 dApp 上線:與 SPERO,$$s$ 相關的第一個去中心化應用程序(dApp)上線,允許用戶參與平台的核心功能。 持續發展和夥伴關係:對項目產品的持續更新和增強,包括與區塊鏈領域其他參與者的戰略夥伴關係,使 SPERO,$$s$ 成為加密市場中一個具有競爭力和不斷演變的參與者。 結論 SPERO,$$s$ 是 web3 和加密貨幣潛力的見證,能夠徹底改變金融系統並賦能個人。憑藉對去中心化治理、社區參與和創新設計功能的承諾,它為更具包容性的金融環境鋪平了道路。 與任何在快速發展的加密領域中的投資一樣,潛在的投資者和用戶都被鼓勵進行徹底研究,並對 SPERO,$$s$ 的持續發展進行深思熟慮的參與。該項目展示了加密行業的創新精神,邀請人們進一步探索其無數可能性。儘管 SPERO,$$s$ 的旅程仍在展開,但其基礎原則確實可能影響我們在互聯網數字生態系統中如何與技術、金融和彼此互動的未來。

89 人學過發佈於 2024.12.17更新於 2024.12.17

什麼是 $S$

什麼是 AGENT S

Agent S:Web3中自主互動的未來 介紹 在不斷演變的Web3和加密貨幣領域,創新不斷重新定義個人如何與數字平台互動。Agent S是一個開創性的項目,承諾通過其開放的代理框架徹底改變人機互動。Agent S旨在簡化複雜任務,為人工智能(AI)提供變革性的應用,鋪平自主互動的道路。本詳細探索將深入研究該項目的複雜性、其獨特特徵以及對加密貨幣領域的影響。 什麼是Agent S? Agent S是一個突破性的開放代理框架,專門設計用來解決計算機任務自動化中的三個基本挑戰: 獲取特定領域知識:該框架智能地從各種外部知識來源和內部經驗中學習。這種雙重方法使其能夠建立豐富的特定領域知識庫,提升其在任務執行中的表現。 長期任務規劃:Agent S採用經驗增強的分層規劃,這是一種戰略方法,可以有效地分解和執行複雜任務。此特徵顯著提升了其高效和有效地管理多個子任務的能力。 處理動態、不均勻的界面:該項目引入了代理-計算機界面(ACI),這是一種創新的解決方案,增強了代理和用戶之間的互動。利用多模態大型語言模型(MLLMs),Agent S能夠無縫導航和操作各種圖形用戶界面。 通過這些開創性特徵,Agent S提供了一個強大的框架,解決了自動化人機互動中涉及的複雜性,為AI及其他領域的無數應用奠定了基礎。 誰是Agent S的創建者? 儘管Agent S的概念根本上是創新的,但有關其創建者的具體信息仍然難以捉摸。創建者目前尚不清楚,這突顯了該項目的初期階段或戰略選擇將創始成員保密。無論是否匿名,重點仍然在於框架的能力和潛力。 誰是Agent S的投資者? 由於Agent S在加密生態系統中相對較新,關於其投資者和財務支持者的詳細信息並未明確記錄。缺乏對支持該項目的投資基礎或組織的公開見解,引發了對其資金結構和發展路線圖的質疑。了解其支持背景對於評估該項目的可持續性和潛在市場影響至關重要。 Agent S如何運作? Agent S的核心是尖端技術,使其能夠在多種環境中有效運作。其運營模型圍繞幾個關鍵特徵構建: 類人計算機互動:該框架提供先進的AI規劃,力求使與計算機的互動更加直觀。通過模仿人類在任務執行中的行為,承諾提升用戶體驗。 敘事記憶:用於利用高級經驗,Agent S利用敘事記憶來跟蹤任務歷史,從而增強其決策過程。 情節記憶:此特徵為用戶提供逐步指導,使框架能夠在任務展開時提供上下文支持。 支持OpenACI:Agent S能夠在本地運行,使用戶能夠控制其互動和工作流程,與Web3的去中心化理念相一致。 與外部API的輕鬆集成:其多功能性和與各種AI平台的兼容性確保了Agent S能夠無縫融入現有技術生態系統,成為開發者和組織的理想選擇。 這些功能共同促成了Agent S在加密領域的獨特地位,因為它以最小的人類干預自動化複雜的多步任務。隨著項目的發展,其在Web3中的潛在應用可能重新定義數字互動的展開方式。 Agent S的時間線 Agent S的發展和里程碑可以用一個時間線來概括,突顯其重要事件: 2024年9月27日:Agent S的概念在一篇名為《一個像人類一樣使用計算機的開放代理框架》的綜合研究論文中推出,展示了該項目的基礎工作。 2024年10月10日:該研究論文在arXiv上公開,提供了對框架及其基於OSWorld基準的性能評估的深入探索。 2024年10月12日:發布了一個視頻演示,提供了對Agent S能力和特徵的視覺洞察,進一步吸引潛在用戶和投資者。 這些時間線上的標記不僅展示了Agent S的進展,還表明了其對透明度和社區參與的承諾。 有關Agent S的要點 隨著Agent S框架的持續演變,幾個關鍵特徵脫穎而出,強調其創新性和潛力: 創新框架:旨在提供類似人類互動的直觀計算機使用,Agent S為任務自動化帶來了新穎的方法。 自主互動:通過GUI自主與計算機互動的能力標誌著向更智能和高效的計算解決方案邁進了一步。 複雜任務自動化:憑藉其強大的方法論,能夠自動化複雜的多步任務,使過程更快且更少出錯。 持續改進:學習機制使Agent S能夠從過去的經驗中改進,不斷提升其性能和效率。 多功能性:其在OSWorld和WindowsAgentArena等不同操作環境中的適應性確保了它能夠服務於廣泛的應用。 隨著Agent S在Web3和加密領域中的定位,其增強互動能力和自動化過程的潛力標誌著AI技術的一次重大進步。通過其創新框架,Agent S展現了數字互動的未來,為各行各業的用戶承諾提供更無縫和高效的體驗。 結論 Agent S代表了AI與Web3結合的一次大膽飛躍,具有重新定義我們與技術互動方式的能力。儘管仍處於早期階段,但其應用的可能性廣泛且引人入勝。通過其全面的框架解決關鍵挑戰,Agent S旨在將自主互動帶到數字體驗的最前沿。隨著我們深入加密貨幣和去中心化的領域,像Agent S這樣的項目無疑將在塑造技術和人機協作的未來中發揮關鍵作用。

860 人學過發佈於 2025.01.14更新於 2025.01.14

什麼是 AGENT S

如何購買S

歡迎來到HTX.com!在這裡,購買Sonic (S)變得簡單而便捷。跟隨我們的逐步指南,放心開始您的加密貨幣之旅。第一步:創建您的HTX帳戶使用您的 Email、手機號碼在HTX註冊一個免費帳戶。體驗無憂的註冊過程並解鎖所有平台功能。立即註冊第二步:前往買幣頁面,選擇您的支付方式信用卡/金融卡購買:使用您的Visa或Mastercard即時購買Sonic (S)。餘額購買:使用您HTX帳戶餘額中的資金進行無縫交易。第三方購買:探索諸如Google Pay或Apple Pay等流行支付方式以增加便利性。C2C購買:在HTX平台上直接與其他用戶交易。HTX 場外交易 (OTC) 購買:為大量交易者提供個性化服務和競爭性匯率。第三步:存儲您的Sonic (S)購買Sonic (S)後,將其存儲在您的HTX帳戶中。您也可以透過區塊鏈轉帳將其發送到其他地址或者用於交易其他加密貨幣。第四步:交易Sonic (S)在HTX的現貨市場輕鬆交易Sonic (S)。前往您的帳戶,選擇交易對,執行交易,並即時監控。HTX為初學者和經驗豐富的交易者提供了友好的用戶體驗。

1.8k 人學過發佈於 2025.01.15更新於 2026.06.02

如何購買S

相關討論

歡迎來到 HTX 社群。在這裡,您可以了解最新的平台發展動態並獲得專業的市場意見。 以下是用戶對 S (S)幣價的意見。

活动图片