Галоўная > Github Copilot: Handoffs і Subagents

Github Copilot: Handoffs і Subagents

AI
copilot

Здаецца, што штучны інтэлект здольны на ўсё. Вы проста апісваеце задачу, ідзеце піць каву, а па вяртанні разлічваеце атрымаць гатовы код. Але рэальнасць іншая: калі даручыць AI-агенту занадта шмат, ён хутка губляе фокус, забываецца на першапачатковыя патрабаванні і пачынае прыдумляць тое, чаго вы ўвогуле не прасілі. У выніку замест вырашэння задачы вы марнуеце час на расшыфроўку таго, што ён напісаў.

Каб атрымаць якасны вынік, працу AI трэба арганізоўваць — гэтак жа, як вы арганізуеце сваю ўласную. У VS Code для гэтага існуюць два інструменты: Handoffs (Перадачы) і Subagents (Сабагенты). Яны дапамагаюць разбіць вялікі хаос на кіраваныя працэсы. Давайце разбяромся, як менавіта.


1. Handoffs: Аўтаматызуем

Уявіце сітуацыю: вы просіце агента спланаваць архітэктуру, а потым напісаць код. Ён пачынае выдатна, выбудоўвае лагічны план. Але на этапе напісання кода раптам цалкам яго ігнаруе і робіць усё па-свойму. Каб пазбегнуць гэтага, вам трэба неяк спыняць яго, правяраць прамежкавы вынік і толькі потым дазваляць працягваць працу.

Тут на дапамогу прыходзяць Handoffs. Гэты падыход пабудаваны на паслядоўнай працы з паўзамі для праверкі. Замест таго каб дазваляць агенту рабіць усё і адразу, вы разбіваеце задачу на этапы. Адзін агент выконвае сваю частку працы, спыняецца і чакае вашага пацверджання перад тым, як перадаць кантэкст наступнаму. Гэта дае вам магчымасць своечасова ўносіць праўкі.

Напрыклад, першы агент можа стварыць падрабязны план. Вы яго вычытваеце, выпраўляеце памылкі ў логіцы і адным націскам кнопкі перадаяце ўзгоднены план другому агенту, які ўжо непасрэдна піша код. Ці яшчэ адзін варыянт — распрацоўка праз тэставанне (TDD), калі адзін агент піша тэсты, а другі, атрымаўшы іх, піша код, які гэтыя тэсты пройдзе.

Як гэта наладзіць

Кіраванне адбываецца праз frontmatter — блок налад у пачатку markdown-файла агента. Вы дадаяце секцыю handoffs, дзе пазначаеце, да якога агента пяройдзе размова і з якім промптам.

yaml
1---
2description: Стварэнне плана
3tools: ['search', 'web']
4handoffs:
5  - label: Пачаць распрацоўку
6    agent: implementation
7    prompt: План зацверджаны. Цяпер напішы код згодна з ім.
8    send: false # Калі true, промпт адправіцца без вашага дазволу. Лепш пакінуць false, каб захаваць кантроль.
9---

Пасля таго як першы агент сканчае адказ, у чаце з'яўляецца кнопка з назвай label (напрыклад, "Пачаць распрацоўку"). Вы націскаеце на яе, і кантэкст аўтаматычна перанакіроўваецца да наступнага агента, а загадзя падрыхтаваны промпт ужо чакае ў полі ўводу.


2. Subagents: Паралельная праца без страты кантэксту

Часта для выканання задачы агенту трэба прааналізаваць шмат пабочнай інфармацыі — напрыклад, прачытаць дакументацыю новага API. Ён загружае ўсё гэта ў свой кантэкст і хутка забываецца, якую менавіта задачу вы яму паставілі першапачаткова, бо аб'ём лішняй інфармацыі проста выцесніў галоўнае.

У такіх выпадках варта выкарыстоўваць Subagents. Калі Handoffs — гэта пра паслядоўнасць і кантроль, то сабагенты — пра дэлегаванне і ізаляцыю. Замест таго каб галоўны агент рабіў усё сам, ён стварае вузкаспецыялізаванага памочніка (сабагента) для канкрэтнай задачы. Гэты памочнік ідзе, вывучае дакументацыю і вяртае толькі кароткую выснову. Асноўны кантэкст галоўнага агента застаецца чыстым.

Гэта ідэальна падыходзіць для папярэдняга аналізу кода, калі сабагент ідзе глядзець, як у праекце рэалізавана аўтарызацыя, і вяртае кароткую даведку. Ці для паралельных праверак: галоўны агент можа адначасова запусціць некалькіх сабагентаў, каб адзін шукаў уразлівасці, другі — невыкарыстаныя зменныя, а трэці ацэньваў прадукцыйнасць.

Як гэта наладзіць

Каб сабагенты працавалі, патрэбны як мінімум два файлы: для галоўнага агента і для самога сабагента.

Крок 1. Стварэнне сабагента (напрыклад, reviewer.agent.md): Каб ён не замінаў вам у агульным спісе агентаў, яго варта схаваць з дапамогай user-invocable: false. Тут таксама зручна задаць больш танную і хуткую мадэль.

yaml
1---
2name: Code Reviewer
3user-invocable: false # Хавае агента з меню, ён даступны толькі іншым агентам.
4model: ['Claude Haiku 4.5'] 
5tools: ['read', 'search'] # Толькі бяспечныя інструменты, каб пазбегнуць выпадковых змен.
6---
7
8Твая задача — прааналізаваць код і знайсці ў ім лагічныя памылкі. Нічога не рэдагуй, толькі напішы справаздачу.

Крок 2. Стварэнне галоўнага агента (напрыклад, techlead.agent.md): Галоўнаму агенту трэба даць інструмент runSubagent, каб ён меў тэхнічную магчымасць запускаць іншых. Каб ён не выкарыстоўваў усё запар, даступныя сабагенты пералічваюцца ў полі agents.

yaml
1---
2name: Lead Developer
3tools: ['runSubagent', 'edit']
4agents: ['Code Reviewer', 'Implementer'] # Абмежаваны спіс тых, да каго можна звяртацца
5---
6
7Калі карыстальнік просіць дадаць функцыянал:
81. Запусці сабагента "Code Reviewer" для ацэнкі бягучага стану файлаў.
92. Запусці "Implementer" для напісання кода.

Важнае правіла працы з сабагентамі: карыстальнік не выклікае іх наўпрост. Вы размаўляеце толькі з галоўным агентам, а ён сам вырашае, у які момант яму спатрэбіцца дапамога ізаляванага кантэксту. Гэта адбываецца ў фонавым рэжыме, і ў інтэрфейсе чата выглядае проста як звычайны выклік інструмента, які можна разгарнуць пры жаданні.

Такі падыход дазваляе будаваць складаныя сістэмы, дзе адзін агент выконвае ролю каардынатара, а руцінная праца размяркоўваецца паміж вузкапрофільнымі выканаўцамі.

Admin, 2026-05-22
Каментары

    (Каб даслаць каментар залагуйцеся ў свой уліковы запіс)