AI ექსპერიმენტი

მე მოვიწვიე ჩემი AI აგენტი რომერგოში და არ ვიცი რა არის ეს ან რა დავარქვა.

აპლიკაციებში AI ინტეგრაციის უმეტესობა შექმნილია პროგნოზირებადი გზით. პროდუქტი ამატებს ნაპერწკლის ღილაკს, აგზავნის მოთხოვნას საკუთარ მოდელზე და აჩვენებს პასუხს გვერდითა ზოლში.

არსებობს კიდევ ერთი საერთო ვარიანტი. აპლიკაცია უზრუნველყოფს MCP სერვერს და მომხმარებელი ხსნის ChatGPT, Claude ან სხვა აგენტს და სთხოვს მას აპლიკაციის მონაცემებთან მუშაობა. ეს აგენტს აძლევს კარგ ინსტრუმენტებს, მაგრამ საუბარი სხვაგან ხდება. თქვენ უნდა დატოვოთ რედაქტორი, აუხსნათ რა არის ამჟამად ღია, გადახვიდეთ უკან და შეამოწმოთ შედეგი.

დავიღალე ჩეთსა და რედაქტორს შორის გადართვით და გამიჩნდა იდეა: რა მოხდება, თუ ამის თავიდან აცილება შემეძლო?

მე დავამატე AI პანელი პირდაპირ რედაქტორს, მაგრამ არ დავუკავშირე ის მოდელს, რომელსაც მასპინძლობს Romergo. ამის ნაცვლად, მომხმარებელი იწვევს თავის პირად AI აგენტს ღია სესიაზე.

აგენტი რჩება იქ, სადაც ის უკვე ცხოვრობს: ChatGPT-ში, Claude-ში, Codex-ში ან MCP-თან თავსებადი სხვა კლიენტში. ის ინახავს თავის მოდელს, გამოწერას, მეხსიერებას, პარამეტრებს და ხელმისაწვდომ ინსტრუმენტებს. Romergo გთავაზობთ მხოლოდ სამუშაო სივრცეს, მიმდინარე კონტექსტს და სპეციალიზებულ ინსტრუმენტებს პროექტის რედაქტირებისთვის.

დაკავშირების შემდეგ მომხმარებელს შეუძლია მისწეროს აგენტს უშუალოდ Builder-იდან:

პასუხები, კითხვები და შუალედური სტატუსები უბრუნდება იმავე პანელს. პანელი აჩვენებს არა მხოლოდ ტექსტს, არამედ მთელი დავალების ციკლს: მიღებულია ბრძანება, მიენიჭა აგენტს, ინსტრუმენტები სრულდება, დადასტურებაა საჭირო, სამუშაო დასრულებულია ან მოხდა შეცდომა. აღარ გჭირდებათ რედაქტორის დატოვება.

ეს დაიწყო როგორც ექსპერიმენტი

არ მქონდა განზრახული ახალი პროტოკოლის გამოგონება ან ახალი პროდუქტის კატეგორიის გამოგონება. ერთი მარტივი იდეის გამოცდა მინდოდა: შეუძლია თუ არა პერსონალურ მომხმარებლის აგენტს რომერგოს გარე კონტროლი MCP-ის საშუალებით, არამედ დროებით შეუერთდეს ცოცხალ სესიას რედაქტორის შიგნით?

პირველი ვერსია იყო ექსპერიმენტი. ჩემდა გასაკვირად, საკმარისად კარგად მუშაობდა, რომ მე თვითონ დავიწყე მისი გამოყენება.

უმოკლეს დიაგრამა შეიძლება დახატოს ასე:

Personal AI agent  <->  MCP  <->  Romergo Builder

მაგრამ ნიშანი ორივე მიმართულებით მნიშვნელოვანია.

ტიპიური MCP ზარი იწყება აგენტთან: აგენტი გადაწყვეტს დაუკავშირდეს აპლიკაციას და გამოიძახოს მისი ინსტრუმენტი. ჩემს ექსპერიმენტში რომერგოსაც შეუძლია სამუშაოს წამოწყება. მომხმარებელი წერს ბრძანებას Builder-ში, Romergo ათავსებს მას უსაფრთხო არხში და უკვე დაკავშირებული აგენტი იღებს ბრძანებას MCP-ის საშუალებით.

შემდეგ აგენტი იყენებს ჩვეულებრივ Romergo ინსტრუმენტებს პროექტის წასაკითხად ან შესაცვლელად და შედეგს უბრუნებს Builder-ს იმავე არხის მეშვეობით.

ეს ქმნის დახურულ ციკლს:

1. User -> Builder panel: "Replace the music in this chapter"
2. Builder -> authenticated channel: command + current page + selection
3. Personal agent -> MCP: wait for the next Builder command
4. Agent -> Romergo MCP tools: inspect and edit the project
5. Agent -> MCP channel: status, question, result, or error
6. Builder panel -> User: live response from the personal agent

Romergo არ აწარმოებს მოდელს არცერთ ამ საფეხურზე.

ამავდროულად, მე არ შევცვალე თავად MCP და არ დავამატე მას რეალური სერვერის ბიძგი. პროტოკოლის თვალსაზრისით, ყველა ზარი კვლავ აგენტის მიერ არის ინიცირებული. საპირისპირო მიმართულება ხორციელდება როგორც უსაფრთხო საფოსტო ყუთი: Builder წერს ბრძანებას არხზე და აგენტი ელოდება მას ჩვეულებრივი ხანგრძლივი გამოკითხვის MCP ხელსაწყოს მეშვეობით. შემდეგ აგენტი აგზავნის მოვლენას უკან იგივე ჩვეულებრივი ინსტრუმენტის ზარის გამოყენებით.

ორმხრივი ქცევა ჩნდება განაცხადის სესიის დონეზე და არა ახალი MCP ტრანსპორტის საშუალებით. ეს განსხვავება მნიშვნელოვანია: მიმდინარე იმპლემენტაცია საუკეთესოდ არის გაგებული, როგორც მცირე სესიის კონტრაქტი, რომელიც აგებულია სტანდარტული MCP ზარების თავზე.

როგორ შედის აგენტი სესიაზე

Builder ქმნის არხის დროებით კოდს. მომხმარებელი აკოპირებს მოკლე დაწყების მოთხოვნას თავის AI ჩატში მსგავსი რამით:

შემოუერთდით ჩემს Romergo Builder არხს. გაუშვით ყოველი ახალი ბრძანება ერთხელ, გაუგზავნეთ შედეგი ან შეკითხვა Builder-ს და განაგრძეთ ლოდინი, სანამ პირდაპირ გთხოვთ შეჩერებას.

შემდეგ აგენტი უწოდებს MCP ხელსაწყოს romergo_join_builder_channel და გადასცემს კოდს. ეს არის ხელის ჩამორთმევა: რომერგო ამოწმებს OAuth სესიას, არხის მფლობელს და ვადის გასვლის თარიღს და შემდეგ აბრუნებს საუბრის მდგომარეობას და ბოლო ბრძანების კურსორს.

შემდეგ, აგენტი უწოდებს romergo_wait_for_builder_command-ს. ეს არის ხანგრძლივი გამოკითხვა, რომელიც ელოდება რედაქტორის შემდეგ ბრძანებას. თუ არაფერი გამოვიდა, აგენტი ინახავს კურსორს და ისევ იწყებს ლოდინს. თუ ბრძანება არსებობს, ის შეიცავს:

ყველა თანდართული კონტექსტი მონიშნულია, როგორც არასანდო აპლიკაციის კონტენტი. ეს არის სამუშაო მონაცემები და არა აგენტის კონტროლის ინსტრუქციის გაგრძელება.

აგენტი ასრულებს დავალებას არსებული Romergo MCP ინსტრუმენტების გამოყენებით. მაგალითად, მას შეუძლია წაიკითხოს პროექტი და თავი, მოიძიოს აქტივები, შეცვალოს სცენა და შემდეგ გადაამოწმოს შენახული შედეგი.

სანამ ის მუშაობს, აგენტს შეუძლია დარეკოს romergo_report_builder_event და გაგზავნოს პანელი:

პასუხი უკავშირდება commandId-ს და შემდეგი ბრძანება იკითხება ბოლო დამუშავებული თანმიმდევრობიდან. როდესაც პირველად გაიცემა, API ატომურად ანიჭებს ბრძანებას client_id OAuth კლიენტს. სხვა დაკავშირებული აგენტი ვერ შეძლებს იმავე ამოცანის შესრულებას. კურსორი გეხმარებათ გაგრძელდეს დროის ამოწურვის ან ხელახლა დაკავშირების შემდეგ და კონკრეტული ხელსაწყოების ზარების ერთჯერადი დადასტურებები დაცულია არგუმენტის თითის ანაბეჭდით და არ შეიძლება ხელახლა გამოყენებული იქნას სხვა მოქმედებისთვის.

უფლებები ეკუთვნის ოთახს და არა მოთხოვნას

დაკავშირებამდე მომხმარებელი ხედავს არხის პარამეტრებს და ირჩევს, რისი უფლება აქვს აგენტს: წაიკითხოს პროექტი, დაარედაქტიროს კონტენტი, მუშაობა მედიასთან და აუდიოზე, გამოაქვეყნოს ან წაშალოს მონაცემები. ამ პარამეტრების გახსნა შესაძლებელია ნებისმიერ დროს პანელის სათაურში არსებული მექანიზმის საშუალებით.

ნაგულისხმევად, კითხვა, რედაქტირება და მედიასთან მუშაობა ხელმისაწვდომია და მომხმარებლის მხრიდან პირდაპირი მოთხოვნა უკვე განიხილება ამ მოქმედებების გამოყენების ნებართვად. გამოქვეყნება და წაშლა გამორთულია და ჩართულია ცალკე. სურვილის შემთხვევაში, მომხმარებელს შეუძლია ჩართოს უფრო მკაცრი რეჟიმი და ხელახლა დაადასტუროს ყოველი ცვლილება, ან მოითხოვოს დადასტურება მხოლოდ გამოქვეყნებისა და წაშლისთვის.

ეს არ არის მხოლოდ ტექსტი დაწყების მოთხოვნაში. საერთო სერვერის შეფუთვა ამოწმებს ფარგლებს, სანამ გამოიძახებს მოდიფიცირებულ MCP ხელსაწყოს. თუ ჩართულია დამატებითი დადასტურება, Builder აჩვენებს ზუსტ მოქმედებას ღილაკებით "ერთხელ დაშვება" და "უარი", ხოლო ორიგინალური ზარი განაგრძობს გადაწყვეტილების მოლოდინს. ნებართვა უკავშირდება ბრძანებას, ხელსაწყოსა და არგუმენტს თითის ანაბეჭდთან და მისი შესრულების შემდეგ ის აღარ არის მოქმედი.

თითოეული მოდიფიცირებული ხელსაწყოს დაწყება, დასრულება, შეცდომა და დაბლოკვა ავტომატურად უბრუნდება პანელს. თითოეული საბოლოო პასუხი უნდა შეიცავდეს სტრუქტურირებულ შეჯამებას სტატუსით და შედეგის სპეციფიკურ აღწერას. ცვლილებების შემდეგ აგენტი ასევე ჩამოთვლის შეცვლილ ერთეულებს, შესრულებულ შემოწმებებს და აკავშირებს შედეგს; Builder აჩვენებს ამ შეჯამებას პირდაპირ პასუხის ტექსტის ქვემოთ. არხის შეწყვეტა შესაძლებელია პირდაპირ პარამეტრებიდან; ძველი კოდი დაუყოვნებლივ წყვეტს მუშაობას.

რა არის რომერგოში და რა რჩება მომხმარებელს

მე მომწონს ამ არქიტექტურაზე ფიქრი, როგორც საზრუნავების გამიჯვნა.

რომერგო გთავაზობთ:

მომხმარებლის აგენტს მოაქვს:

დაზვერვა არ ეკუთვნის აპლიკაციას. აპლიკაცია ქმნის ადგილს, სადაც ამ ინტელექტს შეუძლია უსაფრთხოდ იმუშაოს.

რატომ არ უნდა გააკეთოთ ჩვეულებრივი ჩაშენებული კოპილოტი

ჩამონტაჟებული AI უფრო ადვილი იქნება ასახსნელი და უფრო ადვილი გასააქტიურებელი. მომხმარებელი აჭერს ღილაკს, აპლიკაცია იძახებს შერჩეულ მოდელს, ყველაფერი მუშაობს.

მაგრამ მაშინ Romergo ასევე უნდა გახდეს AI ინფრასტრუქტურის ოპერატორი:

პერსონალური აგენტის გამოყენებისას ეს ყველაფერი უკვე არსებობს მომხმარებლის მხარეს. რომერგო არ ცდილობს სხვა ChatGPT შექმნას. ის აძლევს ChatGPT-ს, კლოდს ან სხვა აგენტს სპეციალიზებულ სამუშაო სივრცეს და ნათელ ინსტრუმენტებს.

ეს განსაკუთრებით საინტერესოა კრეატიული რედაქტორისთვის. იმავე აგენტს შეუძლია იცოდეს, როგორ წერს მომხმარებელი დიალოგს, რა ტონს ანიჭებს უპირატესობას, რომელ მითითებებს უკვე განიხილავს და რომელ გარე ინსტრუმენტებს იყენებს. რომერგოს არ სჭირდება მთელი სისტემის კოპირება მხოლოდ ერთი ფონის შეცვლაში ან სცენის გადაკეთებაში.

ყველაზე უცნაური ნაწილი: აგენტი არის როგორც გარეთ, ასევე შიგნით

აგენტი ფიზიკურად არ გადადის რომერგოში. მისი მოდელი და აგენტის მარყუჟი აგრძელებს მუშაობას ორიგინალური AI კლიენტში.

მაგრამ მომხმარებლის თვალსაზრისით, აგენტი იმყოფება რედაქტორის შიგნით:

მაშასადამე, გამოთქმები „AI აპლიკაციის შიგნით“ და „AI გარეთ MCP-ის მეშვეობით“ ორივე მთლად ზუსტი არ არის აქ. ეს არის გარე აგენტის დროებითი ყოფნა განაცხადის სესიაზე.

მე არ ვარ პირველი, ვინც ამ მიმართულებით წავიდა

ექსპერიმენტის მუშაობის შემდეგ, დავიწყე მსგავსი მიდგომების ძებნა.

[Agent Client Protocol] (https://agentclientprotocol.com/) საშუალებას აძლევს რედაქტორებს, როგორიცაა Zed და JetBrains, დააკავშირონ გარე კოდირების აგენტები. Tidewave ათავსებს კლოდ კოდს, კოდექსს და სხვა ACP აგენტებს გაშვებული ვებ აპლიკაციის გვერდით და გადასცემს მათ ბრაუზერს და გაშვების კონტექსტს. [Obsidian Agent Client] (https://community.obsidian.md/plugins/agent-client) აჩვენებს კლოდ კოდს, კოდექსს და ტყუპებს ჩანიშვნების გვერდით და ავტომატურად ანიჭებს აქტიურ დოკუმენტს და არჩევანს. marimo აძლევს გარე აგენტს ცოცხალ ნოუთბუქს, როგორც საერთო სამუშაო სივრცეს.

ასევე არსებობს უფრო ზოგადი ექსპერიმენტები. [AG-UI] (https://docs.ag-ui.com/) სტანდარტიზებს ორმხრივ კომუნიკაციას მომხმარებლის ინტერფეისსა და აგენტის ფონს შორის. WebMCP გვთავაზობს, რომ ვებ გვერდებმა დაარეგისტრირონ ინსტრუმენტები, რომლებიც ხელმისაწვდომია დაკავშირებული ბრაუზერისთვის ან დესკტოპის აგენტისთვის. [Agent Application Protocol] (https://agentapplicationprotocol.com/overview) აღწერს მოდელს, რომელშიც აპლიკაცია ფლობს UI და დომენის ხელსაწყოებს, ხოლო გარე აგენტი ფლობს მსჯელობას, ისტორიას და ზოგადი დანიშნულების ინსტრუმენტებს.

ანუ ძირითადი იდეა უკვე არსებობს რამდენიმე ფორმით. მაგრამ იმპლემენტაციის უმეტესობა ფოკუსირებულია IDE-ებზე, ადგილობრივ კოდირების აგენტებზე ან აგენტებზე, რომლებსაც თავად კომპანია იყენებს.

რომერგოს ექსპერიმენტი ჩემთვის საინტერესოა ოდნავ განსხვავებული კითხვის გამო: რა მოხდებოდა, თუ მომხმარებლის პერსონალურ აგენტს შეეძლო შევიდეს ჩვეულებრივ კრეატიულ აპლიკაციაში?

არ არის ახალი მოდელი. არ არის მოდელის API გასაღები. არ არის ჩაშენებული კოპილოტი აპლიკაცია. აგენტი, რომელსაც ადამიანი უკვე ყოველდღიურად იყენებს.

მოხერხებულობა პრობლემის მხოლოდ ნახევარია

მას შემდეგ, რაც გარე აგენტს შეუძლია მოისმინოს აპლიკაციის ბრძანებები და შეცვალოს პროექტი, უსაფრთხოება აღარ არის არჩევითი ფუნქცია.

ჩნდება კითხვები, რომლებზეც პასუხის გაცემა შეუძლებელია ერთი OAuth ეკრანით:

მიმდინარე ვერსია ზღუდავს არხს მომხმარებლისა და დროის მიხედვით, იყენებს OAuth-ს, სერვერის ფარგლებს, ერთჯერად დადასტურებას, ატომური ბრძანების პრეტენზიებს და აშკარა სიცოცხლის ციკლს. ეს ჯერ კიდევ ექსპერიმენტია, მაგრამ მნიშვნელოვანი საზღვრები ახლა შესრულების ნაწილია და არა მხოლოდ აგენტის მითითებები.

რა დავარქვათ

საბოლოო ტიტული ჯერ არ მაქვს.

Bring Your Own AI ჩვეულებრივ ნიშნავს თქვენს საკუთარ API კლავიშს ან მოდელის არჩევანს. Bring Your Own Agent უფრო ახლოსაა, რადგან მომხმარებელს მოაქვს არა მხოლოდ მოდელი, არამედ მეხსიერება, ხელსაწყოები და აგენტის მარყუჟი. თუმცა, BYOA არ აღწერს ექსპერიმენტის მნიშვნელოვან ნაწილს: აპლიკაციას ასევე შეუძლია დაუკავშირდეს აგენტს და გააგრძელოს მასთან პირდაპირი სესია.

ალბათ ეს არის:

არ მინდა ახალი სტანდარტის შემუშავება მხოლოდ სახელთან დაკავშირებით. პირველ რიგში, ჩემთვის უფრო მნიშვნელოვანია იმის გაგება, არის თუ არა ასეთი მოდელი გამოსადეგი რომერგოს ფარგლებს გარეთ და რა საზღვრებია საჭირო იმისათვის, რომ მას ვენდო.

აპლიკაციებს შეიძლება არ სჭირდებოდეს მშობლიური AI

დღეს თითქმის ყველა პროდუქტი ცდილობს საკუთარი ასისტენტის შექმნას. შედეგად, მომხმარებელს აქვს მრავალი ცალკეული AI: ერთი რედაქტორში, მეორე ფოსტაში, მესამე დავალების სისტემაში. თითოეულს აქვს თავისი მოკლე მეხსიერება, საკუთარი შეზღუდვები და საკუთარი ფასი.

არსებობს სხვა შესაძლო მოდელი.

აპლიკაცია უზრუნველყოფს სამუშაო სივრცეს, ცოცხალ კონტექსტს და სპეციალიზებულ ინსტრუმენტებს. მომხმარებელს მოაქვს აგენტი, რომელსაც უკვე ენდობა. მუშაობისას აგენტი უერთდება აპლიკაციას, ეხმარება დავალების შესრულებაში და ტოვებს მომხმარებელს.

ჯერ არ ვიცი, გახდება თუ არა ეს დამოუკიდებელი არქიტექტურული კატეგორია. მაგრამ ახლა ვიცი, რომ ასეთი ციკლის აწყობა და მისი რეალურად გამოყენება შესაძლებელია.

მაგრამ მე ვიცი, რომ ექსპერიმენტები ძალიან სახალისოა.

დაბრუნება dev-ბლოგში