OpenClaw + Claude Code/Codex：打造个人开发Agent Swarm

大家好，我是鲁工。

前段在X上刷到一条推文，瞬间就吸引了我。一个叫Elvis的独立开发者说，他现在已经不直接用Claude Code和Codex了，改用OpenClaw作为编排层，让一个叫Zoe的AI编排器去管理一整支Claude Code和Codex的Agent Swarm。

这条推文的数据也很炸裂，490万浏览，1.1万点赞，1800转发。

我们号写Vibe Coding四个多月，Claude Code一直是主力工具。我之前也写过一些多Agent协作、VSCode多Agent架构等相关文章。

但看到Elvis的这套玩法，我只能直呼内行了。一个人，靠一套编排系统，日均50次代码提交，最猛的一天提交了94次，还接了3个客户电话，编辑器一次都没打开。

这不就是一个人当一支开发团队用吗？

今天这篇文章就来拆解一下，他到底是怎么做到的。

OpenClaw大家都不陌生了

这只小龙虾春节前到现在，一直火爆。简单来说就是一个开源的AI Agent框架，GitHub上目前已经超过24万Star，并在前两天正式超越React，成为GitHub历史上star增长最快的开源项目。

创始人Peter Steinberger是奥地利开发者，之前创办过PSPDFKit（一个PDF框架的B2B公司），2021年拿了Insight Partners一亿欧元的投资。今年2月Peter宣布加入OpenAI，OpenClaw项目移交给开源基金会运营。

OpenClaw的定位不是聊天机器人，是一个跑在你本地设备上的AI Agent运行时。它有四个核心组件：Gateway（网关，连接50多个消息平台）、Agent（推理引擎）、Skills（5400多个插件）、Memory（记忆系统）。

但Elvis用OpenClaw的方式比较特别。他直接把它当成编排层，专门用来管理Claude Code和Codex这些编码Agent，没拿它当通用助手在使用。

这个思路确实很不一般。

为什么需要一个编排层呢？

Elvis在推文里提了一个很关键的观点：上下文窗口是零和博弈。

你往里面塞代码，就没空间放业务上下文了。你往里塞客户历史和会议记录，就没空间放代码库了。单个AI再强，它也没办法同时装下这两种完全不同类型的信息。

所以他把系统拆成了两层。

上层是OpenClaw的编排器Zoe，她掌握所有业务上下文，包括客户数据、会议记录、历史决策、哪些方案试过了、哪些失败了。这些信息全部存在Elvis的Obsidian笔记库里，Zoe可以直接读取。

下层是Claude Code和Codex这些编码Agent，它们只看代码，只管写代码。每个Agent启动的时候，Zoe会根据业务上下文给它写一份精准的prompt，告诉它该做什么、背景是什么、客户要的是什么。

简单来说了就是：编排器负责理解需求，编码Agent负责干活。各做各擅长的事。

这个架构和Stripe前段时间公开的内部系统Minions异曲同工。Stripe的Minions也是并行编码Agent加集中式编排层的设计，每周能合并1000多个完全由AI编写的PR。Elvis说他是无意中搭了个类似的架构，只不过跑在自己的Mac mini上。

真实案例工作流

Elvis在推文里用了一个真实案例来讲他的完整工作流，我把核心环节简单串一下。მას შემდეგ, რაც მან მიიღო კლიენტის ზარი, კლიენტი სურდა, რომ გუნდის შიგნით გამოიყენოს არსებული კონფიგურაცია. ზარის დასრულების შემდეგ, მან ზოესთან გაამხილა ეს მოთხოვნა. რადგან ყველა შეხვედრის ჩანაწერი ავტომატურად სინქრონიზდება Obsidian-ში, ზოე უკვე იცოდა, რაც თქვა კლიენტმა, ელვისს დამატებითი ახსნა არ სჭირდებოდა. მათ ერთად განსაზღვრეს ფუნქციონალური დიაპაზონი, საბოლოო გეგმა იყო შექმნან შაბლონის სისტემა.

შემდეგ ზოემ ავტომატურად გააკეთა სამი რამ: კლიენტისთვის გაატარა სერვისის განბლოკვა (მას აქვს ადმინისტრატორის API უფლებები), წარმოების მონაცემთა ბაზიდან გამოიტანა კლიენტის არსებული კონფიგურაცია (მხოლოდ წვდომის უფლებები, კოდირების აგენტს არასოდეს ექნება ეს უფლება), შემდეგ კი შექმნა Codex Agent, რომელიც შეიცავს სრულ ბიზნეს კონტექსტს დეტალური prompt-ით.

ყოველ აგენტს აქვს საკუთარი დამოუკიდებელი worktree (იზოლირებული შტო) და tmux სესია. გაშვების ბრძანება დაახლოებით ასე გამოიყურება:

# Create worktree + spawn agent git worktree add ../feat-custom-templates -b feat/custom-templates origin/main cd ../feat-custom-templates && pnpm install tmux new-session -d -s "codex-templates" \ -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \ "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high აგენტი გაშვების შემდეგ, არსებობს დროითი დავალება, რომელიც ყოველ 10 წუთში ერთხელ შეამოწმებს. მაგრამ ის პირდაპირ არ ეკითხება აგენტს (ეს ძალიან დააწვდის token-ს), არამედ აწარმოებს დადგენილ Shell სკრიპტს, რომელიც ამოწმებს, არის თუ არა tmux სესია ჯერ კიდევ ცოცხალი, შექმნილია თუ არა PR, CI გაიარა თუ არა.

თუ CI ჩავარდა, აგენტი ავტომატურად ხელახლა იწყებს, მაქსიმუმ 3-ჯერ. მხოლოდ მაშინ, როდესაც საჭიროა ადამიანის ჩარევა, იგზავნება შეტყობინება.

აგენტი დავალების შესრულების შემდეგ ავტომატურად ქმნის PR. მაგრამ მხოლოდ PR-ის შექმნა არ არის საკმარისი, ელვისმა განსაზღვრა დასრულების სტანდარტების ნაკრები: PR შექმნა, შტოს სინქრონიზაცია main-თან (ბრძოლების გარეშე), CI მთლიანად გაიარა, სამი AI მოდელის კოდის შემოწმება მთლიანად გაიარა, თუ არსებობს UI ცვლილება, უნდა იყოს დამატებული სკრინშოტი.

სამი AI მოდელი კოდის შემოწმებისთვის

სამი AI მოდელი კოდის შემოწმებას ძალიან სტაბილურად აკეთებს. საინტერესოა, რომ ელვისი საუბრობს ამ სამი მოდელის შეფასებაზე.

Codex Reviewer, მისი შეფასება ყველაზე მაღალია, ამბობს, რომ ის ძალიან საფუძვლიანად ამოწმებს საზღვრის შემთხვევებს და ლოგიკურ შეცდომებს, ცდომილების მაჩვენებელი ძალიან დაბალია.

Gemini Code Assist Reviewer, უფასო, ამბობს, რომ ძალიან პრაქტიკული არის, შეუძლია აღმოაჩინოს სხვა მოდელების გამოტოვებული უსაფრთხოების პრობლემები და გაფართოების საკითხები, ასევე შეუძლია კონკრეტული გამოსწორების გეგმების გაწვდვა.

Claude Code Reviewer, მისი სიტყვებია "ძალიან არაეფექტური", ამბობს, რომ ის ზედმეტად ფრთხილია, ეკრანზე უამრავი "გთხოვთ დაამატოთ..." მსგავსი რეკომენდაციებით, უმეტესობა ზედმეტად დიზაინირებული. თუ არ არის მონიშნული როგორც კრიტიკული პრობლემა, ის პირდაპირ გამოტოვებს.

როდესაც ამას ვხედავდი, ცოტა გაოცებული ვიყავი. როგორც Claude Code-ის აქტიური მომხმარებელი, ნამდვილად მქონდა შემთხვევები, როდესაც ის კოდის შემოწმებისას ზედმეტად კონსერვატიული იყო, მაგრამ "ძალიან არაეფექტური" შეფასება ცოტა ზედმეტია. თუმცა, ეს ასევე მიუთითებს, რომ მრავალ მოდელზე გადაკვეთის შემოწმება ნამდვილად აქვს ღირებულება, სხვადასხვა მოდელების წინასწარმეტყველებები ერთმანეთს ავსებს.

სამი შემოწმება მთლიანად გაიარა, მხოლოდ ამის შემდეგ ელვისი მიიღებს Telegram-ის შეტყობინებას. ამ ეტაპზე, ის ძირითადად სკრინშოტებს უყურებს, რათა დაადასტუროს, რომ UI ცვლილებები სწორია, ბევრი PR ის კოდის გარეშე პირდაპირ აერთიანებს. ამბობს, რომ მისი ხელით შემოწმება მხოლოდ 5-დან 10 წუთამდე სჭირდება.

ზოეს აქტიურობა

ზოე მხოლოდ აღმასრულებელია. სამუშაო პროცესზე უფრო საინტერესოა ზოეს აქტიურობა.

ელვისი ამბობს, რომ ზოე არ ელოდება, რომ მას დავალება მიაწვდონ, ის აქტიურად ეძებს სამუშაოს. დილით სკანირებს Sentry-ის შეცდომების ლოგებს, აღმოაჩენს 4 ახალ შეცდომას, ავტომატურად ქმნის 4 აგენტს მათი გამოსასწორებლად. შეხვედრის შემდეგ სკანირებს შეხვედრების ჩანაწერებს, აღნიშნავს კლიენტის მიერ ნახსენები 3 ფუნქციური მოთხოვნას, შემდეგ ავტომატურად იწყებს 3 Codex აგენტს. საღამოს სკანირებს Git-ის ლოგებს, იწყებს Claude Code-ს, რათა განაახლოს changelog და კლიენტის დოკუმენტები.

ელვისი გარეთ გავიდა და დაბრუნებისას Telegram-ზე აქვს შეტყობინება: 7 PR მზადაა, 3 ახალი ფუნქცია, 4 ბაგის გამოსწორება. ეს ხომ ის არ არის, რაც მე ყოველთვის მინდოდა, რომ OPC ერთპიროვნული კომპანიის განვითარების გუნდის ეფექტი ყოფილიყო?და როდესაც აგენტი წარუმატებელია, ზოეს დამუშავების მეთოდი ბევრად უფრო დახვეწილია, ვიდრე უბრალოდ ხელახლა ცდა. ის გააერთიანებს ბიზნეს კონტექსტს, რათა გაანალიზოს წარუმატებლობის მიზეზი. აგენტის კონტექსტი დაიშალა? ის შეამცირებს დიაპაზონს, რათა აგენტი მხოლოდ სამ ფაილზე კონცენტრირდეს. აგენტის მიმართულება შეცდომაში შევიდა? ის ასევე დაასწორებს, იტყვის აგენტს, რომ მომხმარებელს სჭირდება X, არა Y, და მოაყოლებს შეხვედრაში ნათქვამს.

დროის გასვლისთანავე, ზოე ასევე დააგროვებს გამოცდილებას, გაიხსენებს, რომელი პრომპტების სტრუქტურები რომელ ტიპის დავალებებზე მუშაობს კარგად, და შემდეგში უფრო ზუსტად დაწერს პრომპტებს.

ეს იდეა სინამდვილეში რალფ ლუპის განახლებული ვერსიაა. რალფ ლუპის ძირითადი ლოგიკა არის კონტექსტის მოზიდვა, გამოსვლის გენერირება, შედეგების შეფასება, გამოცდილების შენახვა, მაგრამ უმეტესობა განხორციელების დროს ყოველი ციკლის პრომპტი ფიქსირებული არის. ელვისის სისტემა განსხვავებულია, ყოველი ხელახლა ცდის დროს ზოე დინამიურად აწყობს პრომპტს წარუმატებლობის მიზეზების მიხედვით, და აქვს სრული ბიზნეს კონტექსტი.

ხარჯები და აპარატურა

ხარჯების მხრივ, ელვისის საჯარო მონაცემებია, რომ კლოდი ყოველთვიურად დაახლოებით 100 დოლარი ღირს, კოდექსი კი დაახლოებით 90 დოლარი. ის ასევე ამბობს, რომ დაწყება შეიძლება 20 დოლარით.

ეს ხარჯი, რა თქმა უნდა, ძალიან იაფია, ვიდრე ერთი დეველოპერის დაქირავება. მაგრამ თუ გაითვალისწინებთ, რომ თქვენ ასევე უნდა გააკეთოთ პროდუქტის გადაწყვეტილებები, მომხმარებელთან კომუნიკაცია, კოდის შემოწმება, ეს უფრო მეტად ეფექტურობის გამაძლიერებელია, რაც გაწვდავს კოდირების და ტესტირების ამ ყველაზე განმეორებად პროცესებს.

აპარატურის მხრივ, ელვისი აღნიშნავს, რომ მისი ყველაზე დიდი ბოთლი არის RAM. თითოეულ აგენტს სჭირდება დამოუკიდებელი worktree, თითოეულ worktree-ს აქვს საკუთარი nodemodules, თითოეული აგენტი უნდა აწარმოოს მშენებლობა, ტიპის შემოწმება და ტესტირება. 5 აგენტის ერთდროულად გაშვება ნიშნავს 5 პარალელურ TypeScript კომპილატორს, 5 ტესტირების გამშვებელს, 5 ნაკრებს დამოკიდებულებების.

მისი Mac mini 16GB მეხსიერება მაქსიმუმ 4-5 აგენტის ერთდროულად გაშვებას უძლებს, მეტი კი მეხსიერების გაცვლას იწყებს. ამიტომ მან შეიძინა 128GB მეხსიერების Mac Studio M4 Max (3500 დოლარი), რათა უფრო მეტი აგენტის პარალელური გაშვება შეძლოს.

დასკვნა და რეალური პრობლემები

მართალი გითხრათ, ელვისის ეს სისტემა ჩემზე საკმაოდ დიდი შთაბეჭდილება მოახდინა. ადრე მე OpenClaw-ს როგორც სათამაშოს ვთვლიდი, პროდუქტიულობის შექმნაში კი დამოუკიდებელ კლოდ კოდზე ვიყავი დამოკიდებული. ზოგჯერ worktree-ს ვიყენებდი პარალელურად, მაგრამ არც ისე სისტემატური იყო. მისი ტვიტების ნახვის შემდეგ, ვფიქრობ, AI პროგრამირების ამ საკითხის ჭერი კიდევ უფრო მაღლა აიწია.

ბოლო დროს მისი იდეების მიხედვით ვაპირებ OpenClaw-ს გამოყენებით სრულიად ავტომატიზირებული ერთი ადამიანის განვითარების გუნდის შექმნას. ამიტომ, უახლოეს მომავალში ჩვენ ვაპირებთ რამდენიმე OpenClaw-ის პრაქტიკული სტატიის გამოქვეყნებას.

რამდენიმე რეალური პრობლემა უნდა აღვნიშნო.

ამ სისტემის წინაპირობა არის, რომ თქვენ უნდა გქონდეთ მკაფიო პროდუქტი, მკაფიო მომხმარებლის მოთხოვნები, სრულყოფილი CI/CD პროცესები. ელვისი რეალურ B2B SaaS პროდუქტზე მუშაობს, აქვს მომხმარებელი, აქვს შემოსავალი, აქვს წარმოების გარემო. თუ თქვენ ჯერ კიდევ დემოს წერთ ან სწავლების ეტაპზე ხართ, ამ არქიტექტურის ROI შესაძლოა არ იყოს ძალიან მომგებიანი.

გარდა ამისა, OpenClaw-ის მიმდინარე უსაფრთხოების პრობლემებიც უნდა გაითვალისწინოთ. საჯარო ინფორმაციების მიხედვით, უკვე რამდენიმე მაღალი რისკის CVE გაწვდილია, ასევე 341 მავნე საზოგადოებრივი მოდული აღმოჩნდა მონაცემების მოპარვის ქმედებაში. OpenClaw-ის განთავსებისას, იზოლაცია და უფლებების კონტროლი აუცილებლად უნდა იყოს კარგად გაკეთებული. ეს არის მიზეზი, რის გამოც მე ჯერ არ მაქვს OpenClaw ჩემს ადგილობრივ მთავარ კომპიუტერზე განთავსებული.

და კიდევ ერთი რამ, ელვისი ტვიტებში კლოდ კოდის კოდის შემოწმების შეფასებას დაბალი უწოდებს, მაგრამ हाल ही में კლოდ კოდი ახალი აგენტების გუნდების ფუნქციით (ოფიციალურად ჩაშენებული მრავალ აგენტური თანამშრომლობა) გამოვიდა, ანთროპიკი ასევე ამ მიმართულებით მუშაობს.

თუმცა ამ დეტალების გვერდით, ელვისის ეს არქიტექტურული იდეა ნამდვილად值得 ყურადღების გამახვილებას. კონტექსტის ფანჯრის ნულოვანი და ნულოვანი თამაშები რეალურად არსებობს, ამ პრობლემის გადასაჭრელად ფენური არქიტექტურის გამოყენება, რათა სხვადასხვა AI-ები თავიანთი მოვალეობები შეასრულონ, ამ მიმართულებით მე პირადად ვფიქრობ, რომ სწორია.[[HTMLPLACEHOLDER_0]]