Memory Center 06｜从单项目工具演进为多项目常驻服务

本文属于 Memory Center：AI 编程上下文与记忆系统工程实践，第 06 篇，位于“服务架构与项目边界”模块。案例背景统一采用实际开发项目；复现步骤使用脱敏教学样例，不代表特定生产事故。

从实际问题出发

当多个 AI 宿主都要访问多个项目时，每个连接启动一套绑定目录的工具，会重复承担生命周期和配置成本。服务化把长期运行、项目登记和查询能力集中起来，但也带来了并发和隔离责任。

为什么保留稳定项目上下文

共享服务不能依赖一个可变的“当前项目”字段。请求应携带稳定项目身份，经授权后形成受控上下文。否则并发请求切换目录时，可能把一个项目的证据交给另一个项目。

从单项目工具演进为多项目常驻服务：设计链路示意

图中展示的是本篇关注的职责和顺序。正常流程之外，还要结合下面的源码与实验检查失败分支；它不是对某次线上调用的运行时追踪。

服务化增加了什么成本

需要明确启动和关闭顺序、就绪探针、Worker 回收、凭据撤销与后台任务恢复。单进程服务仍然有单实例边界，不能因为有 HTTP 入口就宣称适合任意远程团队。早期单项目接口只作为演进背景，不能当成当前接入方式。

关键源码与阅读方法

源码基线为 Memory Center 6e90553（文档标注 5.0.0b24）。定位：memory_center/service/app.py，函数 create_service_app，起始行 88。

以下为源码节选，省略后续分支；不能作为独立脚本执行。

def create_service_app(config: ServiceConfig, *, static_dir: Path | None = None) -> FastAPI:
    static_dir = static_dir or Path(__file__).parent / "static"
    ready = False
    mcp = FastMCP(
        "Memory Center 5.0",
        stateless_http=False,
        json_response=True,
        streamable_http_path="/mcp",
        transport_security=TransportSecuritySettings(
            enable_dns_rebinding_protection=True,
            allowed_hosts=list(config.allowed_hosts),
            allowed_origins=[f"http://{host}" for host in config.allowed_hosts],
        ),
    )

    mcp.service_config = config

    def status() -> ServiceStatus:
        return {
            "schema_version": "5.0",
            "version": __version__,
            "stage": release_stage(__version__),
            "ready": ready,
            "capabilities": ["service_status", "workspace_catalog", "scoped_mcp", "background_index", "knowledge", "wiki", "memory", "knowledge_governance", "skill_management"],
            "project_management": "ready",
            "auth_mode": config.auth_mode,
            "single_instance": True,
            "storage": storage_status(config),
            "index_limits": index_limits_status(),
        }

    @mcp.tool()
    def mc_service_status() -> ServiceStatus:
        """返回服务就绪状态与已实现能力，不读取项目或历史配置。"""
        return status()

阅读时先找输入由谁提供，再区分纯计算、读取和写入；遇到异常或提前返回，追问调用方会得到什么，以及已有状态是否仍然有效。上面的代码只证明展示范围内的实现，跨模块行为应继续查看调用处和相应测试。

用一个小实验核对设计

建议在独立临时目录和隔离数据中操作，使用虚构的接口、文档与项目名称。

登记两个微型项目。
交替查询同名函数。
暂停其中一个项目后再次查询。

**要核对的结果：**结果必须保留项目身份，暂停应有明确行为，不能串用另一项目索引。

可把观察记录为下表；没有执行的项写“未执行”，不能用设计预期冒充实测结果。

核对项	应保留的证据
使用条件	源码版本、配置、输入与项目范围
正常行为	实际返回、来源位置或状态变化
关键失败分支	错误码、可见结果与原状态是否保留
结论范围	已覆盖、未覆盖和需要进一步验证的条件

适用边界与继续阅读

本篇以静态源码与项目设计为依据，给出可执行的核对方法，未据此宣称已经完成新的性能或生产环境测试。不同版本的入口、默认值和底层实现可能变化，应先核对当前合同，再把方法用于自己的实际开发项目。

理解这一节后，可以回到专题总导航，沿同一模块继续阅读；顺序学习时使用专栏内的上一篇和下一篇。涉及具体技术选择，应连同本篇的代价与限制一起采用。

专题目录

从单项目工具演进为多项目常驻服务