1274 lines
32 KiB
Markdown
1274 lines
32 KiB
Markdown
# 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 的降维输出自动化。
|
||
|