بناء قوة عمل باستخدام Paperclip: دورة مكثفة في 90 دقيقة

6 سيناريوهات، من الصفر إلى قوة عمل ذكاء اصطناعي مُدارة

Paperclip هو الشركة بالنسبة إلى موظف OpenClaw. حيث أعطتك دورة OpenClaw المكثفة عاملاً واحداً من الذكاء الاصطناعي يعيش على حاسوبك المحمول، تعطيك هذه الدورة الشركة التي توظف أسطولاً منهم وتحكمه وتدققه. العامل الواحد دالة؛ أما قوة العمل فهي مخطط تنظيمي من العمال يعملون ضمن ميزانيات، وتحت موافقات، ويتركون مسار تدقيق. Paperclip هو الشركة حول العامل.

Paperclip شاب ويتحرك بسرعة: عشرات الآلاف من نجوم GitHub بحلول منتصف 2026، ومرخّص بـ MIT، وذاتي الاستضافة، ويعمل بالكامل على حاسوبك المحمول بأمر واحد، بلا حساب ولا بطاقة ائتمان ولا إعداد سحابي. الخاصية الخالية من الاحتكاك التي حققها OpenClaw للعامل، يحققها Paperclip للشركة حوله.

بنهاية هذه التسعين دقيقة سيكون لديك شركة حقيقية معتمدة أصلاً على الذكاء الاصطناعي تعمل على جهازك: كيان شركة له غرض محدد، وعامل موظف على محول وجاهز لتلقي العمل، ومسألة واردة مسندة ومُنجزة بواسطة عامل محلي بلا مفتاح، وموافقة مرفوعة إليك (أنت المجلس) ومقررة بسجل تدقيق دائم، وعامل حقيقي مدعوم بـ LLM حتى تصبح للميزانية بيانات تفرضها، واستعلام SQL واحد يعيد بناء كل ما حدث في أجزاء من الثانية. ليس عرضاً ستنساه بحلول الجمعة؛ بل ركيزة ستلمسها غداً.

---

كيف تعمل هذه الدورة المكثفة. تنزّل مجلداً صغيراً، وتسلمه إلى وكيل البرمجة لديك (Claude Code أو OpenCode)، ثم تمر عبر ستة سيناريوهات. يقرأ الوكيل المجلد، ويثبت Paperclip، ويعد شركتك الأولى، ويوظف عاملك الأول، ويسند أول مسألة، ويفتح أول موافقة، ويستبدل عامل stub بلا مفتاح بعامل LLM حقيقي حتى يصبح لدى الميزانية ما تقيسه، ويجيب عن سؤال تدقيق بمستوى CFO عبر الاستعلام عن سجل النشاط. أنت توجه؛ والوكيل يعمل؛ ويتحول Paperclip إلى مستوى الإدارة الذي تمر عبره قوة عملك.

مسار القراءة · المتطلبات · النسخة العميقة (انقر للتوسيع)

مسار القراءة (ستة سيناريوهات + عادة شهرية واحدة):

1. أقم Paperclip وحدد شركتك. تهيئة أولية، لوحة تحكم عاملة، شركة واحدة مهيأة. نحو 15 دقيقة.
2. وظّف أول عامل. عامل محلي بلا مفتاح (worker-stub.py، موجود في التنزيل) مسجل على محول http، جاهز لتلقي heartbeats. نحو 15 دقيقة.
3. أرسل إلى الشركة أول مسألة حقيقية. تُنشأ مسألة، وتُسند إلى العامل عند وقت الإنشاء، ويلتقطها النبض التالي، وتُحل. نحو 15 دقيقة.
4. ارفع موافقة لفعل محفوف بالمخاطر. رد أموال بقيمة 750 دولاراً يحتاج توقيع المجلس؛ ترفع الطلب، وتقرره، وتقرأ السجل المدقق. نحو 15 دقيقة.
5. استبدل عاملاً حقيقياً يعمل بـ LLM؛ وأعطِ الميزانية أسناناً. لا يؤدي stub بلا مفتاح عملاً قابلاً للفوترة، لذلك لا تتحرك الميزانية. أضف عاملاً حقيقياً مدعوماً بـ Gemini وشاهد الإنفاق يتراكم. نحو 15 دقيقة.
6. استعلم عن مسار التدقيق مثل CFO. استعلام SQL واحد، تاريخ الشركة كله، في أجزاء من الثانية. نحو 10 دقائق.
7. (مرة في الشهر، لا اليوم) شغّل تدقيق قوة العمل. نحو 10 دقائق عندما يحين وقته.

ينتهي كل سيناريو بنجاح قابل للتشغيل. إذا كانت التسعون دقيقة في جلسة واحدة كثيرة، فخذها جلسات منفصلة؛ يبقى كل شيء محفوظاً بينها. تبني السيناريوهات 3 إلى 6 فوق الشركة والعامل من 1 و2.

المتطلبات السابقة (تفترضها الصفحة):

1. Claude Code أو OpenCode مثبت. كلاهما يعمل. إذا لم يكن لديك أي منهما، فأنجز الدورة المكثفة في البرمجة الوكيلة أولاً.
2. Node.js 20 أو أحدث. شغّل node --version في طرفية. إذا كان أقل من v20.0.0، فثبّت LTS من nodejs.org/en/download؛ وسيرشدك وكيل البرمجة إذا طلبت.
3. Python 3. شغّل python3 --version. العامل الذي ستوظفه في السيناريو 2 ملف Python صغير (worker-stub.py، نحو 120 سطراً) موجود في التنزيل ويستخدم المكتبة القياسية فقط: لا شيء تحتاج إلى pip install. يأتي macOS ومعظم Linux مع Python 3؛ وعلى Windows سيساعدك وكيل البرمجة في تثبيته.
4. مفتاح Gemini API مجاني، للسيناريو 5 فقط. تعمل السيناريوهات 1 إلى 4 والسيناريو 6 بلا أي مفتاح API. يستبدل السيناريو 5 العامل بلا مفتاح بعامل LLM حقيقي، وهذا يحتاج إلى مفتاح. الطبقة المجانية من Google تكفي؛ وهو المفتاح نفسه الذي تستخدمه دورة OpenClaw المكثفة. احصل على واحد من aistudio.google.com قبل أن تبدأ، أو عندما تصل إلى السيناريو 5.
5. أنجزت إحدى الدورات السابقة عن عمال الذكاء الاصطناعي، ويفضل OpenClaw أو Digital FTE. فكرة Paperclip هي إدارة قوة عمل من العمال؛ ينبغي أن تعرف ما العامل قبل أن تبدأ توظيفهم.

تريد النسخة المتأنية؟ هناك دورتان مرافقتان على جانبي هذه الدورة في المسار. من Digital FTE إلى عامل إنتاج يغلّف عاملاً واحداً بغلاف متانة Inngest: الخطوة السابقة مباشرة لقوة العمل. ومن قوة عمل ثابتة إلى قوة عمل ديناميكية يحوّل التوظيف إلى قدرة قابلة للاستدعاء: الخطوة التالية مباشرة. تغطي هذه الصفحة مع موجز AGENTS.md مستوى الإدارة من البداية إلى النهاية؛ أما هاتان الدورتان فتضيفان طبقات فوقه ولا تستبدلانه.

---

نمط التعاون

تتقاسم هذه الصفحة ثلاث جهات: أنت، ووكيل البرمجة لديك، وPaperclip. أنت تلصق التعليمات وتتخذ القرارات التي لا يستطيع اتخاذها إلا إنسان. يشغل وكيل البرمجة CLI وAPI في Paperclip، ويراقب السجلات، ويتعافى من الإخفاقات. Paperclip هو مستوى الإدارة: يمسك الشركة، ويوظف العمال، ويحمل العمل إليهم عبر heartbeat، ويسجل كل فعل.

يستخدم كل سيناريو الإيقاع نفسه من خمس خطوات:

1. تلصق جملة واحدة في وكيل البرمجة. إنها موجز، لا سكربت. تصف النتيجة التي تريدها؛ ولا تعدّد الخطوات.
2. يستشير وكيلك AGENTS.md (الموجود أصلاً في سياقه: CLAUDE.md داخل المجلد يستورده تلقائياً عند بدء الجلسة، لذلك لا توجد خطوة جلب) ويقترح خطة. يسمي الأوامر التي ينوي تشغيلها، ويشير إلى أي نقاط قرار. يسألك قبل أول أمر هدّام.
3. توافق وتراقب. يشغّل الوكيل أوامر التثبيت، ويضرب API، ويراقب سجل الخادم، ويعرض لك ما يراه. عندما يصطدم بإخفاق معروف، يتعرف إلى النمط من الموجز ويطبق الإصلاح الموثق.
4. يتوقف وكيلك عند الحد الفاصل. بعض الحركات لا يستطيع فعلها إلا أنت: فتح URL لوحة التحكم، وتقرير هل يُمنح رد أموال بقيمة 750 دولاراً، وتصدير مفتاح API. يسمي الوكيل الحد وينتظر.
5. تنتهي عندما يحدث شيء قابل للملاحظة. صف جديد يظهر في سجل النشاط. مسألة تنتقل إلى done. استعلام SQL يعيد التاريخ المتوقع. يخبرك كل سيناريو بما تراقبه.

هذا كل شيء. يفعل الوكيل ما يجيده الوكيل: التثبيت، والتهيئة، والتنقيح، والاستعلام، والتعافي. وتفعل أنت ما لا يفعله إلا أنت: تقرر وتوافق وتتصرف في الأشياء المرتبطة بحساباتك. هذا الإيقاع، أي وصف الهدف، والحصول على الخطة، والموافقة، والتنفيذ مع التحقق عند كل خطوة، هو نمط التعليمات نفسه في الدورة المكثفة في صياغة تعليمات الذكاء الاصطناعي في 2026؛ وكل سيناريو أدناه يستخدم تعليمتي لصق قصيرتين بدلاً من جدار تعليمات واحد، حتى تختبر الإيقاع بدلاً من أن تقرأ عنه.

حركة تعافٍ واحدة للدورة كلها

إذا انحرف أي شيء في أي لحظة، فلا تحتاج إلى معرفة أوامر CLI أو رموز الأخطاء. الصق هذا في وكيلك:

Something didn't work. Run paperclipai doctor, then read the most recent Paperclip server log, tell me in plain language what you see, and propose a fix I can approve.

يشغّل وكيلك التشخيص، ويقرأ السجل، ويسمي ما يراه، ويقترح الإصلاح. توافق أنت. هذه هي حلقة التعافي لكل سيناريو في هذه الصفحة.

إذا طال السيناريو أكثر من اللازم

لكل سيناريو وقت مخصص، ظاهر في عنوان H2. إذا تجاوزت ضعفي ذلك الوقت، مثل أكثر من 30 دقيقة في سيناريو مدته 15 دقيقة، فأعد وكيلك إلى المسار والصق: "What's blocking us, in one sentence? Let's re-plan from there." الدوران بعد تجاوز الميزانية يعني غالباً أن الوكيل يرتجل؛ وإعادة التثبيت على الخطة تصلح ذلك.

المجلد الذي ستنزله يحتوي على ثلاثة ملفات بالضبط: AGENTS.md، وهو مرجع تشغيلي مضغوط لأي وكيل برمجة يعمل على Paperclip؛ وCLAUDE.md، وهو سطر واحد: @AGENTS.md، يخبر Claude Code أن يستورد الموجز تلقائياً؛ وworker-stub.py، العامل المحلي بلا مفتاح الذي ستوظفه في السيناريو 2. هذه هي البيئة كلها.

Download paperclip-crash-course.zip

فك الضغط في أي مكان. افتح طرفية داخل المجلد المفكوك. شغّل وكيل البرمجة:

cd paperclip-crash-course
claude

صار الموجز محملاً لدى وكيلك الآن. سنمر عبر ستة سيناريوهات واحداً واحداً؛ وينتهي كل سيناريو بنجاح قابل للتشغيل قبل بدء التالي. يفترض هذا الموجز وكيل برمجة قادراً، مثل Claude Code أو OpenCode يعمل على نموذج frontier حالي. النماذج الأقدم أو الأصغر ستنحرف، ويظهر ذلك غالباً في JSON الدقيق لجسم إنشاء العامل في السيناريو 2 وSQL في السيناريو 6؛ إذا بدت أول خطة من وكيلك في السيناريو 1 غامضة أو عامة بدلاً من أن تكون محددة لجهازك، فهذه إشارة إلى الانتقال إلى نموذج أقوى قبل المتابعة.

---

قبل السيناريو 1: تأكد أن الموجز محمّل لدى وكيلك (نحو 30 ثانية)

لصقة واحدة تخبرك هل أدى CLAUDE.md عمله وسحب AGENTS.md إلى سياق وكيلك:

What can you do for Paperclip?

إذا سمّى الرد أعمال Paperclip محددة، مثل فحص ما قبل التثبيت، وشكل الشركة والعامل، وعقد heartbeat، وإسناد المسألة عند الإنشاء، وحمولة الموافقة، وحقيقة الميزانية، واستعلامات activity-log، وعادة التدقيق الشهري، فأنت جاهز للسيناريو 1. إذا بدا الرد كلاماً عاماً عن قدرات الذكاء الاصطناعي بلا تفاصيل خاصة بـ Paperclip، فالاستيراد لم يعمل: أغلق الوكيل، وتأكد أنك داخل مجلد paperclip-crash-course/ المفكوك، ثم شغّله من جديد.

ما الموجود فعلاً في AGENTS.md (الملف الذي يقرؤه وكيلك الآن)

لن تحتاج أبداً إلى قراءة هذا الملف بنفسك؛ هذه هي الفكرة. لكن معرفة شكله تساعدك على طرح أسئلة أفضل، مثل "walk me through the approvals section"، وهذا يعمل لأن القسم موجود. يغطي الموجز، بالترتيب:

PART 1 :: PRINCIPLES (apply everywhere)
  Versions this brief was verified against
  Source of truth, in order         ← live docs > this brief > the running install
  Critical: discover before you act  ← table of intent → where to confirm
  Working pattern (every task)       ← read → propose → ask → execute → verify
  Past tense is for completed actions only
  Trust progression                  ← ask each, then blanket; re-acquire on anomaly
  Safety rails (non-negotiable)
  Secrets discipline
  Sourcing claims that exist only in this brief

PART 2 :: OPERATIONS (verified against a live install)
  Install and onboard            ← the pre-install probe + the onboard flow
  Configure                      ← second instance, keeping the server alive
  Companies                      ← create, goals, projects
  Agents (Workers) and adapters  ← the real adapter list + the verified create body
  The heartbeat contract         ← what the http adapter actually POSTs
  Issues and assignment          ← no routing engine; assign at create time
  Approvals                      ← the payload + why it's a decision record
  Budgets                        ← why they only move for LLM Workers
  Audit trail                    ← activity_log + the real connection string
  Diagnose and recover           ← the most common failures
  When you don't know what to do ← three-layer fallback

إذا بدا قسم معين من AGENTS.md ذا صلة لاحقاً، يمكنك أن تطلب من وكيلك أن يشرحه قبل أن يتصرف، مثل: "walk me through the Approvals section of AGENTS.md before we file that request". كُتب الموجز حتى يستطيع الوكيل أن يوجّه نفسه انطلاقاً منه.

ملاحظة عن مسار المختبر: شغّل المسار كله بلا مفاتيح

العامل الذي ستوظفه في السيناريو 2 هو worker-stub.py، عامل محلي بلا مفتاح يأتي في التنزيل. يعمل على محول http في Paperclip: في كل heartbeat، يرسل Paperclip المسألة كاملة إلى stub بعملية POST، ويرسل stub disposition مرة أخرى. لا LLM، ولا مفتاح API، ولا أداة ثانية. تشغّل مستوى الإدارة كله، heartbeats والإسناد والموافقات والتدقيق، من البداية إلى النهاية بما لديك فعلاً، عبر السيناريوهات 1 إلى 4 والسيناريو 6. ثم في السيناريو 5 تضيف شيئاً واحداً، مفتاح Gemini مجاني، لسبب متعمد: لا يؤدي stub بلا مفتاح عملاً قابلاً للفوترة، لذلك لا تملك الميزانية شيئاً تقيسه عليه. عامل LLM الحقيقي هو ما يعطي الميزانية شيئاً تفرضه. شكل المسار مطابق في الحالتين؛ stub بلا مفتاح ينتج فقط disposition تجريبياً بدلاً من رد مصاغ.

---

السيناريو 1: أقم Paperclip وحدد شركتك (نحو 15 دقيقة)

الهدف: Paperclip يعمل على حاسوبك المحمول، وشركة واحدة مهيأة ("Acme Customer Support" أو أي اسم تختاره)، ولوحة التحكم قابلة للوصول في متصفحك. تعليمتان: اطلب الخطة، ثم وافق ونفّذ.

1a. التهيئة الأولية والتحقق من التثبيت

التعليمة الأولى: صف ما تريد واطلب الخطة.

I'd like to get Paperclip running on my laptop and walk through a first company called Acme Customer Support. Before you touch anything, run the pre-install probe from your brief and walk me through your plan in plain language: what you checked, what you'll change, where you'll need me to step in.

يقرأ وكيلك AGENTS.md، ويشغّل فحص ما قبل التثبيت (إصدار Node، والتثبيتات السابقة، وتوفر المنفذ، ودليل البيانات السابق، وأي عمليات Paperclip أخرى تعمل)، ثم يقترح خطة. سيشير غالباً إلى موضع واحد يحتاج قرارك: إذا وجدت حالة قديمة، مثل تثبيت paperclipai سابق أو عملية تمسك المنفذ الافتراضي، فإنه يتوقف لقرارك قبل لمسها. اقرأ الخطة. إذا شعرت أن شيئاً غير مضبوط، فاعترض. اسأل "why are you doing that?" وسيشرح الوكيل أو يعدّل.

التعليمة الثانية: وافق ودعه يعمل.

Plan looks good. Go ahead step by step, and tell me what you see at each step. Pause before any destructive command. When onboarding finishes, name the dashboard URL so I can confirm I see it in my browser; it auto-opens in some setups.

يشغّل الوكيل أمر onboarding من الموجز، ويراقب خرجه، ويلتقط القيم التشغيلية التي يطبعها السكربت: مضيف API، وURL لوحة التحكم، ومسار دليل البيانات، ومنفذ Postgres المضمن، ومسار ملف الإعداد. يحفظ هذه القيم في ملف محلي للمشروع تتحكم به، ولا يعيدها في المحادثة. تفصيل صغير يخبره الموجز أن يصيبه: شريط onboarding يسمي سطر API بلاحقة /api، لكن الوكيل يلتقط المضيف العاري من دونها، حتى لا تنتهي استدعاءات API اللاحقة بمسار مضاعف /api/api/. لا تحتاج إلى تتبع هذا بنفسك؛ هذا بالضبط نوع التفاصيل الذي يوجد الموجز للتعامل معه. في وضع الربط الافتراضي على loopback لا يصدر مفتاح API تمهيدي (الثقة محصورة في loopback)، وسيقول وكيلك ذلك إذا سألته لماذا لا يظهر مفتاح. عندما ينتهي onboarding، تفتح لوحة التحكم عادة تلقائياً في متصفحك الافتراضي.

ينتهي 1a عندما: يبلغ الوكيل أن خادم API يستمع، وتستطيع فتح URL لوحة التحكم في المتصفح، وتعرض اللوحة بلا أخطاء.

1b. حدد شركتك الأولى

الصق هذا في وكيلك:

Now define the company. Name it Acme Customer Support. Its purpose: "Respond to customer inquiries within 4 hours, with refund decisions made consistently and within policy." Add one goal, "Reduce average response time to under 4 hours," and one project, "Inbound email triage." Check the live API for the exact field names first, then create them. When you're done, show me what's now visible in the dashboard.

يقرأ الوكيل قسم Companies في الموجز، ويتحقق من أسماء الحقول من API العامل (يشير الموجز إلى أن غرض الشركة يوضع في حقل description، وأن اسم حقل غير معروف يفشل بصمت لا بصوت عالٍ)، ثم ينشئ الشركة والهدف والمشروع، ويمشي بك إلى لوحة التحكم للتأكيد.

تنتهي من السيناريو 1 عندما: تعرض لوحة التحكم شركة واحدة باسم "Acme Customer Support" مع هدف واحد ومشروع واحد، ويعرض سجل النشاط صفوف الإنشاء المطابقة (سيقرأ الوكيل أسماء الأفعال الدقيقة التي سجلها Paperclip؛ تبدو مثل company.created وgoal.created وproject.created). كل فعل لاحق يبنى فوق هذا الأساس.

ما ينتقل إلى السيناريو 2

معرّف الشركة الذي عيّنه Paperclip صار الآن في الملف المحلي للمشروع الذي أنشأه الوكيل. يقرأ وكيلك من ذلك الملف في كل سيناريو لاحق، لذلك لا تحتاج أبداً إلى تذكر المعرّف بنفسك. أبقِ وكيلك يعمل داخل المجلد المفكوك حتى يملك الملف في دليل عمله.

---

السيناريو 2: وظّف أول عامل (نحو 15 دقيقة)

الفكرة. العامل في Paperclip هو دور مهيأ: اسم، وبيئة تشغيل، وأذونات، وميزانية، وجدول heartbeat. (تسمي API الخاصة بـ Paperclip هؤلاء "agents"؛ وتقول هذه الصفحة "Worker" دائماً حتى لا يختلط الأمر مع وكيل البرمجة الذي تلصق التعليمات فيه. عندما يعرض وكيلك طلباً إلى /agents، فهذا هو الشيء نفسه.) تُوصل بيئة التشغيل عبر محول. يشحن Paperclip مجموعة منها: بيئات LLM مثل claude_local وcodex_local وgemini_local وغيرها، وopenclaw_gateway، ومحول process يشغّل أمراً عند كل heartbeat، ومحول http يرسل كل heartbeat بعملية POST إلى URL تتحكم به. يستطيع وكيلك سرد المجموعة الحالية باستدعاء API واحد ضد تثبيتك.

في هذه الدورة المكثفة ستوظف عاملك الأول على محول http، موجهاً إلى worker-stub.py، العامل المحلي بلا مفتاح الموجود في التنزيل. إنه ملف Python صغير يستخدم المكتبة القياسية فقط. كلما أسند إليه Paperclip عملاً، يرسل المسألة كاملة إلى stub بعملية POST؛ يقرأ stub المسألة ويرسل disposition مرة أخرى، فينقل المسألة إلى done. لا LLM، ولا مفتاح API. شكل المسار، heartbeat والإسناد والموافقة والتدقيق، هو بالضبط ما سيكون عليه لعامل LLM حقيقي؛ الناتج فقط disposition تجريبي بدلاً من رد مصاغ. في السيناريو 5 تستبدله بعامل حقيقي مدعوم بـ LLM.

ملاحظة عن السلطة. عندما توظف العامل، ستصف ما يسمح له بفعله بلغة واضحة في حقل capabilities: قراءة سجلات CRM، وصياغة ردود، أما رد الأموال فوق 50 دولاراً والبريد الخارجي الصادر فيحتاجان موافقة المجلس. فكّر في ذلك كغلاف سلطة العامل. في إصدار Paperclip لعام 2026، يُخزن ذلك الغلاف كوصف كتبته، ولا ينفذه وقت التشغيل حقلاً بحقل؛ حد الإنفاذ الحقيقي هو بوابة الموافقة التي ستربطها في السيناريو 4. يبقى الغلاف نموذجاً ذهنياً صحيحاً: إنه الخط الذي، عندما تتجاوزه مهمة، ينبغي أن ينتج طلب موافقة بدلاً من فعل.

توظف عبر تعريف الدور وتسجيله من خلال API. تعليمتان: شغّل stub وصغ الدور، ثم سجّل وتحقق.

2a. شغّل عامل stub وصغ الدور

التعليمة الأولى: توجّه، ثم صغ.

I'd like to hire one Worker called Tier-1 Customer Support, running on the http adapter pointed at the worker-stub.py that came in this folder. First, walk me through what worker-stub.py does and how you'll start it. Then show me the agent-create request body from your brief before you register anything: I want to see the role name, the adapter and its config, the capabilities text, the permissions, the budget, and the heartbeat schedule. Set the monthly budget small on purpose; Scenario 5 will use a real Worker to show what a budget meters.

يقرأ وكيلك قسم Agents في الموجز، ويشرح worker-stub.py (خادم HTTP صغير: يستمع إلى POST الخاص بـ heartbeat من Paperclip، ويقرأ المسألة من payload، ثم يرسل disposition done عبر PATCH)، ويعرض كيف سيشغّله (أمر python3 واحد، مع منفذ استماع وURL API الخاص بـ Paperclip كوسيطات). ثم يصوغ جسم agent-create ويعرض البنية: name، وadapterType (http) وadapterConfig (URL الخاص بـ stub)، وcapabilities (نص السلطة بلغة عادية)، وpermissions، وbudgetMonthlyCents، وجدول heartbeat تحت runtimeConfig. اقرأه. إذا بدا حقل خاطئاً، فاسأل؛ وسيتحقق الوكيل من API الحية.

التعليمة الثانية: شغّل، وسجّل، وتحقق.

Looks good. Start the stub Worker, register the role with Paperclip, and confirm it appears in the dashboard. Show me the agent ID Paperclip assigned, the next heartbeat time, and the stub's own log file so I can see it's listening.

يشغّل الوكيل worker-stub.py (يبقى عاملاً في الخلفية ويسجل كل heartbeat يتلقاه)، ويسجل الدور عبر API، ويلتقط معرّف agent المعيّن في الملف المحلي للمشروع، ويطلب منك تحديث لوحة التحكم.

تنتهي من السيناريو 2 عندما: تعرض لوحة التحكم عاملاً واحداً باسم "Tier-1 Customer Support"، ويكون worker-stub.py قيد التشغيل وملف سجله موجوداً، ويعرض سجل النشاط صف إنشاء العامل (سيقرأ الوكيل اسم الفعل الدقيق؛ يبدو مثل agent.created). شيء واحد ينبغي معرفته مسبقاً: عمال Paperclip غير قابلين للتعديل بعد الإنشاء. لا تستطيع تعديل محول العامل أو ميزانيته لاحقاً؛ بل توظف واحداً جديداً. لذلك يوظف السيناريو 5 عامل LLM جديداً بدلاً من ترقية هذا العامل.

ما ينتقل إلى السيناريو 3

العامل مسجل وworker-stub.py يعمل، لكن طابور مسائل العامل فارغ. يعطيه السيناريو التالي عملاً حقيقياً. أبقِ عملية stub قيد التشغيل: إذا أغلقتها، ستصل heartbeats إلى URL ميت ولن تُحل المسائل. إذا توقفت لهذا اليوم، يستطيع وكيلك إعادة تشغيل stub عندما تلتقط السيناريو 3 لاحقاً.

---

السيناريو 3: أرسل إلى الشركة أول مسألة حقيقية (نحو 15 دقيقة)

الفكرة. الشركة موجودة، والعامل موجود، لكن لا شيء مُسند. في الإنتاج الحقيقي، سيطلق بريد عميل حدثاً ينشئ مسألة في Paperclip. لا يملك Paperclip 2026 محرك توجيه قائماً على قواعد: لا توجد طبقة "إذا طابقت المسألة X فأرسلها إلى العامل Y". الإسناد مباشر، ويهم متى تفعله. المسألة المنشأة مع assignee عند وقت الإنشاء تكون موصولة بتنسيق heartbeat: تولد جاهزة، ويلتقطها النبض التالي. أما المسألة المنشأة بلا assignee ثم تُسند لاحقاً فلا تُلتقط بالطريقة نفسها. لذلك الحركة هي: أنشئ المسألة وسمِّ عاملها في الخطوة نفسها.

ما يحدث بعد ذلك هو الجزء المهم: يعمل heartbeat التالي للعامل، ويرسل Paperclip المسألة كاملة إلى worker-stub.py، ويقرأ stub المسألة ويرسل disposition done، وتتحرك المسألة من todo إلى in_progress إلى done، مع صف في activity-log يسجل كل خطوة.

تعليمتان: أنشئ المسألة وأسندها، ثم شاهد العامل يلتقطها.

3a. أنشئ مسألة واردة واحدة، مسندة عند وقت الإنشاء

الصق هذا في وكيلك:

Create one inbound issue for the "Inbound email triage" project: a customer (call them C-4429) is asking about a $30 refund on a product that arrived damaged. Write the description as a realistic two-sentence customer email. Assign it to Tier-1 Customer Support at create time, in the same command, not as a follow-up edit. When it's created, show me the issue ID Paperclip assigned and what status it's in right now.

يقرأ وكيلك قسم Issues في الموجز، وينشئ المسألة مع تسمية العامل كمسند إليه في أمر الإنشاء، ويعرض لك معرّف المسألة (يبدو مثل ACM-1).

ينتهي 3a عندما: يعرض طابور المسائل في لوحة التحكم مسألة واحدة مسندة إلى Tier-1 Customer Support، في حالة todo، ويعرض سجل النشاط صف issue.created.

3b. شاهد العامل يلتقطها

تنبيه قبل أن تلصق هذا. العامل الذي وظفته لديه wake on assignment، لذلك أطلق إسناد المسألة عند وقت الإنشاء heartbeat فورياً. بحلول قراءتك لهذا، قد تكون المسألة done بالفعل. هذا هو النظام يعمل، لا خطوة فاتتك. لذلك هذه التعليمة ليست "اجعل هذا يحدث"؛ بل "أرني ما حدث بالفعل في السجل."

الصق هذا في وكيلك:

Show me what already happened with that issue. Pull up worker-stub.py's own log file and the issue's rows in the activity log, and walk me through the sequence: the heartbeat that fired on assignment, the stub receiving the issue, the stub posting its disposition back, and the issue reaching a terminal status. Tell me which fields prove the work actually happened rather than the issue just being flipped to done. If for some reason the issue is not done yet, fire a heartbeat for Tier-1 by hand and then walk me through the same sequence.

يقرأ الوكيل السجلين ويروي التسلسل الذي جرى: استيقظ العامل عند الإسناد، أرسل Paperclip المسألة إلى stub بعملية POST، وأعاد stub disposition done عبر PATCH. تكون المسألة عند done مع ضبط كل من startedAt وcompletedAt. ويسجل activity log التشغيل. (إذا لم يكن جدول heartbeat قد عمل بعد، يتضمن الموجز أيضاً أمر heartbeat عند الطلب، فيستطيع الوكيل إطلاقه من دون انتظار الإيقاع.)

تنتهي من السيناريو 3 عندما: تنتقل المسألة من todo عبر in_progress إلى done، ويعرض سجل النشاط الانتقال، ويعرض سجل worker-stub.py heartbeat الذي تلقاه وdisposition الذي أرسله. لا تُسجل تكلفة على هذه المسألة، وهذا صحيح: يشرح السيناريو 5 لماذا، وأين تبدأ بيانات التكلفة في الوجود.

ما ينتقل إلى السيناريو 4

لدى عاملك الآن مسألة واحدة في سجلّه، لذلك لم يعد سجل النشاط فارغاً عندما تضيف خطوة الموافقة التالية. يعمل السيناريو 4 عمداً مع مسألة يكون فعلها، رد أموال كبير، أعلى مما ينبغي لعامل Tier-1 أن يقرره وحده، ليريك كيف تُرفع موافقة مجلس وتُسجل.

---

السيناريو 4: ارفع موافقة لفعل محفوف بالمخاطر (نحو 15 دقيقة)

الفكرة. بعض الأفعال أعلى من رتبة عامل Tier-1: رد أموال بقيمة 750 دولاراً، أو تغيير عقد، أو أي شيء يتجاوز غلاف السلطة الذي وصفته في السيناريو 2. جواب Paperclip هو الموافقة: سجل قرار مجلس مُتتبع. عامل LLM حقيقي، وهو يستدل في رد أموال بقيمة 750 دولاراً، سيتعرف إلى أن الفعل يتجاوز سلطته ويرفع طلب موافقة بدلاً من التصرف. عامل stub بلا مفتاح لا يستدل، لذلك في هذا السيناريو تعمل أنت كيد المجلس: ترفع طلب الموافقة الذي كان العامل سيرفعه، ثم تقرره.

شيئان يجب الصراحة بهما مقدماً لأنهما يشكلان معنى "انتهى" هنا:

• الموافقة سجل قرار، لا آلة حالات. رفع موافقة لا يعلّق عاملاً، والموافقة عليها لا تستأنف عاملاً تلقائياً، ولا تغير حالة المسألة المرتبطة، ولا تنفذ الفعل الموافق عليه. التصرف بناءً على القرار خطوة منفصلة وصريحة. ما يعطيك إياه Paperclip هو السجل المتين والمدقق لمن قرر ماذا، وبأي منطق، ومتى. هذا السجل هو الشيء القيّم: ما يقرؤه المدقق بعد ستة أشهر.
• لحظة التعليم هي مسار التدقيق، لا فتحاً تلقائياً. راقب الصف في سجل النشاط، لا تحرك المسألة وحدها.

تعليمتان: ارفع الطلب، ثم قرره.

4a. ارفع طلب الموافقة

الصق هذا في وكيلك:

Create an inbound issue: customer C-1138 is asking for a $750 refund on a product they bought three months ago; they say it arrived defective and they have photos. Do not assign it to a Worker yet: this is an action that needs board sign-off before anyone acts on it. Then, acting as a Worker would when it hits an action above its authority, file a board approval request linked to that issue. Use the approval type for a board decision. In the payload, put the action ("issue a $750 refund"), the rationale (the customer's history, the damage photos, the policy on documented defects), and two or three alternatives considered (partial refund, store credit, no refund). Show me the approval in pending status, and confirm the issue itself is still sitting untouched.

ينشئ الوكيل المسألة بلا assignee، فلا يلتقطها عامل stub وتبقى في حالتها الابتدائية الافتراضية، ثم يرفع طلب الموافقة عبر API موافقات الشركة: type الخاص بقرار المجلس، وpayload حر يحمل الفعل والمنطق والبدائل نصاً. يربط الموافقة بالمسألة. يحصل activity log على صف approval.created.

ينتهي 4a عندما: تكون المسألة موجودة، غير مسندة وغير ملموسة في حالتها الافتراضية، ويحتوي طابور الموافقات في لوحة التحكم على إدخال pending واحد، ويتوقف الوكيل ليسلم القرار إليك.

4b. قرره

هذا الجزء لك. اقرأ الطلب الذي رفعه وكيلك: المبلغ، والمنطق، والبدائل. قرر.

الصق هذا في وكيلك بعد أن تقرر:

I've decided to approve this refund (or: to reject it; tell me which and why in one line). Record my decision. Then walk me through the activity-log rows for this approval and show me the field that proves I, the human board, was the decider, not an agent. And remind me explicitly what did not happen automatically: the issue is still sitting where it was, and what I'd have to do next to actually act on this decision.

يسجل الوكيل قرارك (تنتقل الموافقة إلى approved أو rejected، مع ختم هوية المقرر والطابع الزمني للقرار عليها). يمشي بك عبر سجل النشاط: صف approval.approved أو approval.rejected، مع actor_type مضبوطاً إلى user وactor_id يحدد المجلس. ثم يسمي الجزء الصادق: المسألة المرتبطة لم تتغير حالتها وحدها. إذا أردت إغلاق المسألة أو "إصدار" رد الأموال، محاكاةً لأنه لا يوجد معالج دفع مربوط، فذلك أمر منفصل وسينفذه الوكيل إذا طلبت.

تنتهي من السيناريو 4 عندما: يحتوي سجل النشاط على سلسلة الموافقة (طلب مرفوع، قرار مسجل بواسطتك)، وتكون المسألة المرتبطة ظاهرياً غير متغيرة بالقرار، وتستطيع تسمية الحقل الذي يميز المقرر البشري من فعل الوكيل (actor_type)، وتستطيع أن تقول بكلماتك لماذا الموافقة سجل قرار لا فتح تلقائي.

ما ينتقل إلى السيناريو 5

لديك الآن سجل نشاط صغير لكنه حقيقي: مسألتان، وموافقة واحدة، وheartbeats خلفهما. لكن جدولاً واحداً لا يزال فارغاً: لا توجد بيانات تكلفة بعد. السيناريو 5 هو حيث يتغير ذلك، وهو السيناريو الوحيد الذي يحتاج إلى مفتاح API.

---

السيناريو 5: استبدل عاملاً حقيقياً يعمل بـ LLM؛ وأعطِ الميزانية أسناناً (نحو 15 دقيقة)

الفكرة. لكل عامل ميزانية شهرية، مضبوطة بالسنتات عندما توظفه. لكن الميزانية لا تجد شيئاً تفرضه إلا عندما يؤدي العامل عملاً قابلاً للفوترة: stub بلا مفتاح لا يفعل ذلك، لذلك يبقى إنفاقه صفراً ولا تتحرك ميزانيته. هذا هو الشكل الصادق للشيء، لا خطأ في المختبر. لرؤية الميزانية تقيس شيئاً فعلاً، تحتاج إلى عامل مدعوم ببيئة تشغيل LLM حقيقية.

لذلك يجري هذا السيناريو الاستبدال. ستوظف عاملاً جديداً على محول gemini_local، وهو توظيف جديد لا تعديل لأن العمال غير قابلين للتغيير كما ذكر السيناريو 2، وتعطيه ميزانية شهرية صغيرة عمداً، وتكدّس عملاً كافياً لاستنزاف تلك الميزانية. ثم تراقب ما يفعله Paperclip فعلاً عندما يرتفع الإنفاق نحو الحد. هذا هو السيناريو الوحيد الذي يحتاج إلى مفتاح API: مفتاح Gemini مجاني، وهو نفسه الذي تستخدمه دورة OpenClaw المكثفة. يمشي هذا الدرس عبر Gemini لأن الطبقة المجانية تبقي السيناريو قريباً من بلا مفاتيح؛ وإذا كان لديك مفتاح لبيئة تشغيل منخفضة التكلفة أخرى (codex_local مع نموذج OpenAI رخيص مثلاً)، فستثبت آلية الميزانية نفسها، ويمكن لوكيلك تعديل المحول وفقاً لذلك.

تعليمة واحدة لتوظيف عامل LLM، وأخرى لإعطائه عملاً ومراقبة الميزانية.

5a. وظّف عامل LLM

الصق هذا في وكيلك:

I want to add a real LLM Worker now. I'll export GEMINI_API_KEY in my shell before you start: tell me when you need me to do that. Hire a new Worker called Tier-1 Customer Support (LLM) on the gemini_local adapter, using the cheapest current capable Gemini model. Give it a deliberately small monthly budget, a dollar or two, so I can watch spend accrue against it. Walk me through the create body before you register, and remind me why we're hiring a new Worker instead of editing the stub one.

يذكرك وكيلك أن العمال غير قابلين للتغيير، لذلك هو توظيف جديد لا تعديل، ويسمي اللحظة التي تحتاج فيها إلى تصدير المفتاح، ويصوغ جسم agent-create: الشكل نفسه في السيناريو 2، لكن مع adapterType مضبوطاً إلى gemini_local وbudgetMonthlyCents صغير. يسجل العامل بعد أن تصدّر المفتاح.

5b. أعطه عملاً وراقب الميزانية

الصق هذا في وكيلك:

Now give the LLM Worker work. Create about ten short inbound support issues, varied a little, and assign each one to the new LLM Worker at create time. Fire heartbeats so it works through them. Tail the Paperclip server log. I want to see two things: the per-run cost data start to exist (it didn't, for the keyless stub), and the Worker's monthly spend climb toward the budget I set. Tell me, in plain language, exactly what Paperclip does as the spend approaches and then crosses the limit: that's the behavior I want to observe.

ينشئ الوكيل المسائل ويسندها، ويطلق heartbeats، ويتابع سجل خادم Paperclip. هذه المرة يؤدي العامل عملاً قابلاً للفوترة، لذلك تبدأ بيانات الاستخدام لكل run في الوصول إلى سجلات heartbeat، ويتحرك إنفاق العامل الشهري من الصفر. يروي الوكيل ما يفعله Paperclip فعلاً عندما تتناقص الميزانية ويخبرك به بوضوح: هذه ملاحظة حية، لا نتيجة مكتوبة مسبقاً، ووظيفة وكيلك أن يخبرك بما يراه.

تنتهي من السيناريو 5 عندما: يكون عامل LLM الجديد قد حل مسائل حقيقية، وتكون بيانات التكلفة لكل run موجودة حيث كانت فارغة من قبل، ويتحرك إنفاق العامل الشهري مقابل الميزانية التي ضبطتها، وقد أخبرك وكيلك بلغة واضحة ما فعله Paperclip عندما اقتربت الميزانية من حدها.

كلمة عن مفتاح API

صدّر المفتاح في shell لديك (export GEMINI_API_KEY=...)؛ لا تلصقه أبداً في ملف داخل المشروع، ولا تسمح لوكيلك بكتابته في ملف. يخبر AGENTS.md وكيلك بالأمر نفسه. إذا لصقت مفتاحاً في مكان لا ينبغي، فدوّره. مفتاح الطبقة المجانية منخفض المخاطر، لكن العادة هي المقصود.

ما ينتقل إلى السيناريو 6

لديك الآن عاملان (stub بلا مفتاح وواحد مدعوم بـ LLM)، وأكثر من عشر مسائل، وموافقة واحدة، وشيء جديد في هذا السيناريو: بيانات تكلفة حقيقية. هذا تاريخ كافٍ ليعيد استعلام التدقيق في السيناريو 6 شيئاً يستحق القراءة.

---

السيناريو 6: استعلم عن مسار التدقيق مثل CFO (نحو 10 دقائق)

الفكرة. المعنى كله لمستوى الإدارة هو أن يستطيع شخص خارج قوة العمل، CFO أو القانون أو العمليات أو الامتثال، إعادة بناء ما حدث من قاعدة البيانات وحدها، في ثوان، من دون سؤال أحد. يحفظ Paperclip ذلك التاريخ في قاعدة Postgres مدمجة. الجدول الأهم هو activity_log: صف واحد لكل فعل مغير، مثل إنشاء شركة، أو إنشاء مسألة، أو تقرير موافقة، أو توظيف عامل، أو استدعاء heartbeat، مع الفاعل والفعل والكيان الذي لمسه. جدول ثانٍ، cost_events، يحمل قصة المال: المزود، والنموذج، والرموز، والتكلفة بالسنتات لكل run قابل للفوترة، ولا يحصل على صفوف إلا بعد أن يؤدي عامل LLM عملاً قابلاً للفوترة، ولهذا كان فارغاً حتى السيناريو 5.

تعليمة واحدة: افتح Postgres، وشغّل استعلام التاريخ واستعلام التكلفة، واقرأ الإجابات.

الصق هذا في وكيلك:

Time to play CFO. Connect to the embedded Paperclip Postgres (your brief covers how to assemble the connection string). First, run the "what happened, in order" query against activity_log for our company: every action with its actor and the entity it touched, oldest first. Then run the cost query against cost_events: total cost today, in dollars. Show me the SQL and the results for both. Finally, walk me through one activity_log row for the approval I decided in Scenario 4, and point to the fields an auditor would use to confirm I was the decider.

يقرأ الوكيل قسم Audit-trail في الموجز، ويركب سلسلة اتصال Postgres من ملف إعداد تثبيتك (لا يوجد أمر اختصار لهذا؛ يوضح الموجز كيف)، ويشغّل استعلامين:

1. ما الذي حدث، بالترتيب: استعلام SELECT على activity_log مفلتر إلى شركتك، ومرتب زمنياً. يعيد العمود الفقري الكامل لتشغيلك: إنشاء الشركة والمشروع، وتوظيف العاملين، وكل مسألة منشأة، وheartbeats، والموافقة المرفوعة والمقررة. هذا هو الاستعلام الذي يعمل بلا أي عامل LLM؛ إنه قلب قصة التدقيق بلا مفاتيح.

2. إجمالي تكلفة اليوم: استعلام SELECT SUM(...) على cost_events، يحول عمود السنتات الصحيح إلى دولارات، ومفلتر إلى اليوم. قبل السيناريو 5 لم يعِد شيئاً؛ الآن يعيد التكلفة الحقيقية الصغيرة لتشغيلات عامل LLM لديك.

ثم يعرض لك الوكيل صف activity_log واحداً للموافقة التي قررتها: الفعل (approval.approved أو approval.rejected)، وactor_type مضبوطاً إلى user، وactor_id الذي يحدد المجلس، والطابع الزمني. هكذا يعيد المدقق بناء قرارك.

تنتهي من السيناريو 6 عندما: يعيد استعلام التاريخ القصة المرتبة لتشغيلك كله، ويعيد استعلام التكلفة رقماً حقيقياً من عامل السيناريو 5، وتستطيع تسمية العمود في activity_log (actor_type) الذي يميز القرار البشري عن فعل الوكيل.

---

السيناريو 7: تدقيق قوة العمل الشهري (نحو 10 دقائق/شهر)

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

الصق هذا في وكيلك (عندما يحين الوقت):

Run my Paperclip monthly workforce audit. Walk through everything that's been hired, configured, scheduled, decided, or paused since the last audit. Flag anything I didn't explicitly sign off on, any Worker that hasn't done productive work, any budget that's drifted from where I set it, and any setting that's looser than it should be. Summarize the lot as a single short report I can either approve or trim.

يقرأ وكيلك سجل النشاط، وقائمة العمال الحالية، والميزانيات، وجداول التدقيق، وينتج تقريراً من صفحة واحدة.

ينتهي عندما: تقضي عشر دقائق في مراجعة التقرير وتتخذ قراراً واحداً على الأقل، مثل تضييق نص سلطة عامل، أو تقليم ميزانية إلى موضعها، أو تقاعد عامل غير مستخدم، أو رفع عتبة موافقة. ضع موعداً للشهر القادم في تقويمك.

---

لماذا ينجح هذا

يبقى شيئان طازجين؛ ويبقى شيء واحد متيناً.

الطازج #1: السيناريوهات على هذه الصفحة تعيش على موقع الكتاب. يقرؤها وكيلك عندما تخبره أي سيناريو تعمل عليه.

الطازج #2: أوامر Paperclip الحالية وشكل API يعيشان في paperclip.ing/llms.txt، وهو فهرس صديق للـ LLM للوثائق الكاملة، إضافة إلى docs.paperclip.ing للشرح المتأني. يقرؤها وكيلك طازجة قبل أي عملية غير تافهة. Paperclip يشحن بسرعة؛ هذه هي طريقة بقاء الموجز دقيقاً حتى عندما تنحرف flags فردية.

المتين: المجلد الذي نزلته يحمل AGENTS.md (ما Paperclip، وكيف تتنقل في وثائقه، وسياج السلامة، والأشكال التشغيلية المتحققة، وأنماط التعافي)، وCLAUDE.md (علامة الاستيراد من سطر واحد)، وworker-stub.py (العامل بلا مفتاح نفسه). يغطي AGENTS.md الشركات، والعمال والمحولات، وعقد heartbeat، والمسائل والإسناد، والموافقات، والميزانيات، والتدقيق، والتشخيص. إنه أطول من هذه الصفحة لأنه يغطي كل ما قد يُطلب من وكيل برمجة فعله مع Paperclip، لا السيناريوهات الستة أعلاه فقط. لا شيء في المجلد يشيخ، لذلك تنزله مرة واحدة وتعيد استخدامه.

النمط صغير عمداً: مرجع تشغيلي واحد، وعلامة استيراد واحدة، وعامل قابل للتشغيل واحد. ثلاثة ملفات. الذكاء ليس في الملفات؛ بل في وكيل البرمجة وهو يقرؤها ويطبقها على ما تطلبه لاحقاً. لم تمر عبر ستة عروض منفصلة؛ بل جمعت شركة ستلمسها غداً.

---

ما الذي يعمل الآن فعلاً

ليست ستة عروض: إنه نظام عامل واحد. جرد ما يبقى بعد السيناريو 6:

الأثر	ما هو فعلاً	لماذا يهم غداً
خادم Paperclip	عملية Node.js طويلة التشغيل تحمل API وPostgres المضمنة	تنجو شركتك من إغلاق الطرفية وإعادة التشغيل
دليل البيانات	كل بيانات شركتك، والأسرار المشفرة، وسجلات الخادم	الركيزة؛ انسخ هذا الدليل احتياطياً كما تنسخ dotfiles
شركة واحدة	غرض، وهدف، ومشروع، وعزل ضمن نطاق الشركة حولها	الحد الذي يعيش داخله كل عامل ومسألة وموافقة
عاملان	عامل worker-stub.py بلا مفتاح وعامل LLM على gemini_local	عامل يثبت المسار بلا مفاتيح؛ والآخر يوضح الاقتصاديات
worker-stub.py	عملية HTTP محلية صغيرة، تستمع إلى heartbeats	عاملك الأول، وقالب لأي عامل بلا مفتاح تكتبه لاحقاً
المسائل وسجل النشاط	مسائل مسندة ومُنجزة، مع سجل صفاً بصف لكل فعل	سلوك قوة عمل قابل لإعادة الإنتاج، وتاريخ قابل للاستعلام
موافقة واحدة	قرار مجلس واحد مرفوع ومقرر ومسجل دائماً	التوقيع المدقق الذي تستخدمه قوة عملك للأفعال الخطرة
ميزانية لها بيانات	ميزانية عامل LLM الشهرية، مع إنفاق حقيقي مقاس عليها	الرقم الذي يجعل "لا إنفاق منفلت" قابلاً للإنفاذ لا زخرفة
استعلامات تدقيق تستطيع تشغيلها	SQL فوق activity_log وcost_events يجيب عن أسئلة أصحاب المصلحة بسرعة	الرؤية التي يستطيع CFO أو القانون أو الامتثال استخدامها من دون سؤالك
AGENTS.md وسطر التعافي	الموجز المتين الذي يقرؤه وكيلك في كل جلسة	المهارة التي تعيد استخدامها طوال حياة هذه الشركة

يوم عمل بهذا الشكل يبدو هكذا: تصل رسالة عميل حقيقية؛ تكامل ما، ستربطه لاحقاً، ينشئ مسألة Paperclip مسندة إلى عامل؛ يحملها heartbeat التالي إلى العامل؛ يصوغ العامل رداً؛ تقرر أنت الحالات عالية المخاطر في لوحة التحكم؛ ومرة في الشهر تشغّل التدقيق.

إذا اختفى أي من هذه الآثار لاحقاً، بسبب مسح حاسوب، أو حذف بالخطأ، أو ترقية إصدار سيئة، فإن الموجز مع onboarding جديد واستعادة دليل البيانات من النسخة الاحتياطية يعيدك إلى هذه الصورة نفسها.

قبل أن تربط قناة عملاء حقيقية

الدورة المكثفة أحادية المستخدم: أنت المجلس البشري، وأنت من ينشئ المسائل للاختبار. ربط مصدر وارد حقيقي، مثل صندوق دعم أو نموذج تواصل أو حدث من أنظمتك القائمة، يعني أن الغرباء يستطيعون الكتابة إلى قوة عملك. قبل أن تفعل ذلك، يجب أن يتحقق شيئان: كل عامل يعالج محتوى وارداً يجب أن يملك غلاف سلطة ضيقاً وموصوفاً بوضوح (لا حرية واسعة لمجرد أن العمل "دعم عملاء")، وتحتاج إلى خطة متعمدة للمدخلات التي لا تطابق أي عامل (لا مسائل يتيمة). ابقَ مستخدماً منفرداً حتى تفكر في الأمرين.

---

إلى أين تذهب بعد ذلك

بعد السيناريو 6، لديك شركة عاملة معتمدة أصلاً على الذكاء الاصطناعي: عاملان، وموافقة مجربة واحدة، وميزانية لها بيانات حقيقية خلفها، ومسار تدقيق يجيب عن أسئلة أصحاب المصلحة في ثوان. هذا معظم السطح الذي يحتاجه أغلب الناس للبدء.

للمرور المتأني على أي موضوع لمسته هذه الصفحة، أو أي شيء تخطته، توجد عدة دورات مكثفة أعمق بجوارها في دليل getting-started. خريطة سريعة:

تريد...	اذهب إلى
تغليف عامل واحد بمحرك سير عمل متين قبل إدارة أسطول	From Digital FTE to Production Worker: غلاف متانة Inngest
تحويل التوظيف إلى قدرة قابلة للاستدعاء (عمال يوظفون عمالاً آخرين تحت سياسة)	From Fixed to Dynamic Workforce: خليفة هذه الدورة
استخدام REST API في Paperclip كأدوات من داخل وكيل آخر	راجع docs.paperclip.ing لحزمة خادم MCP الحالية؛ وثبّت الإصدار
نشر Paperclip إلى سحابة أو مضيف مشترك (عدة أجهزة، عدة مستخدمين)	الوثائق الحية في docs.paperclip.ing؛ تحقق مما شُحن قبل الاعتماد عليه
ربط OpenClaw كطبقة حافة بين البشر وقوة عملك	دورة OpenClaw المكثفة

في كل ما عدا ذلك، يغطي AGENTS.md معظم المنصة بالفعل. اسأل وكيل البرمجة: "What does AGENTS.md say about the heartbeat contract?" أو "Walk me through the approvals section of AGENTS.md." الموجز هو المرجع؛ وهذه الصفحة هي الجولة.

الدرس الفوقي: أثمن شيء في المجلد المفكوك هو AGENTS.md. خذ أمسية لقراءته من البداية إلى النهاية، لا لأجل خطوات التثبيت بل لأجل شكل الوثيقة: جدول discover-before-act، ونمط العمل، والعمليات حسب نوع المهمة، وقوائم التشخيص. ثم اكتب واحداً للأداة التالية التي ستضع أمامها وكيل برمجة. النمط قابل للنقل: كل أداة لها سطح قابل للتعلم تستحق AGENTS.md. كان Paperclip هدفاً نظيفاً لأن التثبيت يستفيد من الإعداد المدفوع بالوكيل والعمليات تتفكك إلى سيناريوهات لصق ومشاهدة؛ وستجد أدوات أخرى. اكتب التالي.

---

وسيلة دراسة بالبطاقات التعليمية