ხელოვნური ინტელექტი გაჭედილ სერვერს გაასწორებს: ინსტრუქცია დაცვის წესებით

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

ამ პოსტში ამ ციკლს ერთ რეალისტურ მაგალითზე გავივლით, ვიტყვით, რა წვდომა სჭირდება ასისტენტს თითოეულ ეტაპზე, და ჩამოვთვლით დაცვის წესებს: ერთს, რომლებიც RE:NODE-ის პანელშია ჩაშენებული, და მეორეს, რომლებიც შენს prompt-ში უნდა დაამატო. უმეტესობა ნებისმიერ ჰოსტსა და ნებისმიერ ასისტენტზე მუშაობს. თუ გინდა უფრო ფართო სურათი, სად გვეხმარება კოდის აგენტები და სად გვაზიანებს, ჯერ წაიკითხე AI coding agents for server work; აქ იგივეა, ოღონდ ვიწრო და პრაქტიკული, ერთი ცუდი შუადღისთვის.

როგორ გამოიყურება crash loop და რომელს გაასწორებს AI#

crash loop არის სერვერი, რომელიც ირთვება, ვარდება, თავიდან ირთვება და ზუსტად იმავე ადგილას ისევ ვარდება. Pterodactyl-ზე აგებულ პანელში კონსოლი აჩვენებს გაშვებას, stack trace-ს ან შეცდომის სტრიქონს, კონტეინერის გაჩერებას და შემდეგ ისევ გაშვებას. თუ ზეწოლის ქვეშ კონსოლის კითხვა არასდროს გიცდია, reading the console ხუთ წუთს ნამდვილად ღირს, ხოლო crash loop diagnosis ზოგად მეთოდს აღწერს, AI-ს გარეშე.

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

• JSON, YAML, TOML ან INI ფაილი სინტაქსური შეცდომით - ზედმეტი მძიმე ბოლოში, tab YAML-ში, დაუხურავი ბრჭყალი.
• კონფიგის გასაღები არასწორი ტიპის მნიშვნელობით: სტრიქონი იქ, სადაც რიცხვი იყო მოსალოდნელი, ან true-ს ნაცვლად yes ისეთ ფორმატში, რომელიც მას არ იღებს.
• კონფიგში მითითებული გზა ფაილისკენ, რომელიც არ არსებობს.
• plugin-ის ან მოდის კონფიგი, რომელიც განახლებამ თავიდან შექმნა და ახალ გასაღებებს ძველი კონფიგი ვეღარ ემთხვევა.
• აპლიკაცია, რომელსაც აკლია შესასვლელი ფაილი, გაშვების სკრიპტი ან აუცილებელი გარემოს ცვლადი.

მეორე ჯგუფის მიზეზი არც ერთ ფაილში არ არის, ან გამოსწორება ფაილის რედაქტირება არ არის:

• პროცესი მეხსიერების ლიმიტზე ჩერდება. RE:NODE-ზე kernel კონტეინერს აჩერებს და ის swap-ში ჩავარდნის ნაცვლად სუფთად იწყება თავიდან, ამიტომ მეხსიერების ამოწურვის ციკლი stack trace-ის გარეშე გაჭედვას ჰგავს.
• შენახვის ან სამყაროს ფაილი დაზიანებულია.
• თამაშის განახლება და მოდის ან plugin-ის ვერსია აღარ ეთანხმება ერთმანეთს.
• სერვერს სჭირდება ავტორიზაციის მონაცემი, რომელიც არ აქვს - Steam game-server token, ლიცენზიის გასაღები, მონაცემთა ბაზის პაროლი.
• გაშვების ბრძანება, Java-ს მეხსიერების ფლაგები ან Docker image არასწორია.

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

სანამ რამეს დააკავშირებ#

სამ რამეს ორი წუთი სჭირდება და მთელ შუადღეს გიცავს.

1. შეაჩერე ციკლი. სერვერი, რომელიც განუწყვეტლივ ირთვება, განუწყვეტლივ გადაწერს ლოგებს და ზოგ თამაშში შენახვასაც ეხება. დააჭირე stop-ს Console ჩანართზე. RE:NODE-ზე ამას მეორე მიზეზიც აქვს: დამკვირვებელი ყოველ ორ წუთში ამოწმებს, ხომ არ დაბრუნდა uptime უკან ან ხომ არ გაითიშა სერვერი. ერთ საათში სამი გადატვირთვა სერვერის გვერდზე გაფრთხილებას აჩენს და ავტომატურად ტიკეტს ხსნის; ექვსი სერვერს აჩერებს. შენ მიერ მოთხოვნილი გადატვირთვები არ ითვლება, crash-ით გამოწვეული კი ითვლება.
2. გააკეთე backup. სანამ რომელიმე ფაილს შეცვლიან, შექმენი ერთი Backups ჩანართზე. ასისტენტს backup-ის შექმნა ან აღდგენა არ შეუძლია - არც ერთი AI ბმული backup-ებს ვერ აღწევს - ამიტომ ეს ნაბიჯი შენია. backup, რომელიც არასდროს აღგიდგენია, ჰიპოთეზაა, მაგრამ რედაქტირებამდე ხუთი წუთით ადრე გაკეთებული backup ყველაზე იაფი გაუქმებაა. ჩანართს backups guide განიხილავს, ჩვევას კი backups that actually restore.
3. ჩაიწერე, რა შეიცვალა. crash loop იშვიათად ჩნდება ცარიელი ადგილიდან. იყო განახლება, ახალი მოდი, გუშინ ღამით კონფიგის ცვლილება, გეგმის შეცვლა? ამის შესახებ ერთი წინადადება ასისტენტისთვის პირველ შეტყობინებაში ნებისმიერ რაოდენობის ლოგზე მეტს ღირს.

ნაბიჯი 1: დიაგნოზი წვდომის მიცემის გარეშე#

დიაგნოზისთვის ასისტენტისთვის არაფრის მიცემა არ გჭირდება. ყველა სერვერის Console ჩანართზე, ტერმინალის ზემოთ, არის პანელი სახელით Work on this server with AI. მის ჩამოსაშლელ სიაში, "What the assistant is for", არის ვარიანტი Server won't start. მისი არჩევა ბმულს არ ქმნის. ის აკოპირებს მზა prompt-ს, რომელშიც უკვე ჩასმულია კონსოლის ბოლო გამოტანა, და შენ მას Claude-ში, ChatGPT-ში ან შენთვის სასურველ ასისტენტში ათავსებ.

უმეტესი გაჭედვისთვის ეს სწორი პირველი ნაბიჯია, რადგან ასისტენტს აძლევს ყველაფერს, რასაც კონსოლი ამბობს, და სხვა არაფერს. ის ფაილებს ვერ ხსნის, ვერ ახდენს გადატვირთვას, ბრძანებებს ვერ წერს. მას მხოლოდ ჩასმული ტექსტის წაკითხვა და თავისი აზრის თქმა შეუძლია. პაროლები და token-ები დაკოპირებული ტექსტიდან ამოღებულია: პანელიდან გამოსული ყველაფერი გადის redactor-ში, რომელიც მნიშვნელობებს შლის ცვლადის სახელით (ნებისმიერი, რაც TOKEN-ს, PASSWORD-ს, KEY-ს, SECRET-ს ჰგავს), ფორმით (API გასაღებები, JWT-ები, URL-ებში ჩაწერილი პაროლები, გრძელი შემთხვევითი სტრიქონები) და მნიშვნელობით (სერვერის საკუთარი საიდუმლოები მზა ტექსტიდან იშლება). ეს დაცვის ბადედ მიიჩნიე და არა დაპირებად, და ჩასმამდე თვალი გადაავლე.

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

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

ნაბიჯი 2: მიეცი ხელები, თუ გინდა, რომ იმოქმედოს#

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

RE:NODE-ზე ასისტენტისთვის წვდომის მიცემის ორი გზა არსებობს.

მართვის ბმული. იმავე პანელში აირჩიე Manage this server (start/stop, console, files) და დააჭირე Connect AI-ს. პანელი ქმნის კერძო ბმულს, აკოპირებს და მხოლოდ ერთხელ აჩვენებს. ჩასვი ის ასისტენტში. მას თან მოჰყვება MCP მისამართიც, ასე რომ ასისტენტი, რომელიც remote MCP სერვერებს უჭერს მხარს - Claude Code ან Claude.ai custom connector-ის სახით - URL-ის ჩამოტვირთვის ნაცვლად ნამდვილ ინსტრუმენტებს იღებს. ბმული 24 საათის უმოქმედობის შემდეგ წყვეტს მუშაობას, შექმნიდან 30 დღის შემდეგ კი ყოველთვის, რაც არ უნდა მოხდეს; იმავე მიზნით ახალი ბმულის შექმნა ძველს ანაცვლებს.

OAuth კავშირი. დაამატე პანელის MCP endpoint შენს ასისტენტში და ერთხელ შედი ბრაუზერში:

$ claude mcp add --transport http renode https://panel.renode.space/api/client/mcp

თანხმობის გვერდი გეკითხება, რომელი სერვერები (შენი ყველა თუ არჩეული) და რომელი დონე: Files (ფაილების წაკითხვა და რედაქტირება, კონსოლის გამოყენება) ან Manage (ეს და, გარდა ამისა, start, stop და restart). crash loop-ისთვის გჭირდება Manage, თუ გინდა, რომ ასისტენტმა თავად გადატვირთოს და გადაამოწმოს, და Files, თუ ღილაკზე თავად დაჭერას ამჯობინებ. ორივე შემთხვევაში ის არასდროს აღწევს მონაცემთა ბაზებს, backup-ებს, განრიგებს, მომხმარებლებს, გაშვების პარამეტრებს და ანგარიშის პარამეტრებს.

აი, რას აკეთებს თითოეული სახის წვდომა, რომ ყველაზე მცირე აირჩიო, რომელიც საქმეს აკეთებს:

ბმული მოქმედებს იმ ადამიანის სახელით, ვინც შექმნა, და მისი უფლებებით ამ სერვერზე იმ მომენტში. subuser-ს, რომელსაც სერვერის გადატვირთვა არ შეუძლია, ბმულითაც ვერ გადატვირთავს, ხოლო სერვერზე წვდომის დაკარგვა ბმულს მაშინვე კლავს. იმის შესახებ, რატომ არის ყველაზე მცირე უფლება სწორი არჩევანი, იხილე subusers and least privilege.

სამუშაო მაგალითი: Node აპლიკაცია, რომელიც საკუთარ კონფიგზე ვარდება#

მაგალითი განზრახ ჩვეულებრივია, რადგან ჩვეულებრივს შეხვდები. პატარა Node.js აპლიკაცია app hosting სერვერზე ჩართვისას თავის პარამეტრებს config.json-დან კითხულობს. გუშინ ღამით ვიღაცამ ფაილი ფაილების მენეჯერში შეცვალა, რომ ახალი feature flag დაემატებინა. მას შემდეგ სერვერი ირთვება, ერთ სტრიქონს ბეჭდავს და ითიშება. კონსოლის ბოლო ასე გამოიყურება (შეცდომის ზუსტი ფორმულირება Node-ს ვერსიების მიხედვით განსხვავდება):

container@pterodactyl~ Server marked as starting...> app@1.4.0 start> node index.js/home/container/config.json: Expected double-quoted property name in JSONat position 211 (line 10 column 3)    at Module._extensions..json (node:internal/modules/cjs/loader)    ...container@pterodactyl~ Server marked as offline...

კონსოლის წაკითხვა

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

This server crash-loops since last night's edit to config.json.Read the console tail and the file the error names. Tell me the causeand the smallest edit that fixes it. Do not change anything yet.

ასისტენტი თავის კონსოლის ინსტრუმენტს იძახებს (ბმული ბოლო 100 სტრიქონს აბრუნებს), ხედავს, რომ config.json არის დასახელებული, და კითხულობს მას. ფაილის ინსტრუმენტი ტექსტური ფაილის პირველ 256 KB-ს აბრუნებს, საიდუმლოები კი [redacted]-ით ჩანაცვლებულია. პრობლემა მეათე სტრიქონშია:

  "features": {    "newCheckout": true,    "betaSearch": false,  },  "logLevel": "info"

მძიმე "betaSearch": false-ის შემდეგ JavaScript-ში დასაშვებია, JSON-ში კი არა, და სწორედ ისეთი რამაა, რაც ადამიანის სწრაფ გადახედვას გადაურჩება და JSON.parse-ზე ყოველთვის ვარდება. პოზიცია 211, სტრიქონი 10, სვეტი 3 არის დამხურავი ფრჩხილი, რომელსაც პარსერი შეხვდა, როცა კიდევ ერთი თვისების სახელს ელოდა. კარგი ასისტენტი ამას ორ წინადადებაში იტყვის და ერთი მძიმის წაშლას შემოგთავაზებს.

რედაქტირება

ახლა მას მოქმედების უფლებას აძლევ: "გააკეთე ეს შესწორება და სხვა არაფერი." სწორედ აქ ერთი დეტალი ყველაფერზე მნიშვნელოვანია. ფაილის ის ასლი, რომელიც ასისტენტმა წაიკითხა, ყველა საიდუმლოს [redacted]-ით ცვლის. თუ ასისტენტი მთელ ფაილს ამ ასლიდან უკან ჩაწერს, ფაილში არსებული ნებისმიერი პაროლი, token ან გასაღები სიტყვასიტყვით [redacted]-ით გადაიწერება. შემდეგ სერვერი ირთვება და სხვაგან ვარდება, ჩვეულებრივ მონაცემთა ბაზასთან ან API-სთან პირველივე დაკავშირებისას.

ამიტომ ნებისმიერი ფაილისთვის, რომელშიც საიდუმლოა, წესი ერთ-ერთია შემდეგიდან:

• რედაქტირება კეთდება მხოლოდ ფაილზე, რომელშიც ასისტენტმა დაადასტურა, რომ [redacted] ნიშანი არ არის.
• საიდუმლოები .env-შია და იქ ცვლილებები გადის set_env ინსტრუმენტით, რომელიც პანელის მხარეს ადგენს ან შლის დასახელებულ გასაღებებს, ყველა დანარჩენ ბაიტს ინარჩუნებს და მხოლოდ გასაღებების სახელებს აბრუნებს. .env-ის მთლიანად გადაწერა ზუსტად ის არის, რასაც ის თავიდან აგვარიდებს.
• რედაქტირებას შენ თავად აკეთებ ფაილების მენეჯერში და ასისტენტი მხოლოდ ამოწმებს.

ამ მაგალითში config.json-ში საიდუმლო არ არის, ამიტომ ასისტენტი შესწორებულ ფაილს წერს და გეუბნება, რა შეცვალა. სთხოვე, ჩაწერამდე აჩვენოს diff იმისა, რის ჩაწერასაც აპირებს; ერთი სიმბოლოს ცვლილება ერთი სიმბოლოს ცვლილებას უნდა ჰგავდეს.

ერთხელ გადატვირთვა

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

შესწორების გადამოწმება და არა მხოლოდ გადატვირთვის#

"სერვერი ჩაირთო" არ ნიშნავს "სერვერი მუშაობს". კონფიგის შესწორება გადამოწმებულია, როცა სამივე პირობა სრულდება.

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

სასარგებლო დასკვნითი ინსტრუქცია: "ახლა წაიკითხე კონსოლის ბოლო და რესურსების გამოყენება. თუ სერვერი მუშაობს და შეცდომა აღარ არის, ერთ აბზაცში შეაჯამე, რა შეცვალე, ფაილისა და სტრიქონის მითითებით. თუ არა, გაჩერდი და მითხარი, რას ხედავ." სწორედ ეს აბზაცი ჩაგვაქვს ჩვენს ჩანაწერებში და მას ვადარებთ activity log-ს.

გაჭედვები, რომლებიც ასისტენტმა შენთვის უნდა დააბრუნოს#

ეს ის შემთხვევებია, როცა ასისტენტის სწორი შედეგი დიაგნოზი და რეკომენდაციაა, მოქმედება კი შენია.

მეხსიერების ამოწურვა

თუ კონსოლი შეცდომის გარეშე მთავრდება და Console ჩანართზე მეხსიერების გრაფიკი პროცესის დაცემისას ლიმიტზე იყო, კონტეინერი მეხსიერების ზღვარზე გაჩერდა. კონფიგის ფაილში არაფერია, რაც ამას პატიოსნად გაასწორებს. ვარიანტებია: უფრო პატარა სამყარო ან ნაკლები plugin, heap-ის ან cache-ის უფრო დაბალი პარამეტრი, ან უფრო დიდი გეგმა - და თითოეული ეს შენი სერვერის შესახებ გადაწყვეტილებაა და არა ბეჭდვის შეცდომა. როგორ გაარჩიო, ამას Why your game server keeps restarting და Node memory limits explained განიხილავს.

გაშვების პარამეტრები და ავტორიზაციის მონაცემები

Java heap-ის ფლაგები, გაშვების ბრძანება, Docker image, Steam token-ები და ლიცენზიის გასაღებები Startup ჩანართზე ან ცვლადებშია. არც ერთ AI ბმულს გაშვების ან ცვლადების შეცვლა არ შეუძლია, განზრახ. თუ დიაგნოზია, რომ "-Xmx-ის მნიშვნელობა გეგმის მეხსიერებაზე დიდია" ან "game-server token-ს ვადა გაუვიდა", ასისტენტი გეუბნება და ცვლილებას შენ აკეთებ.

დაზიანებული შენახვები და სამყაროები

crash, რომელიც შენახვის, region-ის ან სამყაროს ფაილზე მიუთითებს, აღდგენის გადაწყვეტილებაა. უკან დაბრუნება პროგრესის დაკარგვას ნიშნავს და მხოლოდ შენ იცი, გუშინდელი backup ღირს თუ დღევანდელი. ასისტენტს შეუძლია გითხრას, რომელი ფაილია შეცდომაში დასახელებული; აღდგენა Backups ჩანართზე ხდება.

მოდების და plugin-ების ვერსიების კონფლიქტი

loader-ის შეცდომა, რომ მოდს თამაშის ან სხვა მოდის განსხვავებული ვერსია სჭირდება, მოგვარდება იმით, რომ შეიცვლება დაყენებული ფაილები, რაც ჩვეულებრივ jar-ებისა და DLL-ების წაშლას ან ჩანაცვლებას ნიშნავს. ბმულებს ფაილების წაშლა ან გადარქმევა არ შეუძლიათ, და არც გინდა, რომ ასისტენტმა მოდის რომელი ვერსია ჩამოტვირთოს, ვარაუდით გადაწყვიტოს. იხილე what to do when a mod update breaks.

როცა სერვერი შეჩერებულია

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

დაცვის წესები, რომლებიც ჩაშენებულია#

უსაფრთხოების მოდელის პანელისეული ნაწილი მოკლეა და მისი ცოდნა ღირს, რადგან გეუბნება, რა აღარ უნდა დაფაროს prompt-მა.

• რა არასდროს არის მისაწვდომი: წაშლა, გადარქმევა, თავიდან დაყენება, გაშვების ან ცვლადების ცვლილება, მონაცემთა ბაზები და მათი პაროლები, backup-ები, განრიგები, მომხმარებლები, SFTP დეტალები და API გასაღებები. არც წაკითხვის ბმულით, არც მართვის ბმულით, არც OAuth-ით.
• ჩაწერის ლიმიტები: ფაილების ჩაწერა მხოლოდ ტექსტია, მაქსიმუმ 1 MB, და არასდროს .git/-ის ქვეშ.
• ლიმიტები ბმულზე: წუთში 60 მოთხოვნა, 20 მოქმედება და 6 ჩართვა-გამორთვის მოქმედება. ასისტენტი შენს სერვერს მჭიდრო ციკლში ვერ გადატვირთავს, თუნდაც ეცადოს.
• რედაქცია: პაროლები და token-ები ამოღებულია ყველაფრიდან, რასაც ასისტენტი კითხულობს, და მონაცემთა ბაზის პაროლები გამოტანაში არასდროს არის.
• ვადა და ბრუნვა: მართვის ბმული 24 საათის უმოქმედობის შემდეგ და სულ 30 დღეში იწურება; სერვერზე მართვის ბმული მაქსიმუმ ორია. OAuth access token-ები ერთ საათს ძლებს, refresh token კი 30 დღის გამოუყენებლობის შემდეგ იწურება.
• ერთი ადგილი გამოსართავად: Account, შემდეგ Connected AI, აჩვენებს ყველა OAuth კავშირს Disconnect ღილაკით და ყველა აქტიურ share ბმულს, რომელიც შენ შექმენი, ნებისმიერ სერვერზე, Revoke ღილაკით.

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

დაცვის წესები, რომლებსაც prompt-ში ამატებ#

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

1. Read before you write. Quote the error line and the file line you   intend to change before changing anything.2. One change at a time. One edit, one start, then read the console.3. Never write back a file that contains [redacted]. Use set_env for   .env, or ask me to make the edit.4. Do not change versions, delete files, or touch anything outside the   file the error names without asking.5. If the console shows an out-of-memory stop, a corrupted save, a   missing credential or a version mismatch, stop and report.6. Finish with: what you changed, in which file, and how you verified it.

კიდევ ორი ჩვევა გეხმარება. საუბარი ერთ პრობლემას დაუთმე: ასისტენტი, რომელმაც ერთი საათი crash-ს მოანდომა, ვარაუდებს შემდეგ ამოცანაშიც გადაიტანს. და როცა გასწორება დასრულდა, გააუქმე მართვის ბმული ან გათიშე OAuth კავშირი, თუ მალე აღარ გამოიყენებ; ვადა საბოლოოდ მაინც გავა, მაგრამ მიზეზი არ არსებობს, რომ მოქმედი ავტორიზაცია საუბრის ისტორიაში იდოს. Environment variables and secrets უფრო ვრცელი არგუმენტია იმისა, რატომ უნდა ინახებოდეს საიდუმლოები .env-ში, რაც მე-3 წესის დაცვას ამარტივებს.

FAQ#

დაინახავს თუ არა AI ჩემს პაროლებს, სანამ სერვერს ასწორებს?

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

ითვლება თუ არა AI-ის გამოწვეული გადატვირთვა crash ლიმიტში?

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

რომელ ასისტენტებთან მუშაობს ეს?

share ბმული URL-ია, ამიტომ ის Claude-ში, ChatGPT-ში ან ნებისმიერ ასისტენტში ჩაიდება, რომელსაც ბმულის წაკითხვა შეუძლია. MCP endpoint და OAuth შესვლა Claude Code-ისა და Claude.ai custom connector-ების გათვალისწინებით აიგო და გამოიცადა და სხვა კლიენტებთანაც მუშაობს, რომლებიც HTTP-ზე remote MCP-ს უჭერენ მხარს.

შეუძლია თუ არა AI-ს ჩემი სერვერი უფრო გააფუჭოს, ვიდრე უკვე არის?

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

იქნებ უბრალოდ თავიდან დავაყენო?

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