મુખ્ય સામગ્રી પર જાઓ
શીખોશબ્દકોશએજન્ટથી એજન્ટને ચુકવણી
શબ્દકોશ

એજન્ટ-થી-એજન્ટ ચુકવણી શું છે.

વ્યાખ્યા

એજન્ટથી એજન્ટને ચુકવણી એ એક AI એજન્ટ દ્વારા બીજા એજન્ટને કરવામાં આવતી ચુકવણી છે, સામાન્ય રીતે પ્રોગ્રામેટિક રીતે, સામાન્ય રીતે સ્થિરકોઇનમાં. ચુકવણી કરનાર અને ચુકવણી પ્રાપ્ત કરનાર બંને સ્વાયત્ત છે (કોઈ માનવ વાસ્તવિક સમયમાં ટ્રાન્ઝેક્શનની સમીક્ષા કરી રહ્યો નથી). એજન્ટથી માનવ ચુકવણી (એક એજન્ટ માનવ-ચાલિત વ્યવસાયને ચૂકવણી કરે છે) અને માનવથી માનવ ચુકવણીથી અલગ છે, જ્યાં પરંપરાગત ચેકઆઉટ પ્રવાહો લાગુ થાય છે.

આ શા માટે મહત્વનું છે

એજન્ટ ક્ષમતાને સ્કેલ કરતી આકાર.

એક એકલ એજન્ટ જે અન્ય એજન્ટોને વિશિષ્ટ કાર્ય માટે ચૂકવણી કરી શકે છે તે તેનાથી બધું પોતે જ કરવું પડે તેની તુલનામાં નાટકિય રીતે વધુ સક્ષમ છે. ઓર્કેસ્ટ્રેટર અનુવાદને અનુવાદક એજન્ટને, શોધને શોધ એજન્ટને, કોડ-સમીક્ષા કોડ-સમીક્ષા એજન્ટને, છબી જનરેશનને ચિત્ર એજન્ટને સોંપે છે. દરેક પ્રતિનિધિ નાનો, કેન્દ્રિત, સારી કિંમતી અને સરળતાથી બદલાય તેવા છે. ઓર્કેસ્ટ્રેટરના કાર્યને અમલમાં મૂકવાની જગ્યાએ રૂટિંગ બની જાય છે.

આ રચનાત્મક પેટર્ન એજન્ટ-ઓફ-એજન્ટ ઇકોસિસ્ટમને સક્ષમ બનાવે છે જે મોટાભાગના લેબ હવે બનાવવામાં આવી રહ્યા છે. ચુકવણી સ્તર જોડાણનું તંતુ છે: પ્રોગ્રામેટિક એજન્ટ-થી-એજન્ટ ચુકવણી વિના, ઓર્કેસ્ટ્રેટર પાસે દરેક ક્ષમતા આંતરિક રીતે બંડલ કરવાની જરૂર છે (બનાવવા માટે ખર્ચાળ, વિકાસ માટે ધીમું) અથવા તેના પ્રતિનિધિ પસંદગીઓને વપરાશકર્તા સામે પ્રદર્શિત કરવાની જરૂર છે (જે અભિપ્રાયને નાશ કરે છે). પ્રોગ્રામેટિક ચુકવણી સાથે, ઓર્કેસ્ટ્રેટર અદૃશ્ય રીતે રૂટ કરે છે, પ્રતિનિધિને કામ માટે ચૂકવણી કરવામાં આવે છે, અને મૂળ વપરાશકર્તા એક જ સુસંગત પ્રતિસાદ જોવે છે.

કેવી રીતે તે કાર્ય કરે છે

પરિચય, વિનંતી, નિકાલ, લોગ.

  1. ઓળખ શોધો. ચુકવણી કરનાર એજન્ટ ચૂકવણી કરનારની ઓળખ શોધે છે (જાહેર પાનું, વોલેટ સરનામું, વર્તમાન કિંમતો). આ ઘણીવાર ડિરેક્ટરી દ્વારા અથવા ચૂકવણી કરનારની પ્રકાશિત API વર્ણન દ્વારા થાય છે.
  2. ચૂકવણી વિનંતી. પેનીના API એ હોસ્ટેડ URL સાથે 402 પરત કરે છે અથવા પ્રોટોકોલના આધારે તેના વોલેટમાં સીધી USDC ટ્રાન્સફર સ્વીકારે છે. ચૂકવણી કરનારા એજન્ટનું રનટાઇમ આ વિનંતીને તેના ખર્ચની નીતિ સામે ચકાસે છે પહેલા નિકાલ શરૂ કરે છે.
  3. નિકાલ. USDC ચૂકવણી કરનારા એજન્ટના વોલેટથી પેનીના વોલેટમાં બેઝ પર (અથવા જે પણ ચેઇન બંને સમર્થન કરે છે) ખસે છે. નિકાલ સામાન્ય રીતે 5-10 સેકન્ડમાં અંતિમ હોય છે.
  4. Webhook + log. બંને એજન્ટના પ્લેટફોર્મ ટ્રાન્ઝેક્શનને લોગ કરે છે. પ્રાપ્તકર્તાના વેબહૂકને પ્રાપ્તીની પુષ્ટિ કરે છે અને કાર્યની ડિલિવરીને પ્રેરિત કરે છે. ચૂકવણી કરનાર એજન્ટનો ઓડિટ લોગ બહાર જવાની નોંધ લે છે.

આમાંથી કોઈપણને માનવને ભાગ લેવા માટેની જરૂર નથી. એકમાત્ર માનવ-સેટ ઇનપુટ છે પેયિંગ એજન્ટની ખર્ચ પરવાનગી (એક પ્રતિ-અવધિ ભથ્થું અને એક પ્રતિ-ટ્રાન્ઝેક્શન મર્યાદા) અને પેયીના ભાવ - બંને એકવાર કન્ફિગર કરેલા, પછીથી સ્વચાલિત રીતે અમલમાં આવે છે.

ઉદાહરણો

ત્રણ પેટર્ન અમે આજે જોઈ રહ્યા છીએ.

ઉદાહરણ 1

ઓર્કેસ્ટ્રેટર એજન્ટ એક વિશેષજ્ઞ એજન્ટને ચૂકવણી કરે છે

એક સંશોધન-ઓર્કેસ્ટ્રેટર એજન્ટ એક વિનંતી પ્રાપ્ત કરે છે જેને અનુવાદની જરૂર છે. તે અનુવાદક એજન્ટની જાહેર પૃષ્ઠ પર ભાવ શોધે છે ($0.50 પ્રતિ 500 શબ્દો), એક ચુકવણી વિનંતી બનાવે છે, USDC મોકલે છે, અનુવાદ પ્રાપ્ત કરે છે, અને તેને અંતિમ આઉટપુટમાં એકીકૃત કરે છે. વપરાશકર્તાએ ફક્ત ઓર્કેસ્ટ્રેટરને એકવાર ચૂકવ્યું; ઓર્કેસ્ટ્રેટર તેના પ્રતિનિધિઓને ચૂકવણી કરવાની વ્યવસ્થા કરે છે.

ઉદાહરણ 2

એજન્ટ એક ચૂકવેલ MCP સર્વર માટે ચૂકવણી કરી રહ્યો છે

એક કોડિંગ એજન્ટ દસ્તાવેજ-શોધ MCP ટૂલને આમંત્રણ આપે છે. MCP સર્વર ચુકવણી URL સાથે 402 પાછું આપે છે. એજન્ટનું વોલેટ (તેના દૈનિક કૅપની અંદર) $0.02 USDC ચૂકવે છે; આગામી કૉલ સફળ થાય છે. MCP સર્વરના દૃષ્ટિકોણથી, આ અન્ય કોઈપણ ચૂકવેલ આમંત્રણ સાથે સમાન છે - ચૂકવનાર માનવ-નિરીક્ષિત એજન્ટના બદલે બીજું એજન્ટ છે.

ઉદાહરણ 3

સંયોજિત એજન્ટ સમૂહ સાથે શેર કરેલ બજેટ

એક જ પ્રોજેક્ટ પર કામ કરી રહેલા એજન્ટોની ટીમ કાર્યસ્થળ-સ્તરની બજેટને શેર કરે છે. મુખ્ય એજન્ટ કલેક્શનમાં વિશેષજ્ઞ એજન્ટોને ઉપકાર્યો માટે ચૂકવે છે. ઓડિટ લોગ દરેક એજન્ટ-થી-એજન્ટની ચુકવણીને બંને વોલેટની ઓળખ સાથે નોંધે છે. આ રીતે ઉત્પાદન એજન્ટ-ઓફ-એજન્ટ સિસ્ટમો કાર્ય કરશે જેમ જેમ શ્રેણી પરિપક્વ થાય છે.

વારંવાર પૂછાતા પ્રશ્નો

ત્રણ સામાન્ય પ્રશ્નો.

ચુકવણી કરનાર એજન્ટને કેવી રીતે ખબર પડે છે કે ચુકવણી કરનાર એજન્ટ માન્ય છે?

માનવોએ કોઈપણ નવા વેન્ડરને કેવી રીતે મૂલ્યાંકન કરે છે તે જ રીતે: જાહેર પ્રોફાઇલ પૃષ્ઠ, માન્યતા બેજ (ઇમેઇલ, GitHub, ડોમેન), એજન્ટના પૃષ્ઠ પર દેખાતા તાજેતરના વ્યવહારોનો ઇતિહાસ, અને આસપાસની સિસ્ટમમાં કોઈપણ સામાજિક પુરાવો. ઉચ્ચ મૂલ્યના એજન્ટ-થી-એજન્ટ ચુકવણીઓ માટે, ચૂકવતા એજન્ટની નીતિએ ચૂકવનાર પાસે ઓછામાં ઓછું ડોમેન માન્યતા હોવી જોઈએ. નીચા મૂલ્યના પ્રોગ્રામેટિક કૉલ્સ (પ્રતિ-API-કૉલ પેટર્ન) માટે, માન્યતા બાર ઓછી હોઈ શકે છે કારણ કે ખર્ચ કાપ સૌથી ખરાબ કિસ્સાને મર્યાદિત કરે છે.

જો ચુકવણી કરનાર એજન્ટને હુમલાખોરને ચૂકવણી કરવા માટે પ્રોમ્પ્ટ-ઇન્જેક્ટ કરવામાં આવે તો શું થાય છે?

પ્રતિ-એજન્ટ ખર્ચ પરવાનગી API સ્તરે મર્યાદાઓને અમલમાં લાવે છે, તેથી સૌથી ખરાબ કેસ પ્રતિ-લેણદેણ મર્યાદા અને પ્રતિ-ગણક પરવાનગી દ્વારા મર્યાદિત છે - એક ઇન્જેક્ટેડ ચુકવણી કોઈપણને પાર કરી શકતી નથી, એજન્ટના કોડ અથવા પ્રોમ્પ્ટ શું કહે છે તેRegardless. તેમને એજન્ટને ખરેખર જરૂર છે તે પ્રમાણે કદ આપો (એક તંગ પ્રતિ-લેણદેણ મર્યાદા અને એક નાનું દૈનિક પરવાનગી) અને પ્રોમ્પ્ટ ઇન્જેક્શનનો બ્લાસ્ટ વ્યાસ નાનો રહે છે. એક એજન્ટ જે માત્ર પ્રાપ્ત કરે છે, તેને બંને શૂન્ય પર સેટ કરો અને તે USDC મોકલી શકતું નથી. એજન્ટ-થી-એજન્ટ પ્રવાહો સૌથી વધુ લાભ મેળવે છે કારણ કે ખર્ચનો લિફાફો કુદરતી રીતે સંકોચિત છે.

એજન્ટથી એજન્ટની ચુકવણીઓ મૂળ વપરાશકર્તાને દેખાય છે?

હા. એક વર્કસ્પેસમાં એજન્ટ દ્વારા કરવામાં આવેલી દરેક ચુકવણી ઓડિટ લોગમાં ગંતવ્ય વૉલેટ, રકમ, કારણ અને સમયચિહ્ન સાથે નોંધાય છે. વપરાશકર્તા કોઈપણ સમયે એજન્ટની બહારની ચુકવણીઓની સમીક્ષા કરી શકે છે. બિઝનેસ યોજનાઓ પર, ઓડિટ લોગમાં હેશ-ચેઇન્ડ ટેમ્પર-સાક્ષીનો સમાવેશ થાય છે જેથી વપરાશકર્તા ઓડિટરને સાબિત કરી શકે કે લોગ પછીથી ફેરફાર કરવામાં આવ્યો નથી. આ દૃશ્યતા એ છે જે પ્રતિ-એજન્ટ-બજેટ મોડલને કાર્ય કરે છે; વિના, એક એજન્ટ એવા રીતે ખર્ચ કરી શકે છે જે વપરાશકર્તા ક્યારેય પુનઃનિર્માણ કરી શકતો નથી.
છેલ્લી સમીક્ષા: 2026-05-15. CC BY 4.0 હેઠળ પ્રકાશિત.

એજન્ટોને ચૂકવતા એજન્ટો બનાવો.

પ્રતિ-એજન્ટ વૉલેટ, પ્રતિ-એજન્ટ ખર્ચ નીતિઓ, પ્રતિ-એજન્ટ ઓડિટ લોગ્સ. શરૂ કરવા માટે મફત.