# Codex 上下文注入稿：CCPE / writing-workbench / video-workbench / skills-vault 当前规划总结

## 0. 本摘要用途

这是一次围绕 CCPE System、writing-workbench、video-workbench、knowledge-vault、skills-vault 的阶段性规划总结，用于后续在 Codex 中继续讨论项目结构、工程边界和下一步改造。

本摘要不展开 HiFi Agent Studio 的整体方法论，只聚焦当前几个具体工程项目的判断：

1. 深度创作流程在 Agentic 化时遇到的问题，为什么原本预期在 `writing-workbench` 上推进的工作暂时难以顺利开展。
2. 为什么自动化更适合优先落在降维输出流程，例如 `video-workbench`。
3. CCPE System 目前还需要补充哪些工程治理内容。
4. CCPE System 与 `skills-vault` 的边界和协作关系。

---

## 1. 当前背景

用户过去有一套成熟的深度创作流程，主要基于 Web 单智能体环境运行。

这个流程已经长期实践，用户用它产出了 200 多篇深度文章，总量超过 100 万字。流程中曾经存在 40+ 个不同功能的 Agent / Prompt / 角色，例如主笔、红队评审、认知结构检测、巨观模型评审、降维输出导演等。

过去的 Web 单智能体流程，本质是用户本人作为主控 Runtime：

* 用户决定什么时候调用哪个角色；
* 用户决定某个角色是否延续会话；
* 用户判断上下文是否污染；
* 用户判断哪些评审意见值得采纳；
* 用户判断韩愈是否直接修复提纲，还是先出修订计划；
* 用户判断张辽是否需要继续追问；
* 用户判断什么时候进入正文、什么时候回炉立意。

在 Web 环境中，这些隐性判断由用户本人承担，所以流程表面上看起来成熟、自然、可控。

但在 Codex / Claude Code 这类 Agentic 环境中，流程必须外显为：

* 文件；
* 状态；
* 输入输出协议；
* invocation packet；
* prompt-to-send；
* returned output；
* human gate；
* authority；
* runtime state；
* stop rule；
* audit；
* trace；
* artifact contract。

因此，用户原本以为只是把一两个成熟写作环节搬到 Agentic 下自动化，实际却变成了：把长期由用户本人承担的“人肉 Runtime”显性化、协议化、可追踪化、可防伪化。

这造成了显著的复杂度跃迁。

---

## 2. 深度创作流程目前遇到的问题

### 2.1 writing-workbench 的原始期望

用户原本设想在 `writing-workbench` 中改造深度创作流程中的一两个关键环节，尤其是：

* 观点素材进入立意；
* 韩愈生成提纲；
* 张辽、认知显影、巨人认知等角色对提纲评审；
* 用户裁决；
* 韩愈修复提纲；
* 必要时多轮循环。

这个流程在 Web 单智能体时代已经多次跑通，用户认为它只是一个成熟流程的 Agentic 迁移。

### 2.2 第一次尝试：写作提纲评审流程改造失败

第一次尝试的目标是抽取“提纲评审小闭环”。

旧流程大致是：

1. 用户给出提纲；
2. 张辽进行红队评审；
3. 认知显影进行认知结构检测；
4. 巨人认知进行宏观模型评审；
5. 用户综合意见；
6. 韩愈修复提纲；
7. 视情况循环。

在 Codex 中测试时，原本计划生成 dispatch pack，分发给各个评审员，然后收集 report。

但真正失败点不是目录、文件或流程结构，而是 **真实调用边界是假的**：

* `dispatch-pack.md` 只是任务说明，不等于真正的 agent invocation packet；
* 主会话读取张辽、韩愈、认知显影、巨人认知的 prompt 后，模拟生成了各自的输出；
* 所谓张辽 report、认知显影 report、巨人认知 report，并非来自独立 Agent / Thread / Sub-session；
* 它们只是主会话在同一上下文里角色扮演的结果；
* 这不符合“多智能体独立评审”的验证目标。

所以第一次尝试被判定为无效。

关键教训：

> 多 Agent 流程的价值来自真实独立视角，而不是主会话模拟多个角色。
> 正式评审报告必须来自真实 invocation，并具备 invocation record。
> 主控会话只能 orchestration、routing、synthesis、bounded verification，不能冒充 Agent 输出。

由此产生了后续规则：

* dispatch pack 不等于 invocation packet；
* 如果外部平台运行，需要生成 `prompt-to-send.md`；
* 正式报告必须有 canonical prompt 路径、输入上下文、执行载体、returned output；
* 如果无法真实调用，应停在 `blocked_waiting_for_participant_output` 或 prompt-to-send 状态；
* 模拟输出必须标记为 `simulation_only: true`、`formal_output: false`、`excluded_from_synthesis: true`。

### 2.3 第二次尝试：素材提炼流程成功但 ROI 失控

第二次尝试是在 `knowledge-vault` 中围绕 `viewpoint-discussion-distillation` 做长讨论蒸馏。

原始材料大约 5 万字，是一次 7 回合的长讨论。用户希望：

1. 打造一个拆解讨论稿的流程 / Skill；
2. 用这个流程拆解讨论稿；
3. 将拆解结果作为后续写文章、优化模型或其他任务的基础。

最初的旧方法是 chunk-first：

* 先把材料按 R01-R07 分块；
* 各 worker 做局部 topic discovery；
* 再试图把局部 topic 拼成整体结构。

这个方法暴露出“盲人摸象”问题：

* 每个 worker 的局部观察可能是真的；
* 但整体主题、主轴、层级、模型演化线会被误判；
* 局部真实容易冒充整体结构。

后续改造引入了 `Whole-Source Gestalt Alignment`：

* 如果源材料仍处于高上下文模型可承载范围内，应先完整阅读；
* 先判断源材料是 coherent、mixed、fragmented；
* coherent source 先建立全局画像、核心张力、主结构、模型演化线、层级风险；
* mixed source 先宏主题拆分；
* fragmented source 不强行制造层级，采用 flat discovery。

第三轮流程最终完成了：

* source-map；
* whole-source gestalt；
* topic map；
* material routing log；
* topic docs；
* coverage audit；
* distortion risk log；
* human confirmation；
* downstream handoff。

从方法论上看，这次流程是成功的，因为它修复了 chunk-first 的结构误判，并建立了可追溯的知识加工链条。

但从 ROI 看，它非常不划算：

* 原始稿只有 5 万字；
* 用大上下文模型其实可以直接整理；
* 这次多轮流程累计消耗约 3000 万 tokens；
* 这不是“蒸馏一篇讨论稿”的正常成本；
* 更准确地说，这是在构建并验证一套知识加工 Runtime 的系统建设成本。

关键判断：

> 第二次不是纯粹“大炮打蚊子”，而是用一只蚊子测试了造炮厂、炮兵训练手册、弹道审计制度和战后复盘体系。
> 问题不是流程完全没价值，而是把“系统建设成本”误记成了“单次内容处理成本”。

### 2.4 深度创作流程为什么暂时难以继续大规模推进

深度创作流程的核心不是简单文本生产，而是高不确定性判断。

它涉及：

* 观点是否成立；
* 立意是否值得写；
* 切入角度是否正确；
* 提纲结构是否承载了主命题；
* 哪些评审意见值得采纳；
* 哪些意见只是角色风格导致的噪音；
* 上下文何时污染；
* 何时应该重启会话；
* 模型是否应该升层；
* 附录脚手架是否需要前置；
* 文章是否进入正文阶段。

这些都不是纯 P 域的工程求解，而是 P / I 混合任务。它们不是不能 Agentic 化，而是不能一上来就 Full Runtime 化。

当前 `writing-workbench` 的大问题是：

> 用户原本以为是在自动化成熟写作流程中的一两个环节；
> 实际上 Codex 要求用户先把大量隐性专家判断显性化为协议、状态、调用边界和人工决策门。
> 这使得原计划的 writing-workbench 改造暂时难以顺利开展。

因此，深度创作流程下一步不宜继续追求完整自动化，而应转向最小真实闭环。

建议的最小闭环：

1. 输入观点素材；
2. 生成 `premise-context-pack`；
3. 真实调用韩愈，输出立意 / 提纲；
4. 真实调用张辽，输出评审；
5. 用户做 decision record；
6. 真实调用韩愈，输出修复版；
7. 保存 invocation records；
8. 停止。

先不要同时上：

* 认知显影；
* 巨人认知；
* 多轮 committee；
* 完整正文；
* 附录脚手架；
* coverage audit；
* downstream model mining。

核心目标不是完整写作自动化，而是验证：

> 一个真实主笔 + 一个真实红队 + 一个用户裁决 + 一次修复回合，能否在 Codex 下可靠运行。

---

## 3. 自动化更适合优先放在降维输出上，例如 video-workbench

### 3.1 深度创作与降维输出是两套流程

用户过去的工作中，深度创作和降维输出本来就是两套流程：

* 深度创作负责“发电”：形成复杂观点、文章、模型、思想结构；
* 降维输出负责“输出”：把深度文章的一两个点转成视频、PPT、口播、短内容、多模态素材。

规划上也应该拆成两个项目：

* `writing-workbench`：深度创作；
* `video-workbench`：降维输出、多模态内容生产。

它们不应混成一个 Runtime。

### 3.2 降维输出流程更适合 Agentic 自动化

用户已有降维输出流程，大致是：

1. 阶段 0：剧集统筹与架构；
2. 阶段 1：破题提案，给出 3 个切入角度；
3. 阶段 2：定基调与总纲；
4. 阶段 3：搭分镜逻辑骨架；
5. 阶段 4：音画深潜产出；
6. 阶段 5：自动生成图片、配音，图生视频暂时人工或半人工；
7. 阶段 6：剪辑，人工；
8. 阶段 7：发布，暂时人工。

这个流程和深度创作相比，更适合自动化，因为：

* 阶段边界清楚；
* 成功标准更外显；
* 验收更容易；
* 低判断、高摩擦的环节多；
* 文件型产物多；
* 工具链明确；
* 错了容易改；
* 对核心思想质量的伤害较小。

可自动化的部分包括：

* 长文拆点；
* 文章模型提炼；
* 剧集拆分建议；
* 单集时长预算；
* 1 分钟约 220 字的字数控制；
* 破题角度候选；
* 视频总纲；
* 分镜骨架；
* 分镜深潜；
* 配音稿；
* 生图提示词；
* TTS 文本拆分；
* 音频生成；
* 图片生成；
* 文件命名和素材归档；
* 剪辑清单；
* 平台标题、简介、标签候选。

保留人工裁决的部分包括：

* 是否拆系列；
* 选哪个破题角度；
* 总体基调；
* 核心隐喻；
* 分镜骨架是否通过；
* 重要画面风格；
* 图生视频抽盲盒选择；
* 最终剪辑；
* 是否发布。

因此，当前更建议把自动化优先级放在 `video-workbench`，而不是继续强攻 `writing-workbench` 的深度创作核心。

### 3.3 video-workbench 的推荐定位

`video-workbench` 可以作为 Agentic MVP：

输入：

* 一篇深度文章；
* 关联 model card / rules；
* 目标平台；
* 目标时长；
* 是否系列化。

输出：

1. 剧集拆分建议；
2. EP.01 三个破题提案；
3. 用户选择记录；
4. 视频总纲；
5. 分镜骨架；
6. 分镜深潜产出；
7. 配音稿；
8. 生图提示词；
9. TTS 文本文件；
10. 图片生成清单；
11. 音频生成清单；
12. 剪辑清单；
13. 发布文案候选。

`video-workbench` 更像生产工坊：P 域为主，少量 I 域。
它适合用“模板化生产 + 人工抽检 + 关键决策门”的方式自动化。

---

## 4. CCPE System 当前还需要补充的内容

CCPE System 的核心定位不变：

> CCPE 是用于设计、审计、重构和维护 Prompt、Agent、Skill、Workflow、Runtime Protocol、Cognitive Model assets 的上下文协议工程框架。

它的核心原则仍然是：

> 不要把所有 AI artifact 都当成 Prompt。
> 第一任务是分类，第二任务是结构诊断，第三任务才是创建或重构。

现有分类包括：

* CCPE-Lite；
* CCPE-Agent；
* CCPE-Skill；
* CCPE-Runtime；
* Model Card；
* Model Index。

但基于最近几轮实践，CCPE 需要补充 Agentic 工程治理层，尤其是以下内容。

### 4.1 Project Intake / Mode Selector

每次任务启动前必须先分诊：

1. QPI 定性：

   * Q：信息缺失；
   * P：路径 / 转换 /生产问题；
   * I：秩序、权衡、共识、责任问题。

2. 任务性质定性：

   * 一次性内容产出；
   * 可复用能力沉淀；
   * 治理级系统建设；
   * 模型校准；
   * 探索预演。

3. 复用级别：

   * one-off；
   * reusable；
   * governed。

4. 运行档位：

   * Lite；
   * Standard；
   * Full。

默认必须从 Lite 开始，只有被证据推动才升级。

### 4.2 Lite / Standard / Full

#### Lite

适用：

* 一次性任务；
* 低风险；
* 单模型可处理；
* 不需要真实多 Agent；
* 不需要完整追踪审计；
* 下游不依赖中间过程。

产物：

* 目标输出；
* 简短输入记录；
* 人工确认；
* 可选抽样检查。

禁止：

* 默认多 Agent；
* 默认 coverage audit；
* 默认 topic docs；
* 默认 downstream handoff；
* 默认 full runtime。

#### Standard

适用：

* 未来会复用；
* 有明确下游消费；
* 需要上下文包、结构化产物、局部追踪；
* 少量真实 Agent / Worker 调用；
* 有关键 human gate。

产物：

* source/context pack；
* confirmed structure；
* reusable output artifacts；
* decision record；
* targeted audit；
* minimal invocation record。

#### Full

适用：

* 多角色；
* 多来源；
* 高风险；
* 可追责；
* 长周期；
* 外部客户交付；
* 后续自动化强依赖过程真实性；
* 需要全链路审计。

产物：

* full runtime；
* invocation records；
* authority map；
* state machine；
* coverage audit；
* distortion-risk log；
* recovery protocol；
* downstream handoff。

### 4.3 Cost Ledger

必须区分四类成本：

1. Content Cost：内容产出成本；
2. System-Building Cost：系统建设成本；
3. Calibration Cost：模型校准 / 反馈修复成本；
4. Exploration Cost：探索预演成本。

红线：

> 禁止将系统建设成本伪装为单次内容任务成本。

这条直接来自 3000 万 tokens 事件。

如果一次 5 万字讨论稿蒸馏消耗 3000 万 tokens，不能简单记为“内容蒸馏成本”。应拆分为：

* 内容产出；
* Runtime 原型建设；
* no-simulation protocol 验证；
* whole-source gestalt 流程验证；
* worker / coverage audit 测试；
* Agentic 边界探索。

### 4.4 Scope Drift Detector

系统必须识别任务漂移。

触发信号包括：

* 一次性任务开始创建通用 Protocol；
* 开始新增 Agent / Skill / Runtime；
* 开始设计未来复用目录结构；
* 原始产物迟迟不交付，系统却持续生成 routing log、coverage audit、handoff；
* Lite 任务擅自派发多个 worker；
* P 域任务滑入 I 域治理；
* token 预算穿透；
* 开始讨论 invocation、authority、state、audit。

一旦触发：

1. 挂起；
2. 重问：我们还在做原始任务吗？
3. 如果不是，是否正式立项为系统建设？
4. 重做 QPI 和 Mode Selector；
5. 重新分账；
6. 人类确认后再继续。

### 4.5 Execution Authenticity

正式多 Agent / Worker 输出必须有真实调用证据。

最小 invocation record 包括：

* agent / role id；
* canonical prompt 或 Agent Spec 路径；
* invocation carrier；
* thread / sub-session id；
* input context；
* returned output；
* timestamp；
* output 是否进入 synthesis。

主控会话只可：

* orchestration；
* routing；
* synthesis；
* bounded verification。

主控会话不可：

* 冒充独立 Agent；
* 代写 reviewer report；
* 代写 worker extraction；
* 将 prompt-only / packet-only 阶段标记为 executed；
* 在没有真实返回时补写正式输出。

无法真实调用时，应停止在：

* `blocked_waiting_for_participant_output`；
* 或生成 `prompt-to-send.md` 等待外部平台执行。

### 4.6 Simulation Labeling

所有模拟产物必须显式标记：

```yaml
simulation_only: true
formal_output: false
excluded_from_synthesis: true
```

模拟可以用于：

* 价值流验证；
* 绿野仙踪阶段；
* 人类参考草稿。

模拟不得用于：

* 正式评审报告；
* 正式 worker output；
* 正式 synthesis；
* downstream handoff；
* coverage audit 依据。

### 4.7 Stop Rule

每个 Runtime 启动前必须定义：

* 最小可用产物；
* sufficient criteria；
* optional artifacts；
* human gate；
* budget ceiling；
* stop condition；
* escalation condition。

系统不得因为“还能继续生成中间物”就继续扩展。

当已达到下游可消费状态时，应停止并交还人类控制。

### 4.8 Human Gate Contract

人工确认不能只写“等待用户确认”，必须结构化。

每个 Human Gate 应包含：

* gate_id；
* decision_owner；
* input_artifacts；
* decision_options；
* default_action；
* downstream_effect；
* reversibility；
* escalation_condition；
* record_path。

这能防止 human-in-the-loop 变成装饰性签字。

### 4.9 Authority Matrix

每个 Agent / Skill / Runtime node 需要权限等级：

* A0 Observe；
* A1 Suggest；
* A2 Draft；
* A3 Modify；
* A4 Decide；
* A5 Execute；
* A6 Block。

尤其需要拆分 A5：

* A5-R：只读工具；
* A5-W：写文件 / 改代码；
* A5-X：外部 API / 发布 / 删除 / 客户可见动作。

A5-X 默认禁止自动执行，必须经过 Human Gate 或明确 Runtime 授权。

### 4.10 Runtime State Protocol

Runtime 需要标准状态：

* initialized；
* running；
* blocked_waiting_for_human；
* blocked_waiting_for_participant_output；
* blocked_waiting_for_tool；
* paused_by_scope_review；
* paused_by_budget_guard；
* failed_recoverable；
* failed_terminal；
* completed；
* aborted_by_human；
* archived。

每次状态变化应记录：

* previous_state；
* new_state；
* trigger；
* responsible_actor；
* timestamp；
* next_allowed_actions。

### 4.11 Tool Safety / Data Safety / Retry / Rollback

CCPE / Agentic Engineering Handbook 应补充：

* 工具最小权限；
* 沙箱目录；
* dry-run / preview；
* action plan；
* action log；
* 回滚路径；
* 密钥不得进入 prompt；
* 客户资料外发确认；
* 敏感数据脱敏；
* 重试上限；
* repair plan；
* rollback protocol。

这部分在 Agentic 工程里非常重要，因为系统不只是“会说”，还会改文件、调 API、生成素材、写代码、发布内容。

### 4.12 Context Compiler

高价值 P 域和 I 域任务不能直接把原始材料倾倒给所有 Agent。

需要 Context Compiler：

* source digest；
* task-specific context pack；
* role-specific dispatch pack；
* decision context；
* source index；
* evidence index。

对 coherent long source，应先 whole-source gestalt，再 segmentation。
对 mixed source，应先 macro-topic split。
对 fragmented source，应 flat discovery，不强行升层。

### 4.13 Source Fidelity / Evidence Index

正式输出中的关键判断必须能回溯至：

* 原始来源；
* source range / paragraph / block id；
* 参与该判断的 Agent / Worker；
* 判断来源是原文、推理、归纳、用户裁决还是模型补充。

禁止：

* 把中间摘要当 source of truth；
* 把模型综合判断伪装成原始材料事实；
* 无来源地生成“看似很合理”的结论。

### 4.14 Evaluation Stack

不能只靠“看起来不错”。

评测应分层：

* E0 Smoke Test；
* E1 Format Test；
* E2 Factual Test；
* E3 Reasoning Test；
* E4 Expert Similarity；
* E5 Decision Utility；
* E6 Calibration Test；
* E7 Governance Test。

不同场景启用不同层级：

* Lite：E0-E2；
* Standard：E0-E5；
* Full：E0-E7。

### 4.15 Platform / Plugin Governance

Codex、Claude Code、OpenClaw、SuperPowers 等平台 / 插件的默认流程不能覆盖 CCPE 的治理底线。

尤其是 SuperPowers 这类偏软件工程的方法论插件，可能天然倾向：

* spec；
* planning；
* TDD；
* subagent；
* review；
* audit；
* repeated verification。

这对代码工程有价值，但对知识蒸馏和写作流程可能放大过度工程倾向。

需要规则：

* 非代码任务默认禁用重型软件工程插件；
* 除非任务已正式升级为系统建设；
* 插件输出不得自动成为正式产物；
* 插件自动触发不得绕过 Mode Selector；
* 项目应声明 allowed / blocked / manual_only skills。

SuperPowers 不是唯一元凶，但它可能放大了工程化惯性。
核心问题仍然是入口分诊、Mode Selector、Scope Drift、Stop Rule 缺失。

---

## 5. CCPE 与 skills-vault 的差异

### 5.1 为什么新增 skills-vault

在 Codex 讨论中发现，有些已经做好的 Skill 并不隶属于 CCPE。

例如：

* `fix-title`；
* markdown heading 修复；
* 文件清洗；
* 引用检查；
* 报告导出；
* 批处理；
* source splitter；
* TTS 生成；
* 图片生成辅助。

这些 Skill 本质上是自动化脚本 / 工具，不是专家智能体，不拥有业务目标，也不需要作为 CCPE Agent / Runtime 的核心资产。

因此新增 `skills-vault`：

> `skills-vault` 是 automation-oriented Skills 的源码仓库。

它存放：

* `SKILL.md`；
* scripts；
* tests；
* fixtures；
* examples；
* install notes；
* migration records。

它不存放：

* CCPE agents；
* committees；
* runtimes；
* model cards；
* model indexes；
* cognitive model assets；
* CCPE System 原有内容。

### 5.2 三个位置的区别

#### skills-vault

源码主仓库。

负责：

* automation Skill 实现；
* 脚本；
* 测试；
* fixtures；
* 示例；
* 安装说明；
* 版本迁移记录。

例子：

```text
skills-vault/
  skills/
    fix-title/
      SKILL.md
      README.md
      scripts/
      tests/
      fixtures/
```

#### `.agents/skills`

本机运行安装面。

负责：

* Codex / Claude Code / 本地 Agent Runtime 可调用的安装副本。

它不是 source of truth。
不应直接在 `.agents/skills` 中长期维护源码。

#### ccpe-system

系统架构工作区。

负责：

* expert agents；
* CCPE-Lite prompt cards；
* durable agent specs；
* committees；
* runtimes；
* model cards；
* model indexes；
* cognitive / method / evaluation skills；
* 对重要 external automation skill 的架构登记。

### 5.3 automation Skill 与 CCPE-Skill 的区别

需要区分三类东西。

#### Automation Skill

归属：`skills-vault`

特点：

* 可安装；
* 可执行；
* 通常有脚本；
* 有测试；
* 行为较确定；
* 主要处理文件、格式、批处理、导出、转换；
* 不拥有业务目标。

例子：

* `fix-title`；
* `markdown-normalizer`；
* `citation-checker`；
* `report-exporter`；
* `source-splitter`；
* `tts-batch-generator`；
* `image-prompt-exporter`。

#### CCPE-Skill

归属：`ccpe-system`

特点：

* 可复用能力模块；
* 不一定有脚本；
* 可能是方法、流程、检查清单、推理协议、评估规则；
* 可能承载认知模型；
* 可被多个 Agent / Runtime 调用；
* 与业务语义、认知结构、评估规则有关。

例子：

* cognitive-imaging skill；
* assumption-stress-test skill；
* argument-chain-inspection skill；
* model-mining skill；
* evaluation skill。

#### Runtime Capability / Project Capability

归属：

* `ccpe-system/runtimes/`；
* 或具体项目 runbook，如 `knowledge-vault`、`writing-workbench`、`video-workbench`。

特点：

* 多步骤；
* 多角色；
* 有状态；
* 有 human gate；
* 可能依赖多个 Agent 和 automation Skill；
* 有上下文工程、调用记录、审计、handoff。

例子：

* `viewpoint-discussion-distillation`；
* `writing-outline-review`；
* `video-episode-production`；
* `knowledge-material-routing`。

这类不应放进 `skills-vault` 当普通工具 Skill。

### 5.4 CCPE 是否需要登记 skills-vault 的 Skill

不是所有 automation Skill 都需要 CCPE 登记。

只有当某个 Skill 进入更大的 Agentic 系统时，才需要登记。

需要登记的情况：

* 某个 CCPE Runtime 调用它；
* 某个 Agent Spec 将它列为 required capability；
* 某个 committee 运行依赖它；
* 该 Skill 有明确 authority / safety / evaluation 规则；
* 它成为可重复 workflow 的固定部分；
* 它会写文件、调用 API、修改客户可见产物。

登记文件只记录架构元数据，不复制源码。

建议登记位置可以是：

```text
ccpe-system/integrations/skills-vault/fix-title.registration.md
```

或：

```text
ccpe-system/skills/tool/fix-title.external-skill.md
```

登记内容：

```yaml
canonical_implementation: skills-vault/skills/fix-title
installed_path: C:\Users\xxx\.agents\skills\fix-title
skill_type: tool-skill / transformation-skill
used_by:
  - ...
authority:
  - may rewrite user-specified markdown file only
validation:
  - heading shift tests pass
safety:
  - dry-run recommended for canonical records
  - must not modify unrelated files
status: active
```

原则：

> `skills-vault` 拥有 implementation source；
> CCPE 拥有 architecture registration；
> `.agents/skills` 是 runtime installation copy。

### 5.5 MCP 与 skills-vault 的关系

MCP 类似工具 / 外部能力接入层。

MCP 本身无需放进 CCPE 作为源码。
但如果某个 Agent / Runtime 正式依赖某个 MCP server 或工具，就应在 CCPE 中登记其依赖关系。

登记内容类似：

```yaml
canonical_implementation:
endpoint:
used_by:
authority:
allowed_operations:
forbidden_operations:
security_notes:
evaluation:
failure_behavior:
```

统一原则：

> 实现源码不进 CCPE；
> 架构依赖进 CCPE；
> 运行安装面不当 source of truth。

### 5.6 推荐边界句

可以把下面这句话作为以后判断归属的规则：

> CCPE 资产拥有或组织业务目标；automation Skill 执行可复用动作。Skill 可以服务业务目标，但不自行定义业务目标。

更具体：

```text
业务目标：Human / Agent / Runtime 决定
执行动作：Skill / Tool / MCP 完成
业务裁决：Human Gate / Runtime 决定
业务材料：Project Vault / Workbench 保存
```

---

## 6. 对现阶段项目的总体建议

### 6.1 writing-workbench：暂停 Full Runtime 化，改走最小闭环

不要继续把完整深度创作流程一次性 Agentic 化。

当前目标应降级为：

* 证明真实主笔调用；
* 证明真实红队调用；
* 证明 human decision record；
* 证明一次修复回合；
* 证明 invocation record；
* 停止。

不要默认上完整 committee、topic docs、coverage audit、正文生成、model mining。

### 6.2 video-workbench：作为优先自动化 MVP

优先把已有降维输出流程自动化：

* 文档拆分；
* 模型提炼；
* 剧集拆分；
* 破题提案；
* 视频总纲；
* 分镜骨架；
* 分镜深潜；
* 配音稿；
* 生图提示词；
* TTS；
* 图片生成；
* 素材归档；
* 剪辑清单。

保留人工：

* 选题；
* 角度选择；
* 基调确认；
* 关键审美；
* 图生视频筛选；
* 剪辑；
* 发布。

这更符合 P 域生产工坊，ROI 更高，工程师也更容易跟进。

### 6.3 knowledge-vault：保留观点蒸馏能力，但增加 Lite / Standard / Full

`viewpoint-discussion-distillation` 的 Full 规格有价值，但不能默认运行。

应拆成：

* Lite：单源讨论稿快速蒸馏；
* Standard：可复用材料包；
* Full：治理级知识加工 Runtime。

5 万字 coherent discussion 默认 Lite 或 Standard，不应默认 Full。

### 6.4 CCPE System：补 Agentic Engineering Handbook

CCPE 需要新增或整合一份工程守则，覆盖：

* Project Intake；
* Mode Selector；
* Cost Ledger；
* Scope Drift；
* Execution Authenticity；
* Simulation Labeling；
* Stop Rule；
* Human Gate Contract；
* Authority Matrix；
* Runtime State Protocol；
* Tool Safety；
* Data Safety；
* Retry / Rollback；
* Platform / Plugin Governance；
* Evaluation Stack；
* Context Compiler；
* Source Fidelity；
* Artifact Contract；
* Runtime Maturity Model。

### 6.5 skills-vault：继续作为 automation Skill 源码仓

`skills-vault` 是必要的，不影响 CCPE 结构。

它是工具源码供应链，不是 CCPE 的替代品。

下一步建议：

* 只迁移 CCPE 外部 automation Skills；
* 不迁移现有 CCPE 内容；
* 每个 Skill 增加 authority、safety、validation、installation note；
* 可选增加 manifest；
* 只有被 Runtime / Agent 正式依赖时才在 CCPE 登记；
* 登记不复制源码。

---

## 7. 当前最关键的工作原则

以后在 Codex 中继续规划时，必须优先遵守这些原则：

1. **先分类，再创建。**
   不要看到一个能力就写成 Prompt、Agent 或 Skill。先判断它是 Lite、Agent、Skill、Runtime、Model Card、external automation skill，还是 project capability。

2. **默认 Lite，证据驱动升级。**
   不要一上来就 Full Runtime。

3. **内容任务与系统建设任务必须分账。**
   如果任务从“产出内容”滑向“建造流程 / Runtime / Protocol”，必须暂停重定性。

4. **正式多 Agent 输出必须真实调用。**
   主会话不能模拟 Agent report。

5. **模拟产物必须隔离。**
   simulation-only 不得进入正式 synthesis。

6. **达到最小充分产物就停止。**
   不要让系统无限生成中间物。

7. **深度创作先保守协议化，不急着自动化。**
   writing-workbench 当前只验证最小真实闭环。

8. **降维输出优先自动化。**
   video-workbench 更适合作为 Agentic MVP。

9. **skills-vault 管工具源码，CCPE 管架构和认知资产。**
   不要混仓，不要复制源码。

10. **MCP / CLI / API 是工具能力。**
    只有当被 Agent / Runtime 正式依赖时，才需要在 CCPE 做 architecture registration。

---

## 8. 下一步给 Codex 的建议任务

可以让 Codex 基于本摘要继续做以下工作：

### 任务 A：审查 CCPE System 是否需要新增 integrations 目录

目标：

```text
ccpe-system/
  integrations/
    skills-vault/
    mcp/
    cli-tools/
```

用于登记 external automation skills、MCP、CLI 工具等架构依赖。

### 任务 B：更新 CCPE classification rules

加入三分法：

```text
automation Skill -> skills-vault
CCPE-Skill -> ccpe-system
Runtime / Project Capability -> ccpe-system/runtimes or project runbook
```

### 任务 C：把 Agentic Engineering Handbook 合并进 CCPE operating rules

重点加入：

* Project Intake；
* Mode Selector；
* Cost Ledger；
* Scope Drift；
* Execution Authenticity；
* Stop Rule。

### 任务 D：为 skills-vault 增加 skill manifest 模板

建议字段：

```yaml
name:
type:
category:
canonical_source:
installed_paths:
entrypoints:
authority:
side_effects:
safety:
tests:
ccpe_registration:
status:
version:
```

### 任务 E：为 writing-workbench 定义最小真实闭环

仅包含：

```text
premise-context-pack
real Han Yu invocation
real Zhang Liao invocation
human decision record
real Han Yu repair
invocation records
stop
```

### 任务 F：为 video-workbench 定义 MVP Runtime

以降维输出生产线为主，自动化：

```text
series planning
angle proposals
video outline
storyboard skeleton
deep shot output
voice script
image prompts
TTS batch
image batch
asset manifest
editing checklist
```

人工保留：

```text
angle choice
tone confirmation
visual approval
editing
publishing
```

---

## 9. 最后的核心判断

当前不是方向错，而是入口任务性质被低估。

用户原以为是在自动化成熟写作流程，实际是在把长期由人承担的隐性判断外显成 Agentic Runtime。

因此：

* `writing-workbench` 的深度创作核心要慢，先做真实调用与人工裁决边界；
* `video-workbench` 的降维输出生产线要快，是更适合自动化的 MVP；
* CCPE System 要补运行治理和外部工具登记机制；
* `skills-vault` 要独立作为 automation Skill 源码仓；
* MCP、CLI、API、automation Skill 都是工具供给层，不应混入 CCPE 认知资产，但被正式依赖时需要在 CCPE 登记。

一句话总结：

> CCPE 负责“谁在什么边界下完成什么认知 / 业务任务”；
> skills-vault 负责“可安装、可测试、可迁移的自动化工具能力”；
> writing-workbench 先验证深度创作的最小真实闭环；
> video-workbench 优先承接高 ROI 的降维输出自动化。