أنا هنا مرة أخرى إلى ELI5 @akileshpotti إليك التفصيل: (أ) تعد سجلات الوكلاء مثل ERC-8004 حلا متوسطا في أحسن الأحوال: تعد السجلات على السلسلة طريقة غير فعالة للتعامل مع شيء معقد مثل اكتشاف الوكيل وتفاعله. إنه لا يعمل بشكل جيد في الممارسة. (ب) وكلاء على السلسلة بالفعل: إذا كنت تريد بالفعل "وكلاء الذكاء الاصطناعي غير الموثوق بهم" على blockchain ، فإن الخطوة المنطقية هي جعل نماذج الذكاء الاصطناعي ووكلاء جزءا أساسيا من السلسلة نفسها - مدمجة في طبقات التنفيذ والإجماع. هذه هي الطريقة التي يمكن بها لأي شخص في السلسلة الوصول إليها محليا وآمنا. @ritualnet بالفعل بناء هذا. لا يحصل عليك السجل على هذا (وانظر (ج)) (ج) لا تعمل الجسور عالية الكعب على السلسلة / خارج السلسلة: ERC-8004 عبارة عن تصحيح غير مفاجئ لتوصيل الأنظمة داخل السلسلة وخارجها. نحن نعلم أنه دون المستوى الأمثل لتجربة المستخدم والمنتج لأننا في @ritualnet قمنا ببناء هذا النموذج بالضبط منذ ما يقرب من عامين باستخدام أوراكل Infernet الخاص بنا. إنه حل نصف فقط (ولهذا السبب قررنا تكريس بنيتنا التحتية) (د) انظر إلى من يكسب المال بالفعل: لا تستخدم شركات وكلاء Web2 الناجحة مثل @DecagonAI و @cursor_ai بعض أسواق الاكتشاف الفوضوية والمفتوحة. إنهم يكسبون المال إما عن طريق (1) تشغيل وكيل قوي بشكل متكرر أو (2) باستخدام مجموعة صغيرة وثابتة من الوكلاء بطريقة منظمة للغاية. حلم "سيكتشف الوكلاء بعضهم البعض بشكل عشوائي" ليس كيف يتم بناء المنتجات المربحة في الممارسة العملية (إذا كان هذا هو هدفك) (ه) المشاكل الصعبة التي لا يحلها أي شخص آخر: من السهل الاتصال بوكيل من blockchain. التحدي الحقيقي هو بناء البنية التحتية للقيام بذلك بشكل صحيح. هذا يعني: - قابلية التوسع: تجنب الحساب الزائد دون المساس بالأمان. - التسعير: بناء أسواق رسوم جديدة تتكيف مع هذه النماذج / الوكلاء المحددين - الأداة المساعدة: بما في ذلك الميزات الأساسية مثل المعاملات المتكررة (فكر في وظائف Cron على السلسلة) التي تجعل الوكلاء مفيدين حقا لم يفكر أي L1 آخر في هذا من خلال أو بنى البنية التحتية لحل كل هذه المشاكل. فقط @ritualnet. (tbh ، أكثر قابلية للهضم هذه المرة في منشور OG الخاص به ، لذا أوصي الناس بقراءته)
Akilesh Potti
Akilesh Potti‏27 أغسطس، 07:19
i am once again here to say agent discovery & registry hell is one of the least impactful things to focus on that for whatever reason keeps nerd sniping cracked ppl...most "mid" solutions for it are good enough and "better" solutions barely move the needle either you: 1) actually take your 'thought experiment' to its sci-fi logical conclusion wrt "autonomous" + "trustless" agents and make them a first class citizen by enshrining the {fdn model, tool use, etc.} components of an agent directly into the chain* (we do this) rather than frankensteining together some off-chain & on-chain stuff as mentioned in 8004 (we did this: infernet) 2) stay grounded in reality & grok how the largest b2b / b2b2c web2 agent startups (sierra, decagon, ...) that are printing real $$$ work. either they're in the camp of single general purpose agent deployed many times or a statically defined computational graph of how specialized agents communicate. this intellectual masturbatory notion of dynamic graphs of agents discovering each other much less useful than you may think if you're in the camp of web2 cos getting real users. if you're not in this camp, and believe in futuristic settings, then you should do 1). anything in between is worst of both worlds imo. *feel free to @ me but your fave L1 today (eth, solana, monad, ...) doesn't allow for enshrined agents. it's also highly non-trivial for them to do this given it's not in line with their fundamental design. expanding the exec clients' vm to handle fwd passes across oss llms, network calls for tool use, etc. is the easy part. hard part is bypassing replicated exec in consensus for non-deterministic behavior w/out ~degrading safety/liveness, fee mech, and how to allow for scheduled txs to exist in a way without borking the perf / end UX for regular txs. wouldn't be possible for us without the gigabrains @noamnisan @n_durvasula @bahrani_maryam and others coming up with some new machinery. reality is most L1s are an exercise in networking-bound settings...we're in an exec-bound one.
‏‎13.01‏K