Цыкл кадавання з двух агентаў без інтэрфейсу на OpenCode і Ollama
Як раздзяліць планаванне і рэв’ю паміж двума агентамі ў OpenCode з Ollama: дазволы, навыкі, правілы маскіравання, скрыншоты і каміты толькі ад чалавека.
Крыніцы: Ollama on Steroids with OpenCode: A Headless Multi Agent Coding Workflow
Большасць дэманаў AI-кодавання захопляюць да таго моменту, калі хтось задае банальны інжынерны пытанне: што саме адбылася, хто гэта пераглядаў, якія тэсты былі запусцаны, і чы можна ўсё гэта павтарыць завтра?
Указаны выконвальны лянцюг прагчыць на гэтыя пытанні. Уместа вікна чату, якое час ад часу стварае хорашы патч, гэты лянцюг розглядае AI-кодаванне як маленькі інжынерны цыкл:
- адны агент плануе і рэалізуе
- другі агент пераглядае і затварае процэс
- кожны запіт атрымвае свой сабскладчык папакі сесіі
- кожны запуск залішае след логаў і доказ таго, што тэсты былі запусцаны
- чалавек, а не агент, вырашае, калі код будзе зафіксаваны або выкананы
- прызначыцкія запыты і выходны матэрыял сесіі застаюцца прыватнымі
Разпад працы: MiniMax разрабатвае планы і пісае код, GLM адзначае і затварае іх, OpenCode керуе працэсамі, а Ollama направляе запіты да модэляў. Рэзультат — гэта не чырагае самастоятэльнае функцыонаванне. Гэта повтароўны цыкл, які стварае планы, адзначэнні, тэсты, скрыншоты, перакананні ў безпеці і здзейснюе зберэжэнні, якімі керуе чалавек.
Што стосуецца інструментаў, OpenCode адказвае некінетычным opencode run, можлівасцю выбору агентаў, выбору модэля, флагам --dir і можлівасцю прыўязкі запуску да безгалавай інстанцыі opencode serve. Сесіі можна экспортаваць за дапамогою --sanitize. Ollama дастаёна документацыю па інтэграцыі з OpenCode праз ollama launch opencode, а OpenCode чытае настройкі праекта, агентаў, правыя, навыкі і серверы MCP.
У зразку настройкаў назвы модэляў Ollama Cloud адзначаюцца як minimax-m3:cloud і glm-5.1:cloud; MiniMax прызначаны для програмавання і вікання завдань агента, а GLM апісваецца як флагманскі модэль для інжынернай працы агентаў. Сама схема не залежыць ад гэтых конкрэтных модэляў. Вядзіце назвы модэляў як прыклады і пераканайцеся ў потычным каталагу Ollama пры ўсуненні іх. Чыстыя запіты, выходныя даны сесіі, локальныя шляхі, ключы і скрыншоты з аднаго праекту тут не дзеляцца, толькі метод.
Паставіце канец таму, што програмаванне з AI спрыяваецца як аднам чатам
Адзін агент для програмавання мае тую ж слабасць, як і самастоятэльны распрацоўшчык пад тым пяцьбою: ён можа пераканаць сябе, што ўжо завершыў працу. Паўтарны запіт да таго ж модэля гэта не выправляе. Працэс жа так:
Prompt -> Plan -> Review -> Implement -> Test -> Review -> Fix -> Signoff -> Human commit
Макет выглядае так:
control-workspace/
AGENTS.md
opencode.json
.opencode/
agents/
minimax-builder.md
glm-reviewer.md
skills/
opencode-ollama-agent-guardrails/
SKILL.md
agent-sessions/
project-slug/
promptNN/
PROMPTNN_CODER.md
PROMPTNN_REVIEWER.md
PROMPTNN_PLAN.md
PROMPTNN_PLAN_REVIEW.md
PROMPTNN_IMPLEMENTATION.md
PROMPTNN_TEST_RESULTS.md
PROMPTNN_IMPLEMENTATION_REVIEW.md
PROMPTNN_SIGNOFF.md
redacted logs
screenshot references
product-repo/
Чаму пачынац з рабочага прастора керування родзіцам? Лячна ў самай базе дадзеных продукту агент можа не магчымаць бачыць файлы запыткаў, файлы сесій, спяльваныя правілы чы ўсю сістэму працы. Абсалютныя шляхі, у свою чаргу, можу включаць дэталі, спецыфічныя для конкрэтнага апарата, у логі. Таму існуе правіло: запускайце OpenCode з родзіцы, вжывайце вялікія шляхі, зберагайце змяны ў продукцыі ў базе дадзеных продукту, а рэзультаты сесій — за ёю. Гэта звучыць проста, але самэ гэта і робіць метод эфектывным.
Два агента з разнымі завадамі
Ключовы выбор у дызайне — не сама модэль, а раздэленне завад.
Стваральнік
minimax-builder можа планаваць, рэдагаваць код, запускаць каманды і пісаць прыметкі да рэалізацыі. Яго абавязкі — чытаць запіт і AGENTS.md, ствараць план, прыменяць адзінакі рэвізора, рэалізаваць толькі затверджаны спектр задач, запускаць перакананне, фіксаваць, што змянілася і што не запрацавало, а таксама зупініцца на чаканне падтверджэння чалавека для будзь-якага коміту. Забраняецца: адкомітаванне, пушынг, рэбейсінг, форс-пушынг, пераход да наступнага запіту, слабэчэнне тэстаў і рэдагаванне файлаў, прызначаных для рэвізора.
Рэвізор
glm-reviewer за сваёй структурой ёсць строгі. Яго чарт адзінакоў: чы план падходзіць да запіту, чы рэалізацыя застаўся ў межах спектру задач, чы тэсты маюць значэнне, чы файлы, створаныя, былі зменены намерова, чы скрыншоты браузера падтрымліваюць тверджэння, чы апрацоўка секрэтных дадзеных адбываецца правільна, і чы minimax-builder перацінівае сваія рэзультаты?
Яго слоўнік рашэнняў застаецца дужа маленькім:
APPROVED
CHANGES_REQUESTED
SIGNED_OFF
NOT_SIGNED_OFF
Маленькій лексыкантнай базе не застаткі для творчасці. Фраза «У цаласці выглядае добра» не ўважаецца затверджэнням.
Канфігурацыя OpenCode
Ось як выглядае канфігурацыя:
{
"$schema": "https://opencode.ai/config.json",
"model": "ollama/minimax-m3:cloud",
"default_agent": "minimax-builder",
"share": "disabled",
"instructions": ["AGENTS.md"],
"enabled_providers": ["ollama"],
"permission": {
"read": {
"*": "allow",
"*.env": "deny",
"*.env.*": "deny",
"*.env.example": "allow"
},
"glob": "allow",
"grep": "allow",
"webfetch": "ask",
"websearch": "ask",
"external_directory": "deny",
"skill": {
"*": "allow"
}
},
"agent": {
"minimax-builder": {
"description": "Main planning and implementation agent.",
"mode": "primary",
"model": "ollama/minimax-m3:cloud",
"temperature": 0.2,
"permission": {
"edit": {
"*": "deny",
"product-repo/**": "allow",
"agent-sessions/project-slug/**": "allow"
},
"bash": {
"*": "ask",
"cd product-repo && *": "ask",
"git status *": "allow",
"git diff *": "allow",
"git log *": "allow",
"git commit *": "deny",
"git push *": "deny",
"git rebase *": "deny",
"rm *": "deny"
}
}
},
"glm-reviewer": {
"description": "Strict reviewer. Must not edit product code.",
"mode": "primary",
"model": "ollama/glm-5.1:cloud",
"temperature": 0.1,
"permission": {
"edit": {
"*": "deny",
"agent-sessions/project-slug/**": "allow"
},
"bash": {
"*": "ask",
"git status *": "allow",
"git diff *": "allow",
"git log *": "allow",
"grep *": "allow",
"rg *": "allow",
"git commit *": "deny",
"git push *": "deny",
"git rebase *": "deny",
"rm *": "deny"
},
"task": "deny"
}
}
}
}
Два моменты заслуговуюць на увагу. Аднароджэнне даных ўвыключана за замовчаннем, і адтуды, што у OpenCode ёсць опцыя share, яе настройкай на "disabled" можна закрыць адпаведны шлях, каб запобiec віпадковым вылівам. Рэвізор таксама не мае шырокіх прав на рэдагаванне: ён можа запісваць файлы з рэвізіямі і падтверджэннямі у папку сесіі, але не павінен зменяць код, які вікорыстоўваецца у працэсе. OpenCode мае дзеяльныя правіла дазволаў для edit, bash, read, grep, glob, skill і іншых функцыяй, таму сама настройка должна контролаваць алгорытм работы.
Настроюйце шляхі для вашай сабе рэпазітарыі. Прынцып застаецца незменным:
builder can edit product code;
reviewer can write review notes;
neither agent can commit or push;
external directories are denied;
dangerous shell commands ask or deny.
Навыкі як перэносны захоўнік
Найбольш перадаўальны элемент — не толькі файл налашчэння. Гэта сам навык. Навыкі OpenCode ўсё можна перадаць за дапамогай відзначэнняў SKILL.md, якія зберагаюцца ў папках навыкаў праекта або глобальна. Стандартная локацыя на рэвэлі праекта ёсць:
.opencode/skills/<skill-name>/SKILL.md
Існуюць таксама шляхіі развіцці навыкаў, сумесныя з Claude і з агентамі, але для гэтага прадзеяння разумна будзе застацца простым. Пастаўце навык-захамленні тут:
.opencode/
skills/
opencode-ollama-agent-guardrails/
SKILL.md
Кожны файл SKILL.md павінен мець фронтматэр, які прынеймна містыць name і description. Імя павінна быць напісана малымі літэрамі, складацца з роздзелачоў, і адпавядаць назве папкі. Навык-захоўнік можа задаць агентам такія правіла:
- Do not publish raw prompts.
- Do not publish raw session logs.
- Do not use absolute local paths.
- Do not edit outside the approved product directory.
- Do not claim success without test output.
- Do not weaken tests to make validation pass.
- Do not commit, push, rebase, or force-push.
- Store review notes separately from production code.
- Treat screenshots as sensitive evidence.
- Stop for human approval after signoff.
Правіла выглядаюць простымі, але яны запобегаюць справжнім памылкам. Калі яны знаходзяцца толькі ў файле AGENTS.md адного рэпазітарыю, яны застаюцца там. Калі яны упакованы як навык, яны супроводжваюць вас усюды.
Рэжым без галавы дапамагае павторуванню
Інтэрактыўнае програмаванне падходзіць для дакладнага аналізу. Рэжым без галавы лепшы для павторування запускаў. Фрагмент коду, які вікорыстоўваецца для будавання, выглядае так:
opencode run \
--model ollama/minimax-m3:cloud \
--agent minimax-builder \
--dir . \
"$(cat agent-sessions/project-slug/promptNN/PROMPTNN_CODER.md)"
І рэзультат аўдыту:
opencode run \
--model ollama/glm-5.1:cloud \
--agent glm-reviewer \
--dir . \
"$(cat agent-sessions/project-slug/promptNN/PROMPTNN_REVIEWER.md)"
Для болейшых сэтапаў з серверамі MCP, спачатку запускіце локальны сервер OpenCode, а пазней прыўяжыце да яго наступныя запускі, тады не будзе павтаральных запускаў з нуля:
opencode serve --hostname 127.0.0.1 --port 4096
opencode run \
--attach http://localhost:4096 \
--agent minimax-builder \
--dir . \
"$(cat agent-sessions/project-slug/promptNN/PROMPTNN_CODER.md)"
З’яўляйце сервер на 127.0.0.1. Кожны, хто выкладае яго на іншы камп’ютар, павінен задаць значэння OPENCODE_SERVER_PASSWORD і запускаты яго як справжню службу для розработы, адколькі інструкцыі для CLI опісваюць метод HTTP basic auth праз гэтую зменную. Мадэль не стала розумнейшай; проста стало важкая ўвесты ёе в галюцынацію.
Зберагаеце запіты і рэзультаты выходу, каб не выкрываць іх
Зберагачыце файлы запітаў і рэзультаты сесій локальна — гэта корыстна для дыбаггінгу поведзення агента. Адпрацоўванне неапранутых запітоў чы неапранутых выходных дадзеных не ў тым. Логі агентаў могу містыць локальныя шляхі, запіты шэлу, назвы галузей, внутрашніе заведамы, секрэты рэалізацыі, назвы сераўнікаў, шляхі до скрыншотаў, ненужныя аутэнтыфікацыйныя даны і формулюванні запітоў, якія вы хацелі б вікорыстаць толькі прыватна.
Правіла: зберагаць усё локальнаа і публікуваць толькі спрасавленыя аптыванні і шаблоны, якія можна вікорыстоўваць знову. Команда opencode export [sessionID] з параметрам --sanitize у OpenCode дапамагае пад час внутранняй перагляд, але яе трэба спрыяваць як першы крок, а не як кнопку публікацыі. Усё, што будзе публічным, павінна працэсаваць другі перагляд з метой спрасавлення.
Для публічнага рэпазітарыю запісваць следзючыя элементы:
AGENTS.md
opencode.json
.opencode/agents/*.md
.opencode/skills/*/SKILL.md
templates/*.md
scripts/*.zsh
scripts/redact_sessions.py
docs/publication-redaction-checklist.md
і ігнаруйце гэтыя:
agent-sessions/**
screenshots/**
.env
project.local.env
*.raw.log
*.events.jsonl
opencode-session-*.json
Рэзультатам ёсць аднародныя атласы, якія можна распаўляць, не ператвараючы хранілніку ў істочнік выцекання дадзенняў.
Дзе дапамаглі інструменты MCP
Мадэлі ёсць толькі частка сістэмы, а інтэрфейс інструментаў мае вельмі важлівую ролю. Корыстны спосаб разумець MCP-інструменты і вбудованыя інструменты — адносіць іх да спецыялізаваных «чувстваў» і «рабоў»:
| Workflow stage | Useful tool or MCP category | What it helped with |
| ---------------- | ------------------------------------------------------- | -------------------------------------------------- |
| Planning | repo search, docs lookup, issue/context reader | understand current architecture before changing it |
| Coding | filesystem, shell, language server, package manager | edit code, inspect symbols, run targeted commands |
| Review | git diff, grep, test reports, generated artifact reader | catch scope creep and weak tests |
| Unit tests | test runner, coverage | prove the patch did not only compile |
| Browser tests | Playwright/browser automation | validate real UI routes and flows |
| Security tests | secret scan, dependency audit, SAST | catch obvious unsafe output before publish |
| Docs/site checks | static-site build, route checks, smoke tests | catch generated-output drift |
Лепшая наладка MCP не ўвімкчвае усё. Яна дае агенту толькі тыя засобы, якія яму трэба, і змушвае тыя, што ўсё ж такі рызыкаваныя, спачатку запытаць. OpenCode адзначае серверы MCP пад ключам mcp у файле opencode.json і мае команды CLI для ўправління ямі. Ставіцеся да гэтых адзначэнняяк да залежнасцей у працэйнай асяроддзі: фіксуйце іх, пераглядайце і адключайце тыя, якія не вікорыстоўваюцца.
Чаму знімкі экрана знайшлі свае месца
Тэсты браузера вяртаюць рэзультаты «працюе» або «не працюе». Знімкі экрана даюць візуальныя доказы. Яны дапамаглі адналежнаму спеціялісту знайсці тое, чаго не можа пазначыць тэсты на елементы: зламаную структуру пасля правільнага запуску, некарэктны контэнт на паведамленні, порожнія створаныя сторункі, рэгрэсіі ў навігацыі, адзнаку праблемы, якой ніхто з тэстаў не пераканаў, а таксама падтверджэнне таго, што паведамленне статычнага сайту існуе і адрасуецца.
Яны таксама несу рызык: назвы профіляў прыгледчыка, прыватныя вікні, шляхі localhost, загаворкі проблем, токены URL і выход дадзеных з адміністрацыйных засобаў могу ўсе апынуцца ў кадрэ. Палітыка заключаецца ў тым, каб фіксаваць толькі скрыншоты інтэрфейсу localhost, строго адбіраць неабходную частку, пераглядаць іх пры публікацыі і ніколі не фіксаваць стороніц аутанацыі, панелей керування для працы, прыватных віконь чы тэрміналоў, якія паказваюць значэнні сяродавысці. Скрыншот ёсць доказам і за замовчаннем не лічыцца як публічны артыфакт.
Аналіз прыватнага праекту wiki
Авар прыклікваў гэта да прыватнага вікі з LLM і праекта статычных сайтаў, і публікаваў толькі адчыстаны тэкст. У яго заканчычных нотатках па верыфікацыі было зазначана, што працавалі 977 тэстаў на Python, была перзбудова статычнага сайта з апштаненнем, перакананне ў правільнасці сайта і домэна, стварэнне дакументацыі, перакананне маршрутаў і працавалі 150 тэстаў Playwright. Чыста па завершаным, абмежаным функцыям авар меў высокую доверыцу да якосці — адпаведна 8-9 з 10, чаго падтрымлівалі павтаральныя тэсты, перакананне створанага сайта, перакананне маршрутаў і верыфікацыя ў браузеры. Гэты рэйтынг ёсць суб’ектывным і не трэба яго генералізаваць за межы таго праекта.
Слабым месцам не быў код продукту. Аднам з скрытых скрыптаў аўтаматызацыі не ўдалося запрацаваць, таму што імены агентаў былі неправільна заданы. У ям былі выкарыстаны загальныя імены:
planner
coder
tester
reviewer
хоча настаўленыя агенты на самай працэ:
minimax-builder
glm-reviewer
З-за несасаблівання працэс выканання перайшаў у неправільны рэжым, таму запланавана процедура підтверджэння дзеяння калькулятора колькіх агентаў не была завершана. Штрафны стан віявіўся корыстным, адколі паказаў значэнне простых імен, точных налашчэнняў, вялікіх шляхоў і неабходнасць пераканання папкі сесіі. Відкорэгаваны шаблон выглядае так:
opencode run \
--model ollama/minimax-m3:cloud \
--agent minimax-builder \
--dir . \
"$(cat agent-sessions/project-slug/promptNN/PROMPTNN_CODER.md)"
opencode run \
--model ollama/glm-5.1:cloud \
--agent glm-reviewer \
--dir . \
"$(cat agent-sessions/project-slug/promptNN/PROMPTNN_REVIEWER.md)"
Гэта значыць, што не можа быць абсалютных пацек, выдуманых імен агентаў і файлаў з інструкцыямі, спрывучаных за межамі рабочага прастору.
Насколькі гэта блізка да рабочага працэсу Frontier?
Тут лёгка пераценіць сітуацыю. Наладжэнне MiniMax плюс GLM на OpenCode і Ollama не ўсё тое ж, што і працэўка з найлепшым модэлем кодавання Frontier безпосерэдня. Модэлі Frontier все ўсё маюць сільнейшае первіснае разумаванне, крашчую працэздатнась у дужах длігіх кантэкстах і крашчая стандартная адпаведнась інструкцыям, таму порэванацыя модэляў з модэлямі не будзе справядлівай. Важлівае порэванацыя — гэта якасць рабочага працэсу: планаванне, перагляд, тэсты, скрыншоты, перакананні ў безпеці і затверджэнне чалавекам.
Працэс выканання задач мае вельмі важлівую роль. У разе задач з чыста апрацаваным межамі, падтрымваных хорашымі тэстамі, такая структура можа нагадваць моцную мадэль тыпу Frontier, адколі ў яй ускладненыя ролі, прадзеяны планаванне, перагляды з обох бакоў рэалізацыі, обавязковыя контрольныя пункты, меморыя локальных сэсій, доказы у вастоўкі экрана, перакананні ў безпеці, а таксама кожны крок контролюецца чалавекам.
Ў апрацаванні функцый з чыста дэтэрміністычнымі правіламі, стварэнні статычных сайтаў, апраноўцы і пошуку, задачах, якія выкарыстоўваюць велікую колькасць тэстаў, пераглядзе выкананых рэзультатаў, выяўленні пераходу за межы заданага масштабу і прымусе агентаў дакументаваць неудачы, такая структура ўжо добра падходзіць. Мадэлі тыпу Frontier застаюцца крашчымі ў сітуацыях з неяснымі архітэктурнымі выбарамі, глыбокіх перэрабках коду, які паслаба прабаваны, у крытыцы і оцэнцы продукту, у самакорэкцыі на далёкай перспектыве, калі трэба менш пракатоў, у выпалненні інструкцый за замовчаннем і у аналізе складных вастоўкаў экрана.
Мадэль аблыкаў
Некалькі з вядомых апасоў, якія існуюць пад час работы з AI-кодаваннем, зменшуюцца пад час выкарыстоўвання гэтага падходу: непадтрыманыя тверджэння пра успех, распрацоўшчыкі, якія працуюць парадзельна ад запланаванага рэпазітарыю, рэвізоры, якія стаюць тымі, хто рэалізуе код, необработаныя запіты, якія потрапляюць у публічныя рэпазітарыі, логі, якія адкрываюць пацекі чыстацоўкі чы абмові, скрыншоты, якія адкрываюць прыватныя вікна чы токены, тыхі змяны ў створаных файлах, а таксама агенты, якія зберагаюць чы падаюць змяны, прычым ніхто іх не пераглядаў.
Патрэбна застава людзкага рэвізавання. Полная автонамія не ёсць метай; метай ёсць строгія структура, пры якой кожна тверджэння супакоўваецца доказамі, а кожны рызыкаваны крок мае практычны ліміт.
Працоўныя якосты і недакладнасці
Працоўныя якосты
- Возможнасць павторэнтыяцыі. Запіты супакоўваюцца папкамі, запускі залічваюць прыміткі, а падтверджэнні можна праследаваць.
- Кераванне. Распрацоўшчык не можа тыха праігнораваць тэсты, калі рэвізор вынужаны блакаваць падтверджэнне без доказаў апрацоўкі.
Недзеянні
- Большая складнасць. Гэта сложней, чым простае чат-запітанне, і гэта ўмова такога падходу.
- Патрэбна настройка для прыменення правіл. Заповедзь пераглядачу не рэдагаваць код для працы ёсць слабейшай, чым яго прымененне за дапамою праваў і перакрыццяў CI.
- Некальканосныя запіты все равно даюць некальканосныя рэзультаты. Гэты цыкл зменшае хаос, але не заменяе чыста адзначанае задачэ.
- Права ўвайшчыць патрэбуюць аберагання. Серверы MCP і доступ да шэлу ёсць моцнымі, таму ўжывайце ўсе заходы, якія вжываюцца для доступу да продакшн-сістэм.
- Логі ёсць чутлівымі. Чым багатшыя вашы логі, тым абавязковае трэба быць абераглівымі ў ўсуненні чутлівай інфармацыі.
Тэза, якая застоіцца
Гэты падход не ператворыць MiniMax чыра GLM у модэлі высшага рангу. Ён проста робіць дэшавшы ўраджанне коду за дапамою агентных тэхналогій, якія працуюць праз Ollama, болей дысцыплінованым, падлежачым аўдыту і корыстным для рэалізацыі спецыфічных інжынерных задач. Гэтая ўсё, што ён можа чыста правдзіва ствердзіць.
Супаўязаныя матэрыялы
- Практычныя прыметкі: Google ADK – як ствараць мульты-агентныя сістэмы — Паследовны апіс практычных прыметак: Google ADK – як ствараць мульты-агентныя сістэмы, укладаючы контракты, перакананні і шаблоны коду для команд, якія вікорыстоўваюць гэты падход.