选择 Crate 与 Cargo Feature

门面或窄 Crate

组合模型、Agent、Workflow、Tool 与可选集成的应用使用 runifold。它重新导出稳定公共 接口；具体 Provider Adapter 由独立的 runifold-providers 选择。构建基础设施、Adapter 或不应依赖 编排的 Library 时，使用窄 Crate。

Feature 地图

0.9 的门面不再包含 Provider Feature。在 runifold-providers 上启用 openai、 anthropic、bedrock、gemini 与 ollama；具名兼容模块复用其中的 openai Feature。runifold 的可选平台 Feature 包括 mcp、 otel、sqlite、sqlite-bundled、workflow-postgres、qdrant、pgvector 与 archive-s3。

Feature 选择编译能力，而不是运行时权限。启用 mcp 或 archive-s3 不会授予 Run 调用 或删除权限。

常见配置

• 模型 API：门面 + 一个 Provider Feature；
• 本地持久服务：Provider + sqlite；
• 分布式 Workflow 平台：Provider + workflow-postgres + otel；
• RAG 服务：Provider + pgvector 或 qdrant；
• MCP Workflow Server：mcp + workflow-postgres；
• 治理归档：workflow-postgres + archive-s3 + otel。

可以从小于生产拓扑的配置开始，但不要选择与最终部署语义冲突的 Store。

依赖边界

CLI 专属 Crate 不进入 Runtime 依赖；数据库 Adapter 留在应用边缘；可复用 Library 不要 启用所有 Provider。向内传 Trait Object 或窄接口，而不是 Provider Client、数据库 Pool 与凭证类型。

出现意外 HTTP、数据库、云或 TLS 依赖时，用 cargo tree -e features 检查来源。

升级检查

固定精确的 1.0 前版本，阅读 Changelog，检查 Feature 变化，运行 MSRV 与目标平台构建， 重新编译示例，执行 Store 迁移和恢复测试，再运行 Provider Conformance 并比较评测 Baseline。API 兼容的依赖更新仍可能改变模型或 Provider 行为。

选择并审计 Features

二进制只应启用自己真正拥有的能力。下面的命令固定使用已发布的 0.9.0：

# OpenAI + 内置 SQLite 的本地持久服务
cargo add runifold@=0.9.0 --features sqlite-bundled
cargo add runifold-providers@=0.9.0 --features openai
 
# PostgreSQL + OpenTelemetry 的分布式 Worker
cargo add runifold@=0.9.0 --features workflow-postgres,otel
cargo add runifold-providers@=0.9.0 --features openai
 
# 检查实际启用的依赖图
cargo tree -e features -i runifold
cargo tree -e features -i runifold-providers
cargo tree -d
cargo check --all-targets

如果出现意外的 TLS 栈、数据库驱动或云 SDK，用 cargo tree -e features 追溯来源，并在应用边界移除对应 Feature。可复用库应优先设置 default-features = false，再用自己的小 Feature 只转发必要能力。