Johdanto: Agentti, jonka kaikki haluavat, ilman hypetystä
Koodausagenteissa on se ongelma, että useimmat niistä yrittävät olla pomosi, apupilottisi ja terapeuttiesi – ja sitten unohtavat vain kirjoittaa koodin. Toimintamalli on tämä: lisää tusina vektoritietokantaa, ripottele päälle orkestroinnin taikapölyä, kiinnitä selain ja that's it. Se toimii hyvin demossa. Mutta se hajoaa heti, kun pyydät sitä korjaamaan epävakaan integraatiotestin perjantaina klo 16.52.
Kevyen koodausagentin rakentaminen 4.5:llä on – yllätys – itse asiassa suoraviivaista, jos lakkaat tavoittelemasta universaalin ohjelmisto-butlerin unelmaa ja rakennat vain työkalun, joka lukee koodia, suunnittelee, muokkaa, suorittaa ja toistaa. Ei saarnaa siitä, että "tekoäly korvaa kehittäjät". Ei -putkia. Vain tiukka silmukka, joka tekee ilmeiset asiat hyvin.
Tämä on ohje siitä, miten siihen päästään ilman kokonaisen tekoälytoimintojen osaston vetämistä mukaan. Käytämme 4.5:tä aivoina, tiedostojärjestelmää ja shelliä käsinä ja pientä muistia lyhytaikaiseen tarkennukseen. Siinä kaikki. Kevyt tarkoittaa, että voit ymmärtää sen yhdeltä istumalta, suorittaa sen paikallisesti ja luottaa siihen, koska jokainen vaihe on tarkastettavissa. Mikä, jos olet käyttänyt mitään tällä alalla viime aikoina, on melkein kumouksellista.
Miksi 4.5 toimii minimaalisessa agentissa
4.5:llä on temperamentti, jota todella haluat koodille: huolellinen ohjeiden noudattamisessa, yllättävän hyvä lukemaan diff:iä, eikä liian innokas hallusinoimaan kehyksiä, joita et pyytänyt. Malli on pätevä vaiheittaisessa päättelyssä ilman, että se vaatii kokonaista kehotenovellia. Tämä yhdistelmä – päättely plus hillintä – tekee siitä ihanteellisen koodausagenttisilmukkaan:
- Tarkkaile: Lue nykyiset tiedostot, virhelokit ja testit.
- Suunnittele: Ehdota konkreettisia muutoksia perusteluineen.
- Toimi: Paikkaa tiedostoja, suorita komentoja.
- Pohdi: Arvioi tulos, iteroida tai lopeta.
Voit kiinnittää tämän mihin tahansa repoon ja saada arvoa iltapäivän aikana. Temppu on vastustaa kiusausta muuttaa sitä "tekoälyalustaksi". Jos pidät agentin kevyenä, 4.5 tekee raskaan työn pääsemättä tielle.
Kevyt arkkitehtuuri: Viisi osaa, ei draamaa
Tässä on koko pino, jonka tarvitset:
- Ydinsilmukka: Yksi prosessi, joka kutsuu 4.5:tä ja tulkitsee sen työkalukäyttöviestejä.
- Työkalut: Pieni joukko – read_file, write_file, list_dir, run_tests (tai run_cmd), search_code.
- Kontekstin rakentaja: Kokoa lyhyt, ytimekäs kehote repo-metatiedoilla ja viimeaikaisilla diff:illä.
- Lyhytaikainen muisti: Liukuva keskusteluikkuna plus eksplisiittinen lehtiö suunnitelmaa ja rajoituksia varten.
- Suojakaiteet: Tunnus, aika ja tiedostojen kirjoitusrajat; kuiva-ajotila; ja palautusvedokset.
Siinä kaikki. Voit suorittaa sen ilman päätä terminaalissa tai kääriä sen minimaaliseen käyttöliittymään, jos on pakko. Syy, miksi tämä toimii, on tylsä: jokainen toiminto havaitaan ja voidaan todentaa. Agentti ehdottaa muutosta, näyttää diff:in, suorittaa testit, lukee tulosteen ja joko jatkaa tai lopettaa. Keskellä ei ole mitään mysteeriä.
Kuinka rakentaa agentti (menettämättä juonta)
Vaihe 1: Määritä sopimus – kehote ja työkalut
Agenttisi on yhtä hyvä kuin sen sopimus mallin kanssa. Pidä järjestelmäkehote lyhyenä, tiukkana ja hellittämättömän käytännöllisenä.
Järjestelmäkehote, tislattuna:
- Olet koodausagentti. Sinun tehtäväsi on tehdä pieniä, oikeita muutoksia repoon käyttäjän tehtävän tyydyttämiseksi.
- Ajattele ääneen piilotetussa lehtiössä; paljasta käyttäjälle vain suunnitelmat ja diff:it.
- Suosi minimaalisia diff:ejä, toimivia testejä ja asteittaista edistystä.
- Kun olet epävarma, ehdota kokeilua ja suorita se.
- Älä koskaan keksi tiedostoja tai komentoja – luettele ja lue ennen kuin muokkaat.
Työkalukaavio (älä yliajattele sitä):
- read_file(path, offset?, length?)
- write_file(path, content, create_if_missing=false)
- run_cmd(command, timeout=60, cwd=repo_root)
- search_code(query, path=repo_root, max_results=50)
Valinnaisia mukavuuksia: git_diff ja git_revert(sha), jos haluat hands-free-palautukset. Voit ohittaa vektoritietokannan; useimmat hyödylliset tehtävät riippuvat kourallisesta tiedostoja työmuistissa sekä nopeasta hausta.
Vaihe 2: Pidä konteksti kevyenä
Kontekstin täyttäminen on agenttisuunnittelun cargo-kultti. Älä dumppaa koko monorepoasi kehotteeseen. Sen sijaan:
- Repo-yhteenveto: Yhden kappaleen README-tiivistelmä; sisääntulopisteet; testin suorittimen komento.
- Aktiiviset tiedostot: Vain tiedostot, joita agentti aikoo koskettaa – lue ne tarvittaessa paloina.
- Tehtävä: Käyttäjän tavoite, ytimekkäästi ilmaistuna: "Korjaa epäonnistunut testi FooTest.test_bar tiedostossa tests/foo_test.py."
- Rajoitukset: Suoritusajan rajat, tiedostojen kirjoitus sallittujen luettelo, tyylisäännöt ja semanttisen versionoinnin odotukset tarvittaessa.
- Viimeaikainen historia: Kaksi viimeistä diff:iä ja niiden testitulokset. Ei mitään muuta.
4.5 pystyy täysin hakemaan lisää kontekstia, kun se tarvitsee sitä search_code- ja read_file-toimintojen kautta. Anna sille kartta, älä aluetta.
Vaihe 3: Silmukka (Tarkkaile → Suunnittele → Toimi → Pohdi)
- Tarkkaile: Aloita luettelemalla hakemistot, lukemalla epäonnistunut testi, testattava koodi ja virheloki. Pyydä a tiivistämään virheen oireet kahdessa tai kolmessa kohdassa.
- Suunnittele: Pyydä a ehdottamaan suunnitelmaa, jossa on:
- Hypoteesi epäonnistumisesta
- Tarkastettavat tai muokattavat tiedostot
- Pienimmät diff:it, joita yrittää
- Testikomento validoitavaksi
- Toimi: Käytä ehdotettu diff write_file-toiminnon kautta. Näytä diff sanasta sanaan. Suorita testit.
- Pohdi: Syötä stdout/stderr takaisin. Kysy lta: jatketaanko, palautetaanko vai lopetetaanko? Jos suunnitelma muuttuu, vaadi yhden lauseen perustelu, jossa viitataan todelliseen tulosteeseen.
- Poistu: Lopeta, kun testit läpäisevät, tai N iteraation jälkeen, kumpi tulee ensin.
Tämä on ylistettyä pariohjelmointia, jossa pidät parin rehellisenä.
Vaihe 4: Suojakaiteet, jotka säästävät viikonloppusi
- Kirjoitusten sallittujen luettelo: Salli kirjoitukset vain src/-, lib/- tai nimenomaisesti hyväksytyissä poluissa.
- Diff-kokoraja: Rajoita muokkaukset 200–500 riviin per vaihe. Jos isompi, jaa alavaiheisiin.
- Komento sallittujen luettelo: testin suorittimet, linters ja muutama dev-skripti. Kiellä verkko. Haluat toistettavuuden, et villin lännen curlia.
- Aikakatkaisu ja uudelleenyritykset: Lyhyet aikakatkaisut, yksi uudelleenyritys enintään – loputtomat uudelleensuoritussilmukat ovat paikkoja, joissa agentit kuolevat.
- Kuiva-ajotila: Tulosta ehdotetut diff:it, mutta älä kirjoita. Erinomainen koodin tarkastukseen.
4.5 pitää kiinni säännöistä, jos teet niistä nimenomaisia. Jos et, älä ylläty, kun se yrittää "auttaa" järjestämällä koko reposi uudelleen jonkin vuoden 2017 blogikirjoituksen mukaisesti.
Vaihe 5: Muisti, joka on todella hyödyllinen
Lyhytaikainen muisti ratkaisee 80 % ongelmasta. Pidä:
- Lehtiö nykyistä hypoteesia ja suunnitelmaa varten.
- Luettelo tällä istunnolla kosketetuista tiedostoista.
- Kaksi viimeistä komennon tulostetta.
Se riittää, jotta 4.5 voi päätellä johdonmukaisesti. Pitkäaikainen muisti – tehtävälokit, upotukset – voivat olla hyödyllisiä toistuville koodikannoille, mutta pidä sitä valinnaisena makeutusaineena. Jos agenttisi ei voi korjata testiä ilman 500 Mt:n vektorihakemistoa, se ei ole agentti – se on riippuvuus.
Minimaalinen toteutusluonnos
Pseudokooditermein voit toteuttaa tämän agentin parissa sadassa rivissä:
- initialize: lataa repo-metatiedot, rajoitukset ja malliasiakas
- observe: lue epäonnistuneet testit, tiedostot, lokit
- plan = model.propose_plan(context)
- while not done and steps < MAX:
- diff = model.propose_patch(plan)
- show(diff); maybe approve
- out = run_cmd(plan.test_cmd)
- reflect = model.evaluate(out)
- if reflect == pass: done = true
- else if reflect == rollback: git_revert(last_commit)
- else: plan = model.revise_plan(out)
Huomaat puuttuvat osat: ei agentteja, jotka hallitsevat agentteja, ei "edustajia", ei erillistä "suunnittelijamallia" ja "toteuttajamallia". 4.5 voi tehdä molemmat työt hyvin, jos et sabotoida sitä -laitteella.
Kehottaminen, joka ei yritä liikaa
Huonot kehotteet yrittävät olla älykkäitä. Hyvät kehotteet ovat tylsiä ja tarkkoja. Tässä on järkevä runko ydinkäsikirjoituslohkollesi:
- Tavoite: Ilmoita tarkka koodaustehtävä ja onnistumiskriteerit.
- Konteksti: Projektirakenne, sisääntulopisteet ja testikomento.
- Rajoitukset: Kirjoitusten sallittujen luettelo, diff-kokoraja, ei verkkoa.
- Tyylimieltymykset: Kieliversio, muotoilija, linter-säännöt.
- Prosessi: Tarkkaile → Suunnittele → Toimi → Pohdi; näytä diff:it; suorita testit; iteroida enintään N vaihetta; lopeta, kun testit läpäisevät.
4.5 ei tällä rakenteella tarvitse 100 rivin roolileikkiskenaariota. Se vain toimii.
Käytännön esimerkki: Korjaa epäonnistunut testi
Oletetaan, että testi epäonnistuu tiedostossa tests/time_test.py, koska parse_time("09:00") palauttaa 5400 32400 sijaan. Agentin silmukan pitäisi näyttää tältä:
- Tarkkaile: Lue time.py ja time_test.py; suorita pytest -k parse_time.
- Suunnittele: Hypoteesi – sekuntien vs minuuttien matematiikkavirhe; ehdota parse_time-muokkausta; lisää yksikköreunatesti.
- Toimi: Paikkaa parse_time, lisää testi johtaville nollatunneille; suorita testit.
- Pohdi: Jos testit epäonnistuvat edelleen, lue virhe, säädä matematiikkaa tai regexiä, suorita uudelleen.
Pienin onnistunut paikkaus voi olla kahden rivin muutos. Se on pointti. Pienet muokkaukset, nopeat syklit, todellinen edistys.
Missä kevyt voittaa täydellisen varustuksen
- Latenssi: Yksi malli, yksi silmukka, ei orkestroinnin yläpuolta.
- Läpinäkyvyys: Jokainen vaihe on auditoitavissa. Voit verrata sitä, voit palauttaa sen, voit suorittaa sen uudelleen.
- Hallinta: Suojakaiteet pitävät vahingon paikallisena. Agentti ei voi harhailla infrastruktuuriisi.
- Kustannukset: Vähemmän puheluita, vähemmän kontekstia, ennustettavat tunnukset.
- UX: Sinä ymmärrät sen. Tiimisi ymmärtävät sen. Tulevaisuuden itsesi ei vihaa sinua.
Ja kompromissit:
- Laajuus: Kevyt koodausagentti ei refaktoroi viiden kielen monorepoasi yhdellä kertaa. Eikä sen pitäisikään.
- Aloitteellisuus: Se ei keksi usean viikon etenemissuunnitelmia. Sinä annat sille tehtäviä.
- Tilan pysyvyys: Ilman suurta muistikerrosta se unohtaa kaukaisen historian suunnittelun perusteella. Se on ominaisuus, kunnes se on vika.
4.5:n makea paikka koodausagenteille
4.5 loistaa:
- Diff:ien ja lokien lukemisessa ja päättelyssä.
- Johdonmukaisten, minimaalisten koodimuutosten tuottamisessa.
- Rajoitusten noudattamisessa ja epävarmuudesta kertomisessa.
Se on vähemmän hyvä:
- API-käyttäytymisen arvaamisessa, jota se ei voi lukea.
- Raskaassa työkalujen koreografiassa (ei tarvita tässä).
- Pitkissä monen tiedoston refaktoroinneissa ilman ihmisen ohjaamia vaiheita.
Viimeinen kohta on tärkeä. Paras tapa saada vahvoja tuloksia ei ole tehdä agentista suurempi – se on tehdä tehtävästä pienempi. Käytä aivojasi rajaamiseen ja 4.5:tä toteutukseen tässä laajuudessa.
Sana IDE-integraatiosta
Vastusta kiusausta leipoa tätä suoraan IDE-ruutuun viidenkymmenen vaihteen kanssa. Terminaalipohjainen silmukka tavallisilla tekstin diff:eillä on helpompi luottaa ja debugata. Jos haluat editorimakeutusta, pidä se tyhmänä:
- Komentoja silmukan käynnistämiseen/pysäyttämiseen.
- Näytä diff:it jaetussa näkymässä.
- Hyväksyntäkehote kirjoituksille (valinnainen, mutta viisas).
Voit integroida myöhemmin. Ensinnäkin, saa sen toimimaan.
Sider.AI, säästeliäästi käytettynä, todella auttaa Jos haluat käytännöllisen ympäristön tämän tyyppisen silmukan suorittamiseen ilman rakennustelineiden keksimistä uudelleen, Sider.AI todella toimii – ainakin kun käytät sitä siihen, missä se on hyvä. Se pitää keskustelun ja diff:it siistinä, antaa sinun suorittaa komentoja eikä pakota sinua johonkin mahtipontiseen "autonomiseen agenttikehykseen". Temppu on pitää omat säännöt: lyhyet kehotteet, tiukat silmukat, näkyvät diff:it. väistää tieltä, mikä on harvinaisempaa kuin sen pitäisi olla. Yleisiä sudenkuoppia (ja kuinka välttää typerältä näyttämistä)
- Ylitäytetty konteksti: Jos kehotteesi kuulostaa lunnasvaatimukselta, teet sen väärin. Hae tiedostoja pyynnöstä.
- Ennenaikainen refaktorointi: Agentti ehdottaa moduulien uudelleenjärjestämistä? Saa sen läpäisemään testit ensin. Refaktoroi myöhemmin.
- Hallusinoituneet tiedostot: Vaadi list_dir ja read_file ennen kuin kirjoitat write_file-toiminnolla uuteen polkuun.
- Loputtomat uudelleensuoritussilmukat: Rajoita vaiheet. Vaadi perustelu jokaiselle uudelle hypoteesille.
- Yksi jättimäinen diff: Jaa muutokset. Pienemmät diff:it epäonnistuvat nopeammin ja niitä on helpompi päätellä.
Turvallisuus ilman vainoharhaisuutta
- Paikallinen suoritus: Suorita hiekkalaatikoidussa hakemistossa. Ei verkkoa oletuksena.
- Riippuvuuksien eristäminen: Käytä paikallista venv:iä tai säiliötä. Kiinnitä versiot.
- Salaisuudet: Agentti ei tarvitse niitä. Jos komento vaatii tunnuksen, lopeta ja kysy.
- Auditointi: Säilytä jokainen suunnitelma, diff ja komento lokissa.
Kuinka tietää, että se toimii
- Läpimenoaika lyhenee: Vikakorjaukset, jotka veivät tunnin, vievät nyt kymmenen minuuttia.
- Vähemmän näppäilyvirheitä: Diff:it pienenevät, testit vihertyvät.
- Luotat siihen: Lakkaat leijumasta jokaisen toiminnon yläpuolella, koska se ei ole polttanut sinua.
- Tiimiläiset käyttävät sitä: Onnistumisen määritelmä on, että muut ottavat sen käyttöön ilman kokousta.
Skaalaaminen ylös, varovasti
Jos sinun on todella skaalattava, tee se kurinalaisesti:
- Rinnakkaiset alitehtävät, ei rinnakkaiset aivot: Jaa työ, suorita useita kevyitä silmukoita erillisissä hakemistoissa ja yhdistä, kun vihreää.
- Episodinen muisti, ei aivovuoto: Tallenna onnistuneet paikkaukset ja oireiden ja korjausten väliset kartoitukset. Nouda kirurgisesti.
- Määräaikaiset "suuremmat" kierrokset: Varaa ihmisen ohjaama istunto refaktorointeihin; agentti avustaa, ei johda.
Minimaalinen viitetoteutus (luonnos)
Python-tyyppinen pseudokoodi liikkeelle pääsemiseksi:
- def init(self, repo_root, model):
- self.history = [] # kaksi viimeistä diff:iä ja testitulostetta
- "repo": summarize_repo(self.root),
- "constraints": {"write_whitelist": ["src/", "tests/"], "max_diff_lines": 300, "no_network": True},
- "history": self.history[-2:],
- plan = self.model("propose_plan", self.context(task))
- diff = self.model("propose_patch", {"plan": plan})
- out = run_cmd(plan.test_cmd)
- eval = self.model("evaluate", {"output": out, "plan": plan})
- self.history.append({"diff": diff, "out": tail(out)})
Ihmisen kokoinen lopetus
Teollisuus lupaa jatkuvasti autonomisia kehittäjäagentteja. Mitä me todella tarvitsemme, on rehellinen avustaja, joka lukee, suunnittelee, muokkaa, suorittaa ja lopettaa. 4.5 on hyvä siinä, kunhan et hauta sitä kehysten alle, jotka ovat olemassa lähinnä oikeuttaakseen itsensä. Kevyt ei ole kompromissi – se on pointti. Rakenna silmukka, lisää suojakaiteet ja anna työkalun tehdä se yksi asia, jonka työkalut ovat aina tehneet, kun pidät ne yksinkertaisina: pienennä työtä.
Johtopäätös: Tylsä pikakuvake, joka voittaa
Tässä on tarkistuslistasi kevyelle koodausagentille 4.5:llä:
- Yksi silmukka, yksi malli, pienet työkalut.
- Tiukka konteksti: tehtävä, muutama tiedosto, viimeiset tulosteet.
- Minimaaliset diff:it, tiheät testit, kovat rajat.
- Paikallinen, hiekkalaatikkosuoritus; ei verkkoa.
- Valinnainen editorimakeutus; ei koskaan pakollinen.
Jos siristät silmiäsi, se näyttää epäilyttävästi hyvältä ohjelmistokehitykseltä, vain nopeammin. Ja se on punchline. Älykkäin asia, jonka voit tehdä täällä, ei ole jahdata "autonomiaa" – se on kodifioida kurinalaisuutta. Mitä vähemmän pyydät agentilta, sitä enemmän saat.
UKK
K1: Kuinka aloitan kevyen koodausagentin rakentamisen 4.5:llä?
Määritä pieni työkalusarja (lue, kirjoita, hae, suorita), kirjoita tiukka järjestelmäkehote ja toteuta Tarkkaile → Suunnittele → Toimi → Pohdi -silmukka. Pidä konteksti pienenä ja syötä todellisia lokeja ja diff:ejä – 4.5 toimii parhaiten, kun tehtävä on kapea ja palaute on konkreettista.
K2: Tarvitsenko vektoritietokantaa tai muistikerrosta 4.5 -koodausagentille?
Ei. Useimmissa tehtävissä lyhytaikainen muisti plus search_code riittää. Lisää pitkäaikaista muistia vain, jos käytät toistuvasti samaa repoa ja voit todistaa, että se säästää tunnuksia tekemättä agentista tyhmempää.
K3: Mitkä suojakaiteet ovat välttämättömiä 4.5 -koodausagentille?
Salli kirjoitettavat polut sallittujen luetteloon, rajoita diff-koot, rajoita komennot ja kirjaa jokainen toiminto. Nämä yksinkertaiset rajat pitävät agentin ennustettavana ja tekevät palautuksista tylsiä – hyvällä tavalla.
K4: Voiko kevyt agentti käsitellä usean tiedoston refaktorointeja?
Kyllä, jos jaat työn pieniin vaiheisiin ja pidät silmukan tiukkana. 4.5 voi hallita refaktorointeja, mutta sinä ohjaat laajuutta; muuten saat yhden jättimäisen, hauraan diff:in, jota et halua tarkistaa.
K5: Missä Sider.AI sopii 4.5 -koodausagentin kanssa?
Sider.AI on hyödyllinen siistinä työtilana: keskustelut, diff:it ja komennot yhdessä paikassa pakottamatta raskasta agenttikehystä. Käytä sitä silmukan suorittamiseen, älä sen keksimiseen uudelleen. 
