თითქმის ყველა აგენტ-პროექტში დგება მომენტი, როცა ვიღაც დაფაზე მეორე ყუთს ხატავს. Router. „Planner agent”. billing აგენტი, shipping აგენტი, compliance აგენტი. ეს კარგ არქიტექტურას ჰგავს, რადგან microservices-ის დიაგრამას ჰგავს — და ჩვენ ყველამ ათი წელი გავატარეთ იმის სწავლაში, რომ პატარა, ფოკუსირებული სერვისები დიდ ტალახის გროვას სჯობს.
აგენტებისთვის ეს ინტუიცია ხშირად მცდარია. არა ყოველთვის, მაგრამ საკმარისად ხშირად იმისთვის, რომ მეორე ყუთის დახატვამდე შევანელოთ.
2026-ის განმავლობაში Anthropic-მა ამ კითხვაზე პრაქტიკული სტატიების სერია გამოაქვეყნა და ერთად ისინი თანმიმდევრულ ამბავს ჰყვება. უახლესი, Building agents: when to fold subagents into your main agent loop (2026 წლის ოქტომბერი), ყველაზე შორს მიდის: ის აღწერს enterprise გუნდებს, რომლებიც უკეთეს შედეგს იღებენ routers-ის, planners-ისა და domain subagents-ის მოშორებით. ეს პოსტი ჩემი სინთეზია: როდის ეხმარება რამდენიმე აგენტი, რომელი კოორდინაციის პატერნი რომელ პრობლემას ერგება, რატომ ბრუნდება ქანქარა ერთ loop-ისკენ, სად ჯდება advisor/executor და გადაწყვეტილების ჩარჩო. კომპრომისები context windows-ის მუშაობიდან მოდის და არა რომელიმე ერთი ფრეიმვორკიდან, ამიტომ ისინი ვრცელდება იმისგან დამოუკიდებლად, იყენებთ Claude Agent SDK-ს, LangGraph-ს თუ ხელით დაწერილ loop-ს.
მეორე აგენტის რეალური ფასი
დავიწყოთ ანგარიშიდან. Anthropic-ის 2026 წლის იანვრის სტატია multi-agent overhead-ს ეკვივალენტური ამოცანისთვის ერთ აგენტთან შედარებით 3–10-ჯერ მეტ ტოკენად ასახელებს. მიზეზები ყოველდღიურია: კონტექსტის დუბლირება ფანჯრებს შორის, კოორდინაციის შეტყობინებები, რომლებიც მომხმარებლისთვის არაფერს აწარმოებს, და summarization ყოველ handoff-ზე.
ბოლო ყველაზე მტკივნეულია, და არა ტოკენების გამო. ყოველი handoff დანაკარგიანია: დეტალები, რომლებიც პირველ ნახტომზე უმნიშვნელო ჩანდა, მესამეზე მნიშვნელოვანია, და იქამდე ისინი უკვე წასულია. იმავე სტატიაში აღწერილია ექსპერიმენტი planner, implementer, tester და reviewer აგენტებით, სადაც subagents მუშაობაზე მეტ ტოკენს კოორდინაციაზე ხარჯავდნენ.
Latency მეორე სიურპრიზია. პარალელიზმი აჩქარებს ცალკეულ ქვეამოცანებს, მაგრამ მთლიანი გამოთვლა იზრდება, ამიტომ სისტემა ხშირად საერთო ჯამში ნელია. ოქტომბრის სტატია ასახელებს ერთ მომხმარებელს, რომლის single-agent loop დაახლოებით ორჯერ სწრაფად მუშაობდა multi-agent harness-ზე, რომელიც ჩაანაცვლა — ეს ერთი მონაცემია და არა კანონი, მაგრამ სწორედ ის მიმართულებაა, რასაც ველოდი.
ყველაზე დაუფასებელი ფასი ორგანიზაციულია. როცა თითოეული გუნდი საკუთარ აგენტს აშენებს, ხოლო platform გუნდი მათზე orchestrator-ს აბამს, მიიღებთ იმას, რასაც ოქტომბრის სტატია ჩამოთვლის: გადაფარვადი subagents მფლობელების გარეშე, სისტემური პრომპტი, შეკერილი გუნდების ურთიერთსაწინააღმდეგო წესებისგან, და evals, რომლებსაც თითოეული გუნდი ლოკალურად ოპტიმიზებს, სანამ end-to-end ხარისხს არავინ ფლობს. არქიტექტურა ორგ-სქემას ირეკლავს. კონვეის კანონმა მოქმედება არ შეწყვიტა, როცა კომპონენტები LLM-ები გახდა.
როდის ეხმარება რეალურად რამდენიმე აგენტი
ეს ყველაფერი არ ნიშნავს „არასოდეს გამოიყენო subagents”. იანვრის სტატია სამ სიტუაციას ასახელებს, სადაც გაყოფა თანმიმდევრულად იგებს, და თითქმის ყველა ლეგიტიმური multi-agent დიზაინი ერთ-ერთზე დაიყვანება:
- კონტექსტის დაცვა. ქვეამოცანა წარმოქმნის ბევრ გამოსავალს, რომელიც მთავარი ამოცანისთვის არარელევანტურია (სტატია დაახლოებით 1,000+ ტოკენს ასახელებს იმ წერტილად, სადაც იზოლაცია ანაზღაურდება). subagent მას ჩაიმუშავებს და აბრუნებს კომპაქტურ summary-ს; მთავარი ფანჯარა სუფთა რჩება.
- პარალელიზაცია. ნამდვილად დამოუკიდებელი ასპექტები — ერთმანეთთან დაუკავშირებელი კვლევის მიმართულებები, ცალკე სარევიუო განზომილებები — ერთდროულად სხვადასხვა ფანჯარაში სრულდება. წყარო სარგებელს დეტალიანობად აყალიბებს და არა სიჩქარედ.
- სპეციალიზაცია. ზედმეტად ბევრი tool, რომელთა შორის სანდოდ არჩევა ჭირს, ურთიერთსაწინააღმდეგო tool-დომენები ან პერსონები, რომლებიც საპირისპირო მიმართულებით ექაჩებიან. როგორც ვნახავთ, ამის უმეტესობის მისაღებად ახლა უფრო იაფი გზებია.
პლუს ერთი cross-cutting გამოყენება: ვერიფიკაცია. აგენტი, რომელიც იღებს არტეფაქტს და წარმატების კრიტერიუმებს, მაგრამ არა build-ის ისტორიას, ნამდვილად დამოუკიდებელი შემოწმებაა.
დაშალეთ კონტექსტით და არა თანამდებობის დასახელებით
მთელი სერიის ყველაზე სასარგებლო იდეა: გაყავით კონტექსტის საზღვრებით და არა პრობლემის ტიპებით. კარგი საზღვრები არის იქ, სადაც ცოტა კონტექსტი უნდა გადავიდეს — დამოუკიდებელი კვლევითი გზები, სუფთა ინტერფეისები, black-box ვერიფიკაცია. ცუდი საზღვრები — ერთი და იმავე სამუშაოს თანმიმდევრული ფაზები, მჭიდროდ დაკავშირებული კომპონენტები, ყველაფერი, რასაც shared state სჭირდება. სტატიის მაგალითი: აგენტმა, რომელიც ფიჩას აშენებს, მისი ტესტებიც უნდა დაწეროს, რადგან კონტექსტი უკვე აქვს. ცალკე „tester agent” რგოლების მოწესრიგებული გაყოფაა, რომელიც სიზუსტეს უჯდება. თუ domain-driven design გიმუშავიათ, ეს ისევ bounded contexts-ია — იმ განსხვავებით, რომ აქ შემოსაზღვრული სიტყვასიტყვით context window-ა.
კოორდინაციის ხუთი პატერნი და რა ღირს თითოეული
როცა გადაწყვეტთ, რომ ნამდვილად ერთზე მეტი აგენტი გჭირდებათ, 2026 წლის აპრილის coordination-patterns სტატია ხუთ ფორმას აღწერს. აი ჩემი შეკუმშული წაკითხვა, თითოეულისთვის მტყუნების რეჟიმით, რომელსაც დავაკვირდებოდი.
| პატერნი | ფორმა | გამოიყენეთ, როცა | ფრთხილად იყავით |
|---|---|---|---|
| Generator–verifier | ერთი აგენტი აწარმოებს, მეორე კრიტერიუმებით ამოწმებს, loop-ი გრძელდება მიღებამდე ან ლიმიტამდე | ხარისხი მნიშვნელოვანია და კრიტერიუმების ცალსახად ჩამოყალიბება შეიძლება | კონკრეტული კრიტერიუმების გარეშე verifier ყველაფერს ბეჭედს ურტყამს; ოსცილირებადი loops |
| Orchestrator–subagent | წამყვანი აგენტი გეგმავს, აბარებს შემოსაზღვრულ ქვეამოცანებს, სინთეზირებს შედეგებს | მკაფიო დეკომპოზიცია, დაბალი ურთიერთდამოკიდებულება | წამყვანი ინფორმაციის ბოთლის ყელად იქცევა; თანმიმდევრული subagents multi-agent ტოკენებს ჯდება აჩქარების გარეშე |
| Agent teams | მუდმივი workers იღებენ საერთო რიგიდან და აგროვებენ კონტექსტს | დამოუკიდებელი, ხანგრძლივი პარტიციები (მაგ. ერთი სერვისი თითო worker-ზე მიგრაციაში) | კონფლიქტური რედაქტირებები გაზიარებულ რესურსებზე; დასრულების არათანაბარი დრო |
| Message bus | აგენტები router-ის მეშვეობით მოვლენებს publish/subscribe-ს უკეთებენ | Event-driven workflows, დამოუკიდებლად deployed აგენტების მზარდი ეკოსისტემა | არასწორად მარშრუტიზებული მოვლენებიდან წყნარი მტყუნებები; ძნელად მოსაძიებელი კასკადები |
| Shared state | აგენტები საერთო საცავში კითხულობენ და წერენ, ცენტრალური კოორდინატორის გარეშე | კოლაბორაციული კვლევა, სადაც აღმოჩენები აგენტებს შორის გზაში უნდა მიედინებოდეს | დუბლირებული სამუშაო, რეაქტიული loops, რომლებიც აშკარა დასრულების პირობის გარეშე არასოდეს კონვერგირდება |
გვერდიგვერდ ყურებისას სამი რამ გამოირჩევა.
Orchestrator–subagent არის ნაგულისხმევი, თუ საერთოდ რამდენიმე აგენტი გჭირდებათ. დანარჩენები ის არის, რისკენაც ვითარდებით, როცა კონკრეტული ტკივილი ჩნდება: orchestrator-ში დაგროვილი მარშრუტიზაციის ლოგიკა bus-ზე მიუთითებს; workers, რომლებსაც ციკლებს შორის დამახსოვრება სჭირდებათ, teams-ზე; აგენტები, რომლებსაც ერთმანეთის შუალედური აღმოჩენები სჭირდებათ, shared state-ზე.
ყოველ loop-ს სჭირდება გაჩერების წესი, დაწერილი მის დაწყებამდე — max iteration რაოდენობა პლუს fallback generator–verifier-ისთვის; დროის ბიუჯეტი ან „N ციკლის განმავლობაში ახალი აღმოჩენა არ არის” shared state-ისთვის. Locking პარალელურ ჩაწერებს წყვეტს; ის ორ აგენტს არ აჩერებს, რომ ერთმანეთს ზრდილობიანად უსასრულოდ დაუსვან follow-up კითხვები.
ვერიფიკაცია იმდენად კარგია, რამდენადაც მისი კრიტერიუმები. იანვრის სტატია აღწერს early-victory მტყუნებას: verifier ორ ტესტს უშვებს, მწვანეს ხედავს და წარმატებას აცხადებს. გამოსწორება მოსაწყენია: ცალსახად მოითხოვეთ სრული suite, negative ტესტები და edge cases.
მარტის workflow-patterns სტატია (თანმიმდევრული, პარალელური, evaluator-optimizer pipelines კოდში ფიქსირებული გზით) უმატებს რჩევას, რომელიც აქ ყველაფერს უდევს საფუძვლად: ჯერ სცადეთ ერთი გამოძახება და სტრუქტურა დაამატეთ მხოლოდ იქ, სადაც ის დასაბუთებულად არ ყოფნის.
ქანქარა ბრუნდება: ერთი loop, progressive disclosure
აქ ოქტომბრის მითითებები საინტერესო ხდება. ბევრი enterprise deployment გაუმჯობესდა routers-ის, planners-ისა და domain subagents-ის ერთ loop-ში ჩაკეცვით; ერთი აგენტი skills-ით ხშირად სჯობდა როგორც single-prompt, ისე subagent დიზაინებს ხარისხით, ხშირად დაბალი ღირებულებითა და latency-ით. ამის ერთი მიზეზი შესაძლებლობაა: უფრო ახალი მოდელები გაცილებით მეტ გადაწყვეტილებას თვითონ იღებენ, ამიტომ ლოგიკა harness-იდან მოდელში გადაინაცვლებს.
სამიზნე არქიტექტურა:
- ერთი მოდელი, ერთი context window, ერთი ღია tool loop, turn-ბიუჯეტებით, ღირებულების ბიუჯეტებითა და harness-ში write gates-ით. Tool-გამოძახებები ბაჩებად მოდის და პარალელურად სრულდება.
- დაგეგმვა loop-ის შიგნით ხდება. მოდელი გეგმავს პირველ turn-ზე და ასწორებს შედეგების შემოსვლისას — planner და executor ერთი და იგივე მოდელია, ამიტომ handoff-ში არაფერი იკარგება.
- Domain პროცედურა გადადის skills-ში; მკაცრი ლიმიტები და live lookups — tools-ში. დეტერმინირებული კოდი კვლავ ამუშავებს იაფ, ყოველთვის საჭირო სამუშაოს, როგორიცაა entity resolution.
რაც ამას მასშტაბირებადს ხდის, არის progressive disclosure: აგენტი ხედავს თითოეული skill-ისა და tool-ის მოკლე აღწერას და სრულ შინაარსს ტვირთავს მხოლოდ მაშინ, როცა ამოცანა მოითხოვს. სტატია აღნიშნავს, რომ Anthropic-მა უფრო მოწინავე მოდელებისთვის Claude Code-ის სისტემური პრომპტი 80%-ზე მეტით შეკვეცა, ნაწილობრივ ამ გზით. აპრილის harness-design სტატია იგივეს მეორე მხრიდან ამტკიცებს: ყოველი წინასწარ ჩატვირთული ტოკენი მოდელის ყურადღებას ეჯიბრება.
Tools იგივე მოპყრობას იღებს. იანვრის ტექსტი გვთავაზობს, რომ tool-ის არჩევა რთულდება დაახლოებით 15–20 tool-ზე; ოქტომბრის ტექსტი დეგრადაციას აკვირდება დაახლოებით 30–50 განსაზღვრების ზემოთ. ორივე გვირჩევს tool search-ს გადადებული ჩატვირთვით აგენტების დამატებამდე, პლუს tools-ს, დაჯგუფებულს მომხმარებლის განზრახვით და არა თითო endpoint-ზე თითო, ხოლო თითოეული მომხმარებლის permissions-ს — თითოეული tool-ის შიგნით.
დააკვირდით, რას უშვრება ეს სპეციალიზაციის არგუმენტს. იმის უმეტესობას, რასაც სპეციალისტი subagent გვთავაზობდა — ფოკუსირებული ინსტრუქციები, შერჩეული tool-ნაკრები — progressive disclosure ახლა ერთ ფანჯარაში იძლევა, დანაკარგიანი handoff-ის გარეშე. ეს არის ნამდვილი ძვრა.
როგორ ჩავკეცოთ რამის გაფუჭების გარეშე
ოქტომბრის მიგრაციის გზა ფრთხილია ისე, რომ მომწონს:
- ჯერ end-to-end evals ააშენეთ — ათი golden მაგალითი დასაწყებად საკმარისია. ახლა აკონტროლეთ routing-ის სიზუსტე; ჩაკეცვის შემდეგ — ჩატვირთა თუ არა აგენტმა სწორი skill ან tool.
- გააერთიანეთ მჭიდროდ დაკავშირებული სპეციალისტები — ისინი, ვინც ერთმანეთის გამოსავალზე ჯაჭვდებიან ან, როგორც წესი, ერთად იძახებიან.
- დარჩენილ subagents-ს გამოუძახეთ როგორც tools-ს, რათა მთავარმა აგენტმა საუბარი ფლობდეს და baseline გქონდეთ.
- ჩაკეცეთ სათითაოდ. პრომპტები ხდება skills, API-გამოძახებები — tools. დააკვირდით, რომელი ამოცანები შეიცვალა და არა მხოლოდ აგრეგატულ ქულას.
სტატიის გამაფრთხილებელი მაგალითი: ერთი subagent-ის support აგენტში ჩაკეცვამ latency შეამცირა, მაგრამ პროცესი გატეხა — მთავარმა აგენტმა მიწოდების თარიღის კითხვას თავად უპასუხა და shipping სპეციალისტს არ მიმართა, ისიც ორიდან მხოლოდ ერთ გაშვებაში. ყოველი ამოცანა რამდენჯერმე გაუშვით; როგორც evals პოსტი ამტკიცებს, აგენტის ქცევა განაწილებაა.
საკუთრებაც იცვლება: გუნდები წყვეტენ აგენტების ფლობას და იწყებენ skills-ისა და tools-ის ფლობას, ხოლო მცირე ცენტრალური გუნდი ფლობს სისტემურ პრომპტსა და end-to-end ხარისხს. ხოლო subagents თავის ადგილს მაინც იმსახურებს, როცა კონტექსტის გაბერვა loop-ს აზიანებს, პარალელურ ამოცანებს ახალი ფანჯრები სჭირდება, ან tool-ის არჩევა და ურთიერთსაწინააღმდეგო ინსტრუქციები ერთ აგენტს სძლევს.
Advisor/executor პატერნი: ინტელექტი მოთხოვნისას
არსებობს მესამე ფორმა, რომელიც „ერთი აგენტი თუ ბევრი” დიქოტომიაში ზუსტად არ ჯდება და მისი ცოდნა ღირს. Anthropic-ის 2026 წლის აპრილის სტატია advisor strategy-ზე აღწერს უფრო მცირე executor მოდელის დაწყვილებას, რომელიც მთელ ამოცანას end-to-end ასრულებს, უფრო დიდ advisor მოდელთან, რომელსაც ის მხოლოდ რთულ გადაწყვეტილების წერტილებზე კონსულტაციას უწევს. advisor კითხულობს გაზიარებულ კონტექსტს და აბრუნებს გეგმას, შესწორებას ან stop სიგნალს. ის არასოდეს იძახებს tools-ს და არასოდეს ესაუბრება მომხმარებელს.
ეს orchestrator პატერნს აბრუნებს: ვიდრე დიდი მოდელი პატარა workers-ისთვის სამუშაოს შლიდეს, პატარა მოდელი მართავს და ზემოთ ამახვილებს. არც დეკომპოზიცია, არც worker pool, ხოლო frontier მსჯელობას მხოლოდ საჭიროებისას იხდით.
Anthropic-ის მიერ მოხსენიებული ციფრები (შიდა evals, გაშვებებს შორის განსხვავებული thinking პარამეტრებისა და პრომპტების გაფრთხილებით): SWE-bench Multilingual-ზე Sonnet Opus advisor-ით 2.7 პუნქტით მეტს აგროვებდა, ვიდრე Sonnet მარტო, თითო ამოცანაზე 11.9%-ით დაბალი ღირებულებით; BrowseComp-ზე Haiku Opus advisor-ით 41.2%-ს აღწევდა მარტოხელა 19.7%-ის წინააღმდეგ. მათი რჩევა სწორია: გამოსცადეთ სამი კონფიგურაცია — პატარა მარტო, პატარა პლუს advisor, დიდი მარტო — და ციფრებს მიანდეთ გადაწყვეტილება.
კონცეპტუალურად მომწონს, რომ ის ერთ კონტექსტსა და ამოცანის ერთ მფლობელს ინარჩუნებს — ზუსტად იმას, რასაც ჩაკეცვის მითითებები იცავს — და იქ, სადაც მნიშვნელოვანია, მეორე აზრს ამატებს. გინდათ planner agent-ის აგება? ჯერ advisor სცადეთ. (ღირებულების მხარეზე მეტი — ტოკენების ეკონომიკაში.)
გადაწყვეტილების ჩარჩო
აი ცხრილი, რომელსაც დაფის გვერდით დავაკრავდი, სანამ ვინმე მეორე ყუთს დახატავს.
| ამოცანის ფორმა | რეკომენდებული არქიტექტურა |
|---|---|
| ერთი ამოცანა, კომფორტულად ეტევა ერთ ფანჯარაში | ერთი აგენტი, ერთი გამოძახება. ორკესტრაციის გარეშე. |
| ფართო დომენი, ბევრი პროცედურა, ბევრი tool | ერთი აგენტის loop skills + tool search-ით (progressive disclosure) |
| უმეტესად რუტინული სამუშაო ხანდახან რთული განსჯით | უფრო მცირე executor + უფრო დიდი advisor |
| ქვეამოცანა აწარმოებს დიდ, უმეტესად არარელევანტურ გამოსავალს | მთავარი loop + კონტექსტის დამცავი subagent, რომელიც აბრუნებს summary-ს |
| ნამდვილად დამოუკიდებელი კვლევითი ან სარევიუო ასპექტები | Orchestrator–subagent, ცალსახად პარალელიზებული |
| გამოსავალი უნდა აკმაყოფილებდეს ცალსახა, შესამოწმებელ კრიტერიუმებს | Generator–verifier max-iteration ლიმიტითა და fallback-ით |
| დამოუკიდებელი, ხანგრძლივი პარტიციები (ერთი თითო სერვისზე) | Agent teams დანაწილებული რესურსებით |
| Event-driven pipeline დამოუკიდებლად deployed აგენტებით | Message bus correlation ID-ებითა და routing evals-ით |
| აგენტებმა ერთმანეთის აღმოჩენებზე თითქმის რეალურ დროში უნდა ააგონ | Shared state ცალსახა დასრულების პირობით |
მესამე რიგის ქვემოთ რამის დანერგვამდე დასვით სამი კითხვა, იანვრის checklist-იდან ადაპტირებული: არის თუ არა რეალური შეზღუდვა (კონტექსტი, პარალელიზმი ან სპეციალიზაცია, რომელსაც skills და tool search ვერ წყვეტს)? მისდევს თუ არა გაყოფა კონტექსტს და არა თანამდებობის დასახელებებს? არის თუ არა მკაფიო ვერიფიკაციის წერტილი? თუ რომელიმე პასუხი არის არა, თქვენ გაქვთ single-agent პრობლემა. „უფრო სუფთაა” შეზღუდვა არ არის.
სად ვიქნებოდი ფრთხილად
- ეს ვენდორის სტატიებია. დაწერილია Anthropic-ის მიერ, Claude-ზე, ციფრებით შიდა evals-იდან ან ცალკეული მომხმარებლებიდან. პატერნები გადატანადია; ციფრები თქვენი დატვირთვის პროგნოზი არ არის.
- „ხშირად” არ ნიშნავს „ყოველთვის”. ოქტომბრის სტატია ამბობს, რომ ერთი loop-ები ხშირად იგებს. თქვენი ალბათ გამონაკლისია — ამას მხოლოდ end-to-end eval suite გეტყვით, თითო კონფიგურაციაზე რამდენჯერმე გაშვებული.
- ზღვრები გადაადგილდება. Tool-ების რაოდენობის ლიმიტები და კონტექსტის ზღვრები მოდელების გაუმჯობესებასთან ერთად იცვლება; harness-design სტატია აჩვენებს ხარაჩოს, რომელიც ერთ მოდელის თაობას სჭირდებოდა და შემდეგს აღარ. ყოველი განახლებისას ხელახლა გაამოწმეთ.
- ჩაკეცვა სირთულეს გადააქვს და არ შლის. ერთ loop-ს სჭირდება დისციპლინირებული სისტემური პრომპტი, მკვეთრი skill და tool აღწერები და მიზანმიმართული მეხსიერების მართვა. ეს context engineering-ია და რეალური სამუშაოა.
- ერთი loop ერთი პროცესია, რომელიც შეიძლება დაეცეს. Checkpointing და idempotent tools უფრო მნიშვნელოვანია orchestrator-ის გარეშე, რომელიც ქვეამოცანებს ხელახლა სცდის — იხილეთ durable execution აგენტებისთვის.
როგორ მივუდგებოდი არსებულ multi-agent სისტემას
თუ დღეს გაქვთ router პლუს ათეული სპეციალისტი, ნუ გადაწერთ:
- ჯერ ააშენეთ end-to-end eval ნაკრები, ერთი ადამიანის საკუთრებაში. მის გარეშე არაფერია უსაფრთხო.
- გაზომეთ handoff-ები — ჩაწერეთ, რას იღებს და აბრუნებს თითოეული აგენტი. დანაკარგიანი საზღვრები სწრაფად ჩნდება.
- გააერთიანეთ წყვილი, რომელიც ყოველთვის ერთად იძახება. ყველაზე დაბალი რისკი, ყველაზე მკაფიო სიგნალი.
- გადააქციეთ სპეციალისტები skills-ად და tools-ად (MCP გონივრული სტანდარტია tool-ის მხარისთვის), სათითაოდ, ყოველ ნაბიჯზე evals-ის ხელახლა გაშვებით.
- შეინარჩუნეთ ის, რაც ადგილს იმსახურებს — და დააფიქსირეთ, სამი შეზღუდვიდან რომელი ამართლებს თითოეულ გადარჩენილ subagent-ს.
კარიერული კუთხე
ხუთი აგენტის ფრეიმვორკით ერთმანეთთან დაკავშირება ახლა ადვილია, რაც ნაწილობრივ პრობლემაცაა. ღირებული უნარია იმის ცოდნა, როდის არა, და evals-ით მისი დამტკიცება. ეს ნიშნავს თავისუფლებას ისეთ რამეებში, რომლებიც ნებისმიერ მოდელს გაუძლებს: კონტექსტის საზღვრების დაპროექტება, skills-ისა და tool-აღწერების წერა, რომლებსაც მოდელი სანდოდ არჩევს, evals-ის აგება, რომელიც პროცესის რეგრესიებს იჭერს, და ტოკენებისა და latency-ის ბიუჯეტებზე მსჯელობა. ინჟინერი, რომელსაც თორმეტყუთიან დიაგრამაზე შეუძლია თქვას „ეს სამი ყუთია და აი eval”, დიდხანს იქნება მოთხოვნადი. enterprise backend-იდან მოდიხართ? იხილეთ C#-იდან Claude აგენტებამდე.
უფრო ღრმად
Claude Agent SDK პრაქტიკულად ფარავს agent loop-ს, subagents-ს, skills-სა და tool-დიზაინს. Building LLM-Powered Apps: RAG & Agents პატერნებს ფრეიმვორკისგან დამოუკიდებლად ფარავს. Claude API ფარავს სამშენებლო ბლოკებს — tool use, caching, ღირებულების კონტროლი. MCP Servers ეხება domain API-ების განზრახვით დაჯგუფებულ tools-ად გადაქცევას. ხოლო Claude Code Mastery აჩვენებს production single-loop აგენტს progressive disclosure-ით მომხმარებლის მხრიდან.
წყაროები: Anthropic, Building agents: When to fold subagents into your main agent loop (2026 წლის ოქტომბერი); Multi-agent coordination patterns: Five approaches and when to use them (2026 წლის აპრილი); Building multi-agent systems: When and how to use them (2026 წლის იანვარი); Common workflow patterns for AI agents and when to use them (2026 წლის მარტი); The advisor strategy (2026 წლის აპრილი); Harnessing Claude’s intelligence (2026 წლის აპრილი). ეს პოსტი დამოუკიდებელი კომენტარია; ციფრები მოყვანილია ისე, როგორც წყაროები ასახელებენ. დაკავშირებული ამ სერიაში: context engineering, evals, ტოკენების ეკონომიკა, durable execution, AI-native SDLC.
