“MAF 负责整个平台运行”
不对MAF 只进入 AI 生成域：模型客户端、Agent 工具循环、FunctionTool、Workflow 和 Checkpoint。网站、鉴权、项目、数据库、支付、积分、Celery、报告存储都由 PackHorizon 自己负责。
官方：Agents / Harness / Workflows；项目：FastAPI + React + PostgreSQL + Celery
最准确的说法：PackHorizon 自己造了业务规则、规划器、计划、数据与质检；MAF 提供模型客户端、Agent、FunctionTool、Workflow 与 Checkpoint。当前规划会动态选 Skill 和生成 DAG，但生产执行尚未使用 MAF 原生 Skill 按需发现，Tool 授权也主要由 Skill 元数据确定。
不是简单的“对或错”：当前实现同时存在 MAF 原生底座、自建业务层，以及几处只搭了接口但没有进入生产主链的能力。
MAF 只进入 AI 生成域：模型客户端、Agent 工具循环、FunctionTool、Workflow 和 Checkpoint。网站、鉴权、项目、数据库、支付、积分、Celery、报告存储都由 PackHorizon 自己负责。
产品类型确实只有两个，但运行口径是三条路径：新包装完整、旧包装完整升级、旧包装部分升级。并且本地生效配置里“新包装完整”的 Planning Policy 为空，当前会在规划入口被拒绝。
Tool 在执行时会被包装成 MAF FunctionTool；但注册表、启停、权限与审计是项目自建。MAF 原生 SkillsProvider 已有辅助代码，生产 Task Agent 却仍把选中 Skill 正文直接拼进 instructions，没有 context_providers，也不会自行 load_skill。
自建 Model Planner 会动态选择 Skill 并生成 DAG，所以技术上不是固定步骤；但 Planner 不选择 Tool，Tool 由 Skill metadata 确定性补齐。完整路径又因一类交付物通常只有一个 Skill，实际自由度很小，业务效果接近受约束的模板流。
“使用了 MAF”不等于“这些概念都是 MAF 的”。项目大量价值来自自建的业务治理层。
| 能力 | 归属 | 当前项目怎么用 | 状态判断 |
|---|---|---|---|
| Agent / ChatClient | MAF 原生 | Planner 用 MAF ChatClient 做结构化输出；业务 Task 用 MAF Agent 执行。 | 主链在用 |
| FunctionTool | MAF 原生权限自建 | 项目把 ToolBroker 授权后的工具包装成 FunctionTool；越权、审计、Manifest 与启停由项目负责。 | 混合实现 |
| Agent Skills | MAF 原生 | 安装包支持 SkillsProvider、FileSkillsSource、load_skill、read_skill_resource。项目也写了 provider helper。 | 生产未接线 |
| Harness | MAF 原生 | 仓库有 build_harness / build_shared_harness 适配器，但产品域没有调用者；当前 Intake 直接调 ChatClient。 | 适配存在 · 主链未用 |
| Workflow / Step | MAF 原生编译器自建 | PlanWorkflow 把自建 PlanSpec 编译成 MAF FunctionalWorkflow，使用 @workflow、@step、并行与恢复。 | 主链在用 |
| Checkpoint / Resume | MAF 原生持久化接线自建 | FileCheckpointStorage 保存步骤结果；项目负责目录、Run 状态、Resume API 与幂等 outbox。 | 代码已接 |
| Business Contract / Policy | PackHorizon 自建 | 限定业务路径、可用 Skill、必需交付物、图片数量和终局报告，不是 MAF 的概念。 | 领域治理层 |
| Planner / Plan / Frozen Plan | PackHorizon 自建 | 模型起草 DAG、Validator 校验、指纹与哈希冻结；只借用 MAF ChatClient，不是 MAF Harness 的内置计划。 | 核心自建 |
| Reviewer / Final Gate / Report | PackHorizon 自建 | 结构校验、独立评审、图片防伪、六方向装配、发布闸与报告表均由项目实现。 | 核心自建 |
橙色是项目自建，蓝色是 MAF 原生，绿色表示“自建业务逻辑运行在 MAF 原语之上”。
答案是“动态编排、强约束、低选择空间”。这三个词缺一个都会产生误解。
不能说“完全固定流程”，因为 DAG 确实由模型生成；也不能说“MAF 在自由规划整个平台”，因为 Planner 是项目自建，而且完整路径的 Skill、依赖和交付约束几乎把结果收敛成一条稳定主链。更准确：自建 Planner 在自建规则框内，生成一张由 MAF 执行的动态任务图。
这里是本地运行中的真实数据库与容器状态，不是迁移文档目标。
安装的 MAF 1.11.0 确实导出 SkillsProvider / FileSkillsSource / load_skill / read_skill_resource；仓库也有 build_skills_provider。
生产 Agent 没有传 context_providers；build_skills_provider 没有生产调用者。当前依然是 skill_bodies[name] 直接加入 instructions。
三条路径当前都允许全部 9 个 Skill，并未按“新包装 / 升级”收窄 Skill 白名单。
9 个 Skill 中只有 packaging-intelligence 声明 4 个必需 Tool，image-brief 声明 image-generation；其余 Skill 没有 Tool 契约。
当前本地库 Intake、Card、Plan、Run、Step、Report、Image 均为 0；没有证据证明一单真实业务已从需求跑到报告。
PHMAF_ALLOW_REAL_IMAGE=0，需要真实出图的完整流程当前会 fail-closed。
不推翻 Contract / Plan / Planner；它们仍有价值。要改的是“Skill 如何进入 Planner 与 Task Agent”。
按 kind + scope 过滤可发现 Skill；不要把完整 Skill 正文塞给 Planner。Contract 是最大允许集，不是固定执行顺序。
把 DB 中激活且被 Contract 允许的版本转换成 InlineSkill，或实现 DB-backed SkillsSource；不能直接读取全局磁盘最新版本。
给 Planner Agent 注入 context_providers=[SkillsProvider]；它先看摘要，再调用 load_skill / read_skill_resource，最后输出结构化 Plan。
保存被选 Skill 的版本、hash、资源清单，以及每个 Task 可发现的 Skill 集；确保管理员后续改配置不影响旧 Run。
执行时只暴露 Frozen Plan 允许的 Skill 摘要，由 Task Agent 调 load_skill；删除当前把整份 SKILL.md 拼进 instructions 的路径。
Contract 给最大范围，Skill 声明 required / optional，Plan 冻结最终子集；强副作用 Tool 由 Workflow 确定性调用，低风险 optional Tool 交给 Agent 判断。
补齐新包装 Policy、核对三路径 Skill 白名单、明确每个 Tool 的消费者，避免“注册了但永远拿不到授权”。
分别跑新包装、完整升级、部分升级；回读 Plan、skills loaded、tool invocations、checkpoint、Gate 和 Report。真实出图需单独授权。
官方语义、当前源码、运行容器与数据库分别核对；没有用上一份报告代替事实源。