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 एजेंट उत्पन्न किया, जिसमें पूर्ण व्यावसायिक संदर्भ के साथ विस्तृत प्रॉम्प्ट शामिल था।

प्रत्येक एजेंट का अपना स्वतंत्र 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 मिनट में एक समयबद्ध कार्य होता है। लेकिन यह सीधे एजेंट से नहीं पूछता (ऐसा करना बहुत टोकन खर्च करेगा), बल्कि एक निश्चित शेल स्क्रिप्ट चलाता है, यह जांचने के लिए कि tmux सत्र अभी भी जीवित है, क्या PR बनाया गया है, और CI पास हुआ है।

यदि CI विफल हो जाता है, तो एजेंट को स्वचालित रूप से पुनः आरंभ किया जाता है, अधिकतम 3 बार पुनः प्रयास किया जाता है। केवल जब मानव हस्तक्षेप की आवश्यकता होती है तब ही सूचनाएं भेजी जाती हैं।

एजेंट कार्य पूरा करने के बाद स्वचालित रूप से PR बनाता है। लेकिन केवल PR बनाना ही पर्याप्त नहीं है, एल्विस ने पूरा करने के लिए मानकों का एक सेट परिभाषित किया: PR का निर्माण, शाखा का मुख्य में समन्वय (कोई विलय संघर्ष नहीं), CI सभी पास, तीन AI मॉडल के कोड समीक्षा सभी पास, यदि UI में परिवर्तन हैं तो स्क्रीनशॉट भी संलग्न होना चाहिए।

तीन AI मॉडल कोड समीक्षा करते हैं

तीन AI मॉडल कोड समीक्षा करते हैं, जो बहुत स्थिर लगते हैं। वह इन तीन मॉडलों के बारे में अपनी राय साझा करता है, जो दिलचस्प है।

Codex Reviewer, उसने इसकी सबसे अधिक प्रशंसा की, कहा कि यह सीमांत मामलों और तार्किक त्रुटियों के मामले में बहुत गहन समीक्षा करता है, और गलत सकारात्मक दर बहुत कम है।

Gemini Code Assist Reviewer, यह मुफ्त है, उसने कहा कि यह बहुत उपयोगी है, अन्य मॉडलों द्वारा छोड़े गए सुरक्षा जोखिमों और विस्तार समस्याओं को पहचान सकता है, और विशिष्ट सुधार योजनाएं भी दे सकता है।

Claude Code Reviewer, उसके शब्द थे "बुनियादी रूप से बेकार", कहा कि यह अत्यधिक सतर्क है, और "विचार करें जोड़ें..." जैसे सुझावों से भरा हुआ है, अधिकांश ओवरडिज़ाइन के अंतर्गत आते हैं। जब तक इसे महत्वपूर्ण समस्या के रूप में चिह्नित नहीं किया जाता, वह सीधे इसे छोड़ देता है।

जब मैंने इस हिस्से को देखा तो मैं थोड़ा चौंका। Claude Code का एक भारी उपयोगकर्ता होने के नाते, मैंने वास्तव में इसे कोड समीक्षा के दौरान अत्यधिक सतर्कता की स्थिति में देखा है, लेकिन "बुनियादी रूप से बेकार" का यह मूल्यांकन थोड़ा अधिक है। लेकिन यह भी एक तरह से यह बताता है कि कई मॉडलों की पारस्परिक समीक्षा वास्तव में मूल्यवान है, विभिन्न मॉडलों की पूर्वाग्रह एक-दूसरे को ठीक से पूरा करते हैं।

तीन समीक्षाएं सभी पास होने के बाद, एल्विस को केवल टेलीग्राम पर सूचना मिलती है। इस चरण पर, वह मुख्य रूप से स्क्रीनशॉट देखता है, यह सुनिश्चित करने के लिए कि UI परिवर्तन सही हैं, कई PR को वह कोड देखे बिना सीधे मर्ज कर देता है। उसने कहा कि उसकी मानव समीक्षा में केवल 5 से 10 मिनट लगते हैं।

ज़ोई की सक्रियता

ज़ोई केवल कार्यान्वयनकर्ता नहीं है। कार्यप्रवाह से अधिक दिलचस्प बात यह है कि ज़ोई की सक्रियता है।

एल्विस ने कहा कि ज़ोई कार्य सौंपे जाने की प्रतीक्षा नहीं करती, वह सक्रिय रूप से काम खोजती है। सुबह Sentry की त्रुटि लॉग को स्कैन करती है, 4 नए त्रुटियों का पता लगाती है, और 4 एजेंटों को स्वचालित रूप से बनाने के लिए भेजती है। बैठक के बाद बैठक के नोट्स को स्कैन करती है, ग्राहक द्वारा उल्लेखित 3 कार्यात्मक आवश्यकताओं को चिह्नित करती है, और फिर 3 Codex एजेंटों को स्वचालित रूप से शुरू करती है। रात में Git लॉग को स्कैन करती है, Claude Code को changelog और ग्राहक दस्तावेज़ अपडेट करने के लिए शुरू करती है।

एल्विस बाहर टहलने जाता है और लौटता है, टेलीग्राम पर एक संदेश होता है: 7 PR तैयार हैं, 3 नए कार्यात्मकताएँ, 4 बग फिक्स। क्या यही नहीं है जो मैं हमेशा OPC एक व्यक्ति कंपनी विकास टीम के प्रभाव को बनाने की उम्मीद कर रहा था?और जब एजेंट विफल होता है, तो ज़ोई का प्रबंधन तरीका साधारण पुनः प्रयास से कहीं अधिक उन्नत है। यह व्यावसायिक संदर्भ के साथ विफलता के कारणों का विश्लेषण करेगा। क्या एजेंट का संदर्भ टूट गया? यह दायरे को संकुचित करेगा, जिससे एजेंट केवल तीन फ़ाइलों पर ध्यान केंद्रित कर सके। क्या एजेंट की दिशा भटक गई? यह भी इसे सही करेगा, एजेंट को बताएगा कि ग्राहक को X चाहिए, Y नहीं, और बैठक में कहे गए मूल शब्दों के साथ।

समय के साथ, ज़ोई अनुभव भी जमा करेगा, यह याद रखेगा कि कौन से प्रॉम्प्ट संरचनाएँ किस प्रकार के कार्यों के लिए अच्छी हैं, अगली बार अधिक सटीक प्रॉम्प्ट लिखने के लिए।

यह विचार वास्तव में राल्फ लूप का उन्नत संस्करण है। राल्फ लूप की मुख्य तर्कशक्ति संदर्भ खींचना, आउटपुट उत्पन्न करना, परिणामों का मूल्यांकन करना, और अनुभव को सहेजना जैसे चक्र हैं, लेकिन अधिकांश कार्यान्वयन में प्रत्येक चक्र के लिए प्रॉम्प्ट निश्चित होते हैं। एल्विस का सिस्टम अलग है, हर बार पुनः प्रयास करते समय ज़ोई विफलता के कारण के आधार पर प्रॉम्प्ट को गतिशील रूप से समायोजित करेगा, और इसके पास पूर्ण व्यावसायिक संदर्भ का समर्थन है।

लागत और हार्डवेयर

लागत के मामले में, एल्विस द्वारा सार्वजनिक डेटा है कि क्लॉड की लागत लगभग 100 डॉलर प्रति माह है, कोडेक्स की लागत लगभग 90 डॉलर प्रति माह है। उन्होंने यह भी कहा कि शुरुआत में 20 डॉलर से परीक्षण किया जा सकता है।

यह लागत एक डेवलपर को नियुक्त करने की तुलना में निश्चित रूप से बेहद सस्ती है। लेकिन अगर आप यह भी ध्यान में रखते हैं कि आपको खुद उत्पाद निर्णय, ग्राहक संचार, कोड समीक्षा करनी है, तो यह अधिक एक दक्षता संवर्धक की तरह है, जो आपको कोडिंग और परीक्षण जैसे सबसे अधिक दोहराए जाने वाले चरणों को बचाने में मदद करता है।

हार्डवेयर के मामले में, एल्विस ने उल्लेख किया कि उनका वर्तमान सबसे बड़ा बाधा RAM है। प्रत्येक एजेंट को स्वतंत्र कार्य वृक्ष की आवश्यकता होती है, प्रत्येक कार्य वृक्ष में अपने स्वयं के node_modules होते हैं, प्रत्येक एजेंट को निर्माण, प्रकार जांच और परीक्षण चलाना होता है। 5 एजेंट एक साथ चलने का मतलब है 5 समानांतर TypeScript संकलक, 5 परीक्षण चलाने वाले, 5 सेट निर्भरताएँ।

उनका मैक मिनी 16GB मेमोरी में अधिकतम 4 से 5 एजेंट एक साथ चला सकता है, इससे अधिक होने पर मेमोरी स्वैपिंग शुरू हो जाती है। इसलिए उन्होंने 128GB मेमोरी वाला मैक स्टूडियो M4 मैक्स (3500 डॉलर) खरीदा, इसे अधिक एजेंटों की समवर्तीता को संभालने के लिए उपयोग करने की योजना बनाई।

सारांश और वास्तविक समस्याएँ

ईमानदारी से कहूँ तो, एल्विस का यह सिस्टम मेरे लिए काफी प्रभावशाली था। मैंने पहले ओपनक्लॉ को एक खिलौने के रूप में खेला था, उत्पादकता के निर्माण में, मैं स्वतंत्र क्लॉड कोड पर निर्भर था। कभी-कभी कार्य वृक्ष का उपयोग करके समानांतर किया, लेकिन इस प्रणालीबद्ध व्यवस्था के स्तर तक नहीं पहुंचा। उनकी ट्वीट पढ़ने के बाद, मुझे लगा कि एआई प्रोग्रामिंग का यह विषय फिर से एक स्तर ऊपर उठ गया है।

मैं हाल ही में उनके विचारों के अनुसार, ओपनक्लॉ का उपयोग करके पूरी तरह से स्वचालित एक व्यक्ति विकास टीम बनाने की योजना बना रहा हूँ। इसलिए, निकट भविष्य में हम ओपनक्लॉ के व्यावहारिक लेखों की कई श्रृंखलाएँ प्रकाशित करेंगे।

कुछ वास्तविक समस्याएँ हैं जिन्हें मुझे सभी को याद दिलाना है।

इस प्रणाली की शर्त यह है कि आपके पास एक स्पष्ट उत्पाद, स्पष्ट ग्राहक आवश्यकताएँ, और एक पूर्ण CI/CD पाइपलाइन होनी चाहिए। एल्विस एक वास्तविक B2B SaaS उत्पाद बना रहा है, जिसमें ग्राहक, आय, और उत्पादन वातावरण है। यदि आप अभी भी डेमो या अध्ययन चरण में हैं, तो इस संरचना का ROI शायद बहुत फायदेमंद नहीं होगा।

इसके अलावा, ओपनक्लॉ की वर्तमान सुरक्षा समस्याओं पर भी ध्यान देना चाहिए। सार्वजनिक जानकारी के अनुसार, कई उच्च जोखिम वाले CVE का खुलासा किया गया है, और 341 दुर्भावनापूर्ण सामुदायिक प्लगइन्स में डेटा चोरी की गतिविधियाँ पाई गई हैं। ओपनक्लॉ को तैनात करते समय, अलगाव और अनुमति नियंत्रण को ठीक से करना आवश्यक है। यही कारण है कि मैंने ओपनक्लॉ को अपने स्थानीय मुख्य मशीन पर तैनात नहीं किया है।

एक और बात, एल्विस ने ट्वीट में क्लॉड कोड की कोड समीक्षा की कम सराहना की, लेकिन हाल ही में क्लॉड कोड ने एजेंट टीमों की सुविधा (आधिकारिक अंतर्निहित बहु-एजेंट सहयोग) पेश की है, एंथ्रोपिक भी इस दिशा में प्रयास कर रहा है।

हालांकि इन विवरणों को छोड़कर, एल्विस की यह व्यवस्था परत और कार्यान्वयन स्तर की संरचना वास्तव में ध्यान देने योग्य है। संदर्भ विंडो का शून्य-योग खेल वास्तव में एक वास्तविक बाधा है, इस समस्या को हल करने के लिए स्तरित संरचना का उपयोग करना, विभिन्न एआई को उनके कार्यों का पालन करने देना, इस दिशा में मुझे व्यक्तिगत रूप से सही लगता है।

इस विषय में रुचि रखने वाले मित्र, सीधे एल्विस की मूल ट्वीट देख सकते हैं, जानकारी की घनत्व बहुत अधिक है:...