OpenAI Pando: صمّم بنية Git تناسب نطاق وكلاء البرمجة

نشرت OpenAI في 2 نوفمبر 2026 تفاصيل Pando: بنية خلفية متوافقة مع Git صُممت لاستيعاب التوازي الذي تخلقه وكلاء البرمجة. تقول الشركة إن Pando يشغّل مستودعها الأحادي، وينسق تحديثات الفروع غير المرتبطة باستقلال، ويخزن Packfiles الواردة ككائنات ثابتة، ويخدم Packs قابلة لإعادة الاستخدام عبر Caches إقليمية، ثم يدمجها في الخلفية.

الدرس المهم ليس «استبدل Git». أبقى Pando بروتوكول Git والعميل المعتادين، لكنه غيّر افتراضات الاتساق والتخزين خلف الخدمة. بالنسبة للفرق التي تستخدم Codex أووكلاء برمجة آخرين، السؤال العملي هو: هل يستطيع Source Control وCI والمراجعة استيعاب فروع وPush وFetch وMerge متزامنة أكثر، من دون تحويل المستودع إلى نقطة تنسيق عالمية؟

يفصل المقال ثلاث طبقات. معمارية Pando وأرقام الإنتاج موثقة في مقال OpenAI الهندسي، لكن الأرقام Company-reported وخاصة بمستودعها. سلوك Git Objects وPackfiles والبروتوكول موثق من مشروع Git. أما نموذج السعة وخطة الترحيل والضوابط التشغيلية أدناه فهي تحليل هندسي، وليست إعلانًا عن منتج متاح للعملاء أوادعاءً بأن Pando متاح للعامة.

الخلاصة أولًا

يحتاج Source Control على نطاق الوكلاء إلى أربعة عقود:

ابدأ بقياس Push-to-fetch Latency: الزمن من قبول Push حتى يستطيع Worker مستقل جلب Commit والتحقق منه. أضف معدل تعارض الفروع، وCPU لبناء Packs، والبايتات المنقولة، وإعادة استخدام Cache، ونجاح Merge، وتأخر CI، وفشل Reachability. لا تعِد تصميم التخزين قبل أن تثبت هذه القياسات موضع الاختناق.

تصلح Pando كدراسة حالة لأنها تنقل التنسيق من المستودع كله إلى كل Ref، وتنقل تكلفة Pack Generation من مسار القراءة إلى بيانات قابلة لإعادة الاستخدام وصلت مع الكتابة. تستبدل هذه المقايضة Snapshot عالمية لجميع Refs وبعض البايتات الإضافية بتوازي كتابة أفقي وقراءات قابلة للتخزين المؤقت.

ماذا أعلنت OpenAI؟

بحسب المقال الهندسي الرسمي، زاد Codex العمل المتوازي داخل Monorepo: فروع وPush وMerge وFetch وClone أكثر من بيئات التطوير والبحث وCI. وتقول OpenAI إن موثوقية النظام السابق هبطت أحيانًا إلى أقل من 90%.

تقول OpenAI إن Pando:

• يشغّل الآن كل التطوير داخل Monorepo لدى الشركة؛
• يحافظ على التوافق مع Git Protocol وClient؛
• يسلسل تحديثات كل Ref ويتيح تقدم Refs غير المرتبطة باستقلال؛
• يخزن Packfiles الواردة في Blob Storage وبيانات Ref Versions منفصلة؛
• يستخدم Packfiles قابلة لإعادة الاستخدام وCaches إقليمية للـFetch؛
• خفّض Median Push Latency بنحو 80%، ووصفته بداية المقال بأنه يقارب خمسة أضعاف؛
• يستطيع تسليم قرابة Petabyte من بيانات Git يوميًا؛
• خدم أكثر من 57 TB من Git Packs في ساعة، وأكثر من 99% من البايتات من Local Disk Cache.

هذه ملاحظات إنتاجية أعلنتها OpenAI، وليست Benchmarks مستقلة. ويصف المقال المقارنة التفاعلية صراحة بأنها نموذج تعليمي اصطناعي. استخدمها لفهم القرارات لا لتوقع أداء مؤسسة أخرى.

وتقول الشركة إن Pando بُني بمساعدة Codex خلال عشرة أسابيع، وبدأ Traffic الإنتاج في أبريل 2026، واستخدم Conformance Tests ومحاكاة حتمية وLean وTLA+ واختبارات مستمرة تقودها وكلاء. هذه ادعاءات عن عملية التطوير، ولا تلغي ملكية البشر أوSecurity Review أوProduction Verification.

قيد Git: يجب أن تتفق Refs وObjects

تاريخ Git رسم بياني من كائنات ثابتة: Blobs وTrees وCommits وTags. والفرع Ref متغيرة تشير إلى Commit. توثق صيغة Pack الرسمية ضغط الكائنات وDeltas، ويشرح Pack Protocol كيف يتفاوض العميل والخادم على بيانات Fetch وPush.

لذلك على خدمة المستودع التزامان:

1. لا يستطيع كاتبان تحريك Ref نفسها بصمت من Tip متوقعة إلى خلفين مختلفين؛
2. لا تصبح Ref قابلة للقراءة قبل إمكانية توفير كل Object يمكن الوصول إليه من Tip.

غالبًا تحتفظ Replication التقليدية بنسخ كاملة وتنسق تحديثات Ref بين Replicas. تعطي رؤية موحدة، لكن Quorum Round Trips وDisk Work يقعان في مسار الكتابة. ويسمح Shared WAL برفع Packs بالتوازي، لكن الفروع غير المرتبطة قد تتنافس على Compare-and-swap Key واحدة.

يزيل تصميم Pando المنشور هذا الترتيب العام. لكل Ref إصدارات؛ يسجل الإصدار Tip وPack التي قدمتها والإصدارات السابقة التي تعتمد عليها Pack. ثم تسجل Metadata Transaction الإصدار وتحدث المؤشر. يحدث التعارض عندما يستهدف كاتبان Ref نفسها، لا لمجرد أنهما داخل المستودع نفسه.

Causal Consistency قرار منتج

يوفر Pando تحديثات قابلة للتسلسل لكل Ref وRead-your-own-write، لكنه لا يقدم Snapshot متزامنة لكل Refs. أثناء قراءة عدة فروع، قد يرى عميل Branch A أحدث وBranch B أقدم، بينما يرى عميل آخر العكس.

يمكن قبول ذلك عندما يكون المسار محليًا للفرع:

• يدفع الوكيل Topic Branch؛
• يجلب CI الـCommit المحددة؛
• تقارن المراجعة مع Base مسجلة؛
• تتحقق Merge Automation من Tips الحالية؛
• تثبت أنظمة الإصدار Commit IDs غير قابلة للتغيير.

ويصبح خطرًا إذا افترض نظام أن Listing لعدة Refs يصنع Snapshot ذرية. من الأمثلة Release Script يختار أحدث Commits من فروع مختلفة، أوPolicy Check يقارن Refs قُرئت باستقلال دون تسجيل Versions، أوDeployment Manifest تُبنى من أسماء متحركة.

أنشئ جرد اعتماد قبل إرخاء الاتساق:

{
  "consumer": "release-orchestrator",
  "reads": ["refs/heads/main", "refs/heads/config"],
  "requires_atomic_snapshot": true,
  "safe_identifier": "commit-id-or-signed-manifest",
  "owner": "platform-team",
  "migration_test": "replay-with-ref-skew"
}

هذا Internal Evidence Schema وليس Pando API.

كيف تغير Reusable Packfiles مسار القراءة؟

في Fetch التقليدي يستخدم الخادم “have” و“want” لحساب فرق الكائنات، ثم يبني Pack مناسبة للعميل. يقلل ذلك البايتات، لكنه يستهلك CPU وI/O ويجعل الاستجابة صعبة المشاركة في Cache.

يتتبع Pando بدلًا من ذلك Packs المستلمة أثناء Push واعتمادها. وعند Fetch يختار Packs مخزنة تغطي نطاق Ref Versions المفقود. تقول OpenAI إنها تستخدم قدرة “packfile-uri” في Git كي يحمل العملاء Packs منفصلة، وخدمة Express لتخزينها إقليميًا.

المقايضة واضحة:

• الفائدة: يمكن لـPack ثابتة خدمة عملاء كثيرين بقليل من الحساب؛
• التكلفة: قد يستقبل العميل Objects موجودة لديه؛
• القيد: يجب إثبات أن العميل يملك كل Dependency حُذفت من Pack؛
• الاحتياج التشغيلي: تصبح سلامة Cache وصلاحية URI والتحقق من Checksum واستعادة التنزيل المنقطع حدودًا حرجة.

يساعد Git Protocol v2 لأنه يصرح Capabilities وCommands ولا يرسل Ref Advertisement إلا بطلب. لكن يجب اختبار التوافق مع نسخ العملاء وProxies وCredential Helpers وصور CI الفعلية.

Compaction خارج مسار الطلب

لا يمكن أن تبقى Pack لكل Push وحدة Fetch إلى الأبد. قد يحتاج عميل متأخر ليوم إلى آلاف التنزيلات. يجمع Pando Packs في Covers هندسية تشبه طبقات LSM Tree. تعيد Workers في الخلفية تعبئة Cover للضغط، بينما تعمل Cover كهيكل قفز عبر Ref Versions.

يحتاج التنفيذ الإنتاجي عقد Compaction واضحًا:

تقول OpenAI إن Pando يحتفظ بـPacks في كل الطبقات. يسهل ذلك بعض الاستعادة وAPI Reads لكنه يزيد التخزين. قد تختار مؤسسة أخرى Garbage Collection، لكن بعد إثبات Reachability وRetention Windows وReader Leases وRestore Procedures.

معمارية عملية لنطاق وكلاء البرمجة

لا تبدأ بخادم Git مخصص. ابدأ بعزل Workloads والأدلة.

### 1. Agent Workspaces

أعط كل Agent أوTask Checkout معزولة، وCredential محدودة، وBase Commit صريحة، وفرعًا فريدًا. طبق عمرًا وتخزينًا أقصى، وأزل الاعتماد قبل الاحتفاظ بـArtifacts.

### 2. Ref Admission Control

استخدم Compare-and-swap لتحديث الفروع. احم Trunk وRelease Refs. حد تزامن Push لكل Actor ومستودع من دون Global Lock واحدة للفروع المستقلة.

### 3. Immutable Object Plane

تحقق من Pack أثناء الإدخال، وخزن البايتات الثابتة تحت Content-derived Identity، وسجل Dependencies قبل نشر Ref Version. تعامل مع Pack Parsing كحد Untrusted Input.

### 4. Fetch Planner وCache

خطط من Commit/Ref-version Mapping المسجلة. وقّع Pack URLs لجمهور وزمن محدودين. تحقق من Checksum لدى العميل، وراقب Cache Misses، واحتفظ بمسار Authoritative Fallback.

### 5. Merge وCI Control Plane

أزل تكرار CI للـCommit وPolicy Version نفسيهما. استخدم Merge Queue وRetry محدود وRequired Checks. نجاح Agent Push ليس إذن Merge أوDeploy.

### 6. Evidence and Security Plane

سجل Actor وAgent Run وCredential وBase/Tip Commit وPolicy Version وPack Checksum وRef Decision وCI Result وReview Decision وDeployment Link. احتفظ بما يكفي للتحقيق دون تسجيل Source أوSecrets غير لازمة.

agent workspace -> validated push -> immutable pack storage
       |                  |                 |
       v                  v                 v
 scoped identity     ref version       regional cache
       |                  |                 |
       +------> CI and merge policy <------+
                         |
                         v
                 signed evidence record
~~

## رحّل خلف Compatibility Boundary

تقول OpenAI إنها أدخلت Pando كـRead/Write-through Proxy أمام النظام السابق، وأبقت الاثنين متزامنين، ورحلت العملاء على مراحل، ونقلت مئات Integrations من APIs وWebhooks وRepository Downloads.

هذا شكل ترحيل سليم:

1. اجرد Git Clients وCI Runners وWebhooks وReview Bots وMirrors وBackup Jobs؛
2. أعد تشغيل Read Traffic وقارن Object وRef Results؛
3. ظلل الكتابات المقبولة إلى النظام الجديد دون خدمتها؛
4. تحقق من Reachability وRef Tips وHooks وDownstream Events؛
5. نفذ Canary لمستودعات أوActors منخفضي المخاطر عبر Proxy؛
6. حافظ على Rollback واضح وطابق النتائج المتباينة؛
7. توسع فقط بعد نجاح Push-to-fetch وMerge Reliability وCorrectness Gates؛
8. أوقف المسار القديم بعد Restore وDR Drills.

لا تنفذ Dual-write من Application Code إلى سلطتين. يجب أن تملك Proxy واحدة القرار وIdempotency Key وسجل Reconciliation.

## بوابات التقييم

اختبر السلوك لاThroughput فقط:

- Git Conformance عبر نسخ العملاء المدعومة؛
- Push متزامنة إلى Ref نفسها وRefs مستقلة؛
- Force-with-lease وProtected Branches؛
- Push منقطعة وPartial Blob Upload وMetadata Timeout؛
- منع Ref ظاهرة مع Object متأخرة أومفقودة؛
- Cache Poisoning وExpired URI وWrong-tenant Access؛
- Clone/Fetch بعد غياب طويل وتاريخ عميق؛
- Compaction Crash وDuplicate Job وIndex Corruption؛
- ترتيب Webhooks وتكرارها وفقد التسليم؛
- CI Deduplication وStale-base Rejection؛
- Regional Outage وMetadata Failover؛
- Restore من Immutable Packs وMetadata Backups.

ولأحمال الوكلاء أضف مستودعات عدائية، وأسماء ملفات خبيثة، وObjects ضخمة، وحدود Decompression، وPackfiles مصنوعة، وHooks غير موثوقة، وPrompts تحاول تجاوز Branch Policy. تزيد الوكلاء المعدل والتنوع؛ ولا تغير Trust Boundary.

## أفضل الممارسات

- ثبت كل Agent Task على Base Commit وPolicy Version صريحتين.
- سلسل التحديثات المتنافسة لكل Ref بدل المستودع كله.
- تحقق من Object Reachability قبل إعلان Ref جديدة.
- قس Push-to-fetch باستخدام قارئ مستقل.
- أعد استخدام البيانات الثابتة فقط مع إثبات Dependencies وChecksums.
- أبق Merge وReview وDeployment Authority خارج Agent.
- اجمع Conformance والمحاكاة الحتمية وFault Injection.
- رحّل عبر Proxy فيها Reconciliation وRollback.
- افصل أرقام الشركات عن أدلة محلية قابلة للتكرار.
- حافظ على توافق Git ما لم يثبت القياس ضرورة كسره.

## Anti-patterns والقيود

- القول إن Pando منتج OpenAI متاح؛ المقال يقول إن الشركة تستكشف طرق مشاركة التقنية.
- نسخ Pando لأن الوكلاء رائجة دون قياس ضغط المستودع.
- معاملة Causal Consistency كتفصيل غير مرئي.
- إظهار Ref قبل دوام Reachable Objects.
- إعادة استخدام Pack دون إثبات Dependency Closure.
- تمرير كل الكتابات عبر Global Manifest أوLock واحدة.
- عد Push المقبولة مع تجاهل Fetch مستقلة.
- إعطاء الوكلاء Git أوCloud Credentials واسعة وطويلة العمر.
- مساواة أرقام OpenAI بـBenchmark مستقلة.
- إزالة النظام السابق قبل نجاح Failure وRestore Drills.

لا ينشر مقال OpenAI Pando كخدمة عملاء مدعومة، ولاSource Code كاملًا أوInfrastructure Cost أوSecurity Model كاملًا أوBenchmark قابلة لإعادة الإنتاج. هذه حدود مهمة. ينبغي لمعظم الفرق أولًا تحسين Branch Isolation وMerge Queues وCI Deduplication وPartial Clone وCaches وObservability قبل التفكير في Backend جديدة.

## قائمة تنفيذية

1. قس Branch Concurrency وPush-to-fetch Latency.
2. حدد كل Consumer يفترض Cross-ref Atomicity.
3. ثبت عمل الوكيل على Commits وفروع معزولة.
4. احم Refs بـCompare-and-swap وLeast Privilege.
5. افحص Packfiles وObject Reachability قبل النشر.
6. افصل Immutable Object Storage عن Ref Coordination.
7. أثبت Cache Integrity وTenant Scope وFallback.
8. قيد Compaction بـLeases وChecksums وBacklog SLOs.
9. نفذ Git Conformance وFault Injection واختبارات وكلاء عدائية.
10. رحّل عبر Proxy قابلة للعكس واحتفظ بالأدلة.

اقرأ أيضًا: [عقد أفعال الوكيل من OpenAI Model Spec](https://nooryasser.com/ar/articles/openai-model-spec-agent-autonomy-action-contract/)، و[GPT-6.1 Terra وComputer Use المحروس](https://nooryasser.com/ar/articles/gpt-6-1-terra-guarded-computer-use/)، و[التحكم في الحمل الموزع](https://nooryasser.com/ar/articles/distributed-overload-deadlines-load-shedding/)، و[مركز AI وRAG والبحث المتجهي](https://nooryasser.com/ar/topics/ai-rag-vector-search/)، و[خدمات الأداء والسحابة](https://nooryasser.com/ar/services/performance-cloud/).

## المراجع الأساسية

- [OpenAI — Scaling Git at OpenAI](https://openai.com/index/scaling-git-at-openai/)
- [OpenAI — نسخة Git العامة](https://github.com/openai/git)
- [OpenAI Git — الرقع والملاحظات](https://oai-git.openai.chatgpt.site/)
- [Git — توثيق Pack Format](https://git-scm.com/docs/pack-format)
- [Git — Protocol v2](https://git-scm.com/docs/protocol-v2)
- [Git — Pack Protocol](https://git-scm.com/docs/gitprotocol-pack)
- [Wikimedia Commons — صورة خلفية Rack في NERSC](https://commons.wikimedia.org/wiki/File:Rear_of_rack_at_NERSC_data_center_-_closeup.jpg)
- [Creative Commons — CC0 1.0](https://creativecommons.org/publicdomain/zero/1.0/)

إعداد: Noor Yasser

إعداد: Noor Yasser