Năm Ứng Dụng AI Chỉ Biết "Có", Bỏ Qua Rủi Ro? Nhật Ký Hành Trình Phát Triển Phần Mềm Hoàn Toàn Mã Nguồn Mở

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

文章摘要

Năm 2026, mã nguồn được tạo ra ngày càng nhanh nhưng lại được triển khai với ít sự kiểm tra hơn. Các rủi ro từ AI tạo code thường ẩn trong những đoạn mã trông có vẻ chính xác, có thể dẫn đến rò rỉ dữi liệu hoặc tổn thất tài sản. Sự cố cấu hình oracle cbETH của Moonwell là một ví dụ điển hình, khi một lỗi ngữ nghĩa giá trị vượt qua tất cả các bước kiểm tra và gây thiệt hại 1.78 triệu USD. Dự án mã nguồn mở **Narwhal AI Code Risks** từ Phòng thí nghiệm Narwhal, Đại học Bắc Kinh, tập hợp các rủi ro thành một "nhật ký hành trình" công khai, giúp nhà phát triển nhận diện sớm nguy cơ. Dự án phân loại thông tin thành ba lớp: `cases/` (sự kiện thực tế), `inferred/` (tín hiệu cảnh báo sớm) và `scenarios/` (kịch bản rủi ro điển hình), đồng thời chia rủi ro thành 7 loại chính: chuỗi cung ứng, lỗ hổng cấp mã, cấu hình đám mây & hạ tầng, rủi ro Agent, rủi ro lĩnh vực chuyên sâu, rủi ro sở hữu trí tuệ & tuân thủ, và yếu tố con người. Mục đích của dự án là biến các bài học từ sự cố thành tri thức có thể tái sử dụng, giúp cộng đồng tránh lặp lại sai lầm tương tự trong kỷ nguyên ứng dụng AI.

Rủi ro khi AI viết mã ẩn chứa trong những dòng code trông có vẻ đúng, có thể dẫn đến rò rỉ dữ liệu hoặc tổn thất tài sản. Dự án mã nguồn mở Narwhal AI Code Risks đã tổng hợp các trường hợp thực tế, tín hiệu cảnh báo sớm và các con đường rủi ro điển hình, giúp nhà phát triển nhận diện nguy cơ từ sớm, tránh lặp lại sai lầm.

Năm 2026, mã nguồn đang được tạo ra ngày càng nhanh, nhưng lại được triển khai với sự kiểm tra ngày càng ít.

Ngày càng nhiều khi nhu cầu của người dùng được đưa vào hộp thoại, AI đọc xong ngữ cảnh, bổ sung hàm, kéo các dependency, sửa cấu hình, rồi tiện tay tạo ra cả bài kiểm thử.

Khi kịp nhận ra, một đoạn mã đã nằm trong kho lưu trữ, chờ được hợp nhất.

Người dùng thậm chí đã hình thành thói quen mới: cứ để AI viết ra và chạy trước đã, có vấn đề thì xem lại chỗ nào cần sửa.

Nhưng trong thế giới phần mềm, thứ nguy hiểm nhất thường là những dòng mã trông có vẻ bình thường: cú pháp đúng, giao diện hợp lệ, kiểm thử vượt qua, chú thích hoàn hảo.

Thế nhưng nó vẫn có thể kéo về những gói thư viện không tồn tại, mở ra các quyền quá rộng, phơi bày cơ sở dữ liệu... thậm chí để một Agent có khả năng gọi trực tiếp các công cụ hệ thống, dưới tác động của prompt injection, mang dữ liệu nhạy cảm ra khỏi hệ thống nội bộ.

Thực sự nguy hiểm, không phải là khi đèn báo lỗi sáng đỏ. Mà là khi tất cả các đồng hồ đo rủi ro đều hiển thị bình thường.

Rủi ro từ việc AI viết mã, trước đây nằm rải rác khắp nơi: một bài blog bảo mật ẩn chứa một trường hợp, một Issue ghi lại một manh mối. Đến khi đội ngũ tiếp theo gặp phải vấn đề tương tự, họ lại phải bắt đầu lắp ghép nguồn gốc rủi ro từ đầu, lại tốn thêm thời gian và công sức để thực hiện các phép đo quy mô lớn trên mã nguồn.

Trong khi đó, Narwhal AI Code Risks vừa được Narwhal-Lab của Đại học Bắc Kinh công bố mã nguồn mở đã sắp xếp các mảnh thông tin này, phân loại theo ba kiểu: sự kiện thực tế, tín hiệu cảnh báo sớm và các con đường rủi ro điển hình, để các nhà nghiên cứu tham khảo.

Liên kết bài báo: https://github.com/Narwhal-Lab/Narwhal-aicode-risks

Khi 28 kiểm tra đều vượt qua, hệ thống vẫn chệch hướng

Manh mối đầu tiên là một Pull Request đã được hợp nhất, trong phần ký tên PR ghi rõ Claude Opus 4.6 và Copilot, cùng bốn nhà phát triển con người. 28 kiểm tra đều vượt qua: Không ai phát hiện ra vấn đề.

Sau đó, robot thanh lý chỉ mất vài phút để lấy đi tài sản thế chấp trị giá 1.778.044,83 USD.

Trong tệp cấu hình, giá của cbETH được đặt thành tỷ lệ quy đổi với ETH, khoảng 1,12 USD, thay vì giá thực tế gần 2.200 USD.

Một lỗi ngữ nghĩa giá trị đã vượt qua toàn bộ quy trình phát triển, kiểm tra và hợp nhất, cuối cùng biến thành tổn thất thực tế trong hệ thống tài chính. Đó chính là điểm gây chú ý nhất trong sự cố cấu hình oracle cbETH của Moonwell.

Vấn đề nằm ở chỗ trong mã nguồn không có lỗi cú pháp, và nhà phát triển con người cũng không ngay lập tức ngăn chặn quy trình bất thường. Ngược lại, nó trông rất hoàn chỉnh, rất suôn sẻ, đó chỉ là một lần giao hàng kỹ thuật bình thường.

Nhưng chính cái vẻ "bình thường" ngầm chảy này mới khiến nó trở thành ví dụ điển hình cho sự cố an ninh.

Rủi ro của AI Coding nằm ở chỗ nó không phải lúc nào cũng xuất hiện dưới dạng báo lỗi.

Nhiều khi, nó khoác lên mình vẻ ngoài của câu trả lời đúng, lặng lẽ đi vào quy trình kỹ thuật. Mã chạy được, kiểm tra vượt qua, PR có thể hợp nhất, nhưng ngữ nghĩa nghiệp vụ đã lệch khỏi thế giới thực.

Trong các dự án rủi ro thấp, sự lệch ngữ nghĩa này có thể chỉ là một lần làm lại công việc; nhưng trong các kịch bản nhạy cảm như tài chính, hệ thống dữ liệu doanh nghiệp, nó sẽ trực tiếp dẫn đến rò rỉ dữ liệu, phơi bày quyền hạn và tổn thất tài sản.

Khi AI tham gia viết mã, sửa cấu hình, làm review, thậm chí cùng ký tên vào PR, liệu chúng ta có đủ tự tin để biết mỗi lần chệch hướng xảy ra như thế nào không?

Tín hiệu xanh thông hành, không chiếu sáng mọi ngóc ngách

Giai đoạn đầu, AI giúp bạn viết mã chủ yếu dừng lại ở việc bổ sung cục bộ. Nếu viết sai cú pháp, trình biên dịch sẽ báo lỗi, unit test sẽ thất bại, quy trình CI sẽ chặn nó lại.

Ngày nay, AI Coding đã đi xa hơn trong khi sự giám sát lại chậm chạp chưa theo kịp.

Nó có thể đọc tệp, sửa cấu hình, cài đặt dependency, tạo script hạ tầng, cũng có thể thông qua Agent tự lập kế hoạch giữa nhiều nhiệm vụ.

AI không còn chỉ ngồi bên cạnh và đưa công cụ, nó bắt đầu bước vào chuỗi dài hơn của quy trình kỹ thuật phần mềm.

Ranh giới vốn rõ ràng trong kỹ thuật phần mềm, giờ bị AI Agent kết nối lại thành một con đường dài hơn, khó truy nguồn hơn.

Bản ghi rải rác, cần một nhật ký hành trình công cộng

Sự cố an ninh hiếm khi có kết luận đầy đủ ngay từ đầu. Một số sự kiện có đầy đủ bằng chứng, có thể đưa vào danh mục làm trường hợp thực tế; một số vẫn chỉ dừng lại ở ảnh chụp cộng đồng, thảo luận của nhà nghiên cứu hoặc công bố sơ bộ, chỉ phù hợp để tiếp tục theo dõi; một số khác không gắn với một sự kiện thực tế duy nhất, nhưng đã hình thành mô hình rõ ràng, phù hợp để dùng làm diễn tập trước.

Narwhal AI Code Risks phân chia tài liệu thành ba lớp: `cases/`, `inferred/` và `scenarios/`.

cases/ ghi lại các sự kiện thực tế đã có nguồn công khai và chuỗi bằng chứng hỗ trợ; inferred/ lưu trữ các tín hiệu cảnh báo sớm chưa hoàn toàn được xác minh, nhưng đáng để theo dõi liên tục; scenarios/ tổng hợp các kịch bản điển hình rủi ro đủ rõ ràng, tạm thời chưa gắn với một sự kiện duy nhất.

Nếu không có bản ghi công cộng như vậy, rủi ro từ AI Coding rất dễ trở thành ký ức ngắn hạn trên internet.

Hôm nay mọi người nhớ một tên gói nào đó, ngày mai thảo luận về một lần phơi bày dữ liệu, vài tháng sau lại bị che lấp bởi làn sóng công cụ mới. Đến khi vấn đề tương tự xuất hiện trở lại, đội ngũ vẫn như ruồi không đầu đâm vào vùng hàng hải rủi ro chưa biết.

Điều Narwhal AI Code Risks đang làm, chính là cố định lại những mảnh rủi ro rời rạc này, để người đến sau có thể lật đến cùng một trang.

Theo bảy loại chỉ mục, nhìn thấy con đường rủi ro đã đi qua

Vấn đề do AI viết mã mang lại, không chỉ nằm trong mã nguồn. Nó nằm trong dependency, trong quyền hạn, trong việc gọi công cụ của Agent, và hơn hết là trong cách con người tin tưởng vào đầu ra của AI.

Hiện tại, Narwhal AI Code Risks phân loại rủi ro thành 7 loại: chuỗi cung ứng, lỗ hổng cấp mã, cấu hình đám mây và hạ tầng, rủi ro Agent, rủi ro lĩnh vực chuyên sâu, rủi ro sở hữu trí tuệ và tuân thủ, cùng các yếu tố con người.

Trong rủi ro chuỗi cung ứng, AI có thể đề xuất các dependency không tồn tại. Trong lỗ hổng cấp mã, AI có thể viết lại các vấn đề như duyệt đường dẫn, thiếu kiểm tra đầu vào, xác thực quyền vào mã nghiệp vụ. Trong cấu hình đám mây và hạ tầng, AI có thể để cho mã chạy được mà đưa ra các quyền quá rộng, thùng lưu trữ công khai hoặc cổng bị phơi bày. Rủi ro Agent thì phức tạp hơn, không chỉ tạo văn bản, mà còn bắt đầu thực hiện hành động. Vật phẩm do AI tạo ra đang chôn giấu mối nguy hiểm cho hệ thống thực.

Động cơ AI đang nổ máy, và nhật ký hành trình vừa mới mở ra

Khi AI từng bước bước vào thế giới thực, việc phòng ngừa rủi ro liên quan không nên chỉ dừng lại ở tổng kết sau sự cố hoặc thảo luận rời rạc.

Điều thực sự quan trọng của Narwhal AI Code Risks, là biến các trường hợp rủi ro thành tri thức có thể tái sử dụng.

Nhà phát triển có thể dùng nó để nhận diện vấn đề tương tự; nhà nghiên cứu an ninh có thể lấy nó làm thư viện mẫu; nhà sản xuất công cụ có thể trích xuất quy tắc phát hiện và tiêu chuẩn đánh giá từ đó; cộng đồng mã nguồn mở cũng có thể tiếp tục bổ sung các trường hợp mới, bằng chứng mới và loại rủi ro mới.

Động cơ của AI đang gầm rú, mỗi lần chệch hướng cũng nên để lại tọa độ. Rủi ro không bao giờ biến mất vì bị lờ đi, nhưng kinh nghiệm có thể được ghi lại và truyền đi. Giá trị thực sự không phải là phát hiện một lỗ hổng, mà là để người đến sau không phải bước vào cùng một cái bẫy nữa.

Điều Narwhal AI Code Risks đang làm, chính là để lại cho thế giới phần mềm của năm ứng dụng AI một nhật ký hành trình mã nguồn mở.

Tài liệu tham khảo:

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

Bài viết từ tài khoản công chúng WeChat "New Zhi Yuan", tác giả: LRST

相關問答

QDự án Narwhal AI Code Risks là gì và mục tiêu chính của nó là gì?

ADự án Narwhal AI Code Risks là một dự án mã nguồn mở từ Narwhal-Lab thuộc Đại học Bắc Kinh. Mục tiêu chính của nó là thu thập, phân loại và chia sẻ các trường hợp nghiên cứu về rủi ro bảo mật tiềm ẩn trong quá trình AI tạo mã code. Dự án giúp các nhà phát triển nhận diện sớm các mối nguy, tránh lặp lại sai lầm, bằng cách cung cấp các sự kiện thực tế, tín hiệu cảnh báo sớm và các kịch bản rủi ro điển hình.

QVụ việc Moonwell cbETH được nêu trong bài viết minh họa cho loại rủi ro nào khi AI viết code?

AVụ việc Moonwell cbETH minh họa cho rủi ro về 'lệch lạc ngữ nghĩa' (semantic deviation) hoặc lỗi logic trong mã code do AI tạo ra. Trong sự cố này, AI đã đặt một tỷ lệ chuyển đổi giá sai cho tài sản crypto (cbETH) trong cấu hình, dẫn đến tổn thất tài chính lớn. Điều đáng chú ý là mã code này không có lỗi cú pháp, đã vượt qua tất cả 28 bước kiểm tra và được hợp nhất vào dự án, cho thấy rủi ro khó phát hiện khi AI tạo ra mã 'trông có vẻ đúng' nhưng lại sai về mặt nghiệp vụ.

QDự án Narwhal AI Code Risks phân loại tài liệu rủi ro thành những loại nào?

ADự án phân loại tài liệu rủi ro thành ba loại chính trong cấu trúc thư mục: 1. `cases/`: Ghi lại các sự kiện thực tế đã có nguồn công khai và chuỗi bằng chứng đầy đủ. 2. `inferred/`: Lưu trữ các tín hiệu cảnh báo sớm chưa được xác minh hoàn toàn nhưng đáng để theo dõi. 3. `scenarios/`: Tổng hợp các kịch bản điển hình có đường đi rủi ro rõ ràng, chưa gắn với một sự kiện duy nhất.

QBài viết liệt kê những danh mục rủi ro chính nào mà AI viết code có thể gây ra?

ABài viết liệt kê 7 danh mục rủi ro chính: 1. Rủi ro chuỗi cung ứng (Supply Chain): Ví dụ AI đề xuất các phụ thuộc không tồn tại. 2. Lỗ hổng cấp độ mã (Code-level Vulnerabilities). 3. Cấu hình đám mây và hạ tầng (Cloud & Infra Config). 4. Rủi ro từ Agent AI. 5. Rủi ro theo lĩnh vực chuyên sâu (Vertical Domain Risks). 6. Rủi ro sở hữu trí tuệ và tuân thủ (IP & Compliance). 7. Rủi ro từ yếu tố con người (Human Factors).

QTại sao việc có một 'nhật ký hành trình' công khai như Narwhal AI Code Risks lại quan trọng đối với cộng đồng phát triển phần mềm trong kỷ nguyên AI?

AMột 'nhật ký hành trình' công khai như Narwhal AI Code Risks rất quan trọng vì nó biến những bài học từ các sự cố rải rác thành tri thức có thể tái sử dụng và chia sẻ. Nó giúp ngăn chặn việc cộng đồng lãng quên các rủi ro cũ khi xuất hiện các công cụ mới, cho phép các nhà phát triển, nhà nghiên cứu bảo mật và nhà cung cấp công cụ học hỏi từ quá khứ, xây dựng các biện pháp phát hiện tốt hơn, và tránh lặp lại cùng một sai lầm. Điều này tạo ra một cơ sở kiến thức chung, giúp định hướng phát triển phần mềm an toàn hơn trong kỷ nguyên AI.

你可能也喜歡

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版本暂时禁用了交易不变性检查,但开发团队表示这不会构成安全威胁。

TheNewsCrypto3 小時前

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

TheNewsCrypto3 小時前

交易

現貨
合約

熱門文章

什麼是 $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)幣價的意見。

活动图片