Directory-as-ID：在无需配置的情况下扩展模块发现

Source: Dev.to

引言

在上一卷中，我们探讨了 AI‑可感知 世界的愿景。现在，是时候深入内部实现了。apcore 协议的第一个技术支柱是一个看似简单的概念：目录即 ID。

在传统的微服务或模块化架构中，中心注册表、庞大的 YAML 配置或复杂的依赖注入容器往往会成为系统从 10 个模块扩展到 1,000 个模块时的瓶颈。合并冲突、命名冲突以及 “扩展腐烂” 是常见的痛点。

apcore 通过让文件系统成为唯一可信来源来解决这些问题。在本篇第十篇文章中，我们将了解 Directory-as-ID 背后的算法以及它为何对 AI‑就绪系统的扩展至关重要。

算法：从路径到规范 ID

原则很直接：模块文件的相对路径即为其唯一标识。

如果你有一个模块根目录（例如 extensions/），apcore 会扫描文件并应用确定性的映射：

1. 去除根目录

   extensions/executor/email/send.py → executor/email/send.py

2. 去除扩展名

   executor/email/send.py → executor/email/send

3. 标准化分隔符

   executor/email/send → executor.email.send   (规范 ID)

为什么这对 AI 很重要

AI 代理对名称极其敏感。通过使用层级化、基于目录的命名约定，你自然会形成 命名空间。代理能够快速区分 executor.user.delete 与 admin.user.delete，因为层级结构提供了上下文。

案例研究：apexe 中的零配置

apexe：为 CLI 宇宙注入 AI

apexe 会扫描已有的 CLI（例如 git 或 docker），并将其包装成 apcore 模块。运行：

apexe scan git

会在 ~/.apexe/modules/ 下生成一套模块层级：

• git commit → cli.git.commit
• git push → cli.git.push

由于采用 Directory-as-ID，apexe 不需要管理 ID 数据库。它只需把文件写入相应的文件夹，apcore 注册表即可瞬间“感知”整个 CLI 命令树。这实现了 动态技能发现：安装新 CLI 工具并扫描后，代理立即获知，无需重启服务器。

技术严谨性：处理多语言漂移

语言无关标准的核心挑战在于不同语言拥有不同的命名约定（Python 偏好 snake_case，TypeScript 偏好 camelCase）。

apcore 协议定义了严格的 ID 标准化规则：

• 标准化：所有 ID 均转换为规范形式（小写、snake_case），供注册表使用。
• 语言映射：每个 SDK（Python、TypeScript、Rust）在规范 ID 与本地文件名之间进行转换（例如 SendEmail.ts 映射为 send_email）。

这确保即使在多语言企业环境中，AI 代理也只能看到单一、统一的地址空间。

结论：规模是设计约束

Directory-as-ID 不仅是便利，更是 Agentic 时代的设计约束。它实现了 零配置发现，消除了注册表瓶颈，并为 AI 感知提供了自然的命名空间。

在下一篇文章中，我们将深入引擎核心：11 步执行流水线。

本文是 apcore：构建 AI‑可感知世界 系列的第 10 篇文章。

GitHub: