मल्टी-एजेंट ऑर्केस्ट्रेशन
कई एजेंट चलाइए। क्रम controller को तय करने दीजिए।
कुछ काम का क्रम पहले से लिखा नहीं जा सकता। type: controller सेट कीजिए, घोषित कीजिए कि रन खत्म होने पर क्या सच होना चाहिए, और Dagu मॉडल को यह चुनने देता है कि निष्कर्ष आते जाने पर अगला एजेंट स्टेप कौन सा चले। हर action सामान्य वर्कफ़्लो स्टेप ही रहता है, लॉग, retries, अनुमोदन और ऑडिट इतिहास के साथ।
# code-review.yaml
type: controller
llm:
provider: anthropic
model: claude-opus-5
system: |
Get top_n.py past both reviews. When a review fails, pass its finding
to revise, then ask that same reviewer again. A revision made for one
reviewer can break the other.
steps:
- name: review_simplicity
description: Judge simplicity. Prints PASS, or FAIL with what to change.
action: harness.run
with:
provider: opencode
prompt: Read top_n.py. Print "PASS" or "FAIL: <what to change>".
- name: review_correctness
description: Judge correctness. Prints PASS, or FAIL with the bug.
action: harness.run
with:
provider: codex
prompt: Read top_n.py. Print "PASS" or "FAIL: <the bug>".
- name: revise
description: Edit top_n.py to resolve one review finding.
action: dag.run
with: { dag: revise }
tasks:
- name: simplicity_passed
description: The latest simplicity review returned PASS on the current file.
- name: correctness_passed
description: The latest correctness review returned PASS on the current file.स्टेप का क्रम नहीं, पूर्णता की शर्तें घोषित करें
हर action असली एजेंट CLI है: Claude, Codex, Gemini, OpenCode
हर task completed, skipped या failed के रूप में निपटता है
मानव उत्तर की प्रतीक्षा में कोई प्रोसेस चलता नहीं रहता
At a glance
Controller वर्कफ़्लो बनाम एजेंट फ़्रेमवर्क
आप पूर्णता की शर्तें घोषित करते हैं। जब कोई task खुला नहीं बचता, रन समाप्त हो जाता है।
या तो मॉडल खुद तय करता है कि काम हो गया, या हर रास्ता पहले से खींचकर हाथ से संभाला जाता है।
प्रतीक्षारत रन अपना प्रोसेस समाप्त करता है और नए प्रोसेस पर फिर शुरू होता है।
लंबी प्रतीक्षा का अर्थ आमतौर पर एक जीवित प्रोसेस और चलाने के लिए एक state store होता है।
शेड्यूल, कतारें, retries, artifacts और ऑडिट इतिहास DAG रन से आते हैं।
हर प्रोजेक्ट में दोबारा बनाया जाता है, या किसी होस्टेड control plane को सौंप दिया जाता है।
वर्कफ़्लो फ़ाइल में लिखे स्टेप का समुच्चय।
जो कुछ भी tool परिभाषाएँ अनुमति देती हैं।
In depth
Where each tool fits
जो लिखा नहीं जा सकता, वह क्रम ही है
ग्राफ़ exit code पर शाखा बना सकता है। वह इस पर शाखा नहीं बना सकता कि समीक्षा ने वास्तव में क्या कहा। Controller वर्कफ़्लो actions को स्थिर रखता है और केवल क्रम सौंपता है।
- स्टेप actions की सूची बन जाते हैं, इसलिए संभालने के लिए कोई depends नहीं बचता
- tasks सूची घोषित करती है कि रन खत्म होने पर क्या सच होना चाहिए
- Controller एक एजेंट का निष्कर्ष अगले एजेंट के parameters में ले जाता है
मॉडल क्रम चुनता है, क्षमता कभी नहीं
Controller केवल उन्हीं स्टेप में से चुनता है जो आपने घोषित किए हैं। वह न कोई स्टेप गढ़ सकता है, न अपना shell कमांड लिख सकता है, न ही उस तक पहुँच सकता है जिसका नाम फ़ाइल में नहीं है, इसलिए प्रभाव क्षेत्र वर्कफ़्लो परिभाषा जितना ही है।
- हर एजेंट को होस्ट पर, या स्पष्ट mounts और egress नियमों वाले कंटेनर sandbox में चलाइए
- हर भूमिका को अपना provider और मॉडल दीजिए, ताकि कोई मॉडल अपने ही काम को न आँके
- जिस पर भरोसा बन जाए उसे सब-वर्कफ़्लो में ले जाइए, वह निर्णय रहना बंद कर देता है
प्रोडक्शन नियंत्रण रन से आते हैं, फ़्रेमवर्क से नहीं
Controller रन एक DAG रन ही है। शेड्यूल, कतारें, retries, artifacts और ऑडिट इतिहास ज्यों के त्यों लागू होते हैं, और एजेंट के ख़र्च की सीमाएँ prompt के निर्देश नहीं, इंजन की सेटिंग हैं।
- ask_user रन को टिकाऊ ढंग से रोकता है: प्रोसेस समाप्त होता है और worker slot मुक्त हो जाता है
- कोई घंटों बाद उत्तर देता है और रन नए प्रोसेस पर फिर से शुरू हो जाता है
- turn, action प्रयास और प्रश्नों की सीमाएँ रन को असफल करती हैं, असीमित ख़र्च नहीं होने देतीं
किसी भी रन को बाद में दोबारा बनाया जा सकता है
Controller में निर्भरता की कोई कड़ी नहीं होती, इसलिए रन ग्राफ़ के बजाय उन निर्णयों के क्रम के रूप में दिखाया जाता है जो वास्तव में लिए गए।
- निर्णयों की टाइमलाइन: हर turn पर एक पंक्ति, प्रयासों की संख्या, अवधि और उत्पन्न child run के लिंक के साथ
- task दृश्य जो बताता है कि controller ने हर लक्ष्य को किस कारण से निपटाया
- पूरा transcript, जिसमें मॉडल द्वारा देखा गया हर tool परिणाम शामिल है
FAQ
Practical questions before adopting Dagu
Controller वर्कफ़्लो एजेंट लूप से किस तरह अलग है?
सादा लूप यह तय करना मॉडल पर छोड़ देता है कि काम कब पूरा हुआ। Controller लूप तो रखता है, पर समाप्ति की शर्त वापस ले लेता है: आप tasks और «पूरा होने» का अर्थ घोषित करते हैं, और जब कोई task खुला नहीं बचता तो रन समाप्त हो जाता है।
अगर कोई task अनावश्यक निकले तो क्या होता है?
Controller उसे skipped चिह्नित करता है और कारण दर्ज करता है, और रन फिर भी सफल रहता है। skipped और failed अलग स्थितियाँ हैं क्योंकि «करने को कुछ था ही नहीं» और «यह किया नहीं जा सका» ऑडिट लॉग में अलग परिणाम हैं।
क्या अलग-अलग स्टेप अलग-अलग मॉडल इस्तेमाल कर सकते हैं?
हाँ। हर Agent Harness स्टेप अपना provider और मॉडल बताता है, और controller का अपना मॉडल अलग से कॉन्फ़िगर होता है, इसलिए एक सस्ता मॉडल महँगे विशेषज्ञों को चला सकता है या दो provider एक-दूसरे की जाँच कर सकते हैं।
रन को असीमित ख़र्च करने से कैसे रोकें?
सीमाएँ इंजन लागू करता है। एक रन में कोई action अधिकतम पाँच बार चलता है, अधिकतम पाँच प्रश्न पूछे जाते हैं, और turn की सीमा डिफ़ॉल्ट रूप से पचास है जिसे घटाया जा सकता है। सीमा तक पहुँचने पर रन असफल होता है और बताता है कि क्या खुला रह गया।
सामान्य ग्राफ़ कब बेहतर रहता है?
अगर ग्राफ़ खींचा जा सकता है, तो ग्राफ़ ही खींचिए। type: graph डिफ़ॉल्ट बना हुआ है क्योंकि वह तेज़, सस्ता और पुनरुत्पाद्य है। Controller तभी उठाइए जब क्रम वाकई इस पर निर्भर करता हो कि पिछले स्टेप ने क्या दिया।
Next step
Start with one workflow.
Install Dagu, move one fragile script or agent task into YAML, and decide from a real run history.