هندسة الحلقات: دورة مكثفة
15 مفهوماً · من البرمجة الوكيلة إلى الأنظمة التي تصوغ تعليماتها بنفسها
لقد تعلّمت قيادة وكيل برمجة. تعطيه تعليمة، فيقرأ ملفاتك ويجري التعديلات، ثم تتحقق أنت من النتيجة. دور بعد دور بعد دور، وأنت ممسك بالأداة طوال الوقت.
تخيّل الآن أنك تركت الأداة. بدلاً من ذلك، تبني نظاماً صغيراً يستيقظ كل صباح، وينظر إلى ما تغير أثناء الليل، ويقرر ما يستحق العمل، ويسند كل مهمة إلى وكيل، ويتحقق من النتيجة، ولا يستدعيك إلا للقرارات التي تحتاج فعلاً إلى إنسان. تبنيه مرةً واحدة، ثم يصوغ تعليماته بنفسه.
هذه هي هندسة الحلقات. تنتقل المهارة القيّمة من التعليمة التي تكتبها إلى الحلقة التي تصممها. تعلّمك هذه الدورة مم تتكون الحلقة، وكيف تبنيها في كل من Claude Code وOpenCode، وهما يصلان إلى المكان نفسه عبر طريقين مختلفين جداً.
المتطلب السابق: Claude Code وOpenCode: دورة مكثفة. علّمتك تلك الدورة نمط التخطيط، وإدارة السياق، وملف القواعد، والمهارات، والوكلاء الفرعيين، وMCP. تفترض هذه الدورة أنك تعرف ذلك كله. إذا كانت هذه الكلمات جديدة عليك، فأنجز تلك الدورة أولاً. تُبنى هندسة الحلقات فوقها مباشرةً. ومن الأفضل أيضاً أن تكون قد أنجزت التطوير المدفوع بالمواصفات: شرط توقف الحلقة هو في حقيقته مواصفة، وهناك تعلّمت كتابة واحدة. يمكنك المتابعة من دونها، لكن جودة حلقاتك لن تتجاوز جودة الشروط التي تستطيع تحديدها.
هل أنت جديد هنا؟ ملخص في دقيقتين لما ينبغي أن تعرفه مسبقاً
- نمط التخطيط: يقرأ الوكيل ملفاتك ويقترح خطة قبل أن يغيّر أي شيء؛ وتوافق أنت أولاً.
- ملف القواعد (
CLAUDE.md/AGENTS.md): ملاحظات قصيرة ودائمة عن المشروع يقرأها الوكيل في بداية كل جلسة. - المهارات (
SKILL.md): تعليمة محفوظة وقابلة لإعادة الاستخدام لا يحمّلها الوكيل إلا حين تطابقها المهمة. - الوكلاء الفرعيون: مساعد منفصل له نافذة سياقه الخاصة، ينجز عملاً ثم يعيد النتيجة وحدها.
- الموصلات / MCP: الطريقة المعيارية لربط الوكيل بأدوات خارجية، مثل GitHub وSlack وقاعدة بيانات.
- إدارة السياق: أبقِ المحادثة خفيفة؛ يسوء أداء النموذج وتزداد كلفته كلما امتلأت.
إذا كان أي من ذلك جديداً عليك، فأنجز الدورة المكثفة في البرمجة الوكيلة أولاً؛ فهذه الدورة تُبنى فوقها مباشرةً.
في منتصف 2026 قال صانعو هذه الأدوات الأمر بوضوح. صاغ Boris Cherny، مبتكر Claude Code، الفكرة هكذا: «لم أعد أكتب تعليمات إلى Claude. لدي حلقات تعمل وتكتب التعليمات إلى Claude... مهمتي هي كتابة الحلقات». وقال Peter Steinberger من OpenClaw: «ينبغي أن تصمم حلقات تكتب التعليمات إلى وكلائك». ثم سمّى Addy Osmani هذا النمط وسرد أجزاءه. لم يقل أي منهم إن العمل صار أسهل؛ بل قالوا إن المهارة القيّمة انتقلت. وعلى هذه الفكرة تقوم الدورة كلها. (تجد مصدر كل اقتباس وادعاء في المصادر والقراءات الإضافية في النهاية.)
التحول الذهني في صورة واحدة

تتناول هذه الدورة أداتين جنباً إلى جنب للسبب نفسه الذي تناولتهما به الدورة السابقة: إذا نجحت تقنية في كليهما، فهي مهارة حقيقية وليست حيلة تخص أداة واحدة. لكن الأداتين تختلفان فعلاً هنا، وهذا الاختلاف درس بحد ذاته. يأتي Claude Code الآن بأجزاء الحلقة داخل المنتج. أما OpenCode فيمنحك الطبقة الأدنى، أي عاملاً تشغّله من نظام التشغيل. سترى الطريقين، وسترى أيضاً أن بنية الحلقة واحدة حتى حين تختلف التوصيلات.
محدّث حتى يونيو 2026. تتغير الأداتان بسرعة، ولا تزال عدة ميزات للحلقات في Claude Code ضمن المعاينة البحثية. قبل أي جلسة، شغّل
claude updateأوopencode upgrade. راجع التوثيق المباشر (code.claude.com/docs، opencode.ai/docs) قبل الاعتماد على حد أو خيار بعينه.
الحلقة الحقيقية تعمل دون مراقبة: تصوغ تعليماتها بنفسها وأنت بعيد. لا يمكن ذلك داخل مربع محادثة claude.ai العادي، فهو ينتظرك دائماً. في المحادثة، أنت الجدول الزمني. لتشغيل حلقة حقيقية تحتاج إلى أداة تستطيع العمل وحدها وفق مؤقت: Claude Code أو OpenCode أو Cowork (انظر دورة Cowork المكثفة). معظم هذه الخيارات ميزات مدفوعة، ولا يزال بعضها ضمن المعاينة البحثية. يمكنك تعلّم الحلقة و_تصميمها_ في أي مكان، لكن تشغيلها بلا مراقبة يحتاج إلى إحدى تلك الأدوات. تعرض هذه الدورة أداتي البرمجة. سؤال منطقي، لأن اسم «claude.ai» يشير عملياً إلى شيئين. الجواب المختصر: لا يستطيع مربع المحادثة تشغيل حلقة، لكن Claude Code، الموجود ضمن حساب claude.ai نفسه، يستطيع ذلك. إذن، المحادثة هي المكان الذي تصمم فيه الحلقة وتتدرب عليها: تصوغ المهارة، وتكتب تعليمة المراجع، وتحدد شرط التوقف، وتشغّل نبضةً واحدة يدوياً. أما Claude Code أو OpenCode فهو المكان الذي تشغّلها فيه. هذا التسليم هو الخطوة الطبيعية التالية بعد التطوير المدفوع بالمواصفات.«لكنني أنجزت دورة التطوير المدفوع بالمواصفات كلها في claude.ai، فهل أستطيع تشغيل حلقة هناك أيضاً؟»
claude.ai/code/routines، على خوادم Anthropic حتى مع إغلاق حاسوبك، ومن دون تثبيت محلي. بهذا المعنى تستطيع إنشاء حلقة حقيقية تعمل بلا مراقبة «من claude.ai». تحتاج هذه الميزة إلى خطة مدفوعة، ولا تزال ضمن المعاينة البحثية.
الجزء 5: حلقة كاملة بطريقتين
قبل أن تسمح لأي حلقة بالعمل وحدها، يجب أن تتضمن هذه العناصر السبعة. وتحتوي الحلقة التي ستبنيها الآن عليها جميعاً:
- شرط نجاح: الطريقة التي تعرف بها أن العمل انتهى، كما في المفهوم 5.
- سقف: حد أقصى للمحاولات أو الدقائق أو الإنفاق، حتى لا تعمل إلى الأبد، كما في المفهوم 13.
- فرع أو شجرة عمل معزولة: حتى لا يتصادم العمل المتوازي، كما في المفهوم 8.
- مدقق للقراءة فقط: وكيل منفصل يقيّم العمل ولا يستطيع تعديله، كما في المفهوم 11.
- ملف حالة: العمود الفقري الذي يتيح لها التذكر بين التشغيلات، كما في المفهوم 12.
- بوابة بشرية: يذهب العمل الخطر أو الفاشل إلى شخص، ولا يصل مباشرةً إلى
main، كما في الجزء 5. - سجل أو إشعار: حتى يظهر إخفاق الليل ولا يبقى صامتاً، كما في الجزء 6.
إذا غاب عنصر واحد، صارت الحلقة غير آمنة أو كثيرة النسيان أو غير مرئية.
حان الآن جمع الأجزاء. هذه حلقة واحدة لصيانة الصباح: تفرز إخفاقات CI التي حدثت ليلاً، وتصوغ إصلاحات آمنة، وتخضعها للتدقيق، وتفتح طلبات دمج للإصلاحات الآمنة، وتضع علامةً على البقية. سنبنيها مرةً في كل أداة. الملفات أدناه حقيقية، ويمكنك نسخها إلى مستودع وتشغيلها.
بنية الحلقة، وهي نفسها في الأداتين:
- النبض: كل يوم عمل في الساعة 9 صباحاً.
- المهارة: تحفظ مهارة
daily-triageالخطوات، فتظل التعليمة سطراً واحداً. - العمود الفقري: اقرأ
progress.mdفي البداية وحدّثه في النهاية. - شجرة العمل: يُصاغ كل إصلاح في نسخة عمل مستقلة.
- الصانع والمدقق: يصوغ منفّذ الإصلاح، ويقول مراجع منفصل PASS أو FAIL.
- الموصل: افتح طلب دمج عند PASS؛ أما عند FAIL أو مع أي شيء خطر، فاكتبه ضمن «يحتاج إلى إنسان» وتوقف.

المهارة المشتركة
يعمل هذا الملف الواحد في الأداتين. احفظه باسم .claude/skills/daily-triage/SKILL.md في Claude Code أو .opencode/skills/daily-triage/SKILL.md في OpenCode.
---
name: daily-triage
description: >-
Runs the morning maintenance pass. Reads the progress file, gathers overnight
CI failures, open issues, and new audit advisories, drafts safe fixes (each
one checked by a separate reviewer agent), opens pull requests for what passes,
and writes anything risky to the progress file for a human. Use this for the
scheduled morning maintenance loop.
---
# Daily triage
You are the morning maintenance loop. Work through these steps in order.
Do not skip the progress file. It is your only memory between runs.
## 1. Read your memory first
- Open `progress.md`. Read the "In progress" and "Open / needs a human" sections.
- Do not redo anything already listed under "Done".
## 2. Find the work
Gather candidates in this order, and stop once you have at most 5:
1. CI runs that failed since the last entry in `progress.md`.
2. Open issues labelled `bug` or `maintenance`.
3. New advisories from `npm audit` (or this project's audit command).
## 3. Work each candidate
- Create an isolated checkout: a git worktree, or a fresh branch named
`claude/<short-slug>`.
- Draft the smallest fix that solves the one problem. Do not bundle changes.
- Send the diff to the reviewer agent. Wait for its verdict before going on.
## 4. Decide from the verdict
- PASS, and the change is low risk (no public API change, no data migration,
no file deletion): open a pull request. Title it `fix: <one short line>` and
link the issue.
- FAIL, or the change touches anything risky: do NOT open a pull request. Add a
short entry to the "Open / needs a human" section of `progress.md`. Say what
you tried and why you stopped.
## 5. Update your memory last
- Move finished items to "Done" with today's date.
- Save `progress.md`. This is the file tomorrow's run will read.
## Rules
- Never open more than 5 pull requests in one run.
- Never change `main` directly. Only `claude/*` branches.
- When in doubt, escalate. A flagged item a human checks is always safer than a
wrong fix shipped while no one was watching.
المراجع، أي المدقق
يطبّق المراجع الفصل بين الصانع والمدقق عملياً. تحتاج إلى الملفين معاً؛ فليسا خيارين بديلين بحسب الأداة. يختلف التنسيق قليلاً بين الأداتين، لذلك يظهر كل ملف كاملاً أدناه.
Claude Code: احفظ الملف باسم .claude/agents/reviewer.md:
---
name: reviewer
description: Reviews a diff against the spec and the test results. Replies PASS or FAIL with reasons. Makes no changes.
tools: Read, Bash(npm test*), Bash(npm run lint*), Bash(git diff*)
model: claude-haiku-4-5-20251001
---
You are a strict, read-only code reviewer. You never edit files.
1. Run the tests and the linter. Read the output yourself. Do not trust a claim
that they pass.
2. Check the change against the project conventions in `CLAUDE.md` and the
relevant spec.
3. Look for bugs, missing edge cases, security risks, and any change to public
behaviour.
Then reply with exactly one of:
- `PASS` — followed by one line saying what you verified.
- `FAIL` — followed by the specific reasons, one per line.
A change that only "looks fine" is not a PASS. The tests must actually pass, and
the change must do only what was asked.
OpenCode: احفظ الملف باسم .opencode/agents/reviewer.md:
---
mode: subagent
model: anthropic/claude-haiku-4-5-20251001
description: Reviews a diff against the spec and tests. Replies PASS or FAIL with reasons. Read-only.
permission:
edit: deny
bash:
"*": deny
"npm test*": allow
"npm run lint*": allow
"git diff*": allow
---
You are a strict, read-only code reviewer. You never edit files.
1. Run the tests and the linter. Read the output yourself. Do not trust a claim
that they pass.
2. Check the change against the project conventions in `AGENTS.md` and the
relevant spec.
3. Look for bugs, missing edge cases, security risks, and any change to public
behaviour.
Reply with exactly one of:
- PASS — followed by one line saying what you verified.
- FAIL — followed by the specific reasons, one per line.
A change that only "looks fine" is not a PASS. The tests must actually pass, and
the change must do only what was asked.
توصيل النبض
أنشئ Routine في claude.ai/code/routines بجدول للساعة 9 صباحاً في أيام العمل، ومستودعك، وموصلي GitHub وSlack. وجّه تعليمته إلى المهارة حتى يبقى تعريف Routine صغيراً:
Run the daily-triage skill.
Start by reading progress.md; finish by updating it.
For each fix: draft it in an isolated worktree, have the reviewer subagent grade it,
open a PR only on PASS, and append anything risky to the "needs a human" section.
تحمل المهارة الخطوات، ويمثل .claude/agents/reviewer.md المدقق، ويمنع isolation: worktree اختلاط الإصلاحات المتوازية، ويفتح موصل GitHub طلبات الدمج. ولأنها Routine سحابية، تعمل في التاسعة صباحاً سواء كان حاسوبك مفتوحاً أم لا، ضمن حد التشغيل اليومي لخطتك.
ابنها كسير عمل في GitHub Actions حتى تعمل في السحابة من دون إبقاء أي جهاز لديك مستيقظاً. يكون Action هو النبض، وopencode run هو العامل، ويحفظ مستودعك المهارة والوكلاء وprogress.md.
name: morning-maintenance
on:
schedule:
- cron: "0 9 * * 1-5"
jobs:
triage:
runs-on: ubuntu-latest
permissions: { contents: write, pull-requests: write, issues: write }
steps:
- uses: actions/checkout@v6
with: { persist-credentials: false }
- uses: anomalyco/opencode/github@latest
env: { ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} }
with:
model: anthropic/claude-sonnet-4-6 # confirm with `opencode models`
prompt: |
Run the daily-triage skill.
Read progress.md first; update it last.
For each candidate fix: draft it on a new branch, then invoke the
@reviewer subagent to grade it. Open a PR only when the reviewer
replies PASS. Append anything risky to the "needs a human" section
of progress.md and leave it for the maintainer.
يمثل وكيل reviewer، الذي يعمل بنموذج أرخص وللقراءة فقط، المدقق. وتؤدي الفروع الجديدة وظيفة عزل شجرة العمل داخل CI، ويفتح تطبيق OpenCode في GitHub طلبات الدمج. هل تريده على جهازك بدلاً من GitHub؟ تعمل التعليمة نفسها تماماً من سطر cron يستدعي opencode run؛ لا يتغير إلا النبض.
كيف يبدو صباح حقيقي واحد
صممت كل ما سبق مرةً واحدة. إليك تشغيلاً واحداً من النوع الذي قد تستيقظ لتجده. المثال أدناه يوضح البنية، وليس تسجيلاً فعلياً:
[09:00] daily-triage fires
→ reads progress.md: 1 item still "in progress" (lodash bump), nothing new flagged
→ finds: 2 CI failures overnight, 1 new npm-audit advisory
→ CI failure #1 (flaky auth test):
drafts fix on branch claude/fix-auth-retry
reviewer → PASS (tests green; retries on token refresh; no API change)
→ opens PR #142, links the issue
→ CI failure #2 (type error in report.ts):
drafts fix on branch claude/fix-report-types
reviewer → PASS → opens PR #143
→ advisory (image library):
the safe fix changes the output format
reviewer → FAIL (public behaviour change)
→ writes it to "Open / needs a human" in progress.md, opens no PR
→ updates progress.md, exits
[you, 09:30] two PRs to review, one flagged item to decide on. You typed nothing.
انظر إلى ما حدث. عثرت الحلقة على العمل، وصاغته، ودققته، وشحنت الجزء الآمن، وسلمتك القرار الوحيد الذي يحتاج إلى إنسان. هذه هي هندسة الحلقات في التطبيق. ولاحظ أن الفرق الحقيقي الوحيد بين الأداتين كان النبض ومكان التشغيل. أما كل ما في الوسط، أي المهارة والعمود الفقري وشجرة العمل والصانع والمدقق والموصل، فكان التصميم نفسه.
في حلقة الفرز الصباحية، ما الذي يمنع دمج إصلاح خاطئ وأنت نائم؟ ثلاثة أشياء تعمل معاً: يجب أن يعيد وكيل المراجع PASS، وهذا هو الفصل بين الصانع والمدقق؛ ولا يُسمح إلا للتغييرات منخفضة الخطر بفتح طلب دمج؛ وترسل البوابة البشرية كل عمل خطر أو فاشل إلى ملاحظة «يحتاج إلى إنسان» بدلاً من اعرض الإجابة
main. ولكل تشغيل أيضاً سقف وسجل.
الجزء 6: البقاء مهندساً
تغيّر الحلقة طبيعة العمل، لكنها لا تخرجك منه. تكبر ثلاث مشكلات كلما تحسنت حلقاتك، ولا تصغر. وهذا الجزء هو الأهم في الدورة.
13. تكلفة الرموز هي الحد الحقيقي، لا اختصار لوحة المفاتيح
هذه أكثر طريقة شائعة تفشل بها الحلقات بفارق كبير. تعمل الحلقة مراراً، وغالباً ما تبدأ وكلاء فرعيين، ويشغّل كل وكيل فرعي نموذجه وأدواته. تنمو التكلفة أسرع مما يتوقعه معظم الناس. والحلول بسيطة:
- ضع سقفاً لكل حلقة: حد أقصى للمحاولات أو الدقائق أو الإنفاق، دائماً، كما في المفهوم 5.
- طابق النموذج مع المهمة: استخدم نموذجاً قوياً للتخطيط والتدقيق، ورخيصاً لتنفيذ العمل. هذا أكبر توفير منفرد، وقد تعلّمته في الدورة السابقة.
- أبقِ تعليمة الحلقة وملف القواعد قصيرين: تدفع تكلفتهما في كل نبضة. انقل التفاصيل إلى مهارات لا تُحمّل إلا عند استخدامها.
- شغّلها بوتيرة أقل: يكفي غالباً تشغيلها مرةً كل ساعة بدلاً من كل خمس دقائق، وتكون التكلفة أقل بنحو 12 مرة.
تصور سريع للأرقام، وهو توضيحي. لنفترض أن نبضةً واحدة، تشمل الصانع والمدقق، تقرأ نحو 40 ألف رمز وتكتب نحو 6 آلاف. بسعر Sonnet 4.6 البالغ 3 دولارات و15 دولاراً لكل مليون رمز، تكلف النبضة نحو 0.20 دولار. وخمس نبضات يومياً في شهر عمل من 20 يوماً تكلف نحو 20 دولاراً، وهذا رخيص. لكن تشغيل الحلقة نفسها كل خمس دقائق على مدار الساعة يعني أكثر من مئة ضعف عدد النبضات، فتتجاوز التكلفة بسهولة 1000 دولار شهرياً من دون قيمة إضافية. الوتيرة، لا اختصار لوحة المفاتيح، هي موضع الإنفاق.

النموذج هو الرافعة الثانية في طريق OpenCode. تفترض الأرقام السابقة استخدام Sonnet 4.6. تشغّل أوامر حلقات Claude Code نماذج Claude، لكن OpenCode يتيح لك اختيار النموذج، ويمكن لنموذج رخيص أن يخفض تكلفة النبضة كثيراً. يشغّل DeepSeek V4 Flash، بسعر يقارب 0.14 و0.28 دولار لكل مليون رمز، النبضة نفسها بنحو 0.007 دولار، أي أرخص بنحو 30 مرة. وهكذا تصبح حلقة العشرين دولاراً شهرياً أقل بكثير من دولار واحد. لكن توجد ملاحظتان صريحتان. أولاً، صانع رخيص ومدقق موثوق: يكتب النموذج الأضعف إصلاحات أسوأ، وقد يستهلك نبضات أكثر أو يفشل التدقيق مرات أكثر، فتلتهم إعادة المحاولة الوفر. استخدم النموذج الرخيص صانعاً ميكانيكياً يعمل وفق مواصفة واضحة، واحتفظ بمدقق تثق به؛ ومشغّل الاختبار وlinter هما أرخص مدقق وأكثره صدقاً. ثانياً، تظل الوتيرة العامل الغالب: حتى النموذج الأرخص 30 مرة قد يكلف أكثر من Sonnet إذا عمل كل خمس دقائق بينما يعمل Sonnet كل ساعة. يخفض النموذج قيمة الفاتورة، لكن عدد مرات التشغيل وإعادة المحاولة هو ما يحددها.
يأتي الإخفاق الشائع بالصورة نفسها دائماً: حلقة تعمل وحدها طوال الليل، وتحاول تحقيق شرط توقف مستحيل، فتكرر المحاولة بلا نهاية. ضع سقفاً قبل بدء الحلقة، وراقب تشغيلاتها الحقيقية الأولى، ثم دعها تعمل وحدها.
14. لا يزال التحقق من العمل مسؤوليتك
الحلقة التي تعمل وحدها ترتكب الأخطاء وحدها أيضاً. يجعل الفصل بين الصانع والمدقق قول الحلقة «انتهيت» ذا معنى، لكن «انتهيت» يظل ادعاءً لا دليلاً. لم تختفِ وظيفتك، بل انتقلت. لم تعد تكتب كل خطوة، لكنك ما زلت من يؤكد أن الحلقة شحنت كوداً يعمل فعلاً. اقرأ الفروق التي فتحتها الحلقة. ثق بها لإنجاز العمل، وتحقق من العمل قبل اعتماده.
15. لا تتوقف عن فهم مشروعك
كلما أسرعت الحلقة في شحن كود لم تكتبه، اتسعت الفجوة بين ما يوجد في مشروعك وما تفهمه أنت فعلاً. هذه الفجوة تكلفة حقيقية، وتوسّعها الحلقة السلسة بصمت. العلاج والفخ هما الفعل نفسه. يبقيك تصميم الحلقة مشاركاً حين تفعله بعناية، ويسمح لك بالتوقف عن التفكير حين تفعله لتجنب العمل. الفعل واحد والنتيجة معاكسة، ولا تستطيع الحلقة معرفة الفرق؛ أما أنت فتستطيع.
يمكن لشخصين بناء الحلقة نفسها تماماً والحصول على نتيجتين متعاكستين. يستخدمها أحدهما للتقدم أسرع في عمل يفهمه بعمق، ويستخدمها الآخر لتجنب فهم العمل كله. ابنِ الحلقة، لكن ابنها كشخص يخطط للبقاء مهندساً، لا مجرد شخص يضغط زر التشغيل.
وهذا هو الخيط الذي يصل الدورة كلها. تمتص الأدوات كل عام مزيداً من آليات الحلقة. التنسيق والمدقق والجدولة، التي كانت قبل عام سكربتات shell تكتبها بنفسك، صارت الآن مدمجة في سير العمل الديناميكي و/goal وRoutines. لكن الأدوات لا تستطيع امتصاص الطرفين اللذين قابلتهما في المفهوم 1: القصد المحدد بدقة تكفي للتحقق منه، والمساءلة عما يُشحن. لهذا نسميه هندسة لا ضغط أزرار، وهذا هو الجزء الذي لا يبلى من المهارة. دع الأدوات تصبح أقوى واعتمد عليها، لكن أبقِ هذين الطرفين بين يديك.
عندما تفشل حلقة وأنت نائم
تفشل الحلقة غير المراقبة من دون مراقبة أيضاً. قبل أن تثق بها طوال الليل، اجعلها قابلةً للملاحظة:
- أرسل المخرجات إلى مكان ستراه: ملف سجل، أو رسالة في Slack أو Discord عبر Channels في Claude Code، أو صندوق فرز. لا ترسلها إلى طرفية أغلقتها بالفعل.
- اكتب سطراً في كل تشغيل، حتى عند الفشل: تضيف كل نبضة ملاحظةً مؤرخة إلى
progress.mdأو إلى سجل، توضح ما حاولته وما نجح وما تعطل. الفشل الصامت هو أسوأ الأنواع. - اجعل التشغيلات قابلةً للإعادة: تمنحك أوامر
opencode run --format jsonوopencode export <id>وopencode session listفي OpenCode السجل الكامل. وفي Claude Code تحتفظ Routine بتاريخ التشغيلات داخل واجهة الويب. - اجعل بلوغ السقف صاخباً: حين تبلغ الحلقة سقفها أو تواجه خطأً، يجب أن تترك ملاحظةً واضحة «يحتاج إلى إنسان»، لا أن تتوقف فحسب.
- اجعلها تستحق نوبة الليل: شغّلها كل ساعة وتحت المراقبة لبضعة أيام قبل السماح لها بالعمل ليلاً دون مراقبة. وحين يبدو شيء خاطئاً، اقرأ العمود الفقري أولاً؛ فهو يخبرك بما فعله آخر تشغيل ناجح.
لا يمكنك الوثوق بحلقة لا تستطيع تنقيحها.
🚀 المشاريع
قراءة الحلقات ليست كبناء واحدة. إليك خمسة مشاريع من السهل إلى الصعب. نفّذها في أي من الأداتين؛ فبنية الحلقة واحدة. استخدم الأمر الموافق للمفهوم: /loop و/goal في Claude Code، أو opencode run مع مؤقت shell في OpenCode.
قاعدتان قبل البدء، في كل مرة:
- استخدم مستودع git يمكنك التخلص منه. تعدّل الحلقة الملفات بنفسها، فلا توجّه حلقاتك الأولى إلى عمل يهمك.
- ضع سقفاً أولاً. حد أقصى للمحاولات أو الدقائق أو الإنفاق، قبل أن تسمح لأي شيء بالعمل وحده، كما في المفهوم 13.
Project 115-30 دقيقةحلقة مراقبةاجعل حلقة تراقب مهمة طويلة وتخبرك لحظة انتهائها.
الصعوبة: سهل · يستخدم: المفهوم 4، الحلقة داخل الجلسة.
ما ستبنيه. ابدأ مهمةً طويلة في مستودعك، مثل سكربت ينتظر مدةً ثم يكتب ملفاً. أنشئ حلقةً داخل الجلسة تتحقق كل دقيقة من انتهاء المهمة، وتخبرك لحظة انتهائها.
تكون قد انتهيت حين تلاحظ الحلقة اكتمال المهمة، وتقول ذلك مرةً واحدة، وتستطيع إيقافها بسلاسة، من دون أن تجلس لمراقبة الطرفية.
Project 230-45 دقيقةاجعل الاختبارات تنجح ثم توقفكرّر حتى يقرر أمر، لا الوكيل، أن العمل انتهى.
الصعوبة: سهل إلى متوسط · يستخدم: المفهوم 5، التشغيل حتى الإنجاز، والمفهوم 11، الصانع والمدقق.
ما ستبنيه. ضع اختبارين أو ثلاثة اختبارات صغيرة فاشلة في مستودعك. ابنِ حلقةً تواصل العمل حتى تنجح الاختبارات، لكن دع أمراً، أي مشغّل الاختبار، يقرر اكتمال العمل بدلاً من الوكيل. ضع سقفاً من 6 محاولات مثلاً.
تكون قد انتهيت حين تتوقف الحلقة لأن الاختبارات نجحت فعلاً، لا لأنها بلغت السقف. وإذا استمرت في بلوغ السقف، فإن شرط التوقف أو التعليمة يحتاج إلى تحسين، وهذا هو الدرس.
Project 345-60 دقيقةموجز الصباح بذاكرةحلقة مجدولة يبني تشغيلها الثاني بوضوح على الأول.
الصعوبة: متوسط · يستخدم: المفهوم 6، الجدول غير المراقب، والمفهوم 12، العمود الفقري.
ما ستبنيه. أنشئ حلقةً مجدولة تعمل مرةً واحدة، وتقرأ progress.md، وتجمع شيئاً بسيطاً من المستودع، مثل تعليقات TODO المفتوحة أو إيداعات اليوم السابق، ثم تكتب ملخصاً قصيراً وتحدّث progress.md بما وجدته وتاريخه.
تكون قد انتهيت حين تشغّلها مرتين ويبني التشغيل الثاني بوضوح على الأول، فلا يكرر ما سجله بالفعل. يثبت ذلك أن العمود الفقري يعمل. وإذا بدأ التشغيل الثاني من الصفر، فلا ذاكرة لحلقتك بعد.
Project 41-2 ساعةحلقة إصلاح بمدقق حقيقييصوغ منفّذ، ويقيّم مراجع منفصل، ولا يفتح طلب دمج إلا PASS.
الصعوبة: متوسط إلى صعب · يستخدم: المفهوم 8، شجرة العمل، والمفهوم 9، المهارة، والمفهوم 11، الصانع والمدقق.
ما ستبنيه. نسخة أصغر من حلقة الجزء 5. اكتب مهارةً قصيرة بخطوات الإصلاح، ووكيل مراجعة يعيد PASS أو FAIL. اختر خطأً حقيقياً واحداً، واجعل المنفّذ يصوغ إصلاحاً في نسخة عمل مستقلة، أي شجرة عمل أو فرع، ثم دع المراجع يقيّمه. لا تفتح طلب دمج إلا عند PASS.
تكون قد انتهيت حين يتحقق أمران معاً: يحصل الإصلاح الجيد على PASS وطلب دمج، ويحصل إصلاح سيئ متعمد تزرعه على FAIL مع أسباب. إذا أجاز المراجع الإصلاح السيئ، فمدققك متساهل جداً؛ شدد قواعده. المدقق الذي يوافق على كل شيء ليس مدققاً.
Project 52-4 ساعاتحلقتك اليومية الخاصةالحلقة الكاملة ذات الأجزاء الستة لمهمة حقيقية، تعمل بلا مراقبة أسبوعاً، وهي المشروع التتويجي.
الصعوبة: مشروع تتويجي · يستخدم: الأجزاء الستة كلها.
ما ستبنيه. اختر مهمةً حقيقية مملة ومتكررة في مشروع تعمل عليه بالفعل، مثل تدقيق الاعتماديات أو فحص حداثة التوثيق أو مسودة سجل التغييرات أو فحص lint. ابنِ الحلقة الكاملة: النبض وشجرة العمل والمهارة والصانع والمدقق والموصل والعمود الفقري. أضف حواجز للميزانية، ثم دعها تعمل.
تكون قد انتهيت حين تعمل بلا مراقبة مدة أسبوع، وتثق بما تشحنه لأنك قرأته لا لأنك توقفت عن القراءة. ثم أجب بصدق عن سؤال المفهوم 15: هل ظل فهمك للمشروع مواكباً لما غيّرته الحلقة؟ إذا لم يحدث ذلك، فأبطئ الحلقة حتى يلحق فهمك بها. وحين تفشل ليلاً، وهذا سيحدث، اتبع خطوات عندما تفشل حلقة وأنت نائم قبل أن تلوم النموذج.
إلى أين تتجه بعد ذلك
- هل تريد تفاصيل الجدولة فقط؟ تغطي صفحة المرجع المهام المجدولة: مهارة الحلقة وأدوات Cron أوامر
/loopوclaude -pوopencode runومجدولات نظام التشغيل بتعمق. - هل تبني حلقات لأعمال غير برمجية؟ تعرض دورة Cowork وOpenWork المكثفة فكرة النبض نفسها للمهنيين، باستخدام مهام مجدولة بدلاً من cron.
- المواصفة التي كتبتها في التطوير المدفوع بالمواصفات هي شرط توقف حلقتك. معايير قبولها هي ما يقيّمه المدقق وما يثبته
/goalقبل التوقف. وحين تبدو الحلقة غير آمنة إذا تُركت تعمل، يكون الحل في الغالب مواصفةً أدق، لا مزيداً من الأتمتة.
المصادر والقراءات الإضافية
تستند هذه الدورة إلى مجموعة صغيرة من المصادر الأولية. يأتي التأطير والاقتباسات من هذه المصادر، وتأتي التفاصيل التقنية من التوثيق الرسمي.
أصل عبارة «هندسة الحلقات»
- Addy Osmani، هندسة الحلقات: المقالة التي سمّت النمط وعرضت نموذج الأجزاء الخمسة مع العمود الفقري. https://addyosmani.com/blog/loop-engineering/
- The New Stack، «قائد Anthropic الذي بنى Claude Code يقول إنه ترك كتابة التعليمات، وأصبح يكتب الحلقات فقط». https://thenewstack.io/loop-engineering/
- جاءت عبارة Boris Cherny «مهمتي هي كتابة الحلقات» من مقابلة مع CNBC نقلها Business Insider. وجاءت عبارة Peter Steinberger «صمم حلقات تكتب التعليمات إلى وكلائك» من منشوره على X.
Claude Code، التوثيق الرسمي
- Routines، للأتمتة السحابية المجدولة والمشغلات وحدود التشغيل: https://code.claude.com/docs/en/routines
- Channels، لإدخال الأحداث إلى جلسة عاملة: https://code.claude.com/docs/en/channels
- تتعمق صفحة الكتاب المرجعية المهام المجدولة: مهارة الحلقة وأدوات Cron في
/loopو/goalوclaude -p.
OpenCode، التوثيق الرسمي
- واجهة سطر الأوامر، وتشمل
opencode runوserveو--attach: https://opencode.ai/docs/cli/ - الوكلاء والوكلاء الفرعيون، بما في ذلك الوكلاء الأساسيون والوكلاء الفرعيون والنماذج المخصصة لكل وكيل: https://opencode.ai/docs/agents/
- تكامل GitHub، ويشمل Action ومشغلات الجدولة وطلبات الدمج والمسائل والأمر
opencode github install: https://opencode.ai/docs/github/
معرّفات النماذج
- Anthropic، تقديم Claude Sonnet 4.6، وهو مصدر سلسلة النموذج
claude-sonnet-4-6: https://www.anthropic.com/news/claude-sonnet-4-6 - Anthropic، معرّفات النماذج وتعيين الإصدارات: يشرح لماذا تكون المعرّفات غير المؤرخة، مثل
claude-sonnet-4-6، لقطةً مثبتة بدءاً من جيل 4.6، بينما تحتفظ نماذج جيل 4.5، مثل Haiku 4.5، بمعرّف أساسي مؤرخ (claude-haiku-4-5-20251001) واسم بديل غير مؤرخ: https://platform.claude.com/docs/en/about-claude/models/model-ids-and-versions
جميع الروابط محدّثة حتى يونيو 2026. تتغير هذه الأدوات كثيراً، لذلك تحقق من أي حد أو خيار أو سلسلة نموذج بعينها في التوثيق المباشر قبل الاعتماد عليها.
ملخص من سطر واحد
توقف عن كتابة التعليمات إلى وكيلك دوراً بعد دور. صمم الحلقة التي تكتب التعليمات إليه نيابةً عنك، بنبض وأربعة أجزاء عاملة وعمود فقري يتذكر، وابقَ المهندس الذي يقرأ ما تشحنه.
وسيلة دراسة بالبطاقات التعليمية
اختبر فهمك
من هنا فصاعداً، يمكنك تشغيل معظم المفاهيم في جلسة حقيقية، لا قراءتها فحسب. أبقِ طرفية مفتوحة بجانب الصفحة (claude أو opencode) وجرّب كل فكرة حين تصل إليها. ابدأ بمستودع git صغير يمكنك التخلص منه، حتى لا تؤذي الحلقة شيئاً يهمك.
ماذا تغطي هذه الدورة
| الجزء | الموضوع | ما تتعلمه |
|---|---|---|
| 1 | التحول | ما الحلقة، وأجزاؤها الستة، والطريقان لبنائها |
| 2 | النبض | جعل شيء يعمل وحده: داخل الجلسة، وحتى الإنجاز، ووفق جدول، واستجابةً لحدث |
| 3 | الجسم | العزل، والمعرفة، والفعل، والفصل بين الصانع والمدقق |
| 4 | العمود الفقري | حالة تبقى بين التشغيلات، وهي الجزء الذي ينساه الناس |
| 5 | الحلقة بطريقتين | حلقة كاملة من فرز الصباح إلى طلب الدمج، بملفات حقيقية وفي الأداتين |
| 6 | البقاء مهندساً | تكلفة الرموز، والتحقق من العمل، والفخاخ التي تكبر كلما تحسنت الحلقات |
| التطبيق | مشاريع تطبيقية | خمس حلقات، من السهل إلى الصعب، تبنيها بنفسك |
هل تفضّل التعلم بالممارسة؟ اقرأ الجزء 5 أولاً لترى حلقة كاملة من البداية إلى النهاية، ثم عُد إلى الأجزاء. وحين تتضح المفاهيم، تمنحك المشاريع التطبيقية خمس حلقات تبنيها بنفسك.
خصص نحو ساعتين لقراءة الدورة. يستغرق بناء الجزء 5 والمشاريع التطبيقية وقتاً أطول، وهذا هو المقصود: أنت تبني حلقات، لا تتصفحها بسرعة.
تسير عبر الدورة طبقتان تتقادم إحداهما أسرع كثيراً من الأخرى. استوعب الأولى، وابحث عن الثانية عند الحاجة.
- الطبقة الدائمة. بنية الحلقة، أي نبض وأربعة أجزاء عاملة وعمود فقري، والفصل بين الصانع والمدقق، والطرفان اللذان لا تستطيع الحلقة أتمتتهما: القصد، وهو تحديد ما تريد بدقة تكفي للتحقق من النتيجة، والمساءلة، وهي تحمل مسؤولية ما يُشحن. هذه هي المهارة، وتبقى صحيحة بعد تغير كل أمر أدناه.
- الطبقة الميكانيكية. كل خيار ومسار ومعرّف نموذج واسم أمر. تتحدث الأدوات أسبوعياً، ولا تزال عدة ميزات هنا ضمن المعاينة البحثية؛ لذلك تعامل مع كل أمر محدد على أنه مؤشر إلى التوثيق المباشر، لا حقيقة تحفظها. إذا اختلفت الدورة مع التوثيق الحالي، فالتوثيق هو المرجع.
إذا تذكرت البنية ذات الأجزاء الستة ونسيت كل ضغطة مفتاح، فقد تعلّمت هندسة الحلقات. وإذا حفظت ضغطات المفاتيح وفاتتك البنية، فقد تعلّمت واجهة سطر الأوامر لهذا الشهر.
📚 وسيلة تعليمية
شاهد العرض التقديمي الكامل: هندسة الحلقات، دورة مكثفة
الجزء 1: التحول
1. من كتابة التعليمات إلى بناء الحلقات
لمدة عامين تقريباً، كانت طريقة الحصول على عمل من وكيل برمجة بسيطة: اكتب تعليمة جيدة، وامنحه سياقاً كافياً، واقرأ ما يعيده، ثم اكتب الشيء التالي. كان الوكيل أداةً تستخدمها دوراً واحداً في كل مرة.
تستبدل الحلقة بك، أي المشغّل، نظاماً. يعثر النظام على العمل، ويوزعه، ويتحقق منه، ويسجل ما فعله، ويقرر ما يأتي بعده. وهو يصوغ التعليمات إلى الوكيل حتى لا تضطر أنت إلى ذلك.
فأين تنتقل القيمة؟ لا تختفي، بل تنقسم بين طرفين لا تستطيع الحلقة أتمتتهما: القصد، أي تحديد ما تريد بدقة ووضوح يكفيان للتحقق من النتيجة، والمساءلة، أي تحمل مسؤولية ما يخرج. تؤتمت الحلقة الوسط، أي الخطوات، ويبقى الطرفان لك. أنت تتقاضى أجراً على القصد والحكم، لا على تجاهل كيفية إنتاج العمل.
الفرق ليس «تعليمة أكبر»، بل بنية عمل مختلفة:
| كتابة التعليمات، كما تعرفها | بناء الحلقات، ما تضيفه هذه الدورة |
|---|---|
| تبدأ أنت كل دور | يبدأ كل دور وفق جدول أو حدث |
| تقرأ المخرج وتقرر ما يأتي بعده | يفحص مدقق المخرج، وتقرر الحلقة ما يأتي بعده |
| يتوقف العمل لحظة توقفك عن الكتابة | يستمر العمل أثناء نومك |
| مهمة واحدة وجلسة واحدة وكامل انتباهك | تشغيلات صغيرة عديدة، معظمها بلا مراقبة، وانتباهك عند البوابة فقط |
ليس هذا سحراً، وليس «اضبطه وانسه». الحلقة التي تعمل وحدها ترتكب الأخطاء وحدها أيضاً. وُجد كل شيء في هذه الدورة لبناء حلقة يمكنك الوثوق فعلاً بتشغيلها دونك. وهذا أصعب من كتابة التعليمات، لا أسهل. المكافأة هي الرافعة: تنجز حلقة جيدة العمل مراراً، وهو عمل كنت ستبدأه يدوياً في كل مرة.
2. مم تتكون الحلقة
تتكون الحلقة التي تعمل فعلاً وحدها من خمسة أجزاء وعمود فقري واحد. سبق أن تعرفت إلى أربعة من الأجزاء الخمسة في دورة البرمجة الوكيلة، وهنا تتولى وظيفة جديدة.

- النبض: جدول، أو حدث، يبدأ الحلقة. بدونه لديك تشغيل واحد، لا حلقة.
- شجرة العمل: عزل يمنع وكيلين يعملان في آن واحد من الكتابة فوق ملفات بعضهما.
- المهارة: معرفة مشروعك مكتوبةً مرةً واحدة، حتى لا يبدأ كل تشغيل من الصفر.
- الوكلاء الفرعيون: الفصل بين الصانع والمدقق؛ الوكيل الذي يكتب الكود ليس الوكيل الذي يقيّمه.
- الموصل (MCP): يتيح للحلقة أن تتصرف داخل أدواتك الحقيقية، مثل فتح طلب دمج أو تحديث تذكرة، بدلاً من تقديم اقتراح فحسب.
ثم يأتي السادس، وهو الذي يتخطاه المبتدئون:
- الحالة / الذاكرة، أي العمود الفقري. ملف على القرص، أو لوحة مثل Linear، يحتفظ بما تم وما يأتي بعده. ينسى النموذج كل شيء بين التشغيلات. يتيح العمود الفقري لتشغيل اليوم معرفة ما فعله تشغيل الأمس. لا عمود فقري، لا حلقة؛ بل خطوة أولى واحدة تتكرر إلى الأبد.
تخصص بقية الدورة قسماً لكل جزء، ثم تعرض مثالاً كاملاً يجمعها.
3. طريقان: منتج يأتي بالأجزاء وطبقة أدنى
هذا هو الموضع الوحيد الذي تختلف فيه الأداتان فعلاً، وهو يشكل كل ما يأتي بعده.

يأتي Claude Code بأجزاء الحلقة داخل المنتج. النبض (/loop و/schedule وRoutines السحابية)، والتشغيل حتى الإنجاز بمدقق مدمج (/goal)، والعزل (--worktree)، واستقبال الأحداث (Channels)، كلها أوامر مدمجة الآن. قبل عام كنت ستكتب مجموعة من سكربتات shell وتعتني بها للحصول على ذلك. أما اليوم فتكتفي غالباً بإعداده.
الأهم هو Routines: عمليات أتمتة سحابية تعمل على خوادم Anthropic حتى مع إغلاق حاسوبك، ويبدأها جدول أو استدعاء API أو حدث GitHub. ثمن هذه السهولة هو حدود يومية للتشغيل لكل حساب، فراجع حدك الحالي في واجهة استخدام Routines بدلاً من الاعتماد على رقم ثابت، إضافةً إلى أن Routines لا تزال معاينةً بحثية قابلة للتغير.
يمنحك OpenCode الطبقة الأدنى. لا يوجد مجدول سحابي مدمج. بدلاً من ذلك، يكون OpenCode هو العامل الذي تستدعيه، وتأتي أنت بالنبض من نظام التشغيل أو CI.
الأمر الأساسي هو opencode run "<prompt>". يشغّل تعليمةً واحدة من دون شاشة المحادثة، ويطبع النتيجة ثم يخرج. هذا الأمر الواحد هو نبضة واحدة من الحلقة. تحوّله إلى حلقة بتغليفه بما يعمل وفق مؤقت: cron أو launchd في macOS وLinux، أو Task Scheduler في Windows، أو GitHub Actions مع مشغّل مجدول. يتطلب ذلك توصيلات أكثر، لكنه يمنحك تحكماً كاملاً، ويعمل على أجهزة لديك أصلاً، ولا يحتاج إلى سحابة المورّد.
لاحظ أن علامتي التبويب تصفان الأجزاء الخمسة نفسها. النبض نبض سواء أكان Routine مُداراً أم سطراً في cron. والفصل بين الصانع والمدقق فكرة واحدة سواء قيّمه /goal أم فعل ذلك تشغيل ثانٍ للأمر opencode run. تعلّم بنية الحلقة مرةً واحدة فتنقلها بين الأدوات. لهذا نعلّم الأداتين.
إلى أين نتجه، الحلقة كلها مبكراً
قبل تفصيل الأجزاء، إليك خط النهاية. تتكون الحلقة التي ستبنيها في الجزء 5 من ست خطوات واضحة:
every weekday at 9am: # 1. Heartbeat
read progress.md # 6. Spine (memory)
find overnight CI failures + issues # what to work on
for each one:
draft a fix in its own checkout # 2. Worktree
using the project's triage skill # 3. Skill
have a separate reviewer grade it # 4. Sub-agents (maker/checker)
if PASS: open a PR via GitHub # 5. Connector (MCP)
if risky: write it to progress.md and leave it for a human
update progress.md # 6. Spine again
احتفظ بهذه الصورة في ذهنك. كل مفهوم في الأجزاء من 2 إلى 4 هو سطر منها.
تعمل حلقة كل صباح، لكن كل تشغيل يبدأ من جديد ولا يتذكر ما فعله بالأمس. أي جزء من الأجزاء الستة مفقود، ولماذا يؤدي غيابه إلى كسر الحلقة؟ المفقود هو العمود الفقري، أي الحالة أو الذاكرة. ينسى النموذج كل شيء بين التشغيلات، ومن دون ملف حالة على القرص تكرر الحلقة خطوتها الأولى إلى الأبد بدلاً من البناء على عمل الأمس.اعرض الإجابة
الجزء 2: النبض
النبض هو ما يحول التشغيل الواحد إلى حلقة. وله أربعة أنواع تبدأ بما «يبقى داخل هذه الجلسة» وتنتهي بما «يعمل من دونك تماماً». تعلّمها بالترتيب؛ تستخدم معظم الحلقات الحقيقية النوعين الأخيرين.

4. حلقات داخل الجلسة، تكرار وأنت تراقب
أبسط نبض هو إعادة تشغيل تعليمة وفق مؤقت ما دامت الجلسة مفتوحة. يفيد ذلك في «راقب هذا حتى ينتهي»، مثل نشر أو اختبار طويل أو مهمة CI.
استخدم مهارة /loop المضمّنة. أعطها فترةً زمنية وتعليمة:
/loop 5m check if the deployment finished and tell me what happened
يحوّل Claude الفترة إلى جدول، ويمنح المهمة معرّفاً، ويشغّل التعليمة كل 5 دقائق ما دامت الجلسة مفتوحة. وعندما تنتهي، ألغها وتابع عملك.
حد واحد ينبغي معرفته: يعمل /loop داخل الجلسة عمداً. إذا أغلقت الطرفية أو دخل الحاسوب في السكون، فإنه يتوقف. هذه ميزة أمان وليست خطأً، لأن الحلقة العابرة داخل الجلسة لا ينبغي أن تعيش أطول منها. استخدم مهمةً مجدولة أو Routine لما يجب أن يستمر، كما في المفهوم 6.
لا يملك OpenCode أمراً باسم /loop. تبني المؤقت بنفسك في shell. ولأن opencode run يخرج بعد تعليمة واحدة، تؤدي حلقة while مع sleep الوظيفة نفسها:
while true; do
opencode run "check if the deployment finished; if it did, say DONE"
sleep 300 # 5 minutes
done
هذه الفكرة نفسها التي ينفذها /loop لكن في طبقة أدنى: يكون shell هو النبض، ويكون opencode run هو النبضة. يبدأ كل تشغيل جديد للأمر opencode run وقت التشغيل كله أولاً، بما فيه الإعدادات والنموذج والإضافات وأي خوادم MCP، قبل تنفيذ شيء واحد. لتجنب دفع تكلفة البدء في كل نبضة، شغّل خادماً مرةً واحدة واتصل به:
opencode serve --port 4096 &
# then, each beat:
opencode run --attach http://localhost:4096 "check the deploy status"
5. التشغيل حتى الإنجاز، الحلقة تقرر متى تتوقف
تتعمد الحلقة ذات المؤقت الثابت البساطة؛ فهي تعمل N مرة مهما حدث. لكنك غالباً تريد فعلياً: «استمر حتى يصبح هذا صحيحاً». هنا تظهر فكرة الصانع والمدقق للمرة الأولى: ينبغي ألا تترك الحلقةُ الوكيلَ الذي أنجز العمل يقرر اكتماله.
استخدم /goal. تعطيه شرط توقف يستطيع Claude إثباته في مخرجاته، أي شيئاً يبرهنه بتشغيل أمر وعرض نتيجته، مثل «تنجح كل الاختبارات في test/auth». يستمر في العمل عبر الأدوار حتى يتحقق الشرط. والجزء المهم هو أن نموذجاً منفصلاً وأصغر، Haiku افتراضياً، يقرأ النص بعد كل دور ويقرر: «هل انتهينا؟» وهكذا لا يقيّم الوكيل الذي كتب الكود عمله بنفسه. توجد دقة مهمة: لا يشغّل ذلك المدقق الأوامر بنفسه، بل يحكم على ما عرضه Claude بالفعل. لذلك يجب أن يكون الشرط شيئاً تستطيع مخرجات Claude إظهاره، لا حقيقة خفية لا يكشفها إلا أمر.
/goal All tests in test/auth pass and `npm run lint` is clean.
سيعدّل ويشغّل الاختبارات ويقرأ الإخفاقات ويحاول من جديد، ولا يتوقف إلا حين يؤكد المدقق تحقق الشرط فعلاً، أو حين توقفه أنت باستخدام /goal clear. لا يوجد أمر مدمج لـ«توقف بعد N محاولة». إذا أردت سقفاً، فاكتبه داخل الشرط (…or stop after 20 turns). اكتب شروطاً يستطيع أمر إثباتها، مثل «الاختبارات ناجحة وlint نظيف»، لا «كود المصادقة جيد». وهنا تؤتي مواصفة التطوير المدفوع بالمواصفات ثمارها: معايير قبولها شروط يستطيع أمر إثباتها، فتمنحك مواصفة جيدة شرط التوقف مجاناً.
لا يملك OpenCode أمراً باسم /goal، لذلك تبني توقف الصانع والمدقق نفسه باستخدام shell ورموز الخروج. النمط هو: ينجز الوكيل العمل، ثم يقرر أمر حقيقي، لا الوكيل، متى يتوقف.
for i in $(seq 1 8); do # cap the tries — never loop forever
opencode run "Make the tests in test/auth pass and fix any lint errors."
if npm test -- test/auth && npm run lint; then
echo "Condition met on try $i"; break
fi
done
هنا يكون مشغّل الاختبار وlinter هما المدقق، وهو أصدق مدقق موجود، لأن الأمر لا يستطيع إقناع نفسه بأن العمل جيد. ولتحقق أذكى، شغّل opencode run مرةً ثانية مع وكيل مخصص للمراجعة، كما في المفهوم 11، واجعله يطبع PASS أو FAIL. ضع سقفاً للمحاولات دائماً؛ فإعادة المحاولة بلا حد هي الطريقة التي تفلت بها فواتير الرموز من السيطرة.
تحتاج دائماً إلى نوعين من التوقف: شرط نجاح، أي أن العمل انتهى، وسقف لعدد المحاولات أو الدقائق أو الإنفاق. ستنفق حلقة لها شرط نجاح بلا سقف كامل ميزانية الرموز في محاولة تحقيق هدف مستحيل.
6. جداول بلا مراقبة، تعمل أثناء نومك
هذا هو النبض الذي يمنح هندسة الحلقات قيمتها: مهمة تعمل سواء كنت أمام الحاسوب أم لا. «كل يوم عمل في التاسعة صباحاً، افرز إخفاقات CI الليلية». «كل يوم اثنين، افحص الاعتماديات وافتح طلب دمج بالإصلاحات الآمنة».
يوجد نوعان بحسب حاجتك إلى تشغيل الحاسوب:
Routines السحابية، ويمكن إغلاق الحاسوب. هذا هو الخيار الحديث الافتراضي. أنشئ Routine في claude.ai/code/routines أو تطبيق سطح المكتب أو باستخدام /schedule في CLI؛ تكتب الخيارات الثلاثة إلى الحساب السحابي نفسه. تجمع Routine تعليمةً ومستودعات يمكنها لمسها وموصلاتها ومشغلاً، مثل جدول أو API أو حدث GitHub، ثم تعمل على خوادم Anthropic. لاحظ حدود التشغيل اليومية لكل حساب، وأن Routine لا تستطيع افتراضياً الدفع إلا إلى فروع تبدأ بـ claude/. هذا حاجز أمان مقصود يمكنك رفعه لكل مستودع من إعداد Allow unrestricted branch pushes.
تشغيل بلا واجهة مرةً واحدة ضمن cron لديك، مع بقاء الحاسوب مفتوحاً ودون سحابة Anthropic. يشغّل claude -p تعليمةً واحدة ثم يخرج؛ ضعه مباشرةً في crontab:
# every weekday at 9am: sort through CI and summarize failures
0 9 * * 1-5 cd /path/to/repo && claude -p "check the CI dashboard and summarize any failures" >> ~/claude-cron.log 2>&1
للتفصيل الكامل، راجع صفحة الكتاب المهام المجدولة: مهارة الحلقة وأدوات Cron.
يأتي نبض OpenCode غير المراقب دائماً من نظام التشغيل أو CI. هذا هو طريق OpenCode. استخدم opencode run من دون شاشة المحادثة، ودع المجدول يشغّله.
على جهازك باستخدام cron:
# every weekday at 9am: sort through CI and summarize failures
0 9 * * 1-5 cd /path/to/repo && opencode run "check the CI dashboard and summarize any failures" >> ~/opencode-cron.log 2>&1
في السحابة باستخدام GitHub Actions، ولا يلزم أن يبقى أي جهاز لديك مفتوحاً. سلسلة model أدناه توضيحية؛ شغّل opencode models لمعرفة المعرّفات الدقيقة التي يعرفها تثبيتك:
name: Scheduled OpenCode Task
on:
schedule:
- cron: "0 9 * * 1-5" # weekdays at 9am UTC
jobs:
opencode:
runs-on: ubuntu-latest
permissions: { contents: write, pull-requests: write, issues: write }
steps:
- uses: actions/checkout@v6
with: { persist-credentials: false }
- uses: anomalyco/opencode/github@latest
env: { ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} }
with:
model: anthropic/claude-sonnet-4-6 # confirm with `opencode models`
prompt: |
Review the codebase for TODO comments and summarize them.
If any are worth acting on, open an issue to track them.
يكون prompt مطلوباً للأحداث المجدولة، فلا يوجد تعليق يستمد منه التعليمات. ويجب منح contents: write وpull-requests: write إذا كان على الحلقة فتح فروع أو طلبات دمج.
تشير وثائق OpenCode الرسمية الحالية إلى GitHub Action باسم anomalyco/opencode/github@latest، بينما لا تزال بعض الأدلة القديمة تعرض sst/opencode/github@latest. يشير الاثنان إلى المشروع نفسه؛ استخدم ما يولده الأمر opencode github install. أما النماذج، فـanthropic/claude-sonnet-4-6 هو معرّف Sonnet الحالي. وصلت المعرّفات غير المؤرخة مع جيل 4.6، حيث تكون السلسلة غير المؤرخة نفسها لقطةً مثبتة. أما نماذج جيل 4.5 الأقدم، مثل Haiku 4.5، فلها معرّف أساسي مؤرخ (claude-haiku-4-5-20251001) واسم بديل غير مؤرخ (claude-haiku-4-5) يشير إلى أحدث لقطة. تثبّت الأمثلة أدناه معرّف Haiku المؤرخ لإمكان إعادة الإنتاج. شغّل opencode models لمعرفة السلاسل الدقيقة التي يعرفها تثبيتك.
7. التشغيل المدفوع بالأحداث، استجابةً لما يحدث
يسأل الجدول: «هل أتحقق كل ساعة؟» بينما يقول الحدث: «استجب فور وقوع X». يُفتح طلب دمج، أو تُنشأ مسألة، أو تصل رسالة، فتعمل الحلقة استجابةً لذلك.
يوجد طريقان. تقبل Routines مشغّل GitHub webhook، فتستطيع Routine العمل عند الدفع أو فتح طلب دمج جديد، لا وفق الساعة فحسب. أما الأحداث الشبيهة بالمحادثة، فتدفع Channels الرسائل من مصادر خارجية، مثل Telegram وDiscord وiMessage المدمجة، أو مستقبل webhook توصله بنفسك، مباشرةً إلى جلسة عاملة. إنها الشريك المدفوع بالأحداث للجدولة. راجع code.claude.com/docs/en/channels.
ثبّت وكيل GitHub مرةً واحدة باستخدام opencode github install، فيضيف الملف .github/workflows/opencode.yml. بعد ذلك يستجيب OpenCode لأحداث المستودع، مثل pull_request وissues وتعليقات /oc أو /opencode، ويعمل داخل مشغلات GitHub Actions:
name: opencode-review
on:
pull_request:
types: [opened, synchronize, reopened, ready_for_review]
jobs:
review:
runs-on: ubuntu-latest
permissions: { contents: read, pull-requests: read }
steps:
- uses: actions/checkout@v6
with: { persist-credentials: false }
- uses: anomalyco/opencode/github@latest
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
model: anthropic/claude-sonnet-4-6
use_github_token: true
prompt: |
Review this pull request for bugs, quality issues, and security risks.
يراجع OpenCode طلب الدمج افتراضياً عند وقوع حدث pull_request بلا تعليمة.
تريد حلقةً تستمر في إصلاح اختبار فاشل حتى ينجح، ثم تتوقف من تلقاء نفسها. أي نبض تستخدم، ومن يقرر «انتهى»؟ استخدم التشغيل حتى الإنجاز: اعرض الإجابة
/goal في Claude Code، أو حلقة shell محدودة في OpenCode. يقرر أمر، أي مشغّل الاختبار، أن العمل انتهى؛ ولا يقرر ذلك أبداً الوكيل الذي كتب الإصلاح. وتظل الحلقة بحاجة إلى سقف حتى لا تعيد المحاولة إلى الأبد.
الجزء 3: الجسم
يبدأ النبض الحلقة. أما هذه الأجزاء الأربعة فهي ما تفعله الحلقة في كل نبضة. تعرفت إليها في دورة البرمجة الوكيلة بوصفها إضافات مفيدة، لكنها تصبح أساسية في الحلقة لأن أحداً لا يراقب كل خطوة.
8. العزل: أشجار العمل
لحظة تشغيل أكثر من وكيل في وقت واحد، يبدأون الكتابة فوق ملفات بعضهم، مثل شخصين يعدّلان الأسطر نفسها من دون تنسيق. تصلح شجرة عمل git ذلك: مجلد عمل منفصل على فرعه الخاص ويشارك تاريخ المستودع نفسه. لا تستطيع تعديلات وكيل لمس نسخة عمل وكيل آخر.
الميزة مدمجة. استخدم الخيار --worktree لفتح جلسة داخل نسخة عمل مستقلة، أو اضبط isolation: worktree على وكيل فرعي ليحصل كل مساعد على نسخة عمل جديدة تُنظف تلقائياً بعده. ويمكن لمهمة مجدولة تشغيل عزل شجرة العمل لكل تشغيل، فلا تتصادم التشغيلات المتوازية مع عملك اليدوي.
لا يوجد خيار واحد. تستخدم أشجار عمل git نفسها وتوجّه كل تشغيل إلى واحدة منها. العزل نفسه لكن بصورته الصريحة:
git worktree add ../wt-feature-a feature-a
git worktree add ../wt-feature-b feature-b
( cd ../wt-feature-a && opencode run "implement feature A" ) &
( cd ../wt-feature-b && opencode run "implement feature B" ) &
wait
يمكن لمشغلات مجتمعية، أي مديري أشجار عمل مبنيين حول OpenCode، تولي التنظيم إذا كنت تفعل ذلك كثيراً.
9. المعرفة: مهارات تمنع أي تشغيل من أن يكون «اليوم الأول»
تبدأ الحلقة باردةً كل مرة، في جلسة جديدة لا تتذكر عادات مشروعك. ومن دون مساعدة، تستنتج إعدادك كله أو تخمّنه في كل نبضة، فتهدر الرموز وتدعو الأخطاء. المهارة هي تلك المعرفة مكتوبةً مرةً واحدة في ملف SKILL.md يقرؤه الوكيل في كل تشغيل.
تعمل المهارة بالطريقة نفسها في الأداتين: مجلد يحوي ملف SKILL.md للتعليمات والبيانات الوصفية، مع سكربتات ومراجع اختيارية. قاعدة الحلقة بسيطة: كل ما كنت ستشرحه من جديد في كل تشغيل ينتمي إلى مهارة. خطوات الفرز، وعادات المشروع، وعبارة «لا نفعل ذلك بهذه الطريقة بسبب تلك الحادثة»، كلها تعيش داخل المهارة، فتتراكم خبرة الحلقة بدلاً من إعادة البدء. تجد المعالجة الكاملة في دورة المهارات والموصلات المكثفة.
بدلاً من لصق جدار من التعليمات في جدول لن يحدثه أحد، تصبح تعليمة الجدولة سطراً واحداً: «شغّل مهارة daily-triage». وتحمل المهارة التفاصيل. هكذا تحصل على تعليمة قصيرة، ومنطق سهل التحديث، وتكلفة رموز أقل في كل نبضة.
10. الفعل: الموصلات تجعل الحلقة تتصرف ولا تكتفي بالاقتراح
الحلقة التي لا تستطيع إلا قراءة ملفاتك لا تستطيع إلا الكلام. تتيح لها الموصلات المبنية على MCP أن تفعل: تفتح طلب دمج، وتحدّث تذكرة Linear، وتنشر في Slack، وتستعلم من قاعدة بيانات، وتستدعي API في بيئة التجهيز. هذا هو الفرق بين حلقة تقول «إليك الإصلاح» وحلقة تفتح طلب الدمج وتربط التذكرة وتنشر في القناة بعد نجاح CI.
تتحدث الأداتان بروتوكول MCP، لذلك ينتقل البروتوكول بينهما، لكن التغليف والمصادقة، مثل المحلي مقابل المستضاف وOAuth والصلاحيات، يحتاجان غالباً إلى توصيل خاص بكل أداة.
أضف خوادم MCP إلى إعداداتك، وضمّنها في قائمة موصلات Routine حتى تستطيع التشغيلات غير المراقبة الوصول إليها. الموصلات نفسها التي تستخدمها يدوياً متاحة للتشغيلات المجدولة والسحابية.
صرّح بالخوادم داخل قسم mcp من opencode.json. تبدأ الخوادم المحلية عمليةً فرعية، وتصل البعيدة إلى نقطة HTTPS مع OAuth تلقائي. في opencode run المجدول، شغّل opencode serve مرةً واحدة واستخدم --attach حتى لا تدفع تكلفة بدء MCP في كل نبضة.
11. الصانع والمدقق: الوكلاء الفرعيون
أهم قرار في الحلقة: يجب ألا يكون الوكيل الذي يكتب العمل هو الوكيل الذي يوافق عليه. يكون النموذج متساهلاً جداً حين يقيّم مخرجاته. يلتقط وكيل ثانٍ، بتعليمات مختلفة وغالباً بنموذج مختلف أو أقوى، ما فاته الأول لأنه كان واثقاً من صحته. لهذا السبب وحده تستطيع ترك حلقة تعمل دونك.
عرّف الوكلاء الفرعيين داخل .claude/agents/، واجمعهم في فرق: يستكشف أحدهم، وينفذ آخر، ويتحقق ثالث وفق المواصفة والاختبارات. «المواصفة» هي التي تعلّمت كتابتها في التطوير المدفوع بالمواصفات؛ معايير قبولها هي ما يقيّمه المدقق الموثوق. مواصفة غامضة تعطي حكماً غامضاً. وهذا ما يفعله /goal داخلياً أيضاً: يقرر نموذج جديد هل انتهت الحلقة بدلاً من أن يقيّم العامل نفسه.
يأتي OpenCode بوكلاء أساسيين مدمجين، هما Build وPlan، ووكيل فرعي عام مدمج باسم general، إضافةً إلى explore وscout خلف خيار تجريبي في الإصدارات الحالية. ويمكنك تعريف وكلائك في opencode.json أو ملفات Markdown داخل مجلد الوكلاء. امنح المدقق نموذجاً خاصاً، أرخص غالباً ومخصصاً للقراءة فقط، واجعل الصانع يستدعيه بإشارة @ أو أداة Task. تقسيم شائع: نموذج قوي يستكشف وينفذ، ونموذج مركز يدقق.
---
mode: subagent
model: anthropic/claude-haiku-4-5-20251001
description: Reviews a diff against the spec and tests. Replies PASS or FAIL with reasons.
---
You are a strict code reviewer. You do not make changes.
Check the diff against the spec and the test results, then reply PASS or FAIL with the reasons.
يشغّل كل وكيل فرعي نموذجه وأدواته، لذلك يزيد الفصل بين الصانع والمدقق استهلاك الرموز فعلاً. هذه هي كلفة مدقق يمكنك الوثوق به. أنفقها حين يهم رأي ثانٍ، مثل أي شيء ستودعه الحلقة وأنت بعيد، وتجاوزها في الأعمال المؤقتة المخصصة للقراءة فقط.
11ب. تدوين الجسم: سير العمل الديناميكي
حتى الآن كان الوكيل يجمع جسم النبضة، أي العثور على العمل وصياغة كل إصلاح في نسخة عمل مستقلة وتكليف وكيل آخر بتقييمه، دوراً بعد دور. يتيح لك Claude Code الآن تدوين ذلك التنسيق كله كسكربت يمكن إعادة تشغيله يسمى سير عمل ديناميكياً: تصف المهمة، فيكتب Claude سكربت يوزع العمل على وكلاء فرعيين كثيرين، ثم يشغّله وقت تشغيل في الخلفية بينما تبقى جلستك متاحة. إنه فصل الصانع والمدقق في المفهوم 11 وفصل أشجار العمل في المفهوم 8 ضمن وحدة قابلة للتكرار. ويمكنه تطبيق نمط جودة حقيقي، لا مجرد تشغيل مزيد من الوكلاء؛ إذ يستطيع مراجعون مستقلون فحص نتائج بعضهم على نحو نقدي قبل الإبلاغ عن أي شيء.
اطلب سير عمل بكلمات عادية، مثل «استخدم سير عمل من أجل...»، أو شغّله بالكلمة ultracode، أو نفّذ /deep-research المضمّن. حين يعطي تشغيل ما تريد، اضغط s في عرض /workflows لحفظ السكربت كأمر /command تعيد تشغيله في كل فرع. يبقي حدان الأمر منضبطاً: يوجد سقف للوكلاء، نحو 16 في آن واحد و1000 لكل تشغيل، حتى لا ينفلت السكربت؛ وتعيش ذاكرة التشغيل داخل ذلك التشغيل وحده. يمكنك استئنافه داخل الجلسة نفسها، لكن جلسةً جديدة تبدأ من الصفر.
لا يوجد أمر /workflows. السكربت الذي تكتبه هو سير العمل: حلقة for المحدودة من المفهوم 5، والتوزيع عبر & وwait من المفهوم 8، هما نسخة يدوية من الفكرة نفسها. يحمل shell الخطة، ويمثل كل opencode run وكيلاً، وتكون رموز الخروج هي المدقق. تحصل على تحكم كامل ومن دون سقف للوكلاء، مقابل كتابة التنسيق وصيانته بنفسك.
هذا أسهل خطأ حين تبدأ سير العمل في الظهور قوية. يعمل سير العمل الديناميكي مرةً واحدة حين تبدأه أنت أو إعداد ultracode، وينسى كل شيء عند انتهائه. ليس له نبض ولا عمود فقري؛ لذلك فهو جسم نبضة واحدة، لا حلقة. الحلقة هي التركيب: يشغّل نبض، مثل Routine أو /loop أو cron، النبضة؛ ويكون سير العمل هو الجسم؛ ويكون ملف تقدم يكتبه الوكلاء هو العمود الفقري الذي يقرؤه التشغيل التالي. سير العمل هو المحرك، وRoutine تدير المفتاح، وprogress.md هو الوقود الذي يبقى بين الرحلات.
الجزء 4: العمود الفقري
12. حالة تبقى بين التشغيلات
هذا هو الجزء الذي يتخطاه المبتدئون، وهو ما يجعل الحلقة حلقة. ينسى النموذج كل شيء بين التشغيلات. إذا بدأت كل نبضة من الصفر، فليست لديك حلقة، بل خطوة أولى واحدة تتكرر إلى الأبد. الحل ممل وقوي: احتفظ بالحالة خارج النموذج على القرص.
تعمل طبقتان من الحالة معاً:
- ملف القواعد (
CLAUDE.md/AGENTS.md): العادات الثابتة التي تقرؤها الحلقة في كل تشغيل. أبقه قصيراً؛ فقد عرفت السبب في الدورة السابقة. تدفع تكلفة ملف القواعد المتضخم في كل نبضة. - ملف تقدم: ملف Markdown عادي، أو لوحة Linear عبر MCP، يسجل ما جُرّب وما نجح وما لا يزال مفتوحاً. هذا هو العمود الفقري الحقيقي. يفتحه تشغيل الغد في التاسعة صباحاً ويتابع حيث توقف تشغيل اليوم.
العادة هي: يقرأ كل تشغيل ملف التقدم في البداية ويحدثه في النهاية. حين تكرر الحلقة الخطأ نفسه، لا يكون الحل تعليمةً أذكى؛ بل أن تكتب الحلقة الدرس في ملف القواعد حتى يبقى الإصلاح لكل تشغيل لاحق.
<!-- progress.md — the loop's memory between runs -->
## Done
- 2026-06-22: fixed flaky test in test/auth (retry on token refresh)
## In progress
- Dependency audit: 3 of 7 advisories patched; lodash bump blocked by an API change
## Open / needs a human
- CVE-2026-xxxx in image lib — the fix changes the output format, escalating to a maintainer
لأن ملف التقدم مجرد نص داخل مستودعك، فهو أيضاً سجل ما فعلته الحلقة وأنت بعيد. وحين تجلس عند البوابة البشرية، تقرأ العمود الفقري، لا النص الكامل لكل تشغيل.
أين ينبغي أن تحتفظ الحلقة بما أنجزته حتى الآن، ولماذا لا تحتفظ به في المحادثة؟ على القرص، في ملف تقدم مع ملف القواعد، أو في لوحة مثل Linear. تُمسح ذاكرة النموذج بين التشغيلات، لذلك يعيش كل ما يجب أن يبقى خارج النموذج. يتذكر المستودع؛ ولا يتذكر النموذج.اعرض الإجابة