理解完整的 Runifold 平台

一张图理解平台

Runifold 不只是 Agent 框架，而是一套分层执行平台：

应用→Agent / Workflow / MCP→Run 内核→Model / Tool / Store

应用选择产品入口，所有入口复用同一套身份、取消、预算、Capability、事件与 Effect 语义。Workflow 可以调用 Agent，MCP Task 可以代表 Workflow，Agent 可以使用检索和类型化 Tool；它们仍然属于同一棵因果 Run 树。

产品面	负责	不负责
执行内核	身份、生命周期、权限、记账、事件	模型或工作流策略
模型协议	中立请求、流、响应与能力证据	Agent 循环
Agent	模型-工具循环、结构化输出、会话、委派	持久业务跳转
工作流	确定性组合、Checkpoint、Worker、等待、Lease	Prompt 语义
集成	MCP、检索、向量存储、SQL Store	应用授权
评测	确定性替身、Scorer、实验与 CI 门禁	生产流量
可观测性	Trace、Metric、Journal 与 SLO 资产	业务补偿

因此你可以直接使用模型层，构建完全不含 Agent 的确定性工作流，或者通过 MCP 暴露持久任务，而不必把所有系统都包装成聊天助手。

Crate 家族	主要职责
`runifold-core`	Run ID、Context、预算、取消、Capability、事件与 Journal
`runifold-model`、`runifold-providers`	规范模型协议与服务商适配器
`runifold-tool`、`runifold-agent`、`runifold-effect`	可调用边界与 Agent 执行
`runifold-workflow`	持久编排、Worker、等待、多租户与保留
`runifold-mcp`、`runifold-retrieval*`	外部能力与知识边缘
`runifold-store-*`	SQLite 与 PostgreSQL 持久化
`runifold-testkit`、`runifold-eval-cli`	离线正确性与质量证据
`runifold-observability-otel`	OpenTelemetry 与运维策略
`runifold`	按 Feature 重新导出平台能力的门面

应用通常从门面 crate 开始；基础设施库可以依赖更窄的 crate，以保持依赖与 Feature 边界明确。

这些规律比具体 Builder 方法稳定。先理解规律，再用对应版本 API Reference 查找精确接口。