Agent 的核心并非 Tool 数量：企业营销 AI 平台的工程实践

TL;DR

企业营销内容平台最容易做出的 Demo¹，是给模型一份资料，让它写一篇文案；最难做成的产品，是让这篇内容在数周之后仍能回答：它属于哪家企业、依据哪些资料、使用了什么策略、由谁审核、到底发布到了哪里、结果是否可信，以及下一轮为什么应该这样改。

当概率模型进入一个已有身份、事实、状态、权限和责任边界的业务系统，最终形成了以 Workspace、Offer、Knowledge、Asset、Brand Kit、Strategy Unit、Creation、PublishingJob、TaskRun 和实际指标为主干²；Web UI、REST³ 与 MCP⁴ 不同入口；模型负责理解和生成，服务端负责租户隔离、对象归属、状态机、幂等、证据与业务校验；外部发布和策略仿真则通过明确的适配器与任务边界接入的综合系统

AI 内容生产的不确定性不可能被消灭，但可以被限制在合适的层；企业 Agent⁵ 的价值，是把模型的创造力嵌入一条可追踪、恢复、审核、学习的业务中。

flowchart LR
    A["企业资料"] --> B["Workspace / Offer"]
    B --> C["Knowledge / Asset / Brand Kit"]
    C --> D["Strategy Unit"]
    D --> E["Topic / Article / Script / Image"]
    E --> F["Creation"]
    F --> G["审核快照"]
    G --> H["PublishingJob"]
    H --> I["TaskRun"]
    I --> J["草稿 / 人工发送"]
    J --> K["表现与 ROI"]
    K --> L["预测校准"]
    L -. "下一轮策略" .-> D

一、从“帮我发出去”开始的业务地图

运营平常是这样和豆包说的：

我把商品手册、官网和几张素材传进来了。请理解这个商品，找一个合适的内容角度，分别生成图文和短视频脚本，保持品牌语气，待我审后放进平台草稿。等我填写实际数据，再告诉我下一轮应该改什么。

如果把这句话直接翻译成一条大 Prompt⁶，Demo 很快就能跑起来。模型可以总结资料、写标题、生成正文，连续调用几个工具后，人工介入登个账号，也真能发出去 号还在不在我不好说，问题通常出现在第二次使用之后

第一次，Agent 把商品建到了错误的品牌下。第二次，网页首页最醒目的宣传语遮住了真正的产品功能，生成内容把多功能产品写成了单功能。第三次，审核过程中正文又被编辑，发布的并不是审核人看过的版本。第四次，为了形成学习闭环，团队把互动率临时当作 ROI⁷，结果预测模型学会了优化热闹，而不是优化生意。

这些问题有一个共同点：单纯靠“换一个更强模型”无法解决。对于Agent而言，这条命令是模糊的，它掩盖了中间每个词的业务含义：“资料”可能是企业级品牌规范，也可能只属于某个商品；“生成内容”可能是临时预览，也可能已经成为可编辑业务对象；“审核通过”可能只是一条通知送达，也可能代表一份冻结内容得到批准；“自动发布”可能只证明点击过按钮，不一定证明平台草稿或公开内容成立；“数据回流”可能是阅读量，也可能是有成本、有收入的 ROI

必须先回答以下问题，才能推进下一步，才能让业务真正跑起来，活起来：

1.1 真正的问题并非“生成”，而在于企业事实散落在不同地方

传统营销团队的资料不会是一张干净的数据库表，业务需求对齐和思路转换往往费时费力，除此以外，品牌规范可能在演示文稿里，商品参数在表格里，客服高频问题在文档里，历史案例散落在网页和 PDF 中，素材又分布在图片、视频和文案库里。运营人员知道这些资料彼此相关，但一个刚接入的 Agent 并不知道 ：

• 哪些资料属于同一个品牌；
• 某条卖点适用于哪个商品；
• 一张图片是品牌视觉参考、商品证明，还是已经过期的活动素材；
• 某段文字是人工确认的事实，还是模型推断的建议；
• 一份脚本是临时生成结果，还是已经进入审核与发布流程的正式内容。

最直觉的实现，是把所有文档塞进 Prompt，或者建一个“企业知识库”来RAG⁹，让模型自己判断。这个方案在 Demo 中很顺滑，在多品牌、多商品和多人协作环境里却很危险：上下文会越来越长，资料会互相污染，过期资料难以识别，模型还可能把“看起来相关”误当成“允许关联” 给我干哪来了，这还是国内吗.jpg

一份原始企业资料，要经历识别业务归属、抽取证据、组织策略、注入上下文和生成稳定产物，最后变成 Creation，系统并非直接把原文翻译成文案，而是先构建领域中间表示，再针对不同平台生成目标产物，我们可以把这个过程称为“编译”

flowchart LR
    R[原始网页 / 文档 / 素材] --> D[领域归属与证据抽取]
    D --> K[Knowledge / Asset / Brand Kit]
    K --> S[Strategy Unit]
    S --> X[分层生成上下文]
    X --> C[Creation]

因此，项目并未从 Prompt 模板开始，意在先定义营销内容域的事实所有权

1.2 Workspace是企业运营边界，Offer是内容生成真正围绕的营销对象

Workspace 与传统 RBAC 意义上的 tenant 语义几乎对齐，也承担租户隔离的业务语义。内容上它代表一家企业或一个品牌运营空间，承载默认语言、品牌画像、语气与合规信息

但绝大多数生成任务不会只围绕“品牌”发生。运营人员真正要推广的是某个商品、服务、组合方案或解决方案，所以 Offer 才是生成链的核心锚点。定位、目标受众、使用场景、核心卖点、常见异议、支撑证据、价格信息、营销目标以及后续仿真所需的预算与转化价值，策略学习参数，都围绕 Offer 组织

• Workspace 回答：这是哪家企业、哪套品牌与合规边界？
• Offer 回答：这次内容究竟在卖什么、对谁说、凭什么可信？

如果只保留 Workspace，商品事实会混在品牌级知识中；如果只保留 Offer，跨商品共享的品牌语气、合规约束与基础知识又会被复制多份,当前实现采用“Workspace 默认层 + Offer 专属层”的组合方式，后者可以补充或覆盖前者

这样一组织，Agent 不必在几十份资料中猜“这次内容到底在卖什么”。它先确定 Offer，再沿作用域读取知识、素材、品牌规范和策略

1.3 Knowledge、Asset 与 Brand Kit：不要把所有资料压成一种 Chunk¹⁰

把它们都压成无类型文本块，检索可能仍能返回“相关内容”，但生成流程无法可靠判断这些内容能否作为事实、能否直接复用，以及应该在哪个环节注入，所以最终做了显式区分，Knowledge、Asset 和 Brand Kit 都使用 scope_type + scope_id 表示属于 Workspace 还是 Offer¹¹。这种多态作用域让 REST、MCP 和 Web UI 可以复用同一套模型和服务

1.4 Strategy Unit：把“策略”从形容词变成对象

Strategy Unit 连接目标受众、场景、渠道、知识和素材，表达“针对谁、在什么情境、用什么论点与材料进行创作”，让策略/转化路径可复用依赖，技巧与思路不再只存在于一次对话里

把策略拆成可复用的决策切片：受众细分 × 使用场景 × 营销目标 × 目标渠道，每个策略单元可以通过显式关联表绑定 Knowledge 和 Asset，并为关联记录角色、优先级与备注。这样，“这张图为什么被选中”“这条证明服务哪个卖点”“这份素材用于 Hook 还是信任背书”就不再只存在于模型临时上下文中，策略对象化让同一份策略能被选题、脚本、素材匹配、仿真与复盘共同消费

1.5 Creation 与 PublishingJob：可编辑产物和冻结事实

Creation 保存最终可交付内容：正文、标题、内容类型、来源应用、商品归属，以及视频脚本等场景需要的结构化带时间戳文本，没有把所有内容压成一个固定 Schema¹²：图文、长文、短视频脚本、分镜与图片任务的结构不同

在前端展示模型流式输出时，产物绝非 Creation，浏览器里不断增长的文字只是临时投影；只有服务端完成持久化并返回 Creation ID，内容才成为可以刷新、评分、审核和发布的业务事实 猜猜我经历了什么（笑）

但是可编辑的 Creation 不能直接作为审核和发布的永久证据。否则用户在送审后修改正文，审核人看到的内容和执行器真正发送的内容就会发生漂移。

因此发布链会在提交时生成 payload_snapshot：

flowchart LR
    C[Creation 可持续编辑] -->|提交确认| S[不可变内容快照]
    S --> P[PublishingJob 审核与发布账本]
    P --> T[TaskRun 执行尝试]
    C -.后续编辑不回写.-> S

这个设计同时关联了两个经典思想：审批应该消费稳定输入，历史应该保留当时发生的事实¹³，不要求整个系统采用 Event Sourcing，要求外部动作不要回读一个已经变化的上游对象

二、原始资料进入系统后，保留了什么

2.1 “支持某格式”不等于“完整提取并理解传输内容”

Knowledge 和 Brand Kit 复用统一资料提取入口。当前支持常见 PDF、DOCX、PPTX、XLSX、CSV、文本、网页和部分远程文档¹⁴；扫描 PDF 会先提取文本层，再通过 OCR¹⁵ 补充识别，不同格式的语义保真程度并不相同，同时为了控制上传风险、响应时间和模型上下文成本，限制输入体积、解析页数和输出长度，这个选择部分牺牲了尾部完整性与档案级保真，换取在线产品可接受的延迟和资源消耗，也防止一个巨无霸打崩服务

2.2 最响亮的文案不一定最接近事实

网页解析最初优先读取可见正文。一次真实任务中，产品首页的 Hero Copy¹⁶ 反复强调某项能力，模型便把一个多功能产品总结成单功能工具，忽略了站点中更完整的产品结构。

后来的流程先从原始 HTML¹⁷ 中提取 JSON-LD¹⁸ 的 Product、Service、SoftwareApplication 等高信号字段，再补充导航项，最后合并网页正文。短内容或噪声异常时会回退到另一条提取路径，也遇到过反方向问题：某些站点把真正的正文放在导航式结构里，过度删除 nav 会伤害信息，因此实现选择了保守提取 + LLM¹⁹语义提取

网页有展示优先级、模板噪声、缓存和结构化元数据，解析器做的每一次清洗，本质上都在改变证据，RAG 工程的本质是在“噪声、信息密度、成本与证据保真”之间做选择与多方面优化，这方面还是得客制化提取，泛用/递归化提取器难做

2.3 Asset 与 Knowledge 分成两条链

Asset 保存图片、视频、音频、文档、链接或文案资产，可以记录存储位置、文件哈希、解析状态、元数据与切片。Knowledge 保存可检索的营销知识，包括类型、正文、结构化内容、来源、置信度与标签，把二者分开有明确业务价值：

• 一张商品图可以作为发布素材，不等于一句产品证明
• 一条 FAQ 可以参与问答，不一定对应一个可视化 Asset
• 一个视频可切出多个 B-roll 片段，而它的文字说明可能形成多条 Knowledge

文档作为 Knowledge 摄取时，主要保留提取文本和来源名称；Asset 链保存原文件与哈希，因此，系统暂时只能回答“这条知识来自某份文件”的文件级别粗粒度标签，细粒度有待优化

当前 Knowledge 查询并不含向量检索。普通列表通过 Workspace/Offer 作用域、知识类型和标题/正文的 PostgreSQL 模糊匹配筛选；问答与 Assistant 使用中英文 token、字符和 bigram 重叠评分²⁰，标题权重更高，再截取有限数量的候选，这不如混合检索“先进”，但规则可解释，出现错召回时容易复现；无需先解决 embedding 模型、索引迁移与多语言评测；在当前知识规模下，先验证领域作用域、引用和生成链是否正确

在同义表达、长文语义、跨资料推理和规模增长后，混合检索轻而易举就会超过词法检索能力，向量或混合检索是合理演进方向；RAG 的核心并非拥有向量数据库，让生成基于可更新的外部知识才是关键，当前阶段选择先验证作用域、来源、召回与引用是否可信；混合检索会在数据上一个量级，Eval²¹ 证明收益后引入 但本阶段ECS还用不起，算喽

三、企业资料如何产出运营内容

3.1 不同事实以不同优先级进入模型

一次内容生成可能同时需要：Workspace 品牌与合规信息；Offer 商品事实、定位和目标；Workspace 与 Offer 两层 Knowledge；Strategy Unit 的受众、场景、目标与渠；Asset 摘要与候选素材；Brand Kit 的品牌语气；用户确认过的长期 Memory²²；当前页面上的临时要求。如果把这些内容无差别拼接，模型很难判断冲突时谁优先覆盖。当前系统采用分层注入：Offer 级品牌语气优先于 Workspace 级；Knowledge 和 Asset 同时聚合两级 Scope；Memory 只在适用的生成 surface²³ 中进入；Strategy Unit 作为显式策略焦点

更细的一项产品取舍是“预览什么”，上下文预览只显示某层是否存在、数量、是否适用、是否已解析和是否注入，前端只暴露给用户“你选择了什么”，“产出了什么”，减轻心智负担²⁴

3.2 Workflow 和 Agent 各自做擅长的事

系统覆盖选题、脚本、图文、图片与素材筛选，但并没有把每一步都交给一个自由规划 Agent，对于路径清晰、可预期的任务，更适合使用 Workflow²⁵，本平台遵循固定的workflow，但是也开放 MCP 能力供用户接 Agent 自由调用：

flowchart LR
    I[用户目标] --> C[加载领域上下文]
    C --> S[选择平台 / 结构 / Persona]
    S --> L[LLM 生成]
    L --> V[确定性解析与校验]
    V -->|合法| P[保存 Creation]
    V -->|不合法| R[回退 / 修复 / 显式失败]
    P --> Q[异步仿真或图片任务]

生成流程按职责编排，当前主链覆盖：热点/知识驱动的选题生成；图文和长文创作；结构化脚本与多个版本；Persona²⁶ 与 B-roll²⁷ 素材匹配；图片生成、参考图和迭代编辑；最终结果保存、评分和历史查询

确定性代码负责解析 JSON 或 Markdown 结构，规范内容类型和平台标识,限制 B-roll 数量、插入位置与时长，清除模型泄漏的 JSON 痕迹，持久化 Creation，决定是否触发下一步 TaskRun 等等

例如：脚本生成中的 B-roll 环节，测试中模型MIMO V2.5有时会把“插入位置”写成一句原文，有时输出越界时长或过多镜头，服务端会尝试把原文定位回字符位置、裁剪时长、排序、限制总数，无法解释的条目则丢弃，让下游视频合成只消费稳定 Schema

同时，脚本创作的页面可以实时展示 token 和 thinking²⁸，但流结束后必须根据服务端返回的 Creation ID 再读一次持久对象，图片封面则先创建 ImageJob²⁹，再由后台任务写回同一个 Job 和 Creation；页面刷新后可以从历史 Job 恢复轮询，失效请求从此失去写 UI 的资格，让每次生成都不止是一个 Promise

sequenceDiagram
    participant U as 用户
    participant A as Agent / Web UI
    participant S as Content Service
    participant R as 审核方
    participant W as Worker
    participant P as 外部平台
    U->>A: 发起创作或发布意图
    A->>S: 结构化请求
    S->>S: 租户、对象与状态校验
    S->>R: 冻结快照送审
    R-->>S: 通过或驳回
    S->>W: 持久 TaskRun
    W->>P: 创建草稿
    P-->>W: 草稿证据或歧义结果
    W-->>S: 回写业务摘要
    S-->>U: 可理解、可恢复的状态

3.3 PublishingJob 与 TaskRun 掌管 Creation 生命周期

PublishingJob 是业务账本，回答：

• 哪一份 Creation 快照进入了审核和发布，审核、批准与派发处于什么状态
• 远程引用、真实指标和失败摘要是什么，用户现在应该看到什么业务结果

TaskRun 是执行尝试，回答：

• 哪类任务何时入队，哪个 Worker 领取
• 尝试了几次、是否重试，当前进度、锁与错误是什么，进程重启后如何继续

同一个 PublishingJob 可以经历多个 TaskRun，但一次 Worker³⁰ 重试不应该改变业务对象的身份，反过来，TaskRun 成功也不一定意味着内容已经发布：它可能只完成了“创建草稿”或“发送审核通知”

PublishingJob 将 review、approval 和 dispatch 分开³¹，内容送达审核通道等待批准，审核通道通过 Adapter 接入协作本平台/跨平台的系统，包括审批实例，机器人通知和回调处理等，以飞书链路为例，保存审核投递、审批结果与远程引用批准后落入发送队列；创建 Job 时还会冻结 Creation 快照，即使之后编辑原内容，已经进入审核的版本仍有自己的证据基础

脚本生成后的仿真、图片生成、发布执行和平台账号验证都可能超过一次 HTTP 请求的寿命，当前 TaskRun 使用 PostgreSQL 持久化任务，没有引入其他消息队列中间件：

1. 入队时用业务 unique_key 去重活动任务
2. Worker 通过 FOR UPDATE SKIP LOCKED 竞争领取待处理项
3. 领取后记录 Worker、锁时间、开始时间和尝试次数
4. 失败时根据尝试上限重排或进入失败态，进程退出留下的陈旧锁可以恢复

PostgreSQL 的 SKIP LOCKED 适合多个消费者领取队列式表³²，它只保证同一时刻不要领到同一行，业务幂等、状态前置和外部副作用仍要由应用层维护。

例如发送草稿时，网络调用失败后，客户端通常无法知道服务器是否已经完成动作，TaskRun 的 unique_key 避免活动任务被重复创建，外部适配器必须使用稳定业务键、创建前后证据或远端幂等能力³³，防止重复草稿和重复通知。

四、策略仿真：把“感觉会火”的运营内容，拆成预测、事实与校准

生成内容之后，还需要回答一个更难的问题：哪份脚本更值得发布？我把 Creation、渠道、预算、商品转化价值和已选 KOL³⁴ 组织成预测请求，交给独立仿真引擎。这样，内容域负责业务事实与流程，仿真域负责模型与消费者行为模拟

flowchart LR
    P[原始预测] --> J[PublishingJob]
    J --> E[草稿 / 用户声明 / 平台证据]
    E --> M[内容表现快照]
    M --> G{ROI 资格门禁}
    G -->|不满足| R[只进入表现报表]
    G -->|满足| L[平台校准权重]
    L --> S[下一轮 Strategy / Ranking]

4.1 仿真引擎的两类消费者模型

外部仿真引擎组合两种路径：

• 向量化 Statistical Agents³⁵：适合大规模、低成本和可复现的数值模拟；
• Soul-Agent³⁶：让 LLM 人格读取 persona、创意、KOL 和渠道上下文，返回点击意愿、理由、评论、感受和短期购买意图。

Soul-Agent 的判断可以作为统计模型的校准信号，切忌用少量 LLM 人格替代整个消费者群体。仿真引擎还会把人格映射回统计人口空间，以加权方式传播校准结果，当前运营生产平台预测请求默认关闭 LLM 决策，优先走更容易复现的统计/模板路径；只有显式开启付费时才使用真实 LLM Soul-Agent，运营生产平台本身也不承载 Soul-Agent 运行时，它只是仿真服务的调用者和结果消费者

4.2 原始预测不能被学习权重覆盖

把 Creation、平台分配、预算、商品转化价值与可选 KOL 信息发送给独立仿真服务后，仿真侧组合统计/规则模型与消费者 Soul Agent，返回 ROI、CTR、CVR³⁷、收入、成本、平台拆分与其他预测信息，仿真结果写回 Creation，同时建立 StrategySimulationReview。Review 保存：

• 原始预测请求与响应，原始 ROI 分数；
• 按平台拆分的预测。学习权重调整后的分数，建议性 verdict³⁸ 与风险说明。

学习权重只影响排序和解释，不覆盖“当时模型原本预测了什么”，防止系统无法复查预测偏差，也无法判断新权重究竟改善还是掩盖了问题。

4.3 满足业务语义的真实指标才进入学习

发布后的累计指标，根据平台不同，可以包含曝光、互动、点击、收藏等内容表现，不同平台对同一个词的定义并不一致：阅读人数和阅读次数不同，收藏和书签可能相近但不完全相同，互动总数有的平台直接给出，有的平台只能由若干字段相加

系统因此维护后端拥有的平台与内容类型目录：生成侧的平台标签、执行器别名与指标字段通过 Alias³⁹ 归一；只有当样本具有正成本，并且存在收入，或可以用转化数与商品转化价值推算收入时，系统才计算真实 ROI：actual_roi = (revenue - cost) / cost⁴⁰

一篇自然流量内容即使没有成本，也可能有真实阅读、点赞、收藏和分享。系统允许保存这类表现快照并用于报表展示，但不得进入 ROI 排名和策略学习，避免把互动率或浏览量重新包装成“商业回报”⁴¹，策略学习服务按 Workspace + Offer 聚合有效样本，再计算各平台的预测 ROI 与真实 ROI 偏差，样本不足时保持冷启动权重；样本成立后，平台 multiplier⁴² 才用于调整后续 Creation 排名

五、Agent 如何接入这台“内容编译器”

5.1 Tools、Resources、Prompts 分别解决什么

当前 MCP 服务静态注册了 61 个 Tools、2 个 Resources 和 5 个 Prompts，这三种原语按MCP规范，承担不同控制权⁴³：

Tools 覆盖 Workspace、Offer、Knowledge、Asset、Strategy Unit、应用运行、Creation、媒体任务、发布任务和 Memory 的读写，以新增知识、保存 Creation、创建发布任务为例，工具会构造与 REST 接口相同的 Pydantic 数据对象，调用相同的 Application Service，再由 SQLAlchemy Async 会算完成事务⁴⁴

Resource 分别面向 Workspace Profile 和 Offer Context，它们适合让客户端把某个品牌或商品上下文附着到会话，表达一类稳定、可寻址的业务上下文，如：workspace://... 表示品牌运营范围，offer://.../context 表示某个商品的完整创作上下文，供Agent自行发现探索

Prompt 覆盖企业认识、内容 Brief、长文创作、营销脚本和知识缺口审计，是客户端可发现的引导模板：告诉 Agent 应该先读取哪些上下文、调用哪些业务能力、怎样把最终内容保存回 Creation

5.2 有关 Agent 的序列化、异常与审计

SQLAlchemy 模型在返回给 Agent 前，会通过 Pydantic Schema 做序列化。对于历史数据库中不够友好的 JSON 包装字段，MCP 层会转换成稳定的扁平形态，避免 Agent 读到一种结构、写回另一种结构

所有注册 Tool 统一包裹调用审计，记录工具名、非空参数摘要、执行时间、结果数量或异常，资源不存在、状态冲突、参数错误和外部能力失败由领域异常与 API 错误语义统一表达，Agent 因而可以区分“对象不存在”“当前状态不允许操作”和“外部服务暂不可用”，不必从 Python Traceback 或供应商原文中猜测下一步

Function Calling 和 Structured Outputs 能约束参数结构⁴⁵，但 Schema 合法不代表 Workspace 正确、对象归属正确或状态允许写入。模型输出仍然是不可信的结构化输入

与此同时，创建 Offer 后，系统可以进一步推断知识：Offer 先提交成为确定事实，知识推断再使用新会话 best-effort⁴⁶ 执行。即使模型服务失败，已经创建的商品不会被一起回滚，这和 Saga⁴⁷ 的思想相似：面对无法纳入数据库事务的远程或非确定性步骤，先明确每一步的业务成立条件，再用补偿、重试或显式失败管理后续状态

REST 主链会从认证账号解析 Workspace，并对 Offer、Knowledge、Asset、Brand Kit 和 Creation 做资源归属校验，确保租户隔离

六、仍然待解决的问题

七、小结：Agent 应该进入业务系统，而不是绕过业务系统

回到开头那篇“看起来正确”的内容，企业最终需要相信的，并非模型写得多像专家，旨在证明系统能够说明：

flowchart LR
    A["企业 / 商品归属"] --> B["原始资料与知识"]
    B --> C["声明 vs 推断"]
    C --> D["策略与品牌偏好"]
    D --> E["Creation 版本"]
    E --> F["审核冻结快照"]
    F --> G["Worker 动作"]
    G --> H["状态回传"]
    H --> I["指标与统计时间"]
    I --> J["确定 ROI 资格"]
    J --> K["后验校准优化"]

能回答这些问题，Agent 才真正成为企业内容系统的一部分

模型可以理解模糊需求、组织语言、提出候选、选择受控工具；确定性代码必须维护身份、作用域、业务关联、状态前置、幂等和证据绑定；人类负责高影响确认和无法稳定自动核查的外部动作；平台事实与商业结果则必须带着来源和时间进入系统。

因此，我真正的产品是一套让企业事实能够被 Agent 安全消费、让内容决策能够被追踪、让外部结果能够被分级相信的业务系统，并非单纯停留在“一个能写营销内容的 AI”

一篇内容之所以可信，并非依赖它毫无错误，更取决于当错误出现时，系统知道应该回到哪一级事实重新检查