فوّض المهام الكبيرة لوكيل جديد

معضلة الوكيل الأب

تخيّل أنك تطلب من Claude Code «افهم كيف تتعامل هذه الـ codebase المؤلفة من 100,000 سطر Rust مع التزامنية». الطريقة المنطقية: يُشغّل ls وcat وgrep في السياق الرئيسي. المشكلة: هذه الجولة الاستكشافية ستُكدّس 30 tool_result في messages[]، كل منها آلاف الـ token. بحلول وقت كتابة الإجابة، امتلأ السياق بعملية الاستكشاف — وبعد خطوات قليلة إضافية سيبلغ الحد الأقصى ويتشتت الإخراج.

حل s04: إسناد مهمة الاستكشاف لوكيل جديد. يبدأ الوكيل الجديد من messages=[]، يستكشف بمفرده، ثم يُعيد للوكيل الأب الملخص النهائي فقط. سياق الأب يزيد بمقدار سطر واحد فقط: «استدعيت أداة task، والنتيجة هي XXX». نظيف ومرتب.

def run_subagent(prompt: str) -> str:
    sub_messages = [{"role":"user", "content": prompt}]  # 全新 context
    for _ in range(30):  # 安全上限，防失控
        response = client.messages.create(..., messages=sub_messages, tools=CHILD_TOOLS, ...)
        ...
    # 只返回最后的文字，中间推理全部丢弃
    return "".join(b.text for b in response.content if hasattr(b, "text"))

مقارنة سياق الأب والابن

يحاكي هذا المكوّن مهمة حقيقية: «أدرج جميع الأماكن التي تستخدم API قديم في هذا المستودع». يمكنك تشغيلها بنهجين: (أ) الوكيل الأب يقوم بها مباشرة؛ (ب) إطلاق subagent. قارن حجم الـ context النهائي على كلا الجانبين.

CHILD_TOOLS: ما الأدوات التي يملكها الوكيل الفرعي

في تطبيق s04 تفصيل يسهل إغفاله: الوكيل الفرعي لا يملك أداة task.

# 子 agent 只能用基础工具，不能再 spawn 孙子
CHILD_TOOLS = [bash, read_file, write_file, edit_file]

# 父 agent 多一个 task 工具
PARENT_TOOLS = CHILD_TOOLS + [task]

لماذا؟ لتجنب انفجار الإرسال التعاودي. وكيل فرعي يُطلق 4 وكلاء أحفاد، وهؤلاء يُطلقون المزيد — في جولات قليلة عشرات الاستدعاءات المتوازية، ولا الـ token ولا حدود API تتحمل ذلك. قاعدة s04: الإطلاق مسطّح، أب ← ابن طبقة واحدة لا أكثر. التطبيق الحقيقي لـ Claude Code يعمل كذلك — Task tool تمنع استدعاء Task tool بداخلها.

ما المرئي وما الخفي

لنُوضح المسؤوليات: الأسئلة التالية، أيها صحيح T وأيها خاطئ F؟