الأدوات Runtime
Tools Runtime
ابدأ بالمعنى، ثم انتقل إلى التفاصيل.
هذا الدرس يشرح الأدوات Runtime ضمن موضوع داخل Hermes وكيف يوسّعه المطور. ستعرف ما الذي يفعله هذا الجزء، متى تحتاجه، وما أصغر خطوة آمنة للتأكد أنه يعمل.
إن كنت جديدًا: لا تحفظ الأسماء. ركّز على ثلاثة أسئلة: ما المشكلة التي يحلها هذا الجزء؟ ما البيانات أو الصلاحيات التي يحتاجها؟ وكيف أعرف أن النتيجة صحيحة؟
للتطبيق: اقرأ المثال الأول، حدّد ما سيغيّره، نفّذه على بيانات تجريبية، ثم قارن الناتج بما وعد به المصدر.
للمتخصص: راجع Tool registration model، How registry.register() works، Discovery: discoverbuiltintools()، ثم افحص حالات الفشل والتوافق مع إصدارك.
اعرف Python وGit وبنية مشروع برمجي قبل تعديل الكود.
نتيجة واضحة قبل أن تقرأ.
- تفهم الأدوات Runtime من دون افتراض معرفة سابقة.
- تفرّق بين الوصف والمعلومة التي تحتاج إلى اختبار في بيئتك.
- اقرأ الأمر الأول وحدد المدخلات والمخرجات قبل نسخه.
تعريفات قصيرة قبل التفاصيل.
- Provider
- الخدمة التي تشغّل النموذج أو توفّر الوصول إليه والمصادقة الخاصة به.
- Tool
- فعل منظّم يستطيع الوكيل استدعاءه لقراءة شيء أو تغييره.
Runtime behavior of the tool registry, toolsets, dispatch, and terminal environments
ما الذي يقوله المصدر، وبأي ترتيب؟
- 01Tool registration model
ابدأ بهذا القسم لتفهم الفكرة أو البنية الأساسية.
- 02How registry.register() works
اقرأه بعد الأساسيات، ثم اربطه بالخطوة السابقة قبل المتابعة.
- 03Discovery: discoverbuiltintools()
اقرأه بعد الأساسيات، ثم اربطه بالخطوة السابقة قبل المتابعة.
- 04Tool availability checking (checkfn)
اقرأه بعد الأساسيات، ثم اربطه بالخطوة السابقة قبل المتابعة.
- 05Toolset resolution
اقرأه بعد الأساسيات، ثم اربطه بالخطوة السابقة قبل المتابعة.
- 06How gettooldefinitions() filters tools
اقرأه بعد الأساسيات، ثم اربطه بالخطوة السابقة قبل المتابعة.
- 07Legacy toolset names
اقرأه بعد الأساسيات، ثم اربطه بالخطوة السابقة قبل المتابعة.
- 08Dispatch
اقرأه بعد الأساسيات، ثم اربطه بالخطوة السابقة قبل المتابعة.
- 09Dispatch flow: model toolcall → handler execution
اقرأه بعد الأساسيات، ثم اربطه بالخطوة السابقة قبل المتابعة.
- 10Error wrapping
اختم بهذا القسم لتفحص النتيجة والحالات الخاصة.
انسخ بعد أن تفهم الأثر.
Each call creates a `ToolEntry` stored in the singleton `ToolRegistry._tools` dict keyed by tool name. A registration that would shadow an existing tool from a **different** toolset is rejected (with an error log) unless the caller passes `override=True`; plugin overrides of built-in tools additionally require the operator opt-in `plugins.entries.<plugin_id>.allow_tool_override: true` in `config.yaml`.
`schema["description"]` is the authoritative model-facing description. The separate `description=` argument populates `ToolEntry.description`; when it is omitted, the registry metadata falls baThis auto-discovery means new tool files are picked up automatically — no manual list to maintain. The AST check only matches top-level `registry.register()` calls (not calls inside functions), so helper modules in `tools/` are not imported.
Each import triggers the module's `registry.register()` calls. Errors in optional tools (e.g., missing `fal_client` for image generation) are caught and logged — they don't prevent other tools from loading.
After core tool discovery, MCP tools and plugin tools are also discovered:
1. **MCP tools** — `tools.mcp_tool.discover_mcp_tools()` reads MCP serverKey behaviors:
- Check results are **cached per-call** — if multiple tools share the same `check_fn`, it only runs once.
- Exceptions in `check_fn()` are treated as "unavailable" (fail-safe).
- The `is_toolset_available()` method checks whether a toolset's `check_fn` passes, used for UI display and toolset resolution.
## Toolset resolution
Toolsets are named bundles of tools. Hermes resolves them through:
- explicit enabled/disabled toolset lists
- platform presets (`hermes-cli`, `hermes-telegram`, etc.)
- dynamic MCP toolsets
- curated special-purpose sets like `hermes-acp`
### How `get_tاقرأ الأمر الأول وحدد المدخلات والمخرجات قبل نسخه.
طابق أي أمر مع إصدار Hermes المثبّت، وراجع الملفات والحسابات التي قد يصل إليها، واستخدم بيانات غير حساسة في أول اختبار. إذا اختلف الشرح عن المصدر، فالمصدر الرسمي هو المرجع النهائي.