1. daļa: Kāpēc aģentu inženierija nav Vibe kodēšana Draugs nesen publicēja par AI prasmēm, izmantojot Matrix analogu: Trinity nemācās lidot helikopteru - Tank augšupielādē precīzu, pārbaudītu programmu tieši viņas prātā. Bet tas atklāj fundamentālu pārpratumu par to, kā šīs sistēmas faktiski tiek veidotas. Trinity nav vibe viņas ceļu uz lidošanu. Tank augšupielādē . Precīza, pārbaudīta programma Tā ir atšķirība starp vibe kodēšanu un to, ko Addy Osmani sauc "Vibe kodēšana" ir saindējusi ieleju - tas liecina, ka jūs varat novirzīt savu ceļu uz ražošanas programmatūru. aģentūras inženierzinātne Manā web3 izstrādes darbplūsmā ir vairāk nekā 70 aģenti. Tie nav steidzami atkritumi. Tie ir strukturēti: skaidras atbildības, skaidras zināšanu faili, definēti handoff punkti starp aģentiem. To veidošana prasīja to pašu arhitektūras domāšanu, kas vienmēr atdala darba sistēmas no haosa. Vecie principi tieši tulko: DRY → DRYP (Neatkārtojiet savu paziņojumu) Atdalīšana bažas → aģentu robežas Interfeisu dizains → Handoff līgumi Dokumentācija → Precompiled konteksts Labas prasmes veidošana ir arhitektūras darbs.Trinity skatuve darbojas, jo kāds Pilotprogramma. „Tank” to nav kodējis. Inženieris Problēma, ar kuru viss sākās Lielākā lieta, ko es iemācījos veidot AI kodēšanas darba plūsmas: . more context is not better Man ir ABIs, kas ir tūkstošiem līniju. Ponder datu bāzes shēma, kas ēdinātu pusi konteksta logu, ja es to barotu neapstrādātu. Tas nedarbojas. AI tiek zaudēts. Svarīgas instrukcijas tiek ignorētas. Tas piestiprina pie nejaušām detaļām. Rezultāti kļūst sliktāki, jo konteksts kļūst lielāks. Kad konteksta logs aizpilda, agrākie norādījumi kļūst "pārpildīti", un modelis sāk tos ignorēt. context rot Tāpēc es izveidoju prasmju speciālistu aģentu. Tās vienīgais darbs ir citu aģentu kontekstu sagatavošana.Tas lasa manu neapstrādāto ABI, shēmas un dokumentus, pēc tam rada plānas atsauces failus, kas pielāgoti konkrētiem uzdevumiem. Kad man ir jāveic UI darbs, es nepārdodu savam ui-dizainerim visu kodu bāzi. prasmju speciālists jau ir izveidojis komponentu atsauci ar tikai aģenta nepieciešamajām īpašībām un modeļiem. Agents building context for agents. Atmiņas hierarhijas garīgais modelis Garīgais modelis, kas padarīja visu klikšķi: izturēties pret kontekstu kā RAM, nevis atkritumu atvilktni. Layer What It Holds Disk Full codebase, raw ABIs, complete schemas RAM Precompiled skills — task-specific reference files Registers The current prompt and immediate context Diskā Pilna koda bāze, neapstrādāti ABI, pilnīgas shēmas Ramāns Iepriekš sagatavotās prasmes — uzdevuma specifiskie atsauces faili Reģistrācijas Pašreizējais ātrais un tūlītējais konteksts Jūs neuzlādējat visu atmiņā. Jūs ielādējat to, kas jums nepieciešams pašreizējam uzdevumam. Mans prasmju speciālists ir kompilators, kas pārvērš disku RAM. Bez tā, es esmu atpakaļ pie pildīšanas kontekstu un cerot uz labāko. Kā izskatās iepriekš sagatavota prasme Šeit ir modelis manu prasmju speciālists rada: # MorphoVault Reference > Use when implementing vault deposit/withdraw flows. ## Terminology - **shares**: Vault shares representing proportional ownership - **assets**: The underlying token being deposited ## Key Functions ### deposit(uint256 assets, address receiver) → uint256 shares Deposits assets and mints shares to receiver. See: protocols/morpho/abis/MetaMorpho.json ### withdraw(uint256 assets, address receiver, address owner) → uint256 shares Burns shares and sends assets to receiver. See: protocols/morpho/abis/MetaMorpho.json ## Events ### Deposit(address indexed sender, uint256 assets, uint256 shares) ### Withdraw(address indexed sender, uint256 assets, uint256 shares) ## Related Hooks - useVaultDeposit: src/hooks/blockchain/useVaultDeposit.ts - useVaultBalance: src/hooks/ponder/useVaultBalance.ts Īss. skenējams. norādes uz avota failiem. domēna termini definēti. skaidras sadaļas. Bruto Morpho ABI ir 2000+ līnijas. Šī atsauce ir 30 līnijas un satur visu, kas aģentam ir nepieciešams, lai īstenotu noguldījumu plūsmu. Māksla aiz aizkaru Mana prasmju radītājs pats par sevi ir prasme, kuru esmu izveidojis, iterējot, testējot un domājot arhitektūrā. Katrai prasmei mūsu sistēmā ir: Skaidras atbildības - ko šis aģents pieder? Eksplicitās zināšanu faili – kāds iepriekš sagatavots konteksts ir vajadzīgs? Definēti handoff punkti - kad tas izsauc citus aģentus? Pārbaudes kritēriji - kā mēs zinām, ka tas ir izdarīts? Tas nav inženierisks, tas ir inženierisks. Izplatīšanas ieskats ir pareizs - prasmes saspiež attālumu starp lietotāju un vērtību. bet kādam joprojām ir jāizveido labi. Atnākšana uz augšu 2. daļā Tālāk es aprakstīšu organizatorisko sasniegumu, kas padarīja pārvaldāmus vairāk nekā 70 aģentus: atšķirība starp (personas, ar kurām jūs runājat) un (Darba ņēmēji, kurus jūs izsūtāt) skills agents Izrādās, ka tikai ~10 bija nepieciešams, lai būtu sarunu. pārējais vienkārši bija nepieciešams, lai būtu atklājams. Šī ir 1. daļa no "Mācības no 100+ aģentu Swarm izveides tīmeklī3." Sekojiet 2. daļai par aģentu organizāciju vai savienojiet, ja veidojat līdzīgas sistēmas.
