ბლოგი

განახლებულია 16 წთ კითხვააგენტების შექმნა და მართვატუტორიალი

საბრძოლო აგენტების მარცხის რეჟიმები (და როგორ დავაპროექტოთ მათ წინააღმდეგ)

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

Northstar

Northstar არის AI agent systems სტუდია. ალექსი - engineering/product, ჯორდანი - operations/workflow fit. Production აგენტები არსებულ tools-ში.

Alex Morgan · LinkedIn · 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-ის დამატება. დაამაპეთ ერთი გზა, შემდეგ დააპროექტეთ კონტროლის წერტილები.

საბრძოლო მარცხის რეჟიმების ტაქსონომია

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

შეკავების კონცეპტუალური მოდელი: ერთი 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-მდე. გამოტოვებული კონტროლები ჩვეულებრივ ნიშნავს, რომ ყველაფერი «უბრალოდ ჩაწერად» მიიჩნეოდა.

დონემაგალითებიდამტკიცების ნაგულისხმევიმფლობელილოგირება
ReadCRM ძებნა, ტიკეტის წამოღება, ინვენტარის სიაავტო დაშვებული ფარგლებშიგზის მფლობელიმოთხოვნისა და შედეგის 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 chainCompromised ან ზედმეტად ძლიერი toolsPin, review, least privilege plugins-ისთვის

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

მრავალაგენტიანი ჩავარდნები (როცა multi-agent არასწორი «მკურნალობაა»)

მეტი აგენტის დამატება დაუმაპავ workflow-ს არ აგვარებს. ის ხელმეორედ ამრავლებს handoffs-ს.

MAST მრავალაგენტიან ჩავარდნებს სამ კატეგორიად აწყობს (arXiv:2503.13657):

  1. System design / specification issues - გაურკვეველი როლები, ბუნდოვანი წარმატების კრიტერიუმები, მყიფე orchestration
  2. Inter-agent misalignment - აგენტები ერთმანეთის საწინააღმდეგოდ მუშაობენ ან კონტექსტს კარგავენ handoffs-ზე
  3. Task verification - სუსტი ან არარსებული შემოწმებები დასრულებულ შედეგზე

Multi-agent ხშირად არასწორი «მკურნალობაა», როცა:

  • ჯერ არ გაქვთ ერთი სანდო single-agent გზა ერთ workflow-ზე
  • როლები არ არის განსაზღვრული აღრიცხვის tools-ითა და წარმატების განმარტებებით
  • არ გაქვთ დამოუკიდებელი verification ნაბიჯი მაღალი გავლენის outputs-ისთვის
  • მფლობელობა გაურკვეველია (ვინ გადატვირთავს swarm-ს ღამის 2 საათზე?)

არქიტექტურის არჩევის დეტალებისთვის იხილეთ მრავალაგენტიანი vs ერთაგენტიანი.

დეტექცია და გაზომვა

ჩუმი ჩავარდნის წინააღმდეგ ვერ დააპროექტებთ, თუ წარმატება მხოლოდ «run დასრულდა»-ა.

ოპერატორის დეტექციის რუკა (საკმარისი ჩავარდნების კლასტერიზაციისთვის - არა observability პროდუქტის სახელმძღვანელო):

  1. გზის ტრეისი - session ID, გეგმის ნაბიჯები, tool calls, დამტკიცებები, საბოლოო ბიზნეს შედეგი.
  2. ჩავარდნების კლასტერიზაცია - იგივე არასწორი tool, იგივე კონექტორის შეცდომა, იგივე ხარისხის rubric miss.
  3. Root-cause ტაქსონომიაში - დააკავშირეთ კლასტერი ზემოთ რეჟიმთან.
  4. გადააქციეთ საბრძოლო ჩავარდნები evals-ად - გაყინეთ მაგალითები, რომლებიც არ უნდა regress-დეს შემდეგ release-მდე.

ინსტრუმენტაციის სიღრმისთვის (logs, traces, redaction საზღვრები) იხილეთ აგენტის დაკვირვებადობა: logs და traces.

ჯერ გაზომეთ ერთ საბრძოლო გზაზე:

მეტრიკარატომ მნიშვნელოვანია
ციკლის დროდასრულებული სამუშაო end-to-end უფრო სწრაფი გახდა?
ხელახალი სამუშაოს სიხშირერამდენად ხშირად აუქმებენ ან ხელახლა აკეთებენ ადამიანები აგენტის output-ს?
შეცდომის / ინციდენტის სიხშირეარასწორი ჩაწერები, პოლიტიკის გაცდენები, კლიენტისთვის ხილული ჩავარდნები
უკონტროლო შეუქცევადი მოქმედებებიუნდა იყოს ნული დამტკიცებული პოლიტიკის გარეთ
დანახარჯი წარმატებულ დასრულებაზეამჟღავნებს retry ციკლებსა და უშედეგო ტრიალს

აწიეთ ეს mid-lifecycle მეტრიკები vanity model scores-მდე. გაშვებამდე eval დიზაინი: როგორ შევაფასოთ AI აგენტები go-live-მდე.

დიზაინის შემოწმების სია (აგების თანმიმდევრობა)

  1. Workflow map - რეალური ნაბიჯები, გამონაკლისები, tools და ჩავარდნის ღირებულება.
  2. აღრიცხვის tools - დაასახელეთ სისტემები, რომლებშიც შეიძლება ჩაწერა.
  3. შეუქცევადი დონეები - read / write / destructive მფლობელებით.
  4. ადამიანი მფლობელი - ერთი დასახელებული ადამიანი გზაზე, და არა «AI team».
  5. გაჩერების ღილაკი - როგორ დააპაუზოთ აგენტი credentials-ის ძებნის გარეშე.
  6. Eval და განხილვის ციკლი - offline cases პლუს ცოცხალი შერჩევა.
  7. წარმატების განმარტება - დასრულებული სამუშაოს ხარისხი ერთ გზაზე (ციკლის დრო, ხელახალი სამუშაო, შეცდომები).
[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 არ ასახელებს შეუქცევად ნაბიჯებს, მფლობელებს ან წარმატებას როგორც დასრულებული სამუშაოს ხარისხს.