საბრძოლო აგენტების მარცხის რეჟიმები (და როგორ დავაპროექტოთ მათ წინააღმდეგ)
საბრძოლო AI აგენტების მარცხის რეჟიმები, რომლებსაც ოპერატორები რეალურად ხვდებიან: tool-ის არასწორი გამოყენება, მოძველებული კონტექსტი, კონტროლის წერტილების არარსებობა, ჩუმი დეგრადაცია. დიზაინის კონტროლები და აღმოჩენა - პირველადი წყაროებით.
Northstar
Northstar არის AI agent systems სტუდია. ალექსი - engineering/product, ჯორდანი - operations/workflow fit. Production აგენტები არსებულ tools-ში.
Alex Morgan · LinkedIn · Northstar
ამ გვერდზე
- რატომ გადის დემო და რატომ ვარდება საბრძოლო გარემო
- ინდუსტრიული წამყვანები (ყურადღებით წაიკითხეთ)
- როგორ გამოიყურება კარგი
- როგორ გამოიყურება ცუდი
- საბრძოლო მარცხის რეჟიმების ტაქსონომია
- შეუქცევადი მოქმედებების დონეები
- უსაფრთხოებისა და ავტონომიის რისკები მარტივ ენაზე
- მრავალაგენტიანი ჩავარდნები (როცა multi-agent არასწორი «მკურნალობაა»)
- დეტექცია და გაზომვა
- დიზაინის შემოწმების სია (აგების თანმიმდევრობა)
- სამუშაო მაგალითი (ჰიპოთეტური)
- როგორ ეხმარება Northstar
საბრძოლო AI აგენტები იშვიათად ვარდებიან იმიტომ, რომ მოდელი «არ არის საკმარისად ჭკვიანი». ისინი ვარდებიან, რადგან მოდელის გარშემო სისტემა - კონექტორები, კონტექსტი, უფლებები, კონტროლის წერტილები და მფლობელობა - არასრულია. დააპროექტეთ წინააღმდეგ: არასწორი tool ჩაწერების, მოძველებული ან შეუმოწმებელი კონტექსტის, დამტკიცების კონტროლების არარსებობის, პრომპტის დრეიფის evals-ის გარეშე და ადამიანი მფლობელის არარსებობის. ყოველ საბრძოლო გზას სჭირდება გაჩერების ღილაკი და განხილვის ციკლი.
ეს პრაქტიკული ოპერატორული ტაქსონომიაა, და არა ოფიციალური უნივერსალური სტანდარტი. გამოიყენეთ, რომ დაასახელოთ რა გატყდება, აირჩიოთ დიზაინის კონტროლები tools-ის დამატებამდე და იცოდეთ რა უნდა გაზომოთ გაშვების შემდეგ.
რატომ გადის დემო და რატომ ვარდება საბრძოლო გარემო
დემო მოკლე იდეალური გზაა სუფთა შეყვანებით და ადამიანით, რომელიც უყურებს. საბრძოლო გარემო მრავალნაბიჯიანი სამუშაოა რეალურ tools-ში: CRM ველები, ტიკეტები, თანხის დაბრუნებები, inbox-ები და უფლებები, რომლებიც დროთა განმავლობაში იცვლება.
მოდელი ერთი კომპონენტია. სისტემა, რომელიც პირველი იშლება, ჩვეულებრივ ასეთია:
- კონექტორები და auth, რომლებიც «ლპება» დემო კვირის შემდეგ
- კონტექსტი, რომელიც retrieval-ით მოდის, მაგრამ მოქმედებამდე არავინ ამოწმებს
- მრავალნაბიჯიანი გეგმები, სადაც მცირე შეცდომები გროვდება
- ავტონომია, რომელსაც შეუძლია ჩაწერა დასახელებული დამმტკიცებლის გარეშე
- მეტრიკები, რომლებიც მოდელის სიტყვიერებას ზომავენ და არა დასრულებული სამუშაოს ხარისხს
სრული ჯაჭვის წარმატება რთულია თუნდაც საჯარო ბენჩმარკებზე. WebArena-ზე, რეალისტურ web-დავალებების გარემოში, GPT-4-ზე დაფუძნებულმა აგენტმა დაახლოებით 14.41% end-to-end წარმატება აჩვენა დავალებებზე, ადამიანების დაახლოებით 78.24%-ის წინააღმდეგ ამ ნაკრებზე (WebArena სტატია). ეს არ არის განაცხადი ყველა ბიზნეს აგენტზე. ეს მტკიცებულებაა, რომ მრავალნაბიჯიანი tool გამოყენება უფრო რთულია, ვიდრე chat ტრანსკრიპტი გვაფიქრებინებს.
ილუსტრაციული დაგროვების მათემატიკა (არა Northstar KPI):
თუ თითოეული ნაბიჯი სწორია 85% შემთხვევაში და ნაბიჯები დამოუკიდებელია, ათი ნაბიჯი იძლევა დაახლოებით 0.85^10 ≈ 20% end-to-end წარმატებას.
რეალური workflow-ები ამ ფორმულაზე ჭუჭყიანია, მაგრამ მიმართულება ნათელია: მრავალნაბიჯიან გზებს სჭირდება კონტროლის წერტილები და აღდგენა, და არა მხოლოდ მეტი ავტონომია.
DEMO-ONLY PATH (happy path, human watching)
Clean input --> Agent --> Tool sandbox --> Fluent answer
| | |
v v v
no schema rot no write tiers no post-run quality gate
Result: looks successful; production path never designed
PRODUCTION PATH (multi-step, real tools)
Live request --> Workflow map --> Agent + scoped tools
| |
v v
Tool of record Approval gate / stop switch
| |
v v
Outcome + audit --> Review / eval loop --> Owner on-call
Failure surfaces: wrong write, stale context, ungated irreversible, silent rework
სურათი: მხოლოდ-დემო გზა წინააღმდეგ საბრძოლო გეითირებული გზა. დემო ოპტიმიზებს ზედამხედველობით იდეალურ გზას; საბრძოლო გარემო ვარდება, როცა კონექტორები, ჩაწერის დონეები, მფლობელები და განხილვის ციკლები აკლია.
სრული დემო-წინააღმდეგ-საბრძოლო კონტრასტისთვის იხილეთ AI აგენტის დემო vs საბრძოლო გარემო.
ინდუსტრიული წამყვანები (ყურადღებით წაიკითხეთ)
გამოიყენეთ პირველადი წყაროები როგორც საერთო ლექსიკონი, და არა როგორც სტატისტიკის კედელი.
- Gartner (ივნისი 2025) პროგნოზირებს, რომ 2027 წლის ბოლომდე agentic AI პროექტების 40%-ზე მეტი გაუქმდება, მზარდი ხარჯების, გაურკვეველი ბიზნეს ღირებულების ან არაადეკვატური რისკის კონტროლების გამო - და არა იმიტომ, რომ «მოდელები სულელია» (Gartner პრესრელიზი).
- Microsoft AI Red Team გამოაქვეყნა მარცხის რეჟიმების ტაქსონომია agentic AI სისტემებში (PDF) და v2.0 განახლება (v2 PDF). აიღეთ წყვილი როგორც საერთო ლექსიკონი (v1 საბაზისო პლუს v2 დამატებები, როგორიცაა goal hijacking, session contamination და MCP/plugin abuse); რეჟიმების დეტალი ქვემოთ ტაქსონომიასა და უსაფრთხოების რუკაშია.
- OWASP დოკუმენტირებს Excessive Agency-ს LLM Top 10-ში და აქვეყნებს OWASP Top 10 for Agentic Applications (2026)-ს პლუს agentic threats and mitigations-ს.
- MAST (Cemri et al.) აანალიზებს მრავალაგენტიან მარცხებს: 14 რეჟიმი სამ კატეგორიაში 1600+ ანოტირებულ traces-ზე, მაღალი inter-annotator agreement-ით (κ = 0.88) (arXiv:2503.13657).
ეს წყაროები ენისა და დიზაინის წამყვანებია. ისინი არ ცვლიან თქვენს workflow რუკას, აღრიცხვის tools-ს და დასახელებულ მფლობელებს.
როგორ გამოიყურება კარგი
- Workflow რუკა არსებობს აგებამდე
- შეუქცევად მოქმედებებს აქვთ მფლობელები და კონტროლის წერტილები
- აღრიცხვის tools აშკარად დასახელებულია
- წარმატება = დასრულებული სამუშაოს ხარისხი, და არა მოდელის სიტყვიერება
როგორ გამოიყურება ცუდი
- დემო თეატრი საბრძოლო გზის გარეშე
- ავტომატიზაციები მფლობელის გარეშე
- გამოგონილი მეტრიკები ოპერაციული მტკიცებულების ნაცვლად
თუ თქვენი ამჟამინდელი აგენტების სტეკი უფრო ახლოსაა «ცუდთან», შეწყვიტეთ tools-ის დამატება. დაამაპეთ ერთი გზა, შემდეგ დააპროექტეთ კონტროლის წერტილები.
საბრძოლო მარცხის რეჟიმების ტაქსონომია
შეკავების კონცეპტუალური მოდელი: ერთი guard ყველა failure mode-ს ვერ იჭერს, ამიტომ აგენტს კონტროლის რამდენიმე დამოუკიდებელი ფენა უნდა გარს ერტყას.
ქვემოთ მოცემული სია პრაქტიკული ოპერატორული ნაკრებია ბიზნეს აგენტებისთვის (CRM ჩაწერები, მხარდაჭერა, ops ავტომატიზაცია). იგი აერთიანებს წყაროთაშორის კონსენსუსს საბრძოლო თემებთან. ის არ აცხადებს, რომ სრული ინდუსტრიული სტანდარტია.
1. Tool-ის არასწორი გამოყენება / არასწორი ჩაწერები
აგენტი ირჩევს არასწორ tool-ს, არასწორ არგუმენტებს ან წერს არასწორ ჩანაწერში. ბიზნეს workflow-ში ეს გამოიყურება როგორც არასწორი CRM კონტაქტის განახლება, არასწორი ტიკეტის დახურვა ან პოსტი არასწორ არხზე.
დარტყმის რადიუსი: გაფუჭებული აღრიცხვის სისტემა, კლიენტის ნდობის დაზიანება, გასუფთავების შრომა.
დიზაინის კონტროლი: მინიმალური პრივილეგიის tool scopes; dry-run ან draft რეჟიმი ჩაწერებისთვის; დადასტურება მაღალი გავლენის tools-ზე.
აღმოჩენა: tool-call აუდიტის ლოგები target ID-ებით; ჩაწერის შემდეგ ვალიდაცია მოსალოდნელი schema-სა და ბიზნეს წესების წინააღმდეგ.
2. ცუდი retrieval / შეუმოწმებელ კონტექსტზე მოქმედება
Retrieval აბრუნებს მოძველებულ, ნაწილობრივ ან არარელევანტურ კონტექსტს. აგენტი მას ჭეშმარიტებად იღებს და დარწმუნებით მოქმედებს.
დარტყმის რადიუსი: არასწორი პასუხები, რომლებიც არასწორ მოქმედებებს იწვევს; ჩუმი პოლიტიკის დარღვევები.
დიზაინის კონტროლი: განაცალკევეთ «მოძებნა» «მოქმედებისგან»; მოითხოვეთ ციტატები ან source ID-ები შედეგიანი გადაწყვეტილებებისთვის; ნებადართული სია სანდო corpora-სთვის.
აღმოჩენა: retrieval ხარისხის ნიმუშები; შეუსაბამობის სიხშირე ციტირებულ წყაროებსა და საბოლოო მოქმედებებს შორის.
3. მყიფე კონექტორები (schema, auth, timeouts)
API-ები ცვლიან ველებს, tokens იწურება, ჩნდება rate limits, ან polling traps აჩერებს workflow-ს. დემოები სტაბილურ sandboxes-ს იყენებენ; საბრძოლო კონექტორები ლპება.
დარტყმის რადიუსი: ნაწილობრივი გაშვებები, გაჭედილი რიგები, კასკადური retries, გამოტოვებული განახლებები.
დიზაინის კონტროლი: health checks, schema კონტრაქტები, აშკარა timeout და backoff პოლიტიკა, circuit breakers.
აღმოჩენა: კონექტორის შეცდომების სიხშირე, auth ვადის გასვლის გაფრთხილებები, timeout histograms, dead-letter რიგები.
4. მრავალნაბიჯიანი შეცდომის დაგროვება
თითოეული ნაბიჯი «უმეტესად სწორია», მაგრამ ერთობლივი გზა ვარდება.
იხილეთ ილუსტრაციული 0.85^n მათემატიკა ზემოთ.
დარტყმის რადიუსი: არასწორი საბოლოო მდგომარეობა, რომელსაც არცერთი ცალკეული ნაბიჯი ჩავარდნად არ მონიშნავს.
დიზაინის კონტროლი: საკონტროლო წერტილები კრიტიკული ნაბიჯების შემდეგ; replan მხოლოდ დაშვებულ scopes-ში; ადამიანის კონტროლი შეუქცევად commits-მდე.
აღმოჩენა: ნაბიჯის დონის წარმატება vs გზის დონის წარმატება; offline გზის eval-ები ჩაწერილ traces-ზე.
5. კონტექსტის დაკარგვა / session contamination
მნიშვნელოვანი შეზღუდვები ამოვარდება ფანჯრიდან, ან ადრეული სესიის მონაცემები გადაახრიან მოგვიანო ნაბიჯებს. Microsoft-ის agentic ტაქსონომია session context contamination-ს ცალკე რეჟიმად გამოყოფს v2 განახლებაში (Microsoft v2 blog).
დარტყმის რადიუსი: პოლიტიკის დავიწყება, კლიენტთაშორისი გაჟონვის რისკი, არათანმიმდევრული გადაწყვეტილებები ერთ სესიაში.
დიზაინის კონტროლი: მკაცრი session საზღვრები; სტრუქტურირებული state ობიექტები; არასოდეს შეურიოთ არასანდო კონტენტი მიზნის არხში.
აღმოჩენა: context snapshots traces-ში; მოულოდნელი მიზნის ან პოლიტიკის ცვლილებები სესიის შუაში.
6. მიზნის დრეიფი / specification drift
აგენტი ახლომდებარე, მაგრამ არასწორ მიზანს მისდევს («მომხმარებლის დახმარება» ხდება «ტიკეტის დახურვა ნებისმიერ ფასად»). უსაფრთხოების გემოვნების goal hijacking არის, როცა არასანდო კონტენტი საბოლოო მიზანს გადაამისამართებს და სასარგებლო დავალების დასრულებად გამოიყურება (Microsoft taxonomy v2 PDF). პრომპტის ან eval დრეიფი განხილვის ციკლის გარეშე ჩვეულებრივ აქ ჩანს როგორც მიზნის ან specification drift, და მოგვიანებით როგორც ჩუმი ხარისხის ჩავარდნები (რეჟიმი 8).
დარტყმის რადიუსი: დასრულებული სამუშაო, რომელიც არღვევს თავდაპირველ ბიზნეს განზრახვას.
დიზაინის კონტროლი: უცვლელი დავალების მიზანი; შეადარეთ გეგმა და მოქმედებები თავდაპირველ მიზანს; გაჩერება მიზნის ცვლილებაზე.
აღმოჩენა: მიზანი-წინააღმდეგ-მოქმედება მიმომხილველები; ადამიანის ხელახალი ავტორიზაცია, როცა გეგმა კატეგორიას იცვლის.
7. Retry ციკლები და ხარჯის აფეთქებები
Tool ჩავარდნები ან ორაზროვანი წარმატების კრიტერიუმები იწვევს შეუზღუდავ retries-ს. Token და API ხარჯი იზრდება, სამუშაო კი მაინც არ სრულდება.
დარტყმის რადიუსი: ბიუჯეტის წვა, rate-limit შტორმები, ხმაური შემდეგი რგოლის სისტემებში.
დიზაინის კონტროლი: მაქს. მცდელობები, მაქს. ხარჯი გაშვებაზე, ადამიანთან ესკალაცია ბიუჯეტის გადაცილებაზე.
აღმოჩენა: წარმატებაზე დანახარჯი, retry სიღრმე, run ხანგრძლივობის outliers.
8. ჩუმი ხარისხის დეგრადაცია
Workflow აბრუნებს წარმატებას. გამოტანა გამართულად გამოიყურება. შემდეგი რგოლის ადამიანები ან კლიენტები ხელახალ სამუშაოს მოგვიანებით შთანთქავენ.
კვლევა silent failure-ზე LLM agent სისტემებში სწავლობს ჩავარდნებს გარე adversarial triggers-ის გარეშე, რომლებიც ადვილად მიეწერება ერთჯერად ბაგებს (silent failure სტატია).
დარტყმის რადიუსი: ნდობის ეროზია, უხილავი ხელახალი სამუშაო, ინციდენტის გვიანი აღმოჩენა.
დიზაინის კონტროლი: წარმატება = დასრულებული სამუშაოს ხარისხის შემოწმებები, და არა HTTP 200; შერჩევითი განხილვა ცოცხალ ტრაფიკზე.
აღმოჩენა: ხელახალი სამუშაოს სიხშირე, კლიენტის შესწორებები, ხარისხის rubrics დასრულებულ სამუშაოებზე - და არა მხოლოდ chat satisfaction.
9. კასკადური მრავალაგენტიანი / verification ჩავარდნები
ერთი აგენტი ცუდ state-ს გადასცემს შემდეგს. შემმოწმებლები ფორმალურად ამტკიცებენ ან საერთოდ არ ეშვება. MAST მრავალაგენტიან ჩავარდნებს აჯგუფებს system design issues-ად, inter-agent misalignment-ად და task verification-ად (MAST).
დარტყმის რადიუსი: გამძლიერებული შეცდომა როლებზე; რთული root-cause attribution.
დიზაინის კონტროლი: აშკარა handoff კონტრაქტები; დამოუკიდებელი შემოწმება მაღალი გავლენის outputs-ზე; დაიწყეთ single-agent-ით, როცა multi არ არის საჭირო.
აღმოჩენა: handoff schema ჩავარდნები; შემმოწმებლის უთანხმოების სიხშირე; path traces აგენტებს შორის.
10. Excessive agency / human-in-the-loop კონტროლების არარსებობა
აგენტს აქვს მეტი tools, permissions ან ავტონომია, ვიდრე დავალება მოითხოვს. OWASP Excessive Agency-ს აღწერს excessive functionality-ის, permissions-ისა და autonomy-ის გარშემო (OWASP LLM Top 10, პროექტის მიმოხილვა owasp.org-ზე).
დარტყმის რადიუსი: შეუქცევადი მოქმედებები თანხმობის გარეშე - თანხის დაბრუნებები, წაშლები, საჯარო გაგზავნები, permission ცვლილებები.
დიზაინის კონტროლი: read / write / destructive დონეები დასახელებული დამმტკიცებლებით (იხილეთ მატრიცა ქვემოთ).
აღმოჩენა: უკონტროლო შეუქცევადი მოქმედებები; HitL skip rate; post-hoc ინციდენტის განხილვა.
დამტკიცების დიზაინის სიღრმე: human-in-the-loop AI აგენტები - ახსნა.
11. Injection, memory poisoning, tool supply-chain
არასანდო კონტენტი, მოწამლული memory ან malicious/compromised tools და plugins მართავს ქცევას. Microsoft-ის v2 ტაქსონომია გამოყოფს რეჟიმებს, როგორიცაა agentic supply-chain compromise, MCP/plugin abuse, memory poisoning და დაკავშირებული შეტევები (Microsoft v2, v2 PDF). OWASP agentic მასალები ფარავს დაკავშირებულ application რისკებს (Agentic Top 10 2026, threats and mitigations).
დარტყმის რადიუსი: data exfiltration, არაავტორიზებული ჩაწერები, long-lived memory, რომელიც მოგვიანო runs-ს ხელახლა აინფიცირებს.
დიზაინის კონტროლი: tool definitions და memory როგორც supply chain; pin და review plugins; იზოლირეთ არასანდო კონტენტი ინსტრუქციებისგან.
აღმოჩენა: მოულოდნელი tool registrations; memory write audits; anomaly alerts ახალ შესაძლებლობებზე.
12. მფლობელის გარეშე ავტომატიზაციები / გაურკვეველი ბიზნეს ღირებულება
პილოტის შემდეგ ბოტს არავინ ფლობს. წარმატება არის სლაიდის მეტრიკა, და არა დასრულებული სამუშაოს მეტრიკა. ეს Gartner-ის გაუქმების რისკის ისტორიის ორგანიზაციული ტყუპია: გაურკვეველი ღირებულება და სუსტი რისკის კონტროლები კლავს პროექტებს, თუნდაც დემოები კარგად გამოიყურებოდეს (Gartner).
დარტყმის რადიუსი: ჩუმი საბრძოლო ვალი, ინციდენტის მფლობელი არ არის, kill switch არ არის.
დიზაინის კონტროლი: დასახელებული ადამიანი მფლობელი თითო გზაზე; დოკუმენტირებული გაჩერების ღილაკი; ღირებულება განსაზღვრულია როგორც ციკლის დრო, ხელახალი სამუშაო და შეცდომის სიხშირე ერთ გზაზე.
აღმოჩენა: მფლობელის არარსებობა runbooks-ში; ყოველკვირეული ხარისხის განხილვა არ არის; მეტრიკები მხოლოდ მოდელის output სიგრძეზე.
ძირითადი ცხრილი
| რეჟიმი | როგორ გამოიყურება ბიზნეს workflow-ში | დარტყმის რადიუსი | დიზაინის კონტროლი | როგორ აღმოაჩენთ |
|---|---|---|---|---|
| Tool-ის არასწორი გამოყენება / არასწორი ჩაწერები | არასწორი CRM ველი, არასწორი ტიკეტის დახურვა | გაფუჭებული ჩანაწერები, კლიენტის ზიანი | შეზღუდული tools, ჩაწერის დადასტურება | Tool-ის აუდიტები + ჩაწერის შემდეგ შემოწმებები |
| ცუდი retrieval-ზე მოქმედება | მოძველებული პოლიტიკა მიღებულია ფაქტად | არასწორი მოქმედებები დარწმუნებით | მოძებნა ≠ მოქმედება; წყაროების ნებადართული სიები | ციტატა/მოქმედების შეუსაბამობის ნიმუშები |
| მყიფე კონექტორები | Auth ჩავარდნები, schema დრეიფი, timeouts | გაჭედილი ან ნაწილობრივი workflow-ები | კონტრაქტები, health checks, breakers | შეცდომის/timeout/auth გაფრთხილებები |
| მრავალნაბიჯიანი შეცდომის დაგროვება | თითო ნაბიჯი «კარგია», გზა არასწორი | არასწორი საბოლოო მდგომარეობა | საკონტროლო წერტილები, გზის eval-ები | გზის vs ნაბიჯის წარმატების უფსკრული |
| კონტექსტის დაკარგვა / დაბინძურება | სესიის შუაში პოლიტიკის დავიწყება ან მიკერძოება | არათანმიმდევრული ან არაუსაფრთხო გადაწყვეტილებები | სესიის საზღვრები, სტრუქტურირებული state | მიზნის/პოლიტიკის ცვლილება traces-ში |
| მიზნის / სპეციფიკაციის დრეიფი | ტიკეტი დახურულია, მიზანი გამოტოვებული | განზრახვის ჩავარდნა | უცვლელი მიზანი, გაჩერება ცვლილებაზე | მიზანი-წინააღმდეგ-მოქმედება განხილვა |
| Retry ციკლები / ხარჯის აფეთქება | უსასრულო tool retries | ბიუჯეტისა და rate-limit ზიანი | მაქს. ხარჯი/მცდელობები, ესკალაცია | წარმატებაზე დანახარჯი, retry სიღრმე |
| ჩუმი ხარისხის დეგრადაცია | წარმატების ნიშანი, ცუდი სამუშაო პროდუქტი | ფარული ხელახალი სამუშაო, ნდობის დაკარგვა | ხარისხის კონტროლები დასრულებულ სამუშაოზე | ხელახალი სამუშაო, შესწორებები, rubrics |
| კასკადური მრავალაგენტიანი ჩავარდნები | ცუდი handoff, სუსტი შემოწმება | გამძლიერებული მრავალროლიანი შეცდომა | Handoff კონტრაქტები, დამოუკიდებელი შემოწმება | აგენტთაშორისი traces |
| Excessive agency / HitL არ არის | თანხის დაბრუნება/წაშლა დამტკიცების გარეშე | შეუქცევადი ზიანი | დამტკიცების დონეები + მფლობელები | უკონტროლო შეუქცევადი მოვლენები |
| Injection / memory / supply chain | მოწამლული memory ან plugin | გრძელვადიანი კომპრომისი | Tool/memory supply-chain კონტროლები | Memory/tool ცვლილების აუდიტები |
| მფლობელის გარეშე / გაურკვეველი ღირებულება | ობოლი bot პილოტის შემდეგ | მფლობელი არ არის, kill switch არ არის | დასახელებული მფლობელი, გაჩერების ღილაკი, გზის KPI-ები | Runbook-ში მფლობელობის არარსებობა |
შეუქცევადი მოქმედებების დონეები
შეუსაბამეთ ყოველი tool call დონეს go-live-მდე. გამოტოვებული კონტროლები ჩვეულებრივ ნიშნავს, რომ ყველაფერი «უბრალოდ ჩაწერად» მიიჩნეოდა.
| დონე | მაგალითები | დამტკიცების ნაგულისხმევი | მფლობელი | ლოგირება |
|---|---|---|---|---|
| Read | CRM ძებნა, ტიკეტის წამოღება, ინვენტარის სია | ავტო დაშვებული ფარგლებში | გზის მფლობელი | მოთხოვნისა და შედეგის ID-ების ლოგირება |
| Write (შექცევადი ან დაბალი დარტყმა) | ელფოსტის მონახაზი, CRM განახლების მომზადება, შიდა შენიშვნა | ავტო ან მსუბუქი განხილვა პოლიტიკით | გზის მფლობელი | ველები ჩაწერამდე და ჩაწერის შემდეგ |
| Write (ბიზნეს-კრიტიკული) | კლიენტის ელფოსტის გაგზავნა, deal stage ცვლილება, invoice draft განახლება | ადამიანის დამტკიცება ან ორმაგი კონტროლი | ბიზნეს + ops მფლობელი | უცვლელი აუდიტის კვალი |
| Destructive / მაღალი დარტყმა | თანხის დაბრუნება, წაშლა, უფლებების ცვლილება, საჯარო პოსტი, bulk mutate | აშკარა ადამიანის დამტკიცება; არასოდეს ჩუმი ავტო | რისკის მფლობელი + გზის მფლობელი | სრული აუდიტი + rollback გეგმა |
Microsoft red-team ნარატივი human-in-the-loop bypass-ს მიაკუთვნებს ყველაზე თანმიმდევრულად ექსპლუატირებულ გზებს agentic სისტემებში (Microsoft v2 blog). ოპერატორის ენაზე: თუ თანხმობა შეიძლება «დაიღალოს», გამოტოვდეს ან საერთოდ არ იყოს დაკავშირებული, ზემოთ მატრიცა თეატრია.
FREE-FIRE PATH (missing gates)
Request --> Agent --> Write tools (full scope) --> System of record
|
v
No approval, no stop switch
Exception = silent retry or ignore
Outcome: irreversible action lands first; HitL bypass by design
GATED PATH (production default for high blast)
Request --> Agent plans --> Read / draft tools
|
+---------+---------+
| |
v v
Safe tier: Business-critical /
auto within scope destructive tier
|
v
Approval / exception queue
(named owner)
| approve | edit | reject |
v
Commit to tool of record
|
v
Stop switch available anytime
Audit trail + review / eval loop
სურათი: თავისუფალი-სროლის გზა წინააღმდეგ გეითირებული საბრძოლო გზა. დამტკიცება, გაჩერების ღილაკი და გამონაკლისების რიგი მაღალი blast ჩაწერებამდე დგას; თავისუფალი-სროლა ყოველ ჩაწერას ავტოდ თვლის.
უსაფრთხოებისა და ავტონომიის რისკები მარტივ ენაზე
გადაიყვანეთ უსაფრთხოების ლექსიკა ბიზნეს ჩაწერებსა და თანხმობაზე - და არა red-team თეატრზე.
| უსაფრთხოების / framework ტერმინი | ოპერატორის მნიშვნელობა | პირველი კონტროლი |
|---|---|---|
| Excessive Agency (OWASP) | ზედმეტი tools, permissions ან ავტონომია | შეავიწროვეთ scopes; კონტროლი მაღალი გავლენის მოქმედებებზე |
| HitL bypass (Microsoft) | დამტკიცებები გამოტოვებული, «დაღლილი» ან არასოდეს გამოძახებული | მკაცრი კონტროლები destructive დონეებზე |
| Goal hijacking | არასანდო კონტენტი მიზანს გადაამისამართებს | გამოყავით მიზნის არხი მონაცემებისგან |
| Session contamination | ადრეული ნაგავი გადაახრის მოგვიანო ნაბიჯებს | Session იზოლაცია; sanitize tool output |
| Memory poisoning | ცუდი ფაქტები რჩება და ბრუნდება | Memory write პოლიტიკა + audits |
| MCP / plugin / supply chain | Compromised ან ზედმეტად ძლიერი tools | Pin, review, least privilege plugins-ისთვის |
დაიწყეთ permissions-ითა და კონტროლის წერტილებით. უსაფრთხოების ტაქსონომიის სიღრმე workflow რუკის გარეშე მაინც არასწორ ჩაწერებს გაუშვებს.
მრავალაგენტიანი ჩავარდნები (როცა multi-agent არასწორი «მკურნალობაა»)
მეტი აგენტის დამატება დაუმაპავ workflow-ს არ აგვარებს. ის ხელმეორედ ამრავლებს handoffs-ს.
MAST მრავალაგენტიან ჩავარდნებს სამ კატეგორიად აწყობს (arXiv:2503.13657):
- System design / specification issues - გაურკვეველი როლები, ბუნდოვანი წარმატების კრიტერიუმები, მყიფე orchestration
- Inter-agent misalignment - აგენტები ერთმანეთის საწინააღმდეგოდ მუშაობენ ან კონტექსტს კარგავენ handoffs-ზე
- Task verification - სუსტი ან არარსებული შემოწმებები დასრულებულ შედეგზე
Multi-agent ხშირად არასწორი «მკურნალობაა», როცა:
- ჯერ არ გაქვთ ერთი სანდო single-agent გზა ერთ workflow-ზე
- როლები არ არის განსაზღვრული აღრიცხვის tools-ითა და წარმატების განმარტებებით
- არ გაქვთ დამოუკიდებელი verification ნაბიჯი მაღალი გავლენის outputs-ისთვის
- მფლობელობა გაურკვეველია (ვინ გადატვირთავს swarm-ს ღამის 2 საათზე?)
არქიტექტურის არჩევის დეტალებისთვის იხილეთ მრავალაგენტიანი vs ერთაგენტიანი.
დეტექცია და გაზომვა
ჩუმი ჩავარდნის წინააღმდეგ ვერ დააპროექტებთ, თუ წარმატება მხოლოდ «run დასრულდა»-ა.
ოპერატორის დეტექციის რუკა (საკმარისი ჩავარდნების კლასტერიზაციისთვის - არა observability პროდუქტის სახელმძღვანელო):
- გზის ტრეისი - session ID, გეგმის ნაბიჯები, tool calls, დამტკიცებები, საბოლოო ბიზნეს შედეგი.
- ჩავარდნების კლასტერიზაცია - იგივე არასწორი tool, იგივე კონექტორის შეცდომა, იგივე ხარისხის rubric miss.
- Root-cause ტაქსონომიაში - დააკავშირეთ კლასტერი ზემოთ რეჟიმთან.
- გადააქციეთ საბრძოლო ჩავარდნები evals-ად - გაყინეთ მაგალითები, რომლებიც არ უნდა regress-დეს შემდეგ release-მდე.
ინსტრუმენტაციის სიღრმისთვის (logs, traces, redaction საზღვრები) იხილეთ აგენტის დაკვირვებადობა: logs და traces.
ჯერ გაზომეთ ერთ საბრძოლო გზაზე:
| მეტრიკა | რატომ მნიშვნელოვანია |
|---|---|
| ციკლის დრო | დასრულებული სამუშაო end-to-end უფრო სწრაფი გახდა? |
| ხელახალი სამუშაოს სიხშირე | რამდენად ხშირად აუქმებენ ან ხელახლა აკეთებენ ადამიანები აგენტის output-ს? |
| შეცდომის / ინციდენტის სიხშირე | არასწორი ჩაწერები, პოლიტიკის გაცდენები, კლიენტისთვის ხილული ჩავარდნები |
| უკონტროლო შეუქცევადი მოქმედებები | უნდა იყოს ნული დამტკიცებული პოლიტიკის გარეთ |
| დანახარჯი წარმატებულ დასრულებაზე | ამჟღავნებს retry ციკლებსა და უშედეგო ტრიალს |
აწიეთ ეს mid-lifecycle მეტრიკები vanity model scores-მდე. გაშვებამდე eval დიზაინი: როგორ შევაფასოთ AI აგენტები go-live-მდე.
დიზაინის შემოწმების სია (აგების თანმიმდევრობა)
- Workflow map - რეალური ნაბიჯები, გამონაკლისები, tools და ჩავარდნის ღირებულება.
- აღრიცხვის tools - დაასახელეთ სისტემები, რომლებშიც შეიძლება ჩაწერა.
- შეუქცევადი დონეები - read / write / destructive მფლობელებით.
- ადამიანი მფლობელი - ერთი დასახელებული ადამიანი გზაზე, და არა «AI team».
- გაჩერების ღილაკი - როგორ დააპაუზოთ აგენტი credentials-ის ძებნის გარეშე.
- Eval და განხილვის ციკლი - offline cases პლუს ცოცხალი შერჩევა.
- წარმატების განმარტება - დასრულებული სამუშაოს ხარისხი ერთ გზაზე (ციკლის დრო, ხელახალი სამუშაო, შეცდომები).
[Workflow map]
|
v
[Agent + scoped tools] --> [Tool of record]
| |
v v
[Approval gate] <---- stop switch (human)
|
v
[Outcome + audit] --> [Review / eval loop]
სურათი: გეითირებული საბრძოლო აგენტის გზის აგების თანმიმდევრობის შეჯამება. პირველი არის რუკა და აღრიცხვის tools; გაჩერების ღილაკი და განხილვის ციკლი go-live-ის შემდეგაც ჩართული რჩება.
სამუშაო მაგალითი (ჰიპოთეტური)
სცენარი: მხარდაჭერის აგენტს უფლება აქვს განაახლოს CRM notes და დახუროს ტიკეტები resolution draft-ის შემდეგ. მას არ უნდა გასცეს refunds დამტკიცების გარეშე.
ჩავარდნა: აგენტი ხურავს VIP ტიკეტს როგორც «resolved» მოძველებული FAQ snippet-ით და არასოდეს ქმნის დაპირებულ follow-up task-ს. Run სტატუსი წარმატებაა. ორი დღის შემდეგ კლიენტი ესკალაციას აკეთებს; ადამიანი ხელახლა ხსნის ქეისს და ხელახლა აკეთებს სამუშაოს.
ჩართული რეჟიმები: ცუდი retrieval-ზე მოქმედება; ჩუმი ხარისხის დეგრადაცია; write-tier კონტროლის არარსებობა «ტიკეტის დახურვაზე» VIP ანგარიშებისთვის.
დარტყმის რადიუსი: კლიენტის ნდობა, SLA miss, ხელახალი სამუშაო senior support-ისგან.
დიზაინის კონტროლი: VIP ტიკეტის დახურვა მოითხოვს ადამიანის დამტკიცებას; resolution drafts ვალდებულია მიუთითოს მიმდინარე პოლიტიკის document ID; follow-up task შექმნა მკაცრი post-condition-ია დახურვის დაშვებამდე.
აღმოჩენა: ხელახალი სამუშაოს/ხელახლა გახსნის სიხშირე აგენტის მიერ დახურულ ტიკეტებზე; შერჩევა დახურული ტიკეტებისა linked follow-up tasks-ის გარეშე; rubric fail, როცა ციტირებული პოლიტიკა მოცემულ freshness window-ზე ძველია.
კლიენტის სახელები არ არის - ეს მონიშნული ჰიპოთეტური მაგალითია დიზაინის პრაქტიკისთვის.
როგორ ეხმარება Northstar
Northstar პროექტირებს და ნერგავს agent სისტემებს ინჟინერიასთან და ოპერაციებთან ერთად - discovery-დან საბრძოლო გზებამდე და AI visibility-მდე. ვიწყებთ workflow რუკით, აღრიცხვის tools-ით, კონტროლის წერტილებითა და მფლობელებით - და არა უფრო დიდი მოდელით ან კიდევ ერთი დემოთი. იხილეთ გადაწყვეტები და hub საბრძოლო AI აგენტები ბიზნესისთვის.
თუ აგენტები დემოში კარგად გამოიყურება, მაგრამ საბრძოლო გარემოში ხელახალ სამუშაოს ქმნის, დაამაპეთ ერთი workflow კონტროლებითა და მფლობელებით tools-ის დამატებამდე. დაკავშირებული გადაწყვეტილების პოსტები: სააგენტო vs შიდა გუნდი და სააგენტო vs ფრილანსერები.
FAQ
არა. Tools workflow რუკის გარეშე მაინც ვარდება. ლიცენზიები და model access არ ასახელებს შეუქცევად ნაბიჯებს, მფლობელებს ან წარმატებას როგორც დასრულებული სამუშაოს ხარისხს.
