أعطِ وكيل الذكاء الاصطناعي قاعدة معرفة: اربط مستنداتك ليجيب من مشروعك لا من الإنترنت

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

الحل ليس نموذجًا أذكى، بل إعطاء الوكيل وصولًا إلى مستنداتك الفعلية، كي يجيب مما دوّنه فريقك بدل متوسط الإنترنت. هذا ما يقصده الناس بعبارة "أعطِ الوكيل قاعدة معرفة"، وفي 2026 يوجد نمط واضح لفعل ذلك جيدًا. تشرح هذه التدوينة النمط وتُري كيف يعمل حين تكون مستنداتك أصلًا بجوار العمل، في أداة مثل Taskfolk.

لماذا يخمّن النموذج العام

نموذج اللغة لا يعرف إلا شيئين: ما تعلمه أثناء التدريب، وما تضعه أمامه الآن. مستند التهيئة عندكم، وأعراف API لديكم، وسبب تخليكم عن مسار الفوترة القديم، لا شيء من ذلك كان في التدريب. إن لم تسلّمه إياه وقت السؤال، سدّ النموذج الفجوة بأفضل تخمين إحصائي لديه.

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

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

نمط 2026: استرجاع جيد، مكشوف عبر MCP

استقر أمران خلال السنة الماضية.

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

ثانيًا، توحّدت الوصلات على Model Context Protocol. قبل MCP، كان ربط وكيل بمستنداتك يعني كتابة أداة مخصصة لكل عميل، ووصف كل نداء في التوجيهات، وإبقاء ذلك الوصف متزامنًا إلى الأبد. أما MCP فهو شكل موحد يفهمه النموذج أصلًا. تكشف الخدمة أدوات البحث والقراءة مرة واحدة، يكتشفها العميل، ويستطيع أي وكيل يدعم MCP استخدامها بلا وصلات مخصصة. كتبنا أكثر عن هذه الموازنة في هل يستخدم وكيلك MCP أم REST API.

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

هكذا يبدو الأمر حين يسأل وكيل شيئًا فعلًا:

sequenceDiagram
    participant A as Agent, any MCP client
    participant M as MCP server
    participant K as Docs + issues search
    A->>M: discover the tools, once, no glue code
    A->>M: search "deploy checklist"
    M->>K: query the live workspace
    K-->>M: current doc sections and issues
    M-->>A: results, with sources
    Note over A: answer grounded in what it found

أين يقع Taskfolk في الصورة، وأين لا يقع

إليك النطاق الصريح مقدمًا. ‏Taskfolk ليس منصة RAG عامة. لا توجهه نحو مجلد ملفات PDF ولا نحو Google Drive كله. ولن يفهرس تاريخ Slack عندكم ولا الكود لديكم.

ما يفعله Taskfolk أضيق، وأنفع بالنسبة إلى أداة مشاريع: يؤسس الوكيل في مساحة عملك. المستندات تعيش في المكان نفسه الذي تعيش فيه مهامك ولوحتك والباكلوج. هذا التجاور هو بيت القصيد. حين يسأل وكيل "ما معايير القبول للمهمة WEB-142"، فالمستند الذي يصفها والمهمة التي تنتمي إليها في المستأجر نفسه، يبلغهما المفتاح نفسه، ويجدهما بحث واحد بنداء واحد.

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

ما الذي يعيش في Taskfolk ويستطيع الوكيل قراءته

لدى Taskfolk توثيق على مستوى مساحة العمل بنص غني وصور، وإشارات بين المستندات، وسجل نسخ. يمكن أن تكون المستندات عامة لمساحة العمل كلها (كتيّب هندسي، دليل أسلوب) أو محصورة في مشروع واحد (ملاحظات معمارية المشروع، دليل تشغيله). وإلى جوارها تجلس المهام والتعليقات والحقول المخصصة، وهي "ما يعرفه الفريق" بقدر أي مستند رسمي.

يعمل البحث على Typesense عبر المستندات والمهام معًا. يتسامح مع الأخطاء الإملائية ويرتب حسب الصلة، وهذا هو نصف النمط الخاص بجودة الاسترجاع وهو يؤدي عمله.

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

flowchart TD
    Q[Agent question] --> S[Search the workspace]
    S -->|hits| C[Put docs in context]
    C --> G[Grounded answer]
    S -->|index down| E[Fast empty result]
    E --> H[Agent says it does not know]

ربط وكيل بها

الميكانيكا قصيرة. كل قدرة يكشفها Taskfolk عبر واجهة REST API مكشوفة أيضًا كأداة MCP، مولّدة من المصدر نفسه، فلا ينحرف أحدهما عن الآخر أبدًا. وللتأسيس، تهمك ثلاث من تلك الأدوات:

• search تبحث عبر المهام والمستندات. نداء واحد يأخذ استعلامًا ومرشح نوع اختياريًا (types=issue,doc) ويعيد نتائج مرتبة من مساحة العمل. هذه خطوة الاسترجاع.
• get_doc تقرأ مستندًا. حين يشير البحث إلى المستند الصحيح، يجلب الوكيل متنه الكامل ليضعه في السياق.
• list_docs تسرد المستندات، لوكيل يريد أن يتمشى في توثيق مشروع بدل البحث فيه.

في عميل يدعم MCP أصلًا، تضيف خادم Taskfolk مرة واحدة بمفتاح API فتظهر هذه الأدوات في عدة الوكيل:

claude mcp add taskfolk-product https://taskfolk.ai/api/mcp/v1/ \
  --header "Authorization: Bearer tfk_live_YOUR_KEY"

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

وإن كان وكيلك يتكلم HTTP الصِرف بدل ذلك، فخطوة الاسترجاع نفسها هي GET واحد. إليك الطلب بثلاث طرق:

curl "https://taskfolk.ai/api/v1/workspaces/YOUR_WORKSPACE/search?q=deploy+checklist&types=issue,doc" \
  -H "Authorization: Bearer tfk_live_YOUR_KEY"

const res = await fetch(
  "https://taskfolk.ai/api/v1/workspaces/YOUR_WORKSPACE/search?" +
    new URLSearchParams({ q: "deploy checklist", types: "issue,doc" }),
  { headers: { Authorization: "Bearer tfk_live_YOUR_KEY" } },
);
const { data } = await res.json();

import requests

res = requests.get(
    "https://taskfolk.ai/api/v1/workspaces/YOUR_WORKSPACE/search",
    params={"q": "deploy checklist", "types": "issue,doc"},
    headers={"Authorization": "Bearer tfk_live_YOUR_KEY"},
)
hits = res.json()["data"]

الاستجابة قائمة واحدة مرتبة بالصلة تخلط نوعي النتائج، فيرى الوكيل المستند والتذكرة جنبًا إلى جنب:

{
  "data": [
    {
      "type": "doc",
      "id": "0197f3a2-...",
      "title": "Release checklist",
      "icon": null,
      "project_slug": "web",
      "updated_at": "2026-05-28T09:14:00.000Z"
    },
    {
      "type": "issue",
      "key": "WEB-142",
      "id": "0197f3a2-...",
      "title": "Ship the new billing flow",
      "project_key": "WEB",
      "project_slug": "web",
      "project_name": "Web app",
      "issue_type": "story",
      "status": "in_progress",
      "priority": "high",
      "updated_at": "2026-06-01T15:02:00.000Z"
    }
  ],
  "pagination": { "next_cursor": null }
}

وحين يشير البحث إلى المستند الصحيح، تكون قراءته نداء واحدًا إضافيًا:

curl "https://taskfolk.ai/api/v1/workspaces/YOUR_WORKSPACE/docs/DOC_ID" \
  -H "Authorization: Bearer tfk_live_YOUR_KEY"

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

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

سير العمل الذي يفتحه هذا

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

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

الموازنات، بوضوح

الاسترجاع لا يكون أفضل مما دوّنته. الوكيل المؤسس على مستند متقادم منذ ستة أشهر سيكرر بثقة حقائق عمرها ستة أشهر. ينقل RAG المشكلة من "النموذج لا يعرف" إلى "أبقوا المستندات محدّثة"، وهي مشكلة أفضل لكنها حقيقية. سجل نسخ المستندات في Taskfolk يساعدك على رؤية آخر تغيير؛ لكنه لا يستطيع إجبار أحد على التحديث.

كما أن MCP ما زال فتيًا. المواصفة تتحرك، ودعم العملاء متفاوت، فبعض الوكلاء سيحتاج مسار REST الصِرف بدلًا منه. لا بأس، فالبابان يصلان إلى الأدوات نفسها.

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

إن أردت أن تجرب، ضع مستندات مشروعك في Taskfolk، أنشئ مفتاحًا للقراءة فقط بصلاحيتي docs:read وsearch:read، ووجّه وكيلًا واحدًا نحوه. راجع توثيق المطورين للإعداد، والتسعير إن كنت توازن المقاعد.