Codex पर एक सेल्फ-इम्प्रूविंग आउटबाउंड सिस्टम कैसे बनाएं

इस साल की शुरुआत में, Andrej Karpathy (@karpathy) ने अपने ट्रेनिंग कोड पर एक एजेंट लगाया और उसे दो दिनों तक चलने दिया। उसने 700 एक्सपेरिमेंट चलाए, उन 20 को रखा जिन्होंने बेंचमार्क को बेहतर किया, और मॉडल को 11% तेज़ी से ट्रेन किया। फिर उसने कुछ बहुत दिलचस्प कहा: कोई भी मीट्रिक जिसे आप सस्ते में मूल्यांकन कर सकते हैं, उसे एजेंट स्वार्म को सौंपा जा सकता है।

रिप्लाई रेट एक ऐसा मीट्रिक है जिसे आप सस्ते में मूल्यांकन कर सकते हैं। मैंने कुछ समय यह समझने में बिताया है कि आउटबाउंड पर लक्षित होने पर वह लूप कैसा दिखता है।

मेरा बिल्ड:

Codex पिछले हफ्ते के परिणाम पढ़ता है, उन स्कोरिंग और प्ले फ़ाइलों को संपादित करता है जिन पर आउटबाउंड सिस्टम चलता है, एक टेस्ट चलाता है, और एक पुल रिक्वेस्ट खोलता है। यह सबूत और स्कोर के साथ प्लेबुक में एक बदलाव का प्रस्ताव करता है, फिर इसे मंजूरी देने के लिए एक मानव की प्रतीक्षा करता है। भेजना और मर्ज करना लूप के बाहर रहता है।

मैंने पहला लूप कुछ बार बनाया है: बाजार को समझना, खाते को स्कोर करना, सिग्नल से लिखना, संदेश की जांच करना, परिणाम लॉग करना, रिप्लाई से सीखना। यह लेख दूसरे लूप के बारे में है, जो पहले को संपादित करता है।

यही बिल्ड है: GTM एक संस्करणित कोड के रूप में जो बाजार से बेहतर होता है।

रिपॉजिटरी

फोल्डर से शुरू करें। संरचना मायने रखती है क्योंकि Codex केवल उसी को बेहतर कर सकता है जिसे वह पढ़ और संपादित कर सकता है।

1codex-self-improving-outbound/
2  AGENTS.md
3  README.md
4  config/
5    scoring.yaml
6    plays.yaml
7  prompts/
8    improve_scoring.md
9    improve_prompt.md
10    pr_summary.md
11  memory/
12    outcomes.jsonl
13  evals/
14    fixtures.yaml
15    score.py
16  scripts/
17    append_outcome.py
18    run_codex_step.sh
19    propose_improvement.py
20    open_pr.sh
21    weekly_tune.sh
22  examples/
23    outcomes.sample.jsonl
24    weekly-pr.md

रिपॉजिटरी जानबूझकर सादा है। config/scoring.yaml में वे नियम हैं जो तय करते हैं कि कौन से सिग्नल मायने रखते हैं। prompts/ में वे प्ले हैं जो संदेश लिखते हैं। memory/outcomes.jsonl में वह है जो बाजार ने किया। evals/score.py वह गेट है जो बताता है कि किसी प्रस्तावित बदलाव ने मदद की या नहीं। AGENTS.md वह कानून है जिसे Codex कुछ भी छूने से पहले पढ़ता है।

पहला वर्जन ऑफलाइन चलाएं। कोई CRM, कोई एनरिचमेंट, कोई डिलीवरी सिस्टम नहीं। सुधार लूप को किसी वास्तविक आउटबाउंड मशीन के पास जाने से पहले लोकल फ़ाइलों पर खुद को साबित करना चाहिए।

चरण 1. पहले कानून लिखें

स्कोरिंग फ़ाइल से पहले, प्रॉम्प्ट फ़ाइलों से पहले, AGENTS.md लिखें। यह वह फ़ाइल है जो एजेंट को उपयोगी और सीमित रखती है।

1# सेल्फ-इम्प्रूविंग आउटबाउंड नियम
2
3आप परिणामों से एक आउटबाउंड सिस्टम को बेहतर बनाते हैं।
4
5कठोर नियम:
6- कभी संदेश न भेजें।
7- कभी वास्तविक लोगों को स्क्रैप या एनरिच न करें।
8- कभी सेल्फ-मर्ज न करें।
9- केवल इस रिपॉजिटरी में फ़ाइलों को संपादित करें।
10- एक बार में एक अवधारणा बदलें।
11- हर प्रस्तावित बदलाव के लिए memory/outcomes.jsonl से परिणाम उद्धृत करें।
12- किसी बदलाव के PR बनने से पहले evals/score.py में सुधार करें।
13- यदि eval में सुधार नहीं होता है, तो अपना संपादन वापस लें और रुक जाएं।
14
15अनुमत संपादन:
16- config/scoring.yaml
17- config/plays.yaml
18- prompts/*.md
19
20आवश्यक आउटपुट:
21- बदली गई फ़ाइलें
22- प्रत्येक बदलाव का कारण
23- पहले का स्कोर
24- बाद का स्कोर
25- पुल रिक्वेस्ट सारांश

कानून का एक ही काम है: काम को संकीर्ण करना। इसके बिना, Codex दायरा बढ़ाकर मदद करने की कोशिश करेगा। वह और डेटा जोड़ेगा, और फ़ाइलों को छुएगा, और टूल्स को कॉल करेगा, या एक ऐसे चरण को स्वचालित करेगा जो मानव नियंत्रण में रहना चाहिए। यहां काम छोटा है: परिणाम पढ़ें, एक फ़ाइल बदलाव का प्रस्ताव करें, साबित करें कि इसने मदद की, फिर प्रतीक्षा करें।

अच्छा कैसा दिखता है। आप PR को मंजूरी देने से पहले कानून पढ़ सकते हैं और ठीक से जान सकते हैं कि Codex को क्या करने की अनुमति थी।

यह कहां टूटता है। कानून एक अनुपालन दस्तावेज़ बन जाता है। यदि AGENTS.md को सामग्री की तालिका की आवश्यकता है, तो यह पहले से ही बहुत बड़ा है। इसे परिचालन बनाए रखें।

चरण 2. निर्णय को कॉन्फ़िग में ले जाएं

अधिकांश आउटबाउंड निर्णय किसी के दिमाग में रहता है। फिर टीम सॉफ्टवेयर खरीदती है और उम्मीद करती है कि सॉफ्टवेयर एक ऐसे निर्णय में सुधार करेगा जिसे वह देख नहीं सकता।

निर्णय को एक फ़ाइल में ले जाएं।

1signals:
2  competitor_comparison:
3    weight: 8
4    reason: "खरीदार विकल्पों की तुलना कर रहा है"
5  implementation_page_visit:
6    weight: 6
7    reason: "खरीदार जांच कर रहा है कि क्या इसे इंस्टॉल किया जा सकता है"
8  job_repost:
9    weight: 5
10    reason: "भूमिका अभी भी खुली है और तत्काल है"
11  funding_event:
12    weight: 5
13    reason: "बजट या जनादेश बदल सकता है"
14  generic_download:
15    weight: 1
16    reason: "सामग्री में रुचि, कमजोर खरीद इरादा"
17
18thresholds:
19  draft: 6
20  human_review: 10
21
22negative_signals:
23  student_research: -8
24  vendor_pitch: -6
25  competitor: -10

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

इस तर्क को Python फ़ंक्शन में न दफनाएं। यदि नियम दृश्य है, तो टीम इसकी समीक्षा कर सकती है, इस पर बहस कर सकती है, और बिक्री के निर्णय को इंजीनियरिंग रीफैक्टर में बदले बिना इसे बेहतर कर सकती है।

अच्छा कैसा दिखता है। फ़ाइल इतनी छोटी है कि इस पर बहस की जा सके। पांच सिग्नल एक अच्छा पहला वर्जन है।

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

चरण 3. परिणामों को मेमोरी के रूप में लिखें

सबसे महत्वपूर्ण फ़ाइल memory/outcomes.jsonl है।

प्रति स्पर्श एक पंक्ति, जब परिणाम ज्ञात हो तब लिखी गई:

1{"date":"2026-07-01","account":"Northwind Finance","signal":"competitor_comparison","play":"migration_note","score":8,"outcome":"reply","reason":"माइग्रेशन नोट्स के लिए पूछा"}
2{"date":"2026-07-01","account":"Bluepeak Studio","signal":"generic_download","play":"resource_followup","score":1,"outcome":"no_reply","reason":"केवल-सामग्री इरादा"}
3{"date":"2026-07-02","account":"KiteOps","signal":"implementation_page_visit","play":"implementation_angle","score":6,"outcome":"reply","reason":"कार्यान्वयन समयरेखा के बारे में पूछा"}
4{"date":"2026-07-02","account":"Atlas Recruiting","signal":"job_repost","play":"hiring_angle","score":5,"outcome":"bad_fit","reason":"छात्र अनुसंधान अनुरोध"}

रीज़न फ़ील्ड पूरा बिंदु है। no_reply आपको लगभग कुछ नहीं बताता है। content-only intent अगले रन को बताता है कि यह सिग्नल ड्राफ्ट के लायक नहीं हो सकता है। bad_fit तभी उपयोगी है जब कारण बताता है कि क्यों। asked about implementation timeline उस तरह का विवरण है जो एक वजन बदल सकता है।

सुधारक बनाने से पहले वैलिडेटर बनाएं:

1scripts/append_outcome.py बनाएं।
2
3यह स्वीकार करता है:
4- date
5- account
6- signal
7- play
8- score
9- outcome: reply | meeting | no_reply | bad_fit | bounced
10- reason
11
12यह अस्वीकार करता है:
13- लापता फ़ील्ड
14- अज्ञात परिणाम
15- खाली कारण
16- भविष्य की तारीखें
17
18मान्य पंक्तियों को memory/outcomes.jsonl में जोड़ें।
19जोड़ी गई पंक्ति प्रिंट करें।

यहीं से compounding शुरू होता है। एक डैशबोर्ड आपको बता सकता है कि एक कैंपेन डाउन है। एक साफ परिणाम लॉग Codex को बता सकता है कि अगले रन से पहले कौन सा सिग्नल, प्ले या वाक्यांश बदलना चाहिए।

अच्छा कैसा दिखता है। एक हफ्ते के बाद, एक अजनबी फ़ाइल पढ़ सकता है और बता सकता है कि किन सिग्नलों ने रिप्लाई बनाई, किन प्ले ने बैड-फिट बातचीत बनाई, और किस आंतरिक पसंदीदा को बाजार ने अनदेखा किया।

यह कहां टूटता है। टीम शुक्रवार को स्मृति से परिणाम बैकफिल करती है। जीत बच जाती है, बैड-फिट कारण धुंधले हो जाते हैं, और सिस्टम कल्पना से सीखता है। जब परिणाम आता है तब पंक्ति लिखें।

चरण 4. eval गेट बनाएं

Codex कुछ भी संपादित करने से पहले, उसे एक परीक्षण की आवश्यकता है जिसे वह समझा नहीं सकता।

evals/fixtures.yaml बनाएं:

1cases:
2  - account: Northwind Finance
3    signals: [competitor_comparison, implementation_page_visit]
4    expected: human_review
5    note: "एक खाते पर दो मजबूत सिग्नल"
6
7  - account: Bluepeak Studio
8    signals: [generic_download]
9    expected: ignore
10    note: "केवल-सामग्री इरादा"
11
12  - account: KiteOps
13    signals: [implementation_page_visit]
14    expected: draft
15    note: "कार्यान्वयन इरादा ड्राफ्ट थ्रेशोल्ड को साफ करना चाहिए"
16
17  - account: Atlas Recruiting
18    signals: [job_repost, student_research]
19    expected: ignore
20    note: "बैड-फिट मार्कर सिग्नल को रद्द करता है"

फिर evals/score.py बनाएं:

1evals/score.py बनाएं।
2
3config/scoring.yaml और evals/fixtures.yaml पढ़ें।
4
5प्रत्येक मामले के लिए:
61. प्रत्येक सिग्नल के लिए वेट का योग करें।
72. नकारात्मक सिग्नल दंड जोड़ें।
83. खाते को रूट करें:
9   - score >= thresholds.human_review => human_review
10   - score >= thresholds.draft => draft
11   - अन्यथा => ignore
124. रूट की expected से तुलना करें।
13
14प्रत्येक भविष्यवाणी प्रिंट करें।
15अंतिम सटीकता को score=0.00 से score=1.00 के रूप में प्रिंट करें।
16केवल तभी Exit 0 करें जब सटीकता 1.00 हो।

पहला गेट इतना छोटा होना चाहिए कि समझा जा सके और इतना तेज हो कि एक वास्तविक चूक को पकड़ सके। मेरे पहले रन में, बेसलाइन एक मामले में विफल रही:

1Northwind Finance: predicted=human_review expected=human_review
2Bluepeak Studio: predicted=ignore expected=ignore
3KiteOps: predicted=ignore expected=draft
4Atlas Recruiting: predicted=ignore expected=ignore
5score=0.75

यह अच्छा था। सिस्टम के पास ड्राफ्ट थ्रेशोल्ड से नीचे कार्यान्वयन इरादा था, इसलिए इसने एक ऐसे खाते को अनदेखा कर दिया जिसे फिक्स्चर ने कहा था कि एक संदेश के लायक है। एक महीने के छूटे हुए खातों के बाद इसे पकड़ने से बेहतर है कि इसे परीक्षण में पकड़ा जाए।

अच्छा कैसा दिखता है। एक कमांड एक नंबर देता है, और हर विफल मामले का निरीक्षण करना आसान होता है।

यह कहां टूटता है। फिक्स्चर में केवल स्पष्ट जीत शामिल है। फिर हर लापरवाह बदलाव पास हो जाता है। गेट में बदसूरत मामले डालें: कमजोर इरादा, बैड फिट, कोई जवाब नहीं, पुराने सिग्नल, और वे खाते जिन्हें आप चाहते हैं कि सिस्टम ने छोड़ दिया होता।

चरण 5. Codex को एक स्कोरिंग बदलाव का प्रस्ताव करने दें

अब Codex संपादित कर सकता है।

prompts/improve_scoring.md बनाएं:

1आप आउटबाउंड स्कोरिंग सिस्टम में सुधार करते हैं।
2
3पढ़ें:
4- AGENTS.md
5- config/scoring.yaml
6- memory/outcomes.jsonl
7- evals/fixtures.yaml
8
9आपका काम:
101. एक स्कोरिंग नियम खोजें जो बदलना चाहिए।
112. कारण को memory/outcomes.jsonl उद्धृत करना चाहिए।
123. केवल config/scoring.yaml बदलें।
134. python3 evals/score.py चलाएं।
145. यदि स्कोर में सुधार होता है, तो बदलाव रखें।
156. यदि स्कोर समान रहता है या गिरता है, तो अपना बदलाव वापस लें और रुक जाएं।
16
17आउटपुट:
18- बदली गई सटीक लाइन
19- वे परिणाम पंक्तियाँ जिनके कारण ऐसा हुआ
20- पहले का स्कोर
21- बाद का स्कोर
22- क्या बदलाव PR बनना चाहिए
23
24प्रॉम्प्ट संपादित न करें।
25नए सिग्नल न जोड़ें।
26डिलीवरी को न छुएं।

इसे रिपॉजिटरी रैपर के माध्यम से चलाएं:

1scripts/run_codex_step.sh improve_scoring

मेरे सुधारक के पहले वर्जन ने एक उपयोगी गलती की। इसने सबसे साफ दिखने वाले रिप्लाई सिग्नल का पीछा किया। छोटे परिणाम लॉग में competitor_comparison की रिप्लाई दर सबसे मजबूत थी, इसलिए सुधारक उस वजन को बढ़ाना चाहता था। eval 0.75 पर रहा, इसलिए बदलाव अस्वीकार कर दिया गया।

ठीक यही कारण है कि गेट मौजूद है। एक कमजोर सिस्टम ने कहानी को स्वीकार कर लिया होता क्योंकि यह उचित लग रहा था। इसने एक बेहतर सवाल पूछा: क्या बदलाव ने ज्ञात चूक को ठीक किया?

दूसरे पास ने सबसे छोटा संपादन पाया जिसने मदद की:

1- implementation_page_visit: 4
2+ implementation_page_visit: 6

eval पास हो गया:

1Northwind Finance: predicted=human_review expected=human_review
2Bluepeak Studio: predicted=ignore expected=ignore
3KiteOps: predicted=draft expected=draft
4Atlas Recruiting: predicted=ignore expected=ignore
5score=1.00

यही वह पल है जब लूप उपयोगी हो जाता है। इसने एक नियम, एक कारण के लिए बदला, और एक फिक्स्चर के खिलाफ बदलाव साबित किया।

अच्छा कैसा दिखता है। प्रस्तावित अंतर उबाऊ और ट्रेसेबल है: एक लाइन बदली गई, एक परिणाम-समर्थित कारण जुड़ा हुआ है, एक eval में सुधार हुआ है।

यह कहां टूटता है। Codex एक साथ तीन वजन और दो प्रॉम्प्ट बदलता है। अब कोई नहीं बता सकता कि किस बदलाव ने मदद की। कानून को सख्त रखें: प्रति प्रस्ताव एक अवधारणा।

चरण 6. प्रॉम्प्ट फ़ाइलों में अलग से सुधार करें

स्कोरिंग केवल आधा सिस्टम है। संदेश टेम्पलेट भी खराब होते हैं।

पिछले महीने जो लाइन काम करती थी वह अब परिचित लगने लगती है। एक सवाल जो एक सेगमेंट में रिप्लाई अर्जित करता है वह दूसरे में अनदेखा कर दिया जाता है। एक वाक्यांश जो आंतरिक रूप से तेज लगता है वह बाजार द्वारा दंडित किया जाता है। प्रॉम्प्ट सुधार को एक अलग लेन के रूप में मानें ताकि Codex एक ही PR में स्कोरिंग और कॉपी को मिश्रित न करे।

config/plays.yaml बनाएं:

1plays:
2  migration_note:
3    prompt_file: prompts/plays/migration_note.md
4    use_when:
5      - competitor_comparison
6    banned_lines:
7      - "thought this might be relevant"
8      - "quick question"
9
10  implementation_angle:
11    prompt_file: prompts/plays/implementation_angle.md
12    use_when:
13      - implementation_page_visit
14    banned_lines:
15      - "checking out our solution"
16      - "would love to chat"

फिर prompts/improve_prompt.md बनाएं:

1आप एक आउटबाउंड प्ले में सुधार करते हैं।
2
3पढ़ें:
4- AGENTS.md
5- config/plays.yaml
6- memory/outcomes.jsonl
7- चुने गए प्ले के लिए प्रॉम्प्ट फ़ाइल
8
9कम से कम 10 परिणामों वाला एक प्ले चुनें।
10
11खोजें:
12- लाइनें या संरचनाएं जो सकारात्मक परिणामों में दिखाई देती हैं
13- लाइनें या संरचनाएं जो no_reply या bad_fit परिणामों में दिखाई देती हैं
14- कोई भी वाक्यांश जिस पर प्रतिबंध लगाया जाना चाहिए
15
16उस प्ले के प्रॉम्प्ट में एक छोटा संपादन करें।
17
18नियम:
19- स्कोरिंग न बदलें।
20- कोई नया प्ले न बनाएं।
21- कोई नया चैनल न जोड़ें।
22- परिणाम पंक्तियों को उद्धृत करें।
23- पहले और बाद के निर्देश लिखें।
24
25फिर यदि मौजूद हो तो कॉपी eval चलाएं।
26यदि कोई कॉपी eval मौजूद नहीं है, तो PR को review_required के रूप में खोलें।

कुछ सुधारों को स्वचालित रूप से स्कोर किया जा सकता है। अन्य को अभी भी स्वाद की आवश्यकता है। यदि कोई कॉपी eval नहीं है, तो Codex प्रॉम्प्ट संपादन का प्रस्ताव कर सकता है, लेकिन इसे संपादन को सिद्ध होने का दिखावा करने के बजाय समीक्षा के लिए PR को चिह्नित करना चाहिए।

अच्छा कैसा दिखता है। Codex कहता है, "यह वाक्यांश सात no-reply परिणामों में दिखाई दिया, इसलिए मैंने इसे banned_lines में जोड़ा," या "सकारात्मक रिप्लाई ने वाक्य एक में कार्यान्वयन विवरण उद्धृत किया, इसलिए मैंने इसे आवश्यक बनाने के लिए प्ले को कड़ा कर दिया।"

यह कहां टूटता है। सुधारक पूरी आवाज को फिर से लिखता है क्योंकि एक संदेश को जवाब मिला। प्रॉम्प्ट संपादन आपकी प्रवृत्ति से छोटे होने चाहिए।

चरण 7. परिवर्तनों को पुल रिक्वेस्ट के रूप में भेजें

यह नियंत्रण परत है। Codex फ़ाइलों को संपादित करता है, eval चलाता है, और PR सारांश लिखता है। एक मानव समीक्षा करता है और मर्ज करता है।

prompts/pr_summary.md बनाएं:

1इस आउटबाउंड सुधार के लिए एक पुल रिक्वेस्ट सारांश लिखें।
2
3शामिल करें:
41. क्या बदला।
52. क्यों बदला, परिणाम पंक्तियों को उद्धृत करते हुए।
63. पहले का स्कोर।
74. बाद का स्कोर।
85. बदली गई फ़ाइलें।
96. जोखिम।
107. मानव समीक्षक को क्या जांचना चाहिए।
11
12इसे छोटा रखें।
13यह दावा न करें कि बदलाव लाइव है।

scripts/open_pr.sh बनाएं:

1#!/usr/bin/env bash
2set -euo pipefail
3
4branch="codex/weekly-tune-$(date +%Y-%m-%d)"
5
6git checkout -b "$branch"
7git add config prompts evals memory
8git commit -m "Codex साप्ताहिक आउटबाउंड ट्यून"
9
10body="$(cat outputs/pr-summary.md)"
11
12python3 scripts/create_pr.py \
13  "$branch" \
14  "Codex साप्ताहिक आउटबाउंड ट्यून" \
15  "$body"

PR को एक टीममेट द्वारा लिखे जैसा पढ़ना चाहिए:

1बदला:
2- implementation_page_visit को 4 से 6 तक बढ़ाया।
3
4क्यों:
5- KiteOps के पास कार्यान्वयन-पेज का इरादा था और उसने कार्यान्वयन समय के साथ जवाब दिया।
6- पिछले स्कोर ने इस खाते को ignore पर रूट किया।
7
8पहले:
9- eval स्कोर 0.75
10
11बाद में:
12- eval स्कोर 1.00
13
14समीक्षक जांच:
15- सुनिश्चित करें कि कार्यान्वयन इरादा पर्याप्त विशिष्ट है।
16- सामान्य डाउनलोड को कम रखें।
17- केवल तभी मर्ज करें यदि यह वास्तविक बिक्री निर्णय से मेल खाता है।

यह सुरक्षा प्रणाली है। Codex थकाऊ काम करता है। ऑपरेटर मानक रखता है।

अच्छा कैसा दिखता है। एक सप्ताह में एक PR, छोटा अंतर, स्पष्ट कारण, पासिंग eval।

यह कहां टूटता है। कोई Codex को मर्ज करने की अनुमति देता है क्योंकि समीक्षा घर्षण की तरह लगती है। वह मिनट एक ऐसी प्रणाली को अलग करता है जो सुधारती है और एक ऐसी प्रणाली जो बहती है।

चरण 8. इसे एक कैडेंस पर रखें

हर जवाब के बाद इसे न चलाएं। इस तरह एक सिस्टम एक जोरदार खाते में ओवरफिट हो जाता है।

सप्ताह होने दें, परिणाम जमा होने दें, फिर ट्यून करें।

scripts/weekly_tune.sh बनाएं:

1#!/usr/bin/env bash
2set -euo pipefail
3
4cd "$(dirname "$0")/.."
5
6python3 evals/score.py || true
7scripts/run_codex_step.sh improve_scoring
8python3 evals/score.py
9scripts/run_codex_step.sh pr_summary > outputs/pr-summary.md
10scripts/open_pr.sh

फिर cron:

10 8 * * MON cd ~/codex-self-improving-outbound && scripts/weekly_tune.sh

यदि आप GitHub Actions का उपयोग करते हैं, तो समान आकार रखें:

1name: weekly-outbound-tune
2
3on:
4  schedule:
5    - cron: "0 8 * * 1"
6  workflow_dispatch:
7
8jobs:
9  tune:
10    runs-on: ubuntu-latest
11    steps:
12      - uses: actions/checkout@v4
13      - uses: actions/setup-python@v5
14        with:
15          python-version: "3.11"
16      - run: pip install -r requirements.txt
17      - run: python3 evals/score.py || true
18      - run: scripts/weekly_tune.sh

पहले दो ट्यून-अप हाथ से चलाएं। हर अंतर पढ़ें। देखें कि जब नमूना पतला होता है तो Codex क्या बदलने की कोशिश करता है। एक बार प्रस्ताव उबाऊ हो जाने के बाद, इसे एक शेड्यूल पर रखें।

अच्छा कैसा दिखता है। एक साप्ताहिक PR सबूत, अंतर और eval परिणाम के साथ दिखाई देता है। आप इसे मर्ज, संपादित या बंद करते हैं।

यह कहां टूटता है। काम चलता है, कोई समीक्षा नहीं करता है, और PR जमा हो जाते हैं। एक सेल्फ-इम्प्रूविंग सिस्टम में अभी भी एक मानव आदत है: अंतर पढ़ें।

क्लोन-एंड-रन वर्जन

रिपॉजिटरी को चार कमांड के साथ शिप करना चाहिए:

1git clone <repo>
2cd codex-self-improving-outbound
3python3 -m venv .venv
4source .venv/bin/activate
5pip install -r requirements.txt
6python3 evals/score.py
7python3 scripts/propose_improvement.py

अपेक्षित पहला रन:

1score=0.75
2changed config/scoring.yaml
3implementation_page_visit: 4 -> 6
4score=1.00
5open PR for human review

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

डिलीवरी को वायर करके शुरू न करें। सुधार लूप को साबित करके शुरू करें।

पूर्ण वर्जन: max

यह रिपॉजिटरी मैनुअल लेयर है। यह फ़ाइलों, सार्वजनिक सिग्नलों और आपकी Codex योजना से चलता है। यह आकार सिखाता है क्योंकि हर नियम उजागर होता है।

yourmax.ai वही सिस्टम है जिसमें सीम छिपी हुई हैं।

एक रिपॉजिटरी के बजाय जिसे आप स्वयं वायर करते हैं, max वह एजेंट है जिसका आप सीधे उपयोग करते हैं। यह बाजार में गति का पता लगाता है, तय करता है कि किससे संपर्क करना है और अभी क्यों, आपकी मंजूरी के लिए ईमेल और LinkedIn पर आउटरीच का मसौदा तैयार करता है, और परिणामों से सुधार करता रहता है।

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

यदि आप पूर्ण रिपॉजिटरी चाहते हैं, तो आप मुझे बता सकते हैं और मैं इसे आपके पास भेज दूंगा।