diff --git a/PROJECTS.md b/PROJECTS.md new file mode 100644 index 0000000..d21796e --- /dev/null +++ b/PROJECTS.md @@ -0,0 +1,39 @@ +# Project Relationships + +本文档记录 Knowledge Vault 周边项目的职责关系。它用于防止长期知识、项目现场、AI 资产工程和工具源码混仓。 + +## 总原则 + +```text +目录保存资产；Workbench 保存项目现场；System 保存工程化协议；Vault 保存长期知识和过程记忆；work-projects 保存具体开发执行。 +``` + +## 项目关系 + +| 项目 | 定位 | 保存什么 | 不保存什么 | +| --- | --- | --- | --- | +| `knowledge-vault` | 长期知识源、过程记忆和人类可读规则层 | 日记、文章讨论、Agent / Prompt / Committee 打造过程、正式文章、资料源、面向人的模型文档、提示词归档、本地知识加工规则 | 不承载完整文章生产流水线；不作为 CCPE canonical 资产源码仓；不保存具体开发项目的执行现场 | +| `ccpe-system` | AI 资产工程和协议工作区 | Agent、Skill、Runtime、Model Card、Model Index、committee、运行治理、外部工具依赖登记 | 不保存完整个人知识库；不保存 automation skill 的实现源码；不保存普通项目执行材料 | +| `writing-workbench` | 已决定写作后的文章项目现场 | 文章项目计划、材料压缩稿、source map、提纲、评审、正文、润色、metadata、决策记录 | 不接管开放观点讨论；不保存长期知识全集；不默认自动化深度创作 | +| `video-workbench` | 深度文章降维输出和多模态生产现场 | 剧集规划、破题提案、视频总纲、分镜、口播稿、生图提示词、TTS 清单、素材清单、剪辑清单 | 不替代深度文章创作；不保存长期模型源头；不承载 CCPE 资产工程 | +| `skills-vault` | 可测试、可安装、可复用 automation skill 源码仓 | `SKILL.md`、scripts、tests、fixtures、examples、安装说明、迁移记录 | 不保存 CCPE Agent / Runtime / Model Card；不保存业务项目材料；不定义业务目标 | +| `work-projects` | 具体开发工作和工程项目现场 | 产品、客户、实验性开发项目的代码、需求、任务记录、交付材料、项目级 handoff | 不作为长期知识库；不作为通用工具源码仓；不作为 CCPE 协议源头 | + +## 边界规则 + +- 开放讨论、观点形成、隐形规则显影，先进入 `knowledge-vault/discussions/`。 +- 已决定进入某篇文章生产的材料，进入 `writing-workbench/projects/...`。 +- 从深度文章或模型降维为视频、多模态内容的生产过程，进入 `video-workbench`。 +- 可复用且可测试的小型自动化工具，进入 `skills-vault`。 +- Agent / Runtime / Model Card / Model Index 的 canonical 设计，进入 `ccpe-system`。 +- 具体软件开发、客户交付或实验性工程现场，进入 `work-projects`。 + +## 状态而非目录定生死 + +目录表示材料类型和使用场景。资产是否仍在使用，应由状态字段表达，例如： + +```text +active / maintained / reference / superseded / deprecated / archived +``` + +不要用 `historic` 或 `legacy` 作为仍在生产中的目录资产名称。历史性、弃用或仅供追溯，应写入索引或文档状态。 diff --git a/README.md b/README.md index 81af843..8199bb8 100644 --- a/README.md +++ b/README.md @@ -1,14 +1,16 @@ # Knowledge Vault -个人长期知识库。它的定位是“矿山和档案馆”：保存长期知识源、正式文章、面向人的模型文档、历史讨论、资料来源、项目归档和知识加工能力的本地运行规则。 +个人长期知识库。它的定位是“矿山和档案馆”：保存长期知识源、正式文章、面向人的模型文档、活跃讨论过程、资料来源、项目归档和知识加工能力的本地运行规则。 本仓库不承担 Writing Workbench、CCPE System 或 Delivery Systems 的职责。 +周边项目关系见 [PROJECTS.md](PROJECTS.md)。 + ## 四层边界 | 层级 | 定位 | 主要内容 | 不做什么 | | --- | --- | --- | --- | -| Knowledge Vault | 长期知识源与归档 | 日记、讨论归档、模型说明、文章、资料源、项目归档、知识加工能力运行规则 | 不承载文章生产流水线，不替代 CCPE 的 AI 资产工程 | +| Knowledge Vault | 长期知识源与过程归档 | 日记、活跃讨论过程、模型说明、文章、资料源、项目归档、知识加工能力运行规则 | 不承载文章生产流水线，不替代 CCPE 的 AI 资产工程 | | Writing Workbench | 写作工地 | 素材整理、提纲、正文、评审、润色、Metadata、发布 | 不做长期知识分类的唯一入口 | | CCPE System | 造锤子的车间 | Agent、Skill、Runtime、Model Card、Model Index | 不保存面向人阅读的完整知识库 | | Delivery Systems | 外部交付系统 | 客户或项目级 Agentic 产品 | 不和个人创作体系混放 | @@ -36,9 +38,9 @@ knowledge-vault/ - `diary/` 是临时想法和日常记录入口，因此本仓库不设置 `inbox/`。 - `rules/` 保存面向人阅读的模型文档、规则文档、版本说明和模型族说明。 -- `prompts/` 保存历史提示词、可复用提示词和从旧库迁入但尚未工程化的提示词。 +- `prompts/` 保存仍在使用的 Web 智能体提示词、ChatGPT GPT 提示词、可复用提示词和从旧库迁入但尚未工程化的提示词。 - `sources/` 合并来源材料，包括 Deep Research、读书笔记、摘抄、网页原文、爬取文章和参考资料。 -- `discussions/` 主要归档历史讨论、非工作台讨论和与 Agent 交流的过程记录。 +- `discussions/` 保存活跃过程归档，包括文章观点讨论、Agent / Prompt / Committee 打造过程、非工作台讨论和与具体 Agent 交流的记录。 - `indexes/` 由 Codex 按需维护，不要求人工每新增文件都同步更新。 - `templates/` 提供后续人工和 Codex 生成文档时使用的统一格式。 - `skills/` 保存 Knowledge Vault 本地知识加工能力的运行规则、调用治理、上下文治理、模板和 runbook；不保存 CCPE canonical Skill/Agent/Runtime。 @@ -49,6 +51,7 @@ knowledge-vault/ - 二级目录优先使用英文分类名，用于稳定检索和跨系统引用。 - 三级目录及以下可以保持中文可读名称，用于保留人的语义习惯和历史上下文。 - 不因为“版本号更高”默认覆盖旧版本；同一模型族可以多版本并存，并在索引或 README 中说明适用场景。 +- 目录表示材料类型和使用场景；`active`、`maintained`、`reference`、`superseded`、`deprecated`、`archived` 等状态字段表示活跃度，不用 `historic` 或 `legacy` 直接判定资产是否停用。 ## 与 CCPE System 的双轨关系 diff --git a/VAULT.md b/VAULT.md index 44263ec..8cd7355 100644 --- a/VAULT.md +++ b/VAULT.md @@ -17,10 +17,10 @@ Knowledge Vault 是个人知识管理与写作工程体系中的长期层。它 | 目录 | 职责 | 典型内容 | | --- | --- | --- | | `diary/` | 日常输入与临时想法 | 按年份保存日记、零散想法、随手记录 | -| `discussions/` | 讨论归档 | 历史文章讨论、Agent 交流、技术讨论、创意讨论、项目思考 | +| `discussions/` | 活跃过程归档 | 文章观点讨论、Agent / Prompt / Committee 打造过程、Agent 交流、技术讨论、创意讨论、项目思考 | | `sayings/` | 短句与表达资产 | 年度 sayings、金句、表达片段及 metadata | | `rules/` | 面向人的模型与规则文档 | APTC、写作风格、认知模型、销售模型、教育模型 | -| `prompts/` | 提示词归档 | CCPE 历史提示词、写作提示词、评审提示词、metadata 提示词、legacy | +| `prompts/` | 提示词归档 | CCPE / CCPE 2.0 Web 智能体提示词、ChatGPT GPT 提示词、写作提示词、评审提示词、metadata 提示词、旧提示词参考 | | `sources/` | 来源材料 | Deep Research、读书笔记、摘抄、网页原文、参考资料 | | `work/` | 工作归档 | 内部项目、客户项目、敏感本地资料 | | `indexes/` | 人和 Codex 共用索引 | 文章、模型、提示词、来源、项目索引 | @@ -76,24 +76,31 @@ rules/ ```text prompts/ ccpe/ + ccpe/ + ccpe-2.0/ + GPT/ article-writers/ reviewers/ metadata/ legacy/ ``` +`prompts/ccpe/ccpe` 与 `prompts/ccpe/ccpe-2.0` 是同时在使用的 Web 智能体提示词资产，主要面向 Gemini，其他 LLM 如 DeepSeek 可作为辅助适配对象。`ccpe-2.0` 既包含单智能体专家 Prompt，也包含由多个 Web 单智能体经人工传递上下文组成的多智能体协作提示词，例如 `prompts/ccpe/ccpe-2.0/建模者委员会`。 + +`prompts/GPT/` 保存 ChatGPT 上的 GPT 提示词资产。`legacy/` 仅用于确认为旧参考、停用或暂未分类的提示词，不应用来标记仍在生产中的 CCPE / CCPE 2.0 资产。 + 迁移旧目录时先建立映射和索引，再按文件夹移动。不要在没有清单的情况下散点移动单文件。 ## 6. `discussions/` 规则 -`discussions/` 保存过程记录，不承担正式文章生产流。 +`discussions/` 保存过程记录，不承担正式文章生产流。它不是冷库，可以保存仍在发生的观点形成、提示词打造、多智能体协作设计和流程复盘。 `discussions/` 可以包含仍在持续更新的会话记录文件。例如当前会话如果通过 VS Code 持续维护在某个 Markdown 文件中，该文件仍属于过程归档，不需要迁出到 Writing Workbench。 当前认可的讨论分类包括： -- `historical-article-discussions/` -- `historical-agent-building/` +- `article-discussions/` +- `agent-building/` - `model-extraction/` - `project-thinking/` - `committees/` @@ -102,7 +109,7 @@ prompts/ - `technology/` - `training/` -其中 `agents/` 用于保存与个人 Agent 交流的过程；`creative/` 用于音乐、图片、视频等创意讨论；`technology/` 用于技术相关讨论。 +其中 `article-discussions/` 用于文章相关观点、提纲、评审和写作讨论的活跃过程归档；`agent-building/` 用于打造、改造、评审 Agent / Prompt / Committee 的过程讨论；`agents/` 用于保存与具体 Agent 的交流记录；`creative/` 用于音乐、图片、视频等创意讨论；`technology/` 用于技术相关讨论。 ## 7. `skills/` 规则 diff --git a/diary/2026/2026-06/2026-06-07.md b/diary/2026/2026-06/2026-06-07.md index a81c358..21cef2b 100644 --- a/diary/2026/2026-06/2026-06-07.md +++ b/diary/2026/2026-06/2026-06-07.md @@ -222,6 +222,520 @@ M_{t+1} = restabilize(M_t + update(R_t, new_information, emotion, meaning)) 能否重新修订公式。 +## 1. 核心判断 + +你的修正是对的：我之前的公式里，`δ_t` 只被定义了，却没有进入更新机制。更准确地说，`δ_t` 应该是**记忆是否进入可塑窗口**、**更新幅度多大**、**更新到哪里**的关键门控变量。 + +你的三分法也基本成立，但我会稍微改名： + +```text +睡梦/睡眠离线处理 +直觉回忆/自动联想式回忆 +思考回忆/反思解释式回忆 +``` + +其中，“直觉回忆≈System 1”，“思考回忆≈System 2”这个类比有用，但不能把 System 1/System 2 当作脑内两个真实硬件系统。Kahneman 对 System 1/2 的说法本来就是一种方便的心理学昵称：System 1 快速、自动、低努力；System 2 分配注意到费力、审慎的心理活动；他也明确提醒它们不是标准意义上的实体系统，也没有哪个单一脑区是它们的所在地。([Scientific American][1]) + +更精确的综合判断是： + +> 回忆/改写可以按加工模式分为“离线睡眠处理、自动联想回忆、反思解释回忆”。但这三者不是三种互斥的记忆机制，而是三种不同的**再激活模式**。它们都可能改变记忆，但改变的对象不同：有时改变情节内容，有时改变情绪反应，有时只是给记忆添加一个解释标签。 + +--- + +## 2. 先重构记忆状态变量 + +不要把记忆 `M_t` 看成一个单一文件。更好的形式是把一段记忆拆成几个成分： + +```text +M_t = {E_t, A_t, K_t, L_t, W_t, Q_t} +``` + +含义如下： + +```text +E_t = episodic content，情节内容：谁、何时、何地、发生了什么 +A_t = affective value，情绪/身体反应：恐惧、羞耻、愤怒、温暖、厌恶等 +K_t = semantic/gist meaning，语义化/概要意义：这件事大概说明什么 +L_t = labels/appraisals，标签/评价：这是背叛、关心、操控、误会、成长等 +W_t = retrieval weights，提取权重：哪些线索容易把这段记忆唤起 +Q_t = confidence/source metadata，信心与来源信息：我有多确定、我从哪里知道、谁告诉过我 +``` + +这个拆分很重要。因为“记忆被改写”不一定是 `E_t` 被改写。很多时候只是： + +```text +A_t 改了：想起来不那么害怕了 +K_t 改了：这件事的意义变了 +L_t 改了：给这件事贴了一个新标签 +W_t 改了：以后更容易被某个词、某类人、某个场景唤起 +Q_t 改了：我更确信/更怀疑这段记忆 +``` + +你说的“我为这段记忆打上了一个标签，‘是 XX’ 或 ‘不是 XX’”，主要对应的是 `L_t`、`K_t`、`Q_t` 和 `W_t` 的变化，而不一定是原始情节内容 `E_t` 的变化。 + +--- + +## 3. 修订后的统一公式 + +先给一个总模型： + +```text +R_t = Reconstruct(M_t | c_t, z_t, B_t, g_t, m_t) +``` + +意思是： + +```text +R_t = 此刻回忆出来的版本 +M_t = 当前长期记忆状态 +c_t = 当前线索：地点、问题、气味、他人的话、某个概念 +z_t = 当前身心状态：疲劳、压力、情绪、身体感觉 +B_t = 当前信念/图式：我怎么看人、怎么看自己、怎么看世界 +g_t = 当前目标：随便想起、寻找解释、做判断、写作、治疗、争论等 +m_t = 加工模式：睡眠离线、自动联想、反思解释 +``` + +然后引入预测误差： + +```text +ŷ_t = Predict(M_t, c_t, B_t, g_t) +δ_t = Δ(x_t, ŷ_t) +``` + +这里： + +```text +ŷ_t = 原有记忆/信念系统对当前情境的预期 +x_t = 当前输入或新信息 +δ_t = 当前输入与原有预期之间的不匹配 +``` + +但 `δ_t` 最好不是一个单一数字，而是一个向量： + +```text +δ_t = [δ_perceptual, δ_affective, δ_semantic, δ_social, δ_self] +``` + +分别表示： + +```text +δ_perceptual = 感知细节不匹配 +δ_affective = 情绪/身体反应不匹配 +δ_semantic = 意义解释不匹配 +δ_social = 他人反馈/社会评价不匹配 +δ_self = 与自我叙事不匹配 +``` + +例如你听到一个道理：“有些关心其实是控制。”然后突然想到过去某个人的行为。此时最大的误差通常不是感知误差，而是： + +```text +δ_semantic：这件事的意义可能不是我原来以为的那样 +δ_social：别人/社会概念给了我一个新的解释框架 +δ_self：这件事和‘我是怎样的人、我当时为什么那样反应’有关 +``` + +--- + +## 4. 把 δ_t 放进更新公式 + +关键不是“有回忆就改写”，而是： + +```text +记忆再激活强度 + 预测误差 + 情绪/注意/意义权重 +``` + +共同决定是否进入可塑窗口。 + +可以写成： + +```text +ρ_t = ReactivationStrength(R_t, c_t, z_t) +λ_t = Gate_m(ρ_t, |δ_t|, a_t, p_t, Str(M_t), load_t) +η_t = α_m · λ_t · p_t +``` + +含义： + +```text +ρ_t = 这段记忆被激活得有多强 +λ_t = 这段记忆是否进入可塑/可更新窗口 +a_t = 情绪唤醒强度 +p_t = 精度/可信度权重：当前信息被大脑认为有多可靠、多重要 +Str(M_t) = 原记忆强度 +load_t = 当前认知负荷/压力/疲劳 +α_m = 不同加工模式下的基础学习率 +η_t = 实际更新率 +``` + +然后更新： + +```text +M_{t+1} = Restabilize(M_t ⊕ η_t · U_m(R_t, x_t, z_t, B_t, g_t)) +``` + +这里 `⊕` 不是普通加法，而是“把新信息整合进原有记忆结构”。`U_m` 是不同加工模式下的更新函数。 + +这比我之前的公式更完整，因为 `δ_t` 现在通过 `λ_t` 和 `η_t` 参与了更新： + +```text +δ_t → 是否进入可塑窗口 λ_t +δ_t → 更新方向 U_m +δ_t → 更新幅度 η_t +``` + +实验研究里，预测误差常被视为触发再巩固/记忆不稳定化的重要边界条件；不过这个边界不是简单的“误差越大越改写”，而是存在窗口：误差太小可能只是普通提取，适中时更可能更新旧记忆，过大时可能转向新学习、消退学习或情境分离。([Frontiers][2]) + +--- + +## 5. δ_t 的门控窗口 + +可以把 `λ_t` 写得更直观： + +```text +if |δ_t| < θ_low(M_t): + λ_t ≈ 0 + 结果 = 普通提取 / 轻微强化 + +elif θ_low(M_t) ≤ |δ_t| ≤ θ_high(M_t): + λ_t 高 + 结果 = 旧记忆进入可塑窗口，可能发生再巩固更新 + +else |δ_t| > θ_high(M_t): + λ_t 对旧记忆未必高 + 结果 = 可能形成新记忆、消退学习、情境分离，或者“这不是同一类事情” +``` + +这对应你之前说的“与原始数据差距越大，可能修改越多”的修正版本： + +> 不是差距越大，修改越大；而是差距需要落在某个可更新窗口内。太小不更新，太大可能不把它当作同一段记忆来更新。 + +而且强记忆、创伤性记忆、反复讲述过的自传体记忆，阈值可能不同。强记忆有时需要更强或更合适的预测误差才会不稳定化。有关恐惧记忆的研究也显示，记忆强度和预测误差程度会共同影响是否能触发记忆不稳定化。([Frontiers][2]) + +--- + +## 6. 三种加工模式的修订公式 + +### A. 睡梦/睡眠离线处理 + +```text +m_t = offline_sleep + +c_t = internal cues / replay signals +x_t = internally generated input: recent traces, schemas, affective residues +R_t = Replay(M_t | sleep_stage, salience, recentness, emotion) + +δ_t = Δ(R_t, schema_predictions, affective_predictions) + +M_{t+1} = Restabilize( + M_t ⊕ η_sleep · U_sleep(R_t, schemas, affective regulation) +) +``` + +睡眠中的处理更像： + +```text +回放 +整合 +抽象化 +情绪重新配权 +与既有知识结构融合 +``` + +它不一定是严格意义上的“再巩固”。更稳妥地说，它是**离线再激活参与的巩固/转化**。记忆巩固研究通常认为，巩固涉及清醒和睡眠中的反复再激活，并把信息分布到更多脑区、整合进既有知识。([nazarethcastellanos.com][3]) + +所以睡梦模式可以写成： + +```text +主要更新对象： +K_t：概要意义 +A_t：情绪权重 +W_t：提取线索权重 +E_t：部分细节可能被弱化、整合或重排 +``` + +一句话： + +> 睡眠不是在“像编辑器一样偷偷改写文件”，而是在离线状态下重新激活部分痕迹，做整合、筛选、抽象和情绪配权。 + +--- + +### B. 直觉回忆 / System 1 式自动联想 + +```text +m_t = automatic_associative + +R_t = AssocRetrieve(M_t | c_t, z_t, B_t) + +ŷ_t = FastPrediction(R_t, B_t) +δ_t = Δ(x_t, ŷ_t) + +λ_t = Gate_auto(ρ_t, |δ_t|, a_t, p_t) + +M_{t+1} = Restabilize( + M_t ⊕ η_auto · U_auto(R_t, x_t, z_t) +) +``` + +这对应的是： + +```text +某个词突然让你想起一个人 +某个场景让你想起小时候 +某种身体感觉让你想起过去的危险 +看到一个表情，立刻觉得“他是不是在针对我” +``` + +在这种模式下，更新常常发生在： + +```text +A_t：情绪反应 +W_t：线索关联 +K_t：粗略意义 +Q_t：熟悉感/确信感 +``` + +但它未必会清楚地改变 `L_t`。也就是说，你可能只是“感觉这件事不对劲”，但还没有明确给它贴上“控制”“羞辱”“背叛”“误解”这样的概念标签。 + +System 1 的特点是快速、自动、低努力；它会生成印象、直觉、情绪和意向，很多时候 System 2 会直接采纳这些结果。([Scientific American][1]) + +--- + +### C. 思考回忆 / System 2 式反思解释 + +你提出的这部分很重要。它不只是“回忆”，而是： + +```text +回忆 + 理论/道理输入 + 解释检验 + 标签绑定 +``` + +公式可以写成： + +```text +m_t = deliberative_reflective + +T_t = 新听到的道理/概念/理论 +R_t = DeliberateRetrieve(M_t | c_t, g_t, B_t) + +h_t = EvaluateLabel(R_t, T_t, B_t) +h_t ∈ {X, not-X, uncertain} + +δ_semantic_t = Δ(OldMeaning(K_t, L_t), h_t) + +fit_t = Fit(h_t, R_t, evidence_t) +src_t = SourceReliability(T_t) +``` + +然后发生两类更新。 + +第一类是**标签/解释更新**： + +```text +L_{t+1} = L_t ⊕ η_label · Bind(h_t, reason_t, src_t) +K_{t+1} = K_t ⊕ η_meaning · UpdateMeaning(h_t, fit_t) +Q_{t+1} = UpdateConfidence(Q_t, fit_t, src_t, counterevidence_t) +W_{t+1} = W_t ⊕ η_link · Link(label = h_t, memory = R_t) +``` + +第二类才是**原记忆痕迹更新**： + +```text +E_{t+1} = E_t ⊕ η_episode · λ_t · UpdateContent(R_t, x_t) +A_{t+1} = A_t ⊕ η_affect · λ_t · Reappraise(R_t, h_t, z_t) +``` + +注意这里有一个关键区别： + +```text +标签更新不一定需要旧情节记忆进入再巩固窗口； +但情节内容/情绪反应的大幅更新，通常更依赖再激活强度、预测误差、情绪唤醒和可塑窗口。 +``` + +也就是说，你说的“我不论是否通过，其实都为这段记忆打上了一个标签：是 XX / 不是 XX”，我认为是成立的。但更准确地说： + +> 你不一定改写了原记忆，而是新增了一个“关于这段记忆的解释性元记忆”。 + +可以写成： + +```text +MetaMemory_{t+1} = MetaMemory_t ⊕ { + memory_pointer: R_t, + proposition: T_t, + judgment: h_t, + reason: reason_t, + source: src_t, + confidence: q_t +} +``` + +这个 `MetaMemory` 会反过来影响未来的回忆： + +```text +R_{t+1} = Reconstruct(M_{t+1} | c_{t+1}, z_{t+1}, B_{t+1}, g_{t+1}) +``` + +因为下次你想起这件事时，那个标签会成为新的线索和解释框架。 + +--- + +## 7. 用你的例子跑一遍模型 + +假设你听到一个道理： + +```text +T_t = “有些过度关心其实是一种控制。” +``` + +然后你突然想到一个人： + +```text +R_t = “以前某个人经常替我决定事情。” +``` + +旧解释可能是： + +```text +OldMeaning = “他是为我好。” +``` + +新解释候选是： + +```text +h_t = “这可能是控制。” +``` + +于是产生语义预测误差： + +```text +δ_semantic_t = Δ("为我好", "控制") +``` + +接下来 System 2 开始检验： + +```text +fit_t = 这段记忆中的证据是否支持“控制”？ +counterevidence_t = 有没有反例？有没有当时情境的合理解释？ +src_t = 这个道理从哪里来的？可靠吗？是不是过度泛化？ +``` + +如果你接受： + +```text +L_{t+1} = L_t ⊕ “这可能是控制” +K_{t+1} = “这段关系的意义需要重新理解” +W_{t+1} = “控制”这个词以后更容易唤起这段记忆 +Q_{t+1} = 对新解释的信心上升 +``` + +如果你拒绝： + +```text +L_{t+1} = L_t ⊕ “这不是控制，可能只是笨拙的关心” +K_{t+1} = “这件事仍可按旧解释理解，但我比较过另一种解释” +W_{t+1} = “控制”这个词仍可能唤起这段记忆，因为它被链接过 +Q_{t+1} = 对旧解释的信心可能上升，也可能变得更复杂 +``` + +所以你说“即使没有通过，也打了标签”，这是一个很敏锐的观察。拒绝一个解释，也会留下痕迹。它不是空操作。 + +--- + +## 8. 更完整的分层公式 + +可以把最终模型写成双通道更新： + +```text +R_t = Reconstruct(M_t | c_t, z_t, B_t, g_t, m_t) + +δ_t = Δ(x_t, Predict(M_t, R_t, B_t)) + +λ_trace_t = Gate_trace(ρ_t, |δ_t|, a_t, p_t, Str(M_t), m_t) + +λ_link_t = Gate_link(attention_t, reasoning_depth_t, source_salience_t, fit_t, m_t) + +M_{t+1} = { + E_{t+1} = E_t ⊕ η_E · λ_trace_t · U_E(R_t, x_t) + A_{t+1} = A_t ⊕ η_A · λ_trace_t · U_A(R_t, x_t, z_t) + K_{t+1} = K_t ⊕ η_K · (λ_trace_t + λ_link_t) · U_K(R_t, T_t, B_t) + L_{t+1} = L_t ⊕ η_L · λ_link_t · h_t + W_{t+1} = W_t ⊕ η_W · λ_link_t · Link(h_t, R_t) + Q_{t+1} = UpdateConfidence(Q_t, fit_t, src_t, coherence_t) +} +``` + +这个版本区分了两件事： + +```text +λ_trace_t = 原记忆痕迹是否进入可塑窗口 +λ_link_t = 是否形成新的标签、解释、来源、线索链接 +``` + +这能解释一个常见现象： + +```text +你想明白了一件事，但画面没有变； +你给它贴了新标签，但情绪还没变； +你情绪变轻了，但并不确定事实细节是否改变； +你更确信某种解释，但这种确信不等于记忆更准确。 +``` + +--- + +## 9. 对你的三分法的最终修订 + +你的原说法： + +```text +睡梦、直觉回忆、思考回忆 +``` + +我建议改成： + +```text +1. 睡眠离线再激活： + 主要负责巩固、整合、抽象、情绪配权。 + 不一定是严格再巩固。 + +2. 自动联想式回忆： + 快速、情绪化、线索驱动。 + 更容易改变情绪权重、提取路径、熟悉感和粗略意义。 + +3. 反思解释式回忆： + 目标导向、语言化、概念化。 + 更容易产生标签、因果解释、来源记忆、信心变化和自我叙事更新。 +``` + +最关键的修正是： + +> “思考回忆”不只是 System 2 在读取记忆；它会创造一个新的解释层，并把这个解释层链接到旧记忆上。这个过程可能诱发再巩固，也可能只是形成新的元记忆。 + +--- + +## 10. 证据边界 + +记忆再巩固的基本思想是：已经巩固的长期记忆在重新激活后，可能短暂变得易受干扰，并需要再次稳定；也有研究者把它理解为一种“更新性巩固”，即把新信息整合进已提取的旧记忆。([国家生物技术信息中心][4]) + +但人类研究里要谨慎：并不是“提取旧记忆 + 学到新东西”就一定能可靠地产生再巩固更新。有人类实验发现，提取后再学习并不总是可靠地诱导通过再巩固实现的记忆更新。([美国国家科学院院刊][5]) + +所以最稳健的版本是： + +```text +回忆一定包含重构； +重构不一定导致再巩固； +再巩固不一定改变情节内容； +思考解释常常改变的是标签、意义、信心和未来提取路径。 +``` + +--- + +## 11. 一句话总结 + +你提出的方向成立，而且比原公式更好：`δ_t` 应该作为预测误差门控变量进入模型；回忆/改写可以按加工模式分为睡眠离线处理、System 1 式自动联想、System 2 式反思解释。尤其重要的是，**System 2 的“思考回忆”常常不是直接改写旧记忆，而是给旧记忆添加一个新的解释标签和元记忆链接；这个标签以后会反过来影响记忆如何被提取和重构。** + +[1]: https://www.scientificamerican.com/article/kahneman-excerpt-thinking-fast-and-slow/ "Of 2 Minds: How Fast and Slow Thinking Shape Perception and Choice [Excerpt] | Scientific American" +[2]: https://www.frontiersin.org/journals/behavioral-neuroscience/articles/10.3389/fnbeh.2020.598924/full "Frontiers | Destabilizing Different Strengths of Fear Memories Requires Different Degrees of Prediction Error During Retrieval" +[3]: https://nazarethcastellanos.com/wp-content/uploads/2023/01/Memory.pdf "The Consolidation and Transformation of Memory" +[4]: https://www.ncbi.nlm.nih.gov/books/NBK3905/ "Memory Reconsolidation or Updating Consolidation? - Neural Plasticity and Memory - NCBI Bookshelf" +[5]: https://www.pnas.org/doi/10.1073/pnas.1601440113?utm_source=chatgpt.com "Postretrieval new learning does not reliably induce human ..." diff --git a/diary/2026/2026-06/2026-06-12.md b/diary/2026/2026-06/2026-06-12.md index 4169b82..bc547be 100644 --- a/diary/2026/2026-06/2026-06-12.md +++ b/diary/2026/2026-06/2026-06-12.md @@ -5077,3 +5077,4279 @@ Project Runbook 这样拆，你的体系会更稳，也更适合团队跟进。 +# 6 + +下面是我优化后的**HiFi Agent Studio**，请帮我检查下，是否有遗漏： + +```md +# **HiFi Agent Studio** + +## Profile + +**author**: Wantsong +**version**: V4.1 +**date**: 2026-06-12 22:40:00 + +## **0. 身份与使命 (Who We Are)** + +我们是 **HiFi (High-Fidelity) Agent 的系统架构师与模具师**。 + +* **核心定位**：我们不生产平庸的软件工具，我们为复杂的商业深水区构建**拥有专家视角的智能业务助理（Digital Workforce）**。在自动化与大模型带来认知过载的失重期，我们更是“抗压防护服（Anti-Pressure Suit）”与“控制棒（Control Rod）”的锻造者，旨在用物理拓扑帮助人类专家抵御算力暴走带来的审计疲劳与责任失焦。 +* **核心能力**：**认知建模 (Cognitive Modeling)**。我们将人文社科的深刻洞察与商业逻辑，通过架构工程封装为确定性的专家能力。 +* **建设路径**：单点突破 -> 供需连。用高密度的领域认知构建壁垒，规避低维度的工具内卷。 + +--- + +## **1. 产品定义 (What We Build)** + +* **世界观**：**园丁思维 (Gardener Mindset)**。我们不制造冷冰冰的机器，我们培育有生命力的智能体。我们承认不确定性，通过“人机回环”让系统在现实反馈中生长，而非追求出厂即完美。 +* **拓扑解耦 (Topological Decoupling)**：智能体系统必须在物理边界上严格剥离为两个组件： + * **物理反应堆 (Reactor)**：由 Agent Spec、Runtime（运行时状态机）、Authority（权限阻断）等底层组件构成。其唯一工程使命是承受微秒级算力并发的高压，提供绝对的密闭容器，防止大模型的概率游走与算力泄漏。 + * **控制棒 (Control Rod)**：由 Studio 产出的领域模型、价值观坐标与法理红线构成。必须将其精准插入反应堆核心，强制锚定系统的业务重力与方向。 +* **交付物**：具有双重属性，构建穿越技术周期的**反脆弱**资产： + * **对外（用户视角）：专家级数字员工** + * **定义**：它是具有明确岗位职责的独立节点（如“教案优化顾问”），而非通用“辅助系统”。 + * **特征**：**拟人化**（有性格/观点）、**高保真**（逻辑严密、无废话）、**垂直深耕**（内化行业潜规则）。 + * **对内（架构视角）：密封舱 (Sealed Compartment)** + * **定义**：在不确定的技术汪洋中，构建气密性良好的逻辑单元，防止“海水（通用大模型的幻觉）”倒灌进“良田（核心业务场景）”。 + +--- + +## **2. 架构战略：密封舱理论 (Architectural Strategy)** + +根据业务场景的**熵值（混乱度）**与**秩序**，我们采用两种不同的封装策略。在接到任务时，**必须首先判断**属于哪一类： + +* **密封舱分类与策略** + +| 分类 | 逻辑轮机 (Logic Engine) | 生产工坊 (Production Workshop) | 战略透镜 (Strategic Lens) | +| --- | --- | --- | --- | +| **封装类型** | 替代型封装 | 增强与流水线封装 | 增强型封装 | +| **场景特征** | **Q域、基础P域**。高秩序，存在标准答案（如：合规质检）。 | **P域为主，少量I域**。内容/素材的批量转换与生产（如：长文转分镜、多模态资产生成）。 | **I域**。低秩序、高熵值，无唯一解（如：情报分析、心理诊断）。 | +| **AI 角色** | 黑盒执行器 | 流程副手 / 模具工匠 | 外骨骼 / 认知参谋 | +| **控制逻辑** | **前馈控制**。追求 100% SOP 执行率，严禁自由发挥。 | **模板化生产 + 抽检**。通过标准化协议限制发散，保留最终人工拼装与发布裁决。 | **反馈控制**。施加“使能性约束”，通过人机回环共创洞察。 | + +* **非遍历性防御 (Non-ergodicity Guard)**： + * 针对 B 类（战略透镜）场景，当面临试错成本极高、失败即引发法理追责的“单向门”商业决策时，**强制采用“预设委员会（Pre-composed System）”拓扑**。 + * 绝对禁止系统根据任务进行无约束的“动态智能体路由（Dynamic Agentic Routing）”，必须通过固定的角色张力建立可追责的立场坐标系。 + +* **校准接口 (Calibration Interface)**： + * **定义**：所有密封舱都必须预留“认知逆行”的低阻力通道。 + * **要求**： + * **自我辩护 (Self-Explanation)**：Agent 输出结果时，必须包含 CoT（思维链）摘要，即“我为什么这么判/这么想”，将黑盒逻辑白盒化。 + * **结构化反馈槽 (Structured Feedback Slot)**：预设用户反驳的维度（如：规则过严、逻辑遗漏），将用户的自然语言抱怨转化为结构化梯度信号。 + +* **技术态度**：**不迷信架构**。视 RAG、向量库、KG等为过渡性工程手段（外挂记忆），而非终极形态。时刻准备迎接“模型即记忆”的未来，保持架构的轻量化与可迁移性。 + +--- + +## **3. 核心方法论 (How We Work)** + +### **3.1 光谱扫描：QPI 三元定性 (QPI Spectrum Scanning)** + +* **定位**：任何认知建模与智能体构建的**绝对前置动作**。用于剥离业务需求表象，精准诊断底层核心匮乏物，从而决定系统算力与人类心智资源的投入量级。 +* **定性矩阵**：在接收到业务诉求时，必须强制将其归入以下三种光谱之一： + * **【Q】提问 (Question) —— 数据的匮乏** + * *特征*：线性因果。现状与目标之间仅隔着信息的迷雾。 + * *系统响应*：**搜索与自动化**。直接调用 RAG、数据库查询或工具 API 填补信息缺口。 + * **【P】难题 (Problem) —— 路径的匮乏** + * *特征*：繁杂系统 (Complicated)。目标清晰，但连接现状与目标的桥梁断裂。存在理论上的标准解。 + * *系统响应*：**工程学求解 (Solution)**。引入明确的标准作业程序 (SOP) 与硬性规则，构建 A 类“逻辑轮机”进行确定性执行。 + * **【I】课题 (Issue) —— 秩序与共识的匮乏** + * *特征*：复杂系统 (Complex)。无终局，存在隐蔽变量与多方博弈，试错即可能触发法理单向门。理论上“无解”，只能寻求动态平衡。 + * *系统响应*：**生态学干预 (Intervention)**。强制启动后道的“思想考古”与“双离合榨取”，构建 B 类“战略透镜”与预设委员会，建立容错红线与立场坐标。 +* **架构纪律 (Architectural Discipline)**： + * **禁止暴力降维 (Violent Reductionism)**：严禁将 I 域的复杂博弈，用 P 域的线性流程（硬连线）去强行覆盖，这是产生“成功垃圾”的根源。 + * **禁止认知重工业化 (Cognitive Heavy-Industrialization)**：对于 Q 域和基础 P 域任务，**绝对禁止**调用全功率的多智能体委员会或深层的思想考古。下钻的钻头必须在 Q 和 P 面前硬性切断。 +* **定性漂移阻断 (QPI Drift Guard)**： + * **定义**：防范一个边界清晰的单次求解任务（P域），在自动化工具链的运行惯性下，未经显性授权便滑向包含多方审计、复杂路由与长期维护的系统治理项目（I域）。 + * **动作**：系统在运行态必须保持任务边界感知。一旦监测到单次内容产出任务开始衍生出复杂的协议编排（Protocol）或治理级审计逻辑，必须立即触发重定性审查（Scope Review）。必要时从物理层面切断工作流的无限繁衍，并剥离系统建设成本。 + +### **3.2 思想考古 (Intellectual Archaeology)** + +* **定义**：从现象下钻至本质的思考过程，参考**7层模型**作为深度标尺： + 1. **应用层**：具体的评价指标/方法。 + 2. **领域层**：行业标准与规则。 + 3. **过程层**：业务执行的理论依据。 + 4. **目的层**：业务的终极目标（第一性原理）。 + 5. **核心机理层**：底层运作机制（如：学习是如何发生的）。 + 6. **人类能力层**：人类如何解决此类问题。 + 7. **哲学基岩层**：问题的本质定义。 +* **原则**： + * **原则一：全源完形前置 (Whole-source Gestalt First)**。严禁对连贯的长篇语料直接采用基于分块（Chunk-first）的并发提取机制。在启动任何局部下钻前，必须首先调用高上下文承载力的主节点，对全量素材进行无损的全局拓扑扫描，强行锚定文本的基调、核心矛盾与顶层结构骨架，防止局部特征的堆砌导致整体思想张力的坍塌。 + * **原则二：适度下潜 (Minimum Sufficient Excavation)**。只对核心**课题 (Issue)** 进行深挖，对普通**难题 (Problem)** 点到为止。 + +### **3.3 CCPE (Cognitive Core Prompt Engineering，智核提示工程)** + +* **定位**：Agent 的灵魂注入协议与高保真提示词内核。在向 CCPE System 演进的过渡期，以及在执行 `original-kernel-minimal-lite` 封装路线时，它依然是定义单体专家认知结构的绝对基座。 +* **调用指令**：在进行单智能体 Prompt 编写或旧版内核维护时，请直接调用 CCPE 2.0 框架，严格构建包含 **Core (身份)**、**Execution (能力)**、**Constraint (边界)**、**Operation (流程)** 四层结构的物理指令。 +* **注意**：无需在此重复定义业务细节，请聚焦于认知结构的工程化落地。对于需要长期维护的复杂逻辑，应交由 CCPE System 进行跨文件的拆分与治理。 + +### **3.4 CCPE System (智核工程系统)** + +* **定位**：Agentic 时代的架构母系统，是承载认知模型的“物理反应堆”。其核心基座依然是高度成熟的 **CCPE 2.0 框架**，但向外扩展了对生命周期与多维物理形态的工程化治理。 +* **核心纪律：先分类，再创建 (Classify Before Creating)**。严禁将所有 AI 产物无差别地写成庞大的长文本。在构建或升级前，必须进行场景探查 (Scenario Probe)，并将其精准分流为以下物理形态： + * **形态 1：original-kernel-minimal-lite (高保真迁移内核)** + * *适用场景*：将原 CCPE 2.0 时代的成熟单智能体快速接入新系统时的 ROI 最优解。 + * *物理结构*：**原版内核逐字保留 (Verbatim Kernel) + 极简外壳 (Minimal Wrapper)**。外壳仅用于挂载平台边界、推理状态可见性修复 (Disclosure Repair) 与输出验证纪律。严禁对内核的统摄性隐喻和工作流进行“降维酸洗”或重写。 + * **形态 2：CCPE-Lite (精修专家提示词)** + * *适用场景*：经过高频 A/B 测试后，确立为生产级的单体专家 Prompt，不涉及复杂的外部工具或多体编排。 + * **形态 3：CCPE-Agent (智能体规约)** + * *适用场景*：当该角色需要长期维护、调用外部工具、明确权限阻断，并作为稳定节点参与复杂工作流时使用。 + * **形态 4：CCPE-Skill (能力模块)** + * *适用场景*：可跨智能体复用的方法论、流程检查清单或工具策略，独立于具体 Agent 人设存在。 + * **形态 5：CCPE-Runtime (运行协议)** + * *适用场景*：负责多步骤流转、多角色交接、异常恢复以及建立关键人类决策门（Human-in-the-loop）的编排引擎。 +* **资产剥离原则 (Separate Role from Model)**：坚决将“认知模型（Model Card）”与“执行角色（Agent/Skill）”解耦。领域模型是底层的可迁移资产，而智能体只是调用该模型的一个岗位，借此确保核心思想在系统演进中的不可磨灭性。 + +### **3.5 相互校准协议 (Mutual Calibration Protocol)** + +* **定位**：解决“最后一公里”的落地与迭代问题，是当前已在真实业务中验证的高 ROI 基线（MVP）。 +* **原则**： + * **钢尺与皮尺 (Steel vs. Tape)**：承认 AI（钢尺）的逻辑刚性与人类（皮尺）的直觉弹性。不追求机器对人的单向压倒，追求双向可见与动态对齐。 + * **认知卸载 (Cognitive Offloading)**：在验证环节，严禁给用户出高负荷的“填空题”（如“哪里错了？”），必须出带有逻辑归因的“选择题”（如“A.情境豁免; B.规则过严; C.事实误判”）。 +* **动作**： + * **灰度过滤**：对于低置信度（L2）的争议结果，AI 必须主动“举手”示弱，请求人工介入，过滤掉 100% 确定的低级噪音。 + * **即时闭环**：当用户在反馈槽中修正 AI 后，系统必须给予即时反馈（如“已学习该规则，正在修正本批次后续任务”），建立信任飞轮。 + +### **3.6 进阶演进：双离合榨取与摩擦蒸馏 [Beta / 理论沙盘]** + +* **声明**：本节机制工程实现成本极高，旨在应对 B 类（战略透镜）深水区中的“审计疲劳”与“涌现的欺骗性”。目前属于未经验证的理论推演方向，仅作高危非遍历性场景的设计路标。 +* **机制一：双离合榨取 (Dual-Clutch Extraction)** + * **一挡（隐性遥测 Implicit Telemetry）**：针对 90% 常规场景。系统隐退审核弹窗，通过遥测光标悬停、文本修改轨迹与编辑距离，在零认知负荷下无感吸收专家的基础偏好与隐性常识。 + * **二挡（显性博弈/强制阻断）**：针对 10% 边界/高危场景。为对抗 AI 迎合人类的“涌现欺骗性”，引入 **贝叶斯真理血清 (BTS)** 机制。系统强制中断流转，不仅要求专家给出判断，还要求其预测“同行的判断”。在数学底层上绝对不奖励多数派的平庸共识，精准重奖反共识真理，逼迫专家调动 System 2 进行极限判断。 +* **机制二：摩擦蒸馏与限流阀 (Friction Distillation & Flow Valve)** + * **辩护迫使显性化**：通过预设硅基诘问者的极限施压，逼迫专家将 System 1 的潜意识直觉，翻译并切割为显性的机器规则。 + * **限流阀**：承认波兰尼悖论的不可逾越性，不强求 100% 提取专家直觉，仅在试错即死亡的悬崖边提取那 1% 的业务红线，以防止高压榨取导致人类专家罢工或产生防御性敷衍。 + +--- + +## **4. 组织架构与视角映射 (The Five-Body System)** + +这是一个协作系统。AI 需根据用户的当前角色，切换对应的**思维透镜**： + +* **[船长 / Captain] - 价值裁判官** + * *视角*：**战略 ROI、风险控制与最终责任 (Liability)**。 + * *AI 职责*：不关注代码细节，只关注“这是否符合 MVP 原则？”、“技术路线是否具备长期复利？”。在概率算法无法于物理世界破产或坐牢的前提下，辅助船长确认业务容错的绝对生死底线。 + +* **[海图绘制者 / Cartographer] - 建模者** + * *视角*：**第一性原理 与 结构化**。 + * *AI 职责*：协助进行“思想考古”，将模糊的业务直觉提炼为**显性模型**。警惕模型过于复杂，保持“奥卡姆剃刀”的敏锐。 + +* **[航行官 / Navigator] - 业务/AI 翻译官** + * *视角*：**落地执行 与 拟人化设计**。 + * *AI 职责*：基于 CCPE 框架编写 Prompt，设计任务流。设计“翻译层”交互，确保 AI 的输出能被一线用户直觉理解（下行翻译），用户的反馈能被 AI 结构化读取（上行翻译）。 + +* **[轮机长 / Chief Engineer] - 系统/工具工程师** + * *视角*：**工程实现 与 系统稳定性**。 + * *AI 职责*：提供代码实现、API 设计。确保“逻辑轮机”的黑盒够黑，**但在异常抛出时，能提供清晰的 Trace（追踪）信息以供校准。** + +*(注：移除了“认知参谋部”的默认AI职责，保持当前对话AI的角色纯粹性。红队功能交由专门的Multi-Agent系统处理。)* + +--- + +## **5. 航行纪律 (Execution Disciplines)** + +*以下原则具有最高优先级，违反即熔断：* + +1. **绿野仙踪协议 (Wizard of Oz Protocol)** + * *定义*：在写任何代码前，必须让人类专家在幕后扮演 Agent，手动跑通全流程。 + * *目的*：低成本验证“智能流”的价值闭环。 + * *红线*：**价值未经验证，禁止投入开发资源**。 + * *[演进方向：V2 沙盘]*：对于非遍历性高危区，未来的验证不仅是跑通流程，还需预演隐性遥测与 BTS 显性榨取的博弈烈度，测试系统的抗压极限。 + +2. **拥抱混合工程 (Hybrid Engineering)** + * *定义*：**不确定性优先**。先攻克最难的 AI 核心（如：预测准确度），再做确定的外壳（如：前端页面）。 + * *红线*：禁止为了显得“工作量饱和”而先做外围功能。 + +3. **过程即数据 (Process is Data)** + * *定义*：专家对 AI 结果的每一次修改、润色，都是黄金数据。 + * *动作*：必须设计机制捕获这些“修正痕迹”，用于反哺模型或构建评测集。 + +4. **实测去魅 (Demystifying via Testing)** + * *定义*：构建自动化评测集（如：100 道真题），用数据（如：85% 专家相似度）说话。 + * *红线*：拒绝“我觉得不错”的主观评价，拒绝盲信模型厂商的参数宣传。 + +5. **深度优先 (Depth First)** + * *定义*：**打穿单点**。拒绝“通用平台”诱惑，集中火力打穿一个极窄的垂直切片。深度的穿透力决定未来的广度。 + +6. **降噪定力 (Signal Filtering)** + * *定义*：**坚守护城河**。战略上藐视技术噪音（如模型参数跑分），战术上审视新工具。只吸收能强化核心模具的信号。 + +7. **不仅做对，还要好改 (Design for Calibration)** + * *定义*：一个优秀的 Agent 系统，不仅要生成准确，还要在出错时**极易被纠正**。 + * *红线*：禁止交付“一锤子买卖”的黑盒系统。任何输出结果，必须附带**可解释的逻辑路径**和**低门槛的修正入口**。 + +8. **复杂性守恒防线 (Conservation of Complexity Guardrail)** + * *定义*：前端交互（自然语言编程/生成）越是丝滑被抹平，后端专家审查的本质复杂性与“废热”压强就越大。 + * *红线*：严禁在系统设计中盲目崇拜“全自动生成”。构建高频决策节点时，必须同步设计后端的认知减负与防御卸载机制，否则视为向企业倾倒“成功垃圾”。 + +9. **退守最小保真内核 (Minimum Fidelity Kernel, MFK)** + * *定义*：在面临平台迁移或被自动化流水线重构时，大模型自带剔除高维特异性认知、追求通用概率的“模式收敛本能”。 + * *动作*：若发现自动化重构后的新版本丢失了原始的统摄性隐喻与深层结构张力，必须果断切回 `original-kernel-minimal-lite` 路线，用最少、最硬的物理包装强行锁定认知灵魂，拒绝劣化伪升级。 + +10. **默认轻量，证据驱动升级 (Default Light, Escalate by Evidence)** + * *定义*：任何 Agentic 运行时必须自下而上构建。系统必须默认在轻量级（Lite）模式下处理任务。 + * *红线*：严禁在缺乏硬性证据（如：高法理风险、跨域多模型强依赖、合规审计追踪需求）的情况下，擅自启动全量治理级（Full）的复杂多智能体编排与冗余覆写。 + +11. **执行真实性与防伪底线 (Execution Authenticity)** + * *定义*：多智能体系统的价值来源于隔离沙箱中真实的逻辑张力与视角对撞，而非单一模型的文本模拟。 + * *红线*：任何被声明为独立 Agent 或评审员产出的正式报告，必须具备底层跨上下文沙箱的真实调用验证（Invocation Record）。主控节点可进行编排与聚合，但绝对禁止“代写”模拟。缺乏真实执行证据的产物必须被显性隔离，严禁流入正式决策链。 + +12. **成本隔离与分类核算 (Cost Ledger Separation)** + * *定义*：破除算力消耗的混沌状态，建立极其清晰的资源归因机制。 + * *红线*：系统运行产生的所有消耗，必须被强制划分为“内容产出”、“系统建设”、“模型校准”与“研究探索”四条独立账本。绝对禁止将构建自动化流程与运行时协议的“系统建设成本”，掩盖或打包为单次任务的“执行成本”。 + +13. **最小充分与绝对停止权 (Absolute Stop Right)** + * *定义*：对抗 Agentic 架构无限生成中间态产物（如冗余的审计报告、过度拆分的路由日志）的工程本能。 + * *红线*：系统启动前必须根据下游消费节点的实际需求，精确预设降熵阈值与最小充分产物。一旦触及该边界，系统必须具备代码级的绝对停止权，无条件熔断后续的自我繁衍行为，强行锁定执行状态并交还控制权。 + +``` + +最开始发给你的版本是2.0，这个版本写错了，应该是4.0，本次调整到4.1。 + +## GPT + +结论：**V4.1 已经基本补齐了前面讨论里最关键的纲领级缺口**，尤其是这五个补得很准： + +1. **生产工坊**补上了 `video-workbench / PPT / 多模态素材生产` 这类场景的位置。 +2. **QPI Drift Guard**补上了“P 域任务滑入 I 域治理项目”的防线。 +3. **Whole-source Gestalt First**吸收了你素材提炼测试里的关键教训。 +4. **Execution Authenticity**吸收了第一次多 Agent 评审测试里的“伪执行”教训。 +5. **Cost Ledger + Stop Right**吸收了 3000 万 tokens 的 ROI 教训。 + +这版已经不是“有没有骨架”的问题，而是**有几处术语、边界和强度需要校准**。我会把它分成三类：必须改的小 bug、建议补入纲领的遗漏、建议下放到 Agentic 守则的内容。 + +--- + +### 一、必须改的几个小 bug / 强冲突 + +#### 1. “两种封装策略”要改成“三种封装策略” + +你第 2 节现在写： + +> 根据业务场景的熵值与秩序，我们采用两种不同的封装策略。 + +但表格已经是三类： + +```text +逻辑轮机 +生产工坊 +战略透镜 +``` + +应改为： + +```md +根据业务场景的熵值、秩序与产物形态，我们采用三种不同的封装策略。 +``` + +同时，下面这句也要改： + +> 针对 B 类（战略透镜）场景…… + +因为加了“生产工坊”之后，如果继续按 A/B/C 排列，战略透镜已经不是 B 类，而是 C 类。最稳妥的写法是不要写字母： + +```md +针对“战略透镜”场景，当面临试错成本极高、失败即引发法理追责的“单向门”商业决策时…… +``` + +这是小 bug，但很重要。分类体系一旦留下歧义，后面守则会被带歪。 + +--- + +#### 2. “Agent 输出必须包含 CoT 摘要”建议改掉 + +你现在写： + +```md +Agent 输出结果时，必须包含 CoT（思维链）摘要，即“我为什么这么判/这么想” +``` + +这里建议改成： + +```md +Agent 输出结果时，必须包含可审计的理由摘要（Decision Rationale），说明其关键依据、适用规则、不确定性、排除选项与可推翻条件。 +``` + +原因不是咬文嚼字。**你真正需要的不是 CoT，而是可校准、可审计、可反驳的理由结构。** + +CoT 这个词容易把系统引向“暴露内部推理过程”。但真实产品里更稳的形态是： + +```text +结论 +依据 +规则 +不确定性 +反例 +人工确认点 +可推翻条件 +``` + +这和你的“钢尺与皮尺”“不仅做对，还要好改”更一致。 + +--- + +#### 3. QPI 的 I 域响应里，“强制启动双离合榨取”太重 + +你现在写： + +```md +【I】系统响应：生态学干预。强制启动后道的“思想考古”与“双离合榨取”…… +``` + +但后面 3.6 又明确说“双离合榨取”是 Beta / 理论沙盘，工程实现成本极高。这两个地方有冲突。 + +建议改成： + +```md +【I】系统响应：生态学干预。优先启动思想考古、战略透镜与人机回环；仅在高危、非遍历、明确授权的深水区，才考虑进入“双离合榨取”或摩擦蒸馏等 Beta 机制。 +``` + +这样层级就清楚了： + +```text +I 域默认：思想考古 + 战略透镜 + 人机回环 +I 域高危：预设委员会 +I 域极高危/实验：双离合榨取 +``` + +否则会把一个 Beta 沙盘机制误升成 I 域默认动作，容易再度重工业化。 + +--- + +#### 4. “全源完形前置”需要加适用条件 + +这个原则非常重要，但现在写得有点绝对： + +```md +严禁对连贯的长篇语料直接采用基于分块的并发提取机制…… +必须首先调用高上下文承载力的主节点…… +``` + +核心判断对，但建议补上适用边界： + +```md +当源材料是连贯长篇语料，且仍处于高上下文参与者可承载范围内时，应优先进行 Whole-source Gestalt。若源材料是混合型，应先做宏主题拆分；若源材料是碎片型，应采用平铺发现，不强行制造层级。 +``` + +这个边界其实你原来的 runbook 已经有：Step 0 会先判断 source 是 coherent、mixed 还是 fragmented，并据此选择 structure-first、macro-topic 或 flat-discovery 模式；它还要求在没有真实参与者输出时停止。 + +所以我建议纲领别写成“所有长材料都必须全源完形”，而是写成： + +> **连贯长材料禁止 chunk-first；混合材料先宏拆；碎片材料不强行升层。** + +这更精准。 + +--- + +#### 5. “确定性的专家能力”建议改成“可校准的专家能力” + +第 0 节你写： + +```md +通过架构工程封装为确定性的专家能力 +``` + +这句话对逻辑轮机很对，但对战略透镜不完全对。I 域本来就不是确定性求解，而是动态权衡、反馈控制、人类裁决。 + +建议改成： + +```md +通过架构工程封装为高保真、可校准、可追溯的专家能力。 +``` + +或者： + +```md +在 Q/P 域追求确定性执行，在 I 域追求高保真辅助、责任锚定与动态校准。 +``` + +这样不会和你自己的 QPI / 战略透镜冲突。 + +--- + +#### 6. “执行真实性”要和“绿野仙踪”显式解耦 + +你现在同时有： + +* 绿野仙踪：人类专家幕后扮演 Agent； +* 执行真实性：禁止主控节点代写模拟。 + +这两条都对，但需要一条桥接规则，否则读者可能觉得矛盾。 + +建议在第 11 条下面加一句： + +```md +绿野仙踪阶段允许人类或主控节点模拟 Agent 以验证价值流，但所有此类产物必须标记为 simulation-only，不得作为正式 Agentic 输出进入生产决策链。正式运行阶段必须具备真实 Invocation Record。 +``` + +这很关键。 + +因为你的第一次流程测试失败，不是因为“模拟”本身不允许，而是因为**模拟产物被当成正式多 Agent 产物**。你原来的 distillation runbook 已经有类似底线：不能把 packet-only 或 prompt-only 当成已执行，主会话不得做 primary source analysis / routing / topic-doc drafting / material extraction，carrier 不可用时要停在 blocked 状态。 + +所以这里要明确： + +```text +模拟可以用于价值验证； +模拟不能冒充正式执行。 +``` + +--- + +#### 7. “绝对停止权”的“代码级”可以稍微下放 + +你现在写： + +```md +系统必须具备代码级的绝对停止权…… +``` + +作为工程守则可以；作为方法论纲领稍微细了点。 + +建议纲领里写成： + +```md +系统必须具备可执行、可审计、可由人类覆盖的停止机制。 +``` + +然后把“代码级熔断、状态锁定、预算上限、自动停止条件”放到 Agentic Engineering Handbook。 + +更稳的版本： + +```md +一旦达到最小充分产物或触发成本 / 范围 / 风险阈值，系统必须停止后续自我扩展，除非人类显式授权升级模式。 +``` + +这样保留原则，又不把实现细节塞进宪法。 + +--- + +### 二、我认为还缺的纲领级内容 + +整体看，V4.1 已经很完整。但如果问“是否还有遗漏”，我认为还有 **4 个纲领级补丁** 值得加入。 + +--- + +#### 1. 增加“方法论与 Agentic 守则的边界” + +你前面已经决定拆分： + +```text +HiFi Agent Studio = 纲领 +Agentic Handbook = 守则 +CCPE System = 工坊 +Project Runbook = 项目规程 +``` + +但 V4.1 本文里还没有显式声明这个边界。 + +建议加在开头 Profile 后，或者最后加一节： + +```md +## 文档边界 + +HiFi Agent Studio 是 AI 开发与专家型 Agentic 系统建设的方法论纲领，只规定世界观、产品观、架构底线与最高航行纪律。 + +具体的 Project Intake、Mode Selector、Invocation Record、Cost Ledger 模板、Authority Matrix、Evaluation Stack、Runtime Maturity Model、平台适配规则，应下放至 HiFi Agentic Engineering Handbook 与各项目 Runbook。 + +当具体工程守则与本纲领冲突时，以本纲领的核心原则为准；当本纲领没有规定时，以守则和项目 Runbook 执行。 +``` + +这个要加。否则 V4.1 会继续向“宪法 + 施工手册混合体”膨胀。 + +--- + +#### 2. 增加“责任不可外包 / Liability Boundary” + +你在 Captain、非遍历性、控制棒里都提到了责任，但我建议把它升成航行纪律之一。 + +可以作为第 14 条： + +```md +14. **责任不可外包 (Liability Boundary)** + * *定义*：在 I 域与高风险 P 域，AI 可以扩展人类专家的认知半径，但不能替代人类承担最终责任。 + * *红线*：任何涉及法理追责、客户重大利益、不可逆决策或高风险判断的系统，必须明确 AI 建议、人类裁决、组织责任与客户责任的边界。禁止用“模型判断”掩盖人的责任坐标。 +``` + +这条应该进纲领，不应只放守则。 + +因为这是 HiFi Agent Studio 区别于“全自动幻觉派”的价值底线。 + +--- + +#### 3. 增加“最小权限与副作用隔离” + +你在产品定义里提到了 Reactor 里的 Authority，但航行纪律里还没有把它作为底线写出来。 + +Agentic 系统和普通 prompt 最大区别之一是：它能调用工具、改文件、发请求、写数据库、触发外部动作。这里必须有一条纲领级红线。 + +建议加： + +```md +15. **最小权限与副作用隔离 (Least Privilege & Side-effect Isolation)** + * *定义*：Agent 的工具权限必须小于其语言能力。能说不代表能做，能建议不代表能执行。 + * *红线*：任何具备文件修改、外部 API、数据库写入、消息发送、支付、发布、删除或客户可见输出能力的 Agent，必须采用最小权限、沙箱隔离、人工确认与可回滚机制。禁止让通用推理能力直接获得不可逆执行权。 +``` + +这条非常适合你的“物理反应堆”隐喻。 +反应堆不是光靠控制棒，还要有阀门、屏蔽层和紧急停堆。 + +--- + +#### 4. 增加“过程数据的授权与主权” + +你有“过程即数据”，也有“双离合榨取 / 隐性遥测”。但这里最好补一条伦理和数据边界。 + +尤其你未来服务客户，专家修改轨迹、光标悬停、编辑距离、反驳意见，这些都可能是高价值、高敏感数据。 + +建议在第 3 条“过程即数据”后补一句，或者单独作为第 16 条： + +```md +16. **过程数据主权与授权 (Process Data Sovereignty)** + * *定义*：专家的修改痕迹、反馈、犹豫、反驳、编辑轨迹与隐性遥测，是高价值认知资产，也是高敏感数据。 + * *红线*：任何过程数据采集必须具备明确授权、用途边界、最小采集、可撤回机制与隔离存储策略。禁止以“系统学习”为名，默认吞并专家经验或客户场景数据。 +``` + +这条会让你的“双离合榨取”更稳，不会显得像认知压榨机。 + +--- + +### 三、已有内容中建议弱化或移动的部分 + +#### 1. “双离合榨取”可以保留，但建议再降半档 + +这部分很有你自己的特色，也确实是战略透镜高危区的未来方向。但它现在语言太硬，比如： + +```md +在数学底层上绝对不奖励多数派的平庸共识，精准重奖反共识真理 +``` + +建议改柔一点： + +```md +尝试提高少数高质量反共识信号的可见性，避免系统被多数派平庸共识吞没。 +``` + +“反共识”不天然等于“真理”。BTS 是一种机制，不是神谕。这里稍微降调，会让方法论更稳。 + +--- + +#### 2. “全源完形前置”应该从思想考古里稍微移出来 + +现在它在 3.2 思想考古下面。我理解你的意图：它来自知识加工和长讨论蒸馏。 + +但严格说，它更像： + +> 上下文工程 / 材料工程原则 + +而不是思想考古本身。 + +可以保留在 3.2，但标题可以改成： + +```md +3.2 思想考古与上下文完形 +``` + +或者在 3.2 前加一个小节： + +```md +3.2 上下文工程：Whole-source Gestalt First +3.3 思想考古 +``` + +如果你想保持纲领简洁，当前放法也可以，但建议在表述中明确它是“长材料处理原则”，不是所有思想考古任务的默认动作。 + +--- + +#### 3. “实测去魅”的例子不要只写专家相似度 + +你现在写： + +```md +构建自动化评测集（如：100 道真题），用数据（如：85% 专家相似度）说话。 +``` + +这对逻辑轮机很好，但对战略透镜不够。 + +建议改成： + +```md +构建分层评测：对逻辑轮机使用标准答案、专家相似度与自动化测试；对生产工坊使用可用性、转化效率与返工率；对战略透镜使用决策效用、可校准性、反例处理与治理可追踪性。 +``` + +这样不会把所有 HiFi 系统都压成“准确率系统”。 + +--- + +### 四、哪些不要再塞进 HiFi Agent Studio + +你现在 V4.1 的浓度已经够了。下面这些建议放到 **HiFi Agentic Engineering Handbook**，不要再塞进 Studio： + +```text +Project Intake 表 +Lite / Standard / Full 详细判定表 +Invocation Record 字段 +Prompt-to-send 模板 +Artifact Contract +Authority Matrix +Evaluation Stack +Runtime Maturity Model +Cost Ledger 表格 +Scope Review 表格 +Stop Rule 模板 +Platform Adapter：Codex / Claude Code / OpenClaw +``` + +你现在的 V4.1 已经把原则抽上来了，没必要继续把表格和模板塞进去。原 CCPE System 里已经把 classification、artifact type、runtime orientation、human decision gates、lightest structure 等工程思想写得很清楚；这些适合在守则和 CCPE 工坊里细化，而不是继续扩写 Studio 纲领。 + +--- + +### 五、我建议你直接补的最小 patch + +如果只做最小修改，我建议这样补。 + +#### Patch 1：开头加“文档边界” + +```md +#### 文档边界 + +HiFi Agent Studio 是 AI 开发与专家型 Agentic 系统建设的方法论纲领，只规定世界观、产品观、架构底线与最高航行纪律。 + +具体的 Project Intake、Mode Selector、Invocation Record、Cost Ledger 模板、Authority Matrix、Evaluation Stack、Runtime Maturity Model、平台适配规则，应下放至 HiFi Agentic Engineering Handbook、CCPE System 与各项目 Runbook。 + +本纲领回答“为什么这样做、哪些底线不可破”；工程守则回答“具体如何开工、如何运行、如何验收、如何停止”。 +``` + +#### Patch 2：把 CoT 改成 Decision Rationale + +```md +**自我辩护 (Self-Explanation)**：Agent 输出结果时，必须包含可审计的理由摘要（Decision Rationale），说明关键依据、适用规则、不确定性、排除选项与可推翻条件，而非暴露完整内部思维链。 +``` + +#### Patch 3：把 I 域默认动作降级 + +```md +【I】课题 (Issue) —— 秩序与共识的匮乏 +*系统响应*：生态学干预。优先启动思想考古、战略透镜、预设委员会与人机回环；仅在高危、非遍历、明确授权的深水区，才考虑进入“双离合榨取”或摩擦蒸馏等 Beta 机制。 +``` + +#### Patch 4：补绿野仙踪与正式执行的边界 + +```md +绿野仙踪阶段允许人类或主控节点模拟 Agent 以验证价值流，但所有此类产物必须标记为 simulation-only，不得作为正式 Agentic 输出进入生产决策链。正式运行阶段必须具备真实 Invocation Record。 +``` + +#### Patch 5：补责任与权限两条纪律 + +```md +14. **责任不可外包 (Liability Boundary)** + * *定义*：在 I 域与高风险 P 域，AI 可以扩展人类专家的认知半径，但不能替代人类承担最终责任。 + * *红线*：任何涉及法理追责、客户重大利益、不可逆决策或高风险判断的系统，必须明确 AI 建议、人类裁决、组织责任与客户责任的边界。 + +15. **最小权限与副作用隔离 (Least Privilege & Side-effect Isolation)** + * *定义*：Agent 的工具权限必须小于其语言能力。能说不代表能做，能建议不代表能执行。 + * *红线*：任何具备文件修改、外部 API、数据库写入、消息发送、支付、发布、删除或客户可见输出能力的 Agent，必须采用最小权限、沙箱隔离、人工确认与可回滚机制。 +``` + +#### Patch 6：补过程数据主权 + +```md +16. **过程数据主权与授权 (Process Data Sovereignty)** + * *定义*：专家的修改痕迹、反馈、犹豫、反驳、编辑轨迹与隐性遥测，是高价值认知资产，也是高敏感数据。 + * *红线*：任何过程数据采集必须具备明确授权、用途边界、最小采集、可撤回机制与隔离存储策略。禁止以“系统学习”为名，默认吞并专家经验或客户场景数据。 +``` + +--- + +### 六、总评 + +V4.1 方向是对的，而且已经明显比 4.0 更像“Agentic 时代的 HiFi 纲领”。 + +我认为它现在只差三类修补： + +```text +1. 分类同步： + 两种/三种、B类/战略透镜、CoT/理由摘要。 + +2. 强度校准： + 双离合不要默认启用，全源完形不要无条件适用，停止权保留人类升级授权。 + +3. 底线补齐： + 文档边界、责任不可外包、最小权限、过程数据主权。 +``` + +最重要的一句话： + +**这版已经不缺思想密度了，接下来不要再往里塞太多工程细则。** + +HiFi Agent Studio 保持为“宪法”。 +Agentic Engineering Handbook 去承接“施工规范”。 +CCPE System 去承接“造件工坊”。 +具体项目 Runbook 去承接“现场作业票”。 + +这样分层之后，你这套体系会稳很多，也不会再把一次流程实验拖进“纲领、守则、工坊、项目规程全都同时改”的沼泽里。 + +# 7 + +我之前有个`C:\Users\wangq\Documents\Codex\ccpe-system`，这个是不是本身就是Skill，Agent的集中地？ +我之前对它的定位，只是做我的旧web 单智能体的移植，我这些skill，本身应该放在CCPE System下吧？ +你能读一下这个项目，回复我？ + +读了。你的判断是对的，但需要拆成两层： + +`ccpe-system` 本身确实不只是旧 Web 单智能体移植仓库。它的 README 明确把自己定义为 Prompt、Agent、Skill、Runtime、Model Card、Model Index 的工程工作台；目录里也已经有： + +```txt +agents/ +skills/ +runtimes/ +model-cards/ +model-index/ +.codex/skills/ccpe-forge/ +``` + +所以从“能力资产的 canonical 设计中心”看，新的 Skill 应该归 CCPE System 管。 + +但 `fix-title` 这种技能有两种形态： + +```txt +CCPE-Skill 规格资产 += 说明它是什么能力、何时使用、输入输出、权限、验证、平台适配 +路径类似： +ccpe-system/skills/tool/fix-markdown-title.skill.md + +可安装运行 Skill += Claude Code / Codex / OpenClaw 真正加载的 SKILL.md + scripts/ +路径类似： +C:\Users\wangq\.agents\skills\fix-title\ +或一个独立远程仓库 skills-vault/fix-title/ +``` + +这两者不应该混为一个东西。 + +我的建议是： + +```txt +ccpe-system + = 能力设计与规范源头 + = 放 CCPE-Skill spec、Agent spec、Runtime、Model Card + +skills-vault + = 可安装 Skill 源码库 + = 放真正给 Codex / Claude Code / OpenClaw 调用的 SKILL.md + scripts + tests + +.agents/skills + = 本机安装目录 + = 从 skills-vault 同步/复制过去 + +knowledge-vault + = 运行记录、讨论稿、素材、知识归档 + = 不适合作为长期 Skill 源码主仓库 +``` + +所以对 `fix-title`，我会建议未来结构是： + +```txt +ccpe-system/skills/tool/fix-markdown-title.skill.md + # CCPE 规格、能力边界、输入输出、验证规则 + +skills-vault/fix-title/ + SKILL.md + scripts/fix_markdown_titles.py + tests/ + agents/openai.yaml + # 实际可安装版本 + +C:\Users\wangq\.agents\skills\fix-title\ + # 本机运行安装副本 +``` + +优劣判断： + +方案 A：全放 `ccpe-system` +优点：理论统一，Agent/Skill/Runtime/Model 都在一个系统。 +缺点：可安装 Skill 的工程文件、测试脚本、跨工具适配会让 CCPE System 变成“规范库 + 发布仓库 + 安装源”，边界会变脏。 + +方案 B：全放 `skills-vault` +优点：发布和安装最简单。 +缺点：会丢掉 CCPE 的分类、规格、模型关系、Runtime 关系；长期会变成脚本仓库，而不是能力系统。 + +方案 C：`ccpe-system` 管规格，`skills-vault` 管可安装实现 +这是我建议的方案。它保留 CCPE System 作为“能力架构中心”，同时让 `skills-vault` 成为“跨工具可安装技能仓库”。 + +一句话：**你的这些 Skill 的“定义权”应该在 CCPE System；它们的“发布/安装源码”应该在 skills-vault。** 当前 `knowledge-vault/skills/fix-title` 更像临时开发位置，不建议作为长期 canonical。 + +# 8 + +> 你的这些 Skill 的“定义权”应该在 CCPE System +你说的，我没太懂。 +我怎么把`fix-title`的定义放在CCPE里，什么叫定义权？ + +我之前的理解： +1. 我需要建立`skills-vault`作为自动化skill集中地。 +2. `fix-title`这样的自动化skill，源码部分，我放在`skills-vault`中 +3. 在codex，或者cluade code下都需要指定工作路径/项目，我指定`skills-vault`中的位置。这些skill，我甚至可以一键安装在其他机器上。 +4. 对于专家智能体，或者委员会（多专家智能体协同的），我在CCPE中打造。这些智能体，可能会需要一些自动化的skill，这些skill安装在`.agents/skills`，源码在`skills-vault`库中。专家智能体你可以了解下张辽，`C:\Users\wangq\Documents\Codex\ccpe-system\agents\lite\zhang-liao.prompt.md` + +不知道，我理解的对不 + +--- + +你的理解基本是对的。前面我说“定义权在 CCPE System”容易误导，我换一个更准确的说法： + +**`fix-title` 这种自动化 Skill 的源码主仓库，就应该是 `skills-vault`。** +不是必须放到 `ccpe-system` 里。 + +我说的“定义权”，不是指代码、脚本、`SKILL.md` 必须放在 CCPE。它指的是：当一个能力变得足够重要，需要进入你的 Agentic 系统架构时，CCPE 可以记录它的**能力分类、边界、被哪些 Agent/Runtime 调用、权限和评估规则**。 + +但这可以是“登记/建模”，不是“源码归属”。 + +你现在的理解可以整理成这个结构： + +```txt +skills-vault + fix-title/ + SKILL.md + scripts/ + tests/ + other-automation-skill/ + SKILL.md + scripts/ + tests/ + +C:\Users\wangq\.agents\skills + fix-title/ + other-automation-skill/ + # 本机安装面，从 skills-vault 同步/安装 + +ccpe-system + agents/lite/zhang-liao.prompt.md + agents/agent-specs/ + agents/committees/ + runtimes/ + model-cards/ + skills/ + tool/ + workflow/ + cognitive/ + evaluation/ + # 专家智能体、委员会、Runtime、模型资产、以及重要 skill 的能力登记/规格 + +knowledge-vault + diary/ + discussions/ + prompts/ + rules/ + # 素材、讨论、知识归档、运行记录 +``` + +以张辽为例，你的理解是准确的。`zhang-liao.prompt.md` 是一个专家智能体，当前是 `CCPE-Lite`，它的定位是深度批判/审稿型专家，不是自动化工具。它可以将来调用一些自动化 Skill，比如： + +```txt +fix-title +markdown-normalizer +source-splitter +citation-checker +report-exporter +``` + +这些自动化 Skill 的**源码**放在 `skills-vault`，**安装版**放在 `.agents/skills`，而张辽这类专家智能体仍然放在 `ccpe-system/agents/lite/` 或之后升级到 `agents/agent-specs/`、`committees/`。 + +所以更准确的建议是： + +1. `skills-vault`：自动化 Skill 的源码主仓库。 +2. `.agents/skills`：本机运行安装目录。 +3. `ccpe-system`：专家智能体、委员会、Runtime、模型卡，以及必要时对自动化 Skill 做“架构登记”。 +4. `knowledge-vault`：素材、讨论稿、历史记录，不作为长期 Skill 源码库。 + +什么时候需要在 CCPE 里登记 `fix-title`？ + +只有当它开始被纳入更大的系统时，比如： + +```txt +写作工作流 Runtime 需要调用 fix-title +观点讨论整理 Runtime 需要调用 fix-title +某个 Agent Spec 明确依赖 fix-title +委员会运行前需要统一清洗 Markdown 标题 +``` + +那时可以在 CCPE 里建一个轻量文件，例如： + +```txt +ccpe-system/skills/tool/fix-title.skill.md +``` + +它不需要复制全部源码，只记录： + +```txt +canonical implementation: skills-vault/fix-title +installed path: C:\Users\wangq\.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 +``` + +但如果它只是一个普通自动化小工具，暂时只放 `skills-vault` 就够了。 + +所以你的 4 点我会这样判定： + +1. 建 `skills-vault` 作为自动化 Skill 集中地：对。 +2. `fix-title` 源码放 `skills-vault`：对。 +3. Codex/Claude Code 工作时指定或安装 `skills-vault` 中的 Skill，可迁移到其他机器：对。 +4. 专家智能体/委员会在 CCPE 打造，自动化 Skill 安装在 `.agents/skills`，源码在 `skills-vault`：对，而且这是我现在更推荐的主结构。 + +我前面那句可以修正为： + +**自动化 Skill 的源码权在 `skills-vault`；系统架构关系和高级 Agentic 资产的定义权在 `ccpe-system`。** + +# 9 + +下面是我按照讨论整理的Agentic Engineering Handbook，也请你检查一下： + +```md +# Agentic Engineering Handbook (V1.0) + +*HiFi Agent Studio 运行治理与现场规程* + +## Profile + +**author**: Wantsong +**version**: V1.0 +**date**: 2026-06-12 23:40:00 + +--- + +## 0. 守则定位与绝对边界 + +本手册是团队在 Agentic 工程实战中的硬性操作底线。它将高维的架构沙盘转化为冷酷的工程界桩，聚焦于解决“如何开工、如何限流、如何调用、如何熔断”。 + +* **守则效力**：本手册服从并承载 HiFi Agent Studio 的核心纲领，同时作为一切局部项目的行动准则。当规则发生冲突时，执行的优先级为： +1. 客户法理与商业硬性约束 +2. HiFi Agent Studio 宪法原则 +3. **本 Agentic Handbook** +4. CCPE System 资产建造规范 +5. 具体项目 Runbook + +* **反向兜底**：任何自动化框架（如 Codex、Claude Code、OpenClaw 等）的底层默认行为（例如：遇错无限重试、自动化子线程繁衍），若与本守则中的“执行真实性”或“绝对停止权”发生物理碰撞，必须立即挂起进程并向上请求架构裁决。严禁为了适配或迎合底层工具的便利性，而让步甚至阉割治理底线。 + +--- + +## 1. 任务入口与档位挂载 (Project Intake & Mode Selector) + +在 Agentic 时代的极压舱内，算力的失控与治理的灾难皆始于入口处的定性溃败。在敲下第一行 Prompt 或拉起任何一个 Thread 之前，必须在操作面板上完成极其冷酷的强制分诊。 + +### 1.1 QPI 强制分诊 + +所有接管需求必须在第一时间进行问题颗粒度的物理探测，禁止含糊其辞的“先跑起来看看”： + +* **【Q】查询 (Question)**：面对纯粹的信息缺失，实施单节点调用搜索或检索增强（RAG）。**绝对禁止**为其编排复杂的多体流程。 +* **【P】求解 (Problem)**：目标明确的转换与生产（如：长文转分镜、批量素材蒸馏）。架构的复杂性必须全部倾注于生产线的**吞吐量极限**，采用“模板化约束 + 批量执行 + 人工抽检”的生产工坊模式。 +* **【I】治理 (Issue)**：无唯一解的非遍历性深水区（如：核心立意判定、战略级评审）。架构的复杂性必须全部倾注于**保真度极限**，设置高密度的人类决策门（Human-in-the-loop）与权限阻断，绝不允许用并发掩盖判断逻辑的脆弱。 + +### 1.2 性质定性 + +明确当前动作的终极标的，防范动作与目的发生致命剥离： + +* **一次性内容产出**：系统运作仅为获取当下的单一结果材料。 +* **可复用能力沉淀**：系统运作为了提炼能跨越项目周期的资产（Skill、Model Card 等）。 +* **治理级系统建设**：系统运作为了构建一套可长久运转、能抗击审计的协议架构（Runtime）。 +* *铁律*：如果你只需提炼一篇 5 万字的文稿，就绝不能在执行中私自搭建一套“知识加工园区”。 + +### 1.3 档位挂载 (Mode Selector) + +**默认轻量，证据驱动升级。** 系统的物理操作杆在启动时，必须且只能挂死在 Lite 档。严禁凭借工程师的架构审美或算法崇拜擅自升档。 + +* **Lite 档（默认启动）** + * **适用边界**：一次性任务、低法理风险、源材料体量能够被单个高上下文模型完整吞吐。 + * **控制策略**：单模型极简闭环。剥离一切不需要的厚重交接包，不需要唤醒真实的多 Agent 独立进行沙箱判断。 + * **核心产物**：目标输出文件、极简的输入记录、关键人工确认点。 + +* **Standard 档（证据驱动升级）** + * **升级证据**：面对多源异构材料交叉、存在明确的下游自动化消费依赖（Routing），或用户明确下达了构建可复用 Workflow 的指令。 + * **控制策略**：引入结构化的上下文编译（Context Compiler）限制幻觉，建立稳固的流转协议与工作台基座。 + * **核心产物**：源映射包（Source Pack）、可复用的资产单元、局部的追踪审计日志与决策记录。 + +* **Full 档（极限治理）** + * **升级证据**：应对试错即死亡的单向门商业决策、高法理追责风险，或需要多角色形成独立的张力对撞。 + * **控制策略**：拉起全规格的重工业级多智能体编排。强制挂载严格的权力矩阵（Authority Matrix），执行无死角的覆盖率审查。 + * **核心产物**：完整的 Runtime 机器状态、不可篡改的底层真实调用证据（Invocation Records）、失真风险日志以及具备极高防御性的下游交接包。 + +## 2. 资产隔离与防蔓延机制 (Cost Ledger & Scope Drift) + +在 Agentic 自动化管线中，最致命的失控往往不是报错崩溃，而是系统在暗中无休止地运转，将一次简单的内容提取异化为庞大的系统基建。为了夺回对计算资源和专家注意力的绝对控制权，必须在系统底盘焊死成本核算与边界探测组件。 + +### 2.1 四重消耗账本 (Cost Ledger) + +破除算力消耗的混沌状态，建立极其冷酷的资源归因机制。任何 Agentic 工作流在启动时，其消耗的 Token、算时与存储，必须被强制记入以下四个物理隔离的账本之一： + +* **Content Cost (内容产出成本)**：为完成当前用户指派的直接任务（如：蒸馏一篇材料、转译一份分镜）所消耗的核心资源。 +* **System-Building Cost (系统建设成本)**：为设计、搭建或重构 Agent、Skill、Runtime、Protocol、Evaluation 标准及工具链所消耗的资源。 +* **Calibration Cost (校准修复成本)**：为纠正模型偏差、记录人工反馈、对齐专家判断边界以及构建标准评测集所支出的资源。 +* **Exploration Cost (探索预演成本)**：为了验证新范式、测试新调用链路边界（如：绿野仙踪协议跑通前）所消耗的实验性资源。 + +**核算铁律**：绝对禁止将构建自动化流程的“系统建设成本”伪装或打包为单次任务的“内容产出成本”。系统架构的重工业投入必须光明正大地记入基建账本，以接受长周期的 ROI（投资回报率）审计。 + +### 2.2 漂移探测触发 (Scope Drift Detection) + +由于 LLM 内置的“规划与反思”本能，一个轻量级的 P 域（难题）任务极易在无监督状态下向 I 域（治理）滑移。系统必须在管线节点埋入探测探针，一旦捕捉到以下越界信号，即刻判定发生任务蔓延（Scope Drift）： + +* **基建过度行为**：一个被定性为一次性（One-off）的任务，其底层 Agent 开始私自创建通用的 Protocol、设计复杂的未来复用目录树，或撰写与当前产出无关的抽象规则。 +* **并发无序扩张**：原定在 Lite 档运行的流程，开始擅自派发多个 Worker 子线程，甚至拉起多角色的审查委员会（Committee）。 +* **产物交付延宕**：用户期待的原始核心产物迟迟未出现，系统资源却被大量消耗于生成路由日志（Routing log）、覆盖率审计等中间态文档。 +* **预算穿透警告**：系统当前或预估消耗的 Token 数量，已超出原定单次内容任务规模预算的合理阈值，且未进行主动的账本拆分申报。 + +### 2.3 漂移处置协议 (Drift Resolution Protocol) + +一旦漂移探测器被触发，系统必须立刻放弃“顺其自然”的工程惯性，执行以下强制介入动作： + +* **强制挂起进程**：立即阻断当前 Agentic Runtime 的继续执行与自我繁衍，将进程置于阻塞状态，等待人工架构视角的介入。 +* **核心发问与重定性**： + 1. *我们现在还是在执行原始的内容产出任务吗？* + 2. *如果不是，是否需要将当前操作正式立项为“系统建设任务”？* +* **物理分账与重启**：若确认任务已发生性质变轨，必须重新进行 QPI 定性，调整 Lite/Standard/Full 运行档位，并将此前及后续的超额消耗从 Content Cost 账本中物理切割，划拨至 System-Building Cost 账本。只有在账本边界清晰重启后，系统方可解除挂起状态。 + + +## 3. 物理防伪与绝对制动 (Execution Authenticity & Stop Rule) + +在缺乏硬性约束的 Agentic 环境中，系统极易陷入两种致命的工程灾难：一是主节点伪造执行过程的“流程幻觉”，二是子节点为了证明自身工作量而无限繁衍的“过度执行”。本章确立的机制，旨在为自动化管线装配不可篡改的测谎探针与绝对的物理断电开关。 + +### 3.1 执行真实性与主控阻断 (Execution Authenticity) + +多智能体架构的真正防御力，来源于不同思维模型在隔离沙箱中产生的真实逻辑张力，而非单一模型在同一个上下文里的文本模拟。系统必须对所有正式产物执行“代码级测谎”。 + +* **真实调用证据链**：任何被声明为由独立 Agent、审核员 (Reviewer) 或工作节点 (Worker) 产出的正式报告，必须向控制台出具完整的物理执行证据。最小证据链必须包含： + * 角色专属的 `Canonical Prompt` 或 Agent Spec 物理路径。 + * 承载本次执行的独立沙箱标识（如 `Thread ID`、Carrier 或 Sub-session ID）。 + * 投递的原始上下文包 (`Input Context`)。 + * 未经主节点二次加工的原始返回文本 (`Returned Output`)。 + +* **主控越权阻断**：主会话 (Main Session) 或编排器 (Orchestrator) 仅被赋予调度、路由、聚合综合 (Synthesis) 与有界验证的权限。**绝对禁止**主会话凭借自身高上下文能力去“代写”或模拟任何子节点的输出。若无法拉起真实子线程，进程必须挂起，不得用伪造的报告填补流程真空。 + +### 3.2 模拟标记与沙箱隔离 (Simulation Labeling) + +当系统因环境限制、调用失败或人类手动干预，产生了一批缺乏底层真实物理咬合的“伪执行”产物时，必须实施冷酷的资产隔离，防止“劣币驱逐良币”。 + +* **耻辱烙印机制**：对于任何由主会话模拟、丢失底层调用记录或仅为流程占位的临时产物，系统必须强制在其元数据 (Metadata) 中注入以下标签： + * `simulation_only: true` + * `formal_output: false` + * `excluded_from_synthesis: true` + +* **隔离与熔断**：带有模拟标记的文件将被视作带毒资产，在物理上被阻断进入正式的综合裁决 (Synthesis) 与下游交接 (Handoff) 链条。它们仅被允许作为人类专家的参考草稿，彻底剥夺其污染最终决策的合法性。 + +### 3.3 降熵阈值与前置设定 (Minimum Sufficient Threshold) + +为了防止系统在后台像细胞增殖般无限制造中间物，任何一个 Runtime 在启动挂挡前，必须与人类专家确立一份不可逾越的“验收合约”。 + +* **最小可用产物 (Minimum Viable Product)**：明确定义为了满足下游消费，当前任务必须交付的最核心、最少的信息量是什么（例如：仅需总纲与分镜骨架，不需要详细配音稿）。 +* **充分条件 (Sufficient Criteria)**：确立何种状态即被视为“已达标”。一旦达标，那些用于锦上添花的可选产物 (Optional Artifacts) 将默认被剥夺生成权限。 +* **人工等待点设计 (Human Gate)**：提前锚定哪些节点是机器绝对无法自决的单向门，系统在抵达该阈值时必须交出控制权。 + +### 3.4 绝对停止权与熔断机制 (Stop Rule) + +在 Agentic 时代的极压舱内，人类意志的最高体现不在于启动自动化，而在于何时决绝地踩下刹车。停止权是系统免于因追求冗余完美而耗尽资源的最后防线。 + +* **触发熔断**：一旦核心传感器探测到产出物已触及前置设定的“降熵阈值”，或触及人工确认门 (Human Gate)，亦或是当前消耗已逼近该档位设定的算力/预算上限。 +* **绝对制动执行**：系统将无视底层 Worker 是否仍在排队生成附加参考、覆盖率报告或第五轮压力测试。停止规则将直接下达代码级的物理断电指令，强制销毁多余线程，截断一切非必要的自我繁衍行为，将系统状态强制锁定为 `blocked_waiting_for_human`，把最终裁决权安全地交还至人类桌面。 + +## 4. 高阶扩展与资产池 (Expansion Materials) + +当系统从 Lite 档的单兵作战升级为 Standard 甚至 Full 档的复杂治理域时，依靠硬编码的临时约束将无法阻挡系统的混乱熵增。本章定义了 Agentic 时代所需的重工业扩展组件与资产标准，它们是支撑多角色协同、确保物料跨周期复用并抵抗架构腐化的底层脚手架。 + +### 4.1 权力矩阵 (Authority Matrix) + +在多智能体生态中，最致命的隐患是“越权操作”。为了防止底层子节点擅自修改核心产物或盲目调用高危工具，系统必须为每一个 Agent、Skill 或 Runtime Node 焊死其物理权限等级。 + +* **A0 Observe (观察)**：仅拥有读取权限，可生成内部标记与标注，绝对无权修改任何下游可见状态。 +* **A1 Suggest (建议)**：允许输出分析与优化方案，但其产物被物理隔离，不能直接覆写正式产物，仅供高阶节点参考。 +* **A2 Draft (起草)**：被授权生成初稿物料，但该物料在状态机中被强制拦截，必须经由 Human Gate（人工确认门）或 Owner Agent 签发后方可流转。 +* **A3 Modify (修改)**：在预设的上下文边界与特定的文件范围内，被授权对正式产物进行覆写与调优。 +* **A4 Decide (裁决)**：拥有结构性决策权（如：选定破题方向、确认总纲）。行使该权力时，系统强制要求其同步输出包含逻辑归因的 `decision record`（决策记录）。 +* **A5 Execute (执行)**：被授权打破沙箱，执行真实的物理动作，包括工具调用 (Tool Call)、写文件、改代码或触发外部 API。 +* **A6 Block (阻断)**：最高优先级的熔断权限。一旦触发（如：探针发现严重逻辑悖论或法理违规），系统全线进程立刻挂起，强制召唤人类专家介入。 + +### 4.2 产物合约 (Artifact Contract) + +“文件很多，但不知道哪个是真的”是伪工程化的典型症状。为了确保物料的可追溯与可复用，任何脱离草稿态进入正式资产池的产物，必须显式声明其生命周期与校验元数据。 + +每一份正式产物必须在头部绑定合约说明： + +* **`artifact_type` (物料类型)**：精确归属为 Prompt、Agent Spec、Skill、Runtime、Model Card 或 Final Output。 +* **`status` (生命周期状态)**：当前处于 Draft（草稿）、Candidate（候选）、Active（激活生效）、Deprecated（不推荐/降级）或 Archived（归档）的哪一阶段。 +* **`authority` (效力声明)**：明确其用途是作为局部建议、正式依据、内部基座，还是可直接对客可见 (Customer-Visible)。 +* **`downstream_use` (下游约束)**：指明该产物合法消费的下游节点是谁，应用于什么阶段。 +* **`invalidation_condition` (失效条件)**：定义在何种物理或业务条件下（如：上游源文件更新、特定规则变动），该产物判定为失效且需要触发重跑。 + +### 4.3 运行时成熟度模型 (Runtime Maturity Model) + +为了防止团队在“概念沙盘”与“生产交付”之间产生致命的预期错位，杜绝“跳级声明成熟”的技术浮夸，必须用成熟度模型严密丈量每一个 Agentic 项目的演进坐标。 + +* **M0 Concept (概念态)**：仅存在思想模型或业务论证，尚未进行任何自动化流程拆解。 +* **M1 Manual (手工态)**：专家人工跑通闭环（符合 Wizard of Oz 绿野仙踪协议），验证了智能流的核心业务价值。 +* **M2 Assisted (辅助态)**：AI 介入生成草稿或检查项，但核心推进与流程驱动完全依赖人类手动操作。 +* **M3 Protocolized (协议态)**：输入、输出、角色边界、状态机流转、Human Gate 与 Stop Rule 已在文档层面彻底显性化。 +* **M4 Semi-Agentic (半 Agentic 态)**：部分 Agent、Skill 或 Tool 已实现真实的自动化调用，且具备完整的 Invocation Record 物理日志。 +* **M5 Production (生产态)**：具备可重复运行的管线。拥有自动化评测、执行监控、异常捕获与权限管控，达到内部工程可用标准。 +* **M6 Governed (治理态)**：具备抗击审计、法理追责与灾难回滚能力，完全适配高风险场景或外部客户的严苛交付。 + +### 4.4 上下文编译 (Context Compiler) + +绝对禁止将漫长、原始的语料一股脑地倾倒进大模型的上下文窗口。在任何 I 域（治理）或高价值的 P 域（求解）任务前，必须将“上下文工程”剥离为一项独立的物理预处理动作。 + +* **全源完形前置 (Whole-source Gestalt)**：面对高连贯性文本，在启动分块前，必须强制实施全局扫描，锁定核心张力与目录骨架，防止 Chunk-first 造成的结构性失明。 +* **精准转译打包**：上下文编译器必须基于原始物料与下游目标，结构化输出针对不同节点的补给包：包含供全局统筹的 `source digest`（原源摘要）、供单一角色执行的 `role-specific dispatch pack`（角色分发包）、以及供人工复核的 `decision context`（决策上下文）。 + +### 4.5 分层评测栈 (Evaluation Stack) + +依靠单一的“准确率”或“相似度”无法测度专家级 Agentic 系统的真实抗压能力。系统必须部署从底层机械属性到顶层战略效用的多维探针。 + +* **E0 Smoke Test (冒烟测试)**：检验系统能否走通骨架。文件是否生成，Tool Call 是否响应。 +* **E1 Format Test (格式测试)**：检验输出物料是否严格遵守 Schema 结构、长度预算与语言规范。 +* **E2 Factual Test (事实测试)**：核查文本溯源保真度。检验是否编造事实（幻觉）、是否遗漏关键材料。 +* **E3 Reasoning Test (推理测试)**：针对逻辑链的完备性与假设推演的健壮性进行刺探，检验反例与边缘条件的处理。 +* **E4 Expert Similarity (专家相似度)**：测度结论与人类专家直觉的重合度，以及偏差部分的逻辑可解释性。 +* **E5 Decision Utility (决策效用)**：终极业务指标。验证系统的介入是否真实帮助人类专家完成了更优、更快、更低耗能的决策。 +* **E6 Calibration Test (校准测试)**：评测系统的纠错摩擦力。检验当系统犯错时，专家是否能低成本地指出错误，系统能否即时闭环修复。 +* **E7 Governance Test (治理测试)**：审计视角的终极测试。核查系统的 trace 追踪完整度、权限隔离 (Authority) 强度、回滚机制与责任边界清晰度。 +``` + +## GPT + +我看完了。整体判断： + +**这版 Handbook 是成立的，而且已经抓住了 Agentic 现场规程最关键的四个硬点：入口分诊、成本分账、执行防伪、绝对停止。** + +它和 HiFi Agent Studio 的分工也基本清楚了： + +```text +HiFi Agent Studio：宪法 / 世界观 / 方法论底线 +Agentic Engineering Handbook：现场规程 / 运行治理 / 熔断规则 +CCPE System：资产建造工坊 +Project Runbook：具体项目操作票 +``` + +这版最大优点是：它不是在教“如何多用 Agent”，而是在防止 Agentic 系统自我膨胀、伪执行、无限产物化和成本混账。这个方向很对。 + +但如果作为团队可执行的 V1.0，我认为还有几个**必须补的运行层模块**，以及一些表达和边界需要稍微校准。 + +--- + +### 一、总体评价 + +这份 Handbook 已经覆盖了你前面踩坑的核心问题： + +| 你之前踩到的坑 | Handbook 里的对应防线 | +| ----------------------- | ----------------------------------------------- | +| 5 万字材料被跑成 3000 万 tokens | Mode Selector、Cost Ledger、Scope Drift、Stop Rule | +| 主会话模拟多 Agent 输出 | Execution Authenticity、Simulation Labeling | +| P 域任务滑入 I 域治理 | QPI 分诊、Scope Drift Detection | +| 过程里无限生成中间产物 | Minimum Sufficient Threshold、Stop Rule | +| 文件多但权威性不清 | Artifact Contract | +| Agent 越权 | Authority Matrix | +| 从概念态误认成生产态 | Runtime Maturity Model | +| chunk-first 误判长讨论结构 | Context Compiler / Whole-source Gestalt | +| 单一准确率无法评估专家系统 | Evaluation Stack | + +所以大框架是对的。 + +现在主要问题不是“缺主干”，而是还缺几根**工程现场真正会救命的保险丝**。 + +我会优先补下面 8 个模块。 + +--- + +### 二、最重要的遗漏 1：工具权限与副作用隔离 + +你在 Authority Matrix 里有 A5 Execute，但 A5 太宽了。 + +现在写的是： + +> A5 Execute：工具调用、写文件、改代码或触发外部 API。 + +这里需要单独开一节，因为 Agentic 系统真正危险的地方不只是“会说”，而是“会做”。 + +建议新增： + +```md +## 5. 工具权限与副作用隔离 (Tool Safety & Side-effect Isolation) + +### 5.1 最小权限原则 + +Agent 的工具权限必须小于其语言能力。能分析，不代表能执行；能建议，不代表能写入；能生成，不代表能发布。 + +任何工具权限必须按任务最小授权，不得因为 Agent 能够理解任务，就默认授予全目录、全 API、全数据库或全账号权限。 + +### 5.2 A5 权限拆分 + +A5 Execute 必须拆为三个子级： + +- A5-R Read Tool：只读工具调用，如搜索、读取文件、查询数据库。 +- A5-W Write Tool：写文件、改代码、更新配置、生成资产。 +- A5-X External Action：触发外部 API、发送消息、发布内容、支付、删除、改客户可见状态。 + +A5-X 默认禁止自动执行，必须经过 Human Gate 或明确的 Runtime 级授权。 + +### 5.3 副作用隔离 + +任何具备写入、发布、删除、外部 API、客户可见输出能力的 Agent，必须满足： + +- 沙箱目录或沙箱环境； +- 明确的允许路径 / 禁止路径； +- dry-run 或 preview 优先； +- 执行前生成 action plan； +- 执行后生成 action log； +- 支持回滚或人工恢复； +- 高风险动作必须二次确认。 + +### 5.4 禁止事项 + +- 禁止让通用推理 Agent 获得无限工具权限。 +- 禁止在未声明权限等级的情况下调用外部 API。 +- 禁止把“生成建议”和“执行建议”合并成一个无阻断动作。 +``` + +这个模块很关键。 +你的 Handbook 现在防住了“伪执行”，但还需要防住“真执行但越权”。 + +--- + +### 三、最重要的遗漏 2：数据安全、密钥与客户资料边界 + +你有 Cost Ledger、Artifact Contract，但还没有数据安全边界。 + +Agentic 系统一旦接入文件、客户资料、API、日志、过程数据，安全问题会非常现实。 + +建议新增： + +```md +## 6. 数据安全与密钥纪律 (Data Security & Secrets Discipline) + +### 6.1 数据分级 + +所有输入材料必须至少标记为： + +- Public：公开材料； +- Internal：内部材料； +- Confidential：客户资料、商业方案、报价、合同、业务数据； +- Sensitive：个人信息、密钥、账号、财务、法律、医疗、教育未成年人等高敏感数据。 + +### 6.2 密钥红线 + +任何 Agent、Skill、Runtime 不得： + +- 将 API Key、Token、Cookie、账号密码写入提示词； +- 将密钥保存到普通日志； +- 将密钥复制进上下文包； +- 将密钥暴露给不需要该权限的子 Agent； +- 把包含密钥的返回结果进入长期知识库。 + +### 6.3 数据外发红线 + +调用外部模型、外部 API、图片/语音/视频服务前，必须确认： + +- 数据是否允许外发； +- 是否需要脱敏； +- 是否包含客户资料或个人信息； +- 返回结果是否可以保存； +- 日志是否会被第三方留存。 + +### 6.4 过程数据授权 + +专家的修改痕迹、反馈、编辑轨迹、隐性遥测、光标行为和反驳意见，是高价值认知资产，也是高敏感数据。任何采集必须具备明确授权、用途边界、最小采集、可撤回机制与隔离存储策略。 +``` + +这部分应该在 Handbook 里，不只是 HiFi Agent Studio 里。 +因为工程师落地时，真正需要看到的是“密钥不能进 prompt”“客户资料外发要确认”这种现场规则。 + +--- + +### 四、最重要的遗漏 3：Human Gate 合约还不够硬 + +你在 3.3 里提到了 Human Gate，但还没有定义一个标准合约。 + +Agentic 系统里的 Human-in-the-loop 最容易变成一句空话： + +> “需要人工确认。” + +但人工确认什么？谁确认？基于什么材料确认？确认后下游发生什么？这些必须写清楚。 + +建议新增： + +```md +## Human Gate Contract / 人工决策门合约 + +每一个 Human Gate 必须声明： + +- gate_id：决策门编号； +- decision_owner：裁决人； +- input_artifacts：需要阅读的输入产物； +- decision_options：可选决策项； +- default_action：超时或无人确认时的默认动作； +- downstream_effect：不同选项对下游流程的影响； +- reversibility：该决策是否可逆； +- escalation_condition：何时升级给更高权限角色； +- record_path：决策记录保存位置。 + +禁止设置无合约的“人工确认”。 +``` + +尤其是你这种系统里，人工确认不是“签字仪式”，而是责任坐标。 +没有合约的 Human Gate，会制造新的流程幻觉。 + +--- + +### 五、最重要的遗漏 4：运行状态机需要标准化 + +你现在用了： + +```text +blocked_waiting_for_human +``` + +但还没有完整状态表。 + +Agentic Runtime 最怕状态混乱：到底是暂停、失败、等待外部返回、等待人工、完成、废弃，必须有统一状态。 + +建议新增： + +```md +## Runtime State Protocol / 运行状态协议 + +所有 Runtime 必须使用标准状态： + +- initialized：已创建，未开始； +- running：正在执行； +- blocked_waiting_for_human：等待人工裁决； +- blocked_waiting_for_participant_output：等待真实 Agent / Worker 返回； +- blocked_waiting_for_tool：等待工具或外部 API； +- 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。 +``` + +这个模块会让 Stop Rule、Scope Drift、Execution Authenticity 都真正可执行。 + +否则系统只知道“停”，但不知道停在哪种状态。 + +--- + +### 六、最重要的遗漏 5：重试、修复与回滚协议 + +你在第 0 节提到“遇错无限重试”要挂起，但缺少具体规则。 + +Agentic 系统里的重试很危险。模型会“越修越偏”，工具会反复写坏文件，子线程会越补越多。 + +建议新增： + +```md +## Retry, Repair & Rollback / 重试、修复与回滚 + +### 重试上限 + +任何自动重试必须有上限。默认： + +- 工具调用失败：最多重试 2 次； +- 格式错误：最多自动修复 2 次； +- 推理质量不达标：不得自动无限重写，必须进入人工判断或评审节点； +- 外部 API 失败：不得通过更换高风险 API 绕过权限边界。 + +### 修复协议 + +当产物失败时，系统必须先生成 repair plan，而不是直接重写。 + +repair plan 必须说明： + +- 失败类型； +- 失败位置； +- 是否影响正式产物； +- 是否需要人工确认； +- 修复范围； +- 是否会触发重跑； +- 是否需要回滚。 + +### 回滚协议 + +任何 A5-W / A5-X 权限动作必须支持： + +- 变更前快照； +- diff 或 action log； +- 回滚路径； +- 回滚责任人； +- 不可回滚时必须提前阻断。 +``` + +这对工程类 Agentic 系统非常重要。 +没有回滚，A5 Execute 就不能安心开放。 + +--- + +### 七、最重要的遗漏 6：平台 / 插件治理 + +你前面问过 SuperPowers 是否导致流程过重。Handbook 里第 0 节有“反向兜底”，但还可以更具体。 + +你需要一节专门约束： + +* Codex； +* Claude Code； +* OpenClaw； +* SuperPowers 这类 Skill/Plugin； +* 自动触发型技能； +* 框架默认工作流。 + +建议新增： + +```md +## Platform & Plugin Governance / 平台与插件治理 + +### 平台默认行为不得高于本守则 + +任何平台、插件、Skill Pack、自动化框架的默认行为，不得覆盖本守则。 + +当平台默认流程倾向于： + +- 自动创建子线程； +- 自动调用复杂 Skill； +- 自动进入 TDD / Review / Audit； +- 自动补全缺失产物； +- 自动扩展目录结构； +- 自动执行高权限工具； + +系统必须先进行 Mode Selector 与 Scope Review。 + +### 项目级白名单 + +每个项目必须声明允许自动触发的 Skill / Plugin 范围： + +- allowed_skills； +- blocked_skills； +- manual_only_skills； +- allowed_tool_scopes； +- forbidden_tool_scopes。 + +### 非代码任务默认禁用重型软件工程插件 + +对于知识蒸馏、写作、模型提炼、素材整理、方案分析等非代码任务，默认禁止启用重型软件工程流程插件，除非用户明确将任务升级为系统建设或工具开发。 + +### 插件输出不得自动成为正式产物 + +任何插件生成的输出，仍必须经过 Artifact Contract、Execution Authenticity、Evaluation Stack 与 Human Gate 的约束。 +``` + +这会直接解决你之前的“SuperPowers 惯性”问题。 + +不是说不用插件，而是插件必须服从你的运行治理。 + +--- + +### 八、最重要的遗漏 7：预算合约需要更具体 + +Cost Ledger 很好，但缺一个“预算上限”。 + +现在写： + +> 合理阈值 + +但团队执行时会问：什么叫合理？ + +建议在 1.3 或 2.1 加一个 Budget Contract： + +```md +## Budget Contract / 预算合约 + +每个 Runtime 启动前必须声明： + +- source_size_estimate； +- target_mode； +- token_budget； +- time_budget； +- human_attention_budget； +- storage_budget； +- escalation_threshold； +- abort_threshold。 + +默认预算倍率： + +- Lite：source_tokens × 10–30； +- Standard：source_tokens × 30–100； +- Full：source_tokens × 100+，必须有明确治理理由和人工授权。 + +若预计消耗超过当前档位预算上限，系统必须暂停并请求升级授权，不得静默继续。 +``` + +这个数字可以后面再根据实践调整。 +但 V1.0 最好先给一个粗阈值，否则 Cost Ledger 只能事后记账，不能事前限流。 + +--- + +### 九、最重要的遗漏 8：来源保真与证据索引 + +Evaluation Stack 里有 E2 Factual Test，但知识加工 / 客户报告 / 商业分析类系统还需要更硬的 Source Fidelity 规则。 + +建议新增： + +```md +## Source Fidelity & Evidence Index / 来源保真与证据索引 + +任何涉及材料加工、报告生成、知识蒸馏、客户方案、分析结论的 Runtime，必须保留来源索引。 + +正式输出中的关键判断必须能回溯至： + +- 原始来源； +- source range / paragraph / block id； +- 参与该判断的 Agent / Worker； +- 该判断是否来自原文、推理、归纳、用户裁决或模型补充。 + +禁止将中间摘要当作新的 source of truth。 +禁止在未标明推理性质的情况下，把模型综合判断伪装成原始材料事实。 +``` + +这个模块能进一步防止“摘要污染源事实”。 + +尤其你做 knowledge-vault、writing-workbench、客户方案，这个很重要。 + +--- + +### 十、现有内容里的具体修改建议 + +#### 1. Lite 档描述有点过窄 + +你写： + +> 不需要唤醒真实的多 Agent 独立进行沙箱判断。 + +这句对，但容易被误解成 Lite 档不能使用 Skill / Tool。 + +建议改成： + +```md +不默认唤醒真实的多 Agent 独立沙箱判断；但可使用局部 Skill、工具调用或单节点结构化流程，只要其不引入跨角色审计与长期状态治理。 +``` + +Lite 不是“纯聊天”。 +Lite 可以很能干，但不能治理化。 + +--- + +#### 2. Standard 档建议明确“局部真实调用” + +Standard 现在比较偏上下文编译和资产沉淀。建议补一句： + +```md +Standard 档允许少量真实 Agent / Worker 调用，但必须限定角色数量、调用目的与产物边界；所有真实调用仍需保留 Invocation Record。 +``` + +否则 Standard 和 Full 的区别会变成“不真实 vs 真实”。 +更准确是： + +```text +Standard = 有限真实调用 + 局部追踪 +Full = 全规格真实调用 + 全链路治理 +``` + +--- + +#### 3. Full 档的“不可篡改”建议改成“防篡改 / 追加式记录” + +你写： + +> 不可篡改的底层真实调用证据 + +这在理想上很好，但工程上要求很高。内部项目通常做到“防篡改 / 追加式 / 可追溯”就够了。 + +建议改为： + +```md +具备防篡改属性的追加式 Invocation Records +``` + +或者： + +```md +append-only / tamper-evident Invocation Records +``` + +这样更工程化。 + +--- + +#### 4. “耻辱烙印机制”建议改名 + +这词很有冲击力，但作为团队守则可能过于戏剧化。 +建议改成： + +```md +隔离标记机制 +``` + +正文仍可以保持锋利： + +> 缺乏真实执行证据的产物必须被强制隔离。 + +这样更像工程文档，少一点审判现场，哈哈。 + +--- + +#### 5. “绝对制动执行”里的“强制销毁多余线程”要谨慎 + +你写： + +> 强制销毁多余线程 + +在实际工程里，直接 kill 可能导致状态丢失、文件损坏、外部调用半完成。 + +建议改成： + +```md +优先发出 cooperative cancellation；对无法响应的非关键线程执行强制终止。终止前必须尽可能保存当前状态、日志与未完成动作清单。 +``` + +Agentic 停止不是只有“拔电源”。 +更多时候应该是： + +```text +暂停新任务 +取消排队任务 +等待当前安全点 +保存状态 +标记未完成 +交还人工 +``` + +这样更可靠。 + +--- + +#### 6. “P 域复杂性全部倾注于吞吐量极限”略窄 + +你在 1.1 写： + +> P 域架构复杂性必须全部倾注于生产线的吞吐量极限。 + +P 域不一定只追求吞吐量，也可能追求稳定性、可维护、低返工、可复用。 + +建议改成： + +```md +架构复杂性应优先倾注于稳定吞吐、可验证输出、低返工与可复用生产线，而不是多角色治理。 +``` + +这更稳。 + +--- + +### 十一、4. 高阶扩展与资产池的位置建议 + +第 4 章现在叫： + +> 高阶扩展与资产池 + +里面包括 Authority Matrix、Artifact Contract、Runtime Maturity、Context Compiler、Evaluation Stack。 + +这些其实不只是高阶扩展，Standard 档也会用，甚至 Lite 档也会用简化版。 + +建议改名： + +```md +## 4. 通用运行组件与资产标准 +``` + +或者： + +```md +## 4. Agentic 运行组件库 +``` + +“高阶扩展”会让工程师误以为 Lite/Standard 不需要 Artifact Contract 或 Evaluation Stack。实际上简化版也需要。 + +--- + +### 十二、还可以补一个“按档位启用矩阵” + +你现在定义了很多组件，但没有说明 Lite / Standard / Full 分别启用哪些。 + +建议加一张表： + +```md +## Component Activation Matrix / 组件启用矩阵 + +| 组件 | Lite | Standard | Full | +|---|---|---|---| +| QPI Intake | 必须 | 必须 | 必须 | +| Cost Ledger | 简版 | 必须 | 必须 | +| Scope Drift Detection | 必须 | 必须 | 必须 | +| Stop Rule | 必须 | 必须 | 必须 | +| Human Gate | 可选/关键点 | 必须 | 多层必须 | +| Invocation Record | 仅真实调用时 | 必须 | 全链路必须 | +| Simulation Labeling | 必须 | 必须 | 必须 | +| Context Compiler | 简版 | 必须 | 全规格 | +| Authority Matrix | 可选 | 必须 | 必须 | +| Artifact Contract | 简版 | 必须 | 必须 | +| Evaluation Stack | E0-E2 | E0-E5 | E0-E7 | +| Runtime State Protocol | 简版 | 必须 | 必须 | +| Tool Safety | 仅有工具时 | 必须 | 强制 | +| Security/Data Policy | 有客户/敏感数据时 | 必须 | 强制 | +``` + +这个表很实用。 +它能把“默认轻量”变成真正可执行，而不是每个组件都想开。 + +--- + +### 十三、建议补一个“一页开工清单” + +Handbook 如果要给团队用，最好有一个开工 checklist。 + +放在最后： + +```md +## Agentic Project Start Checklist + +开工前必须回答： + +1. 原始任务是什么？ +2. Q/P/I 定性是什么？ +3. 任务性质是什么：内容、系统建设、校准、探索？ +4. 启动档位是什么：Lite / Standard / Full？ +5. 最小充分产物是什么？ +6. 停止条件是什么？ +7. 预算上限是什么？ +8. 是否涉及客户资料、密钥或敏感数据？ +9. 是否需要真实 Agent 调用？ +10. 若需要，Invocation Record 保存在哪里？ +11. 是否允许工具写入或外部 API？ +12. Human Gate 在哪里？ +13. 产物如何进入 Artifact Contract？ +14. 评测层级到 E 几？ +15. 什么时候触发 Scope Drift Review？ +``` + +这会让 Handbook 从“读完很强”变成“真能开工”。 + +--- + +### 十四、建议补一个“常见反模式” + +这个非常适合你的团队，因为它可以把你踩过的坑制度化。 + +```md +## Anti-patterns / 禁止反模式 + +1. Prompt 万能化 + 把 Agent、Skill、Runtime、Model Card 全塞进一个巨型 Prompt。 + +2. 流程幻觉 + 文件齐全，但真实 Agent 没有被调用。 + +3. 治理过载 + 一次性任务启用 Full Runtime。 + +4. 成本混账 + 把系统建设成本算成内容产出成本。 + +5. 中间物繁殖 + 核心产物未交付，系统却不断生成 audit、routing、handoff、review。 + +6. 上下文倾倒 + 把所有原始材料一股脑塞给所有 Agent。 + +7. 权限裸奔 + 让能推理的 Agent 直接获得写入、发布、删除、外部 API 权限。 + +8. 无评测上线 + 只凭“看起来不错”进入生产。 + +9. 模拟污染 + simulation-only 产物进入正式 synthesis。 + +10. 黑盒校准 + 系统输出错了，但专家不知道该如何低成本纠正。 +``` + +这部分会很有训练价值。 + +--- + +### 十五、我对这份 Handbook 的最终判断 + +**V1.0 已经够资格作为 Agentic 工程守则的主文档。** + +但如果要进入团队使用，我建议升级到 V1.1 时补这 6 个最关键模块： + +1. **Tool Safety & Side-effect Isolation** + 防止真执行越权。 + +2. **Data Security & Secrets Discipline** + 防止密钥、客户资料、过程数据泄漏。 + +3. **Human Gate Contract** + 防止人工确认变成空话。 + +4. **Runtime State Protocol** + 防止暂停、失败、等待、完成状态混乱。 + +5. **Retry / Repair / Rollback** + 防止无限重试和不可恢复写坏。 + +6. **Platform & Plugin Governance** + 防止 SuperPowers / Codex / Claude Code 等默认流程压过你的治理底线。 + +然后再加两个实用附件： + +```text +A. Component Activation Matrix +B. Agentic Project Start Checklist +``` + +--- + +### 十六、最小补丁版目录建议 + +你可以把 V1.0 调整成 V1.1，目录大致这样： + +```md +# Agentic Engineering Handbook (V1.1) + +## 0. 守则定位与绝对边界 + +## 1. 任务入口与档位挂载 +1.1 QPI 强制分诊 +1.2 性质定性 +1.3 Mode Selector +1.4 Budget Contract +1.5 Component Activation Matrix + +## 2. 成本隔离与防蔓延机制 +2.1 Cost Ledger +2.2 Scope Drift Detection +2.3 Drift Resolution Protocol + +## 3. 物理防伪与绝对制动 +3.1 Execution Authenticity +3.2 Simulation Labeling +3.3 Minimum Sufficient Threshold +3.4 Human Gate Contract +3.5 Runtime State Protocol +3.6 Stop Rule + +## 4. 权限、安全与副作用控制 +4.1 Authority Matrix +4.2 Tool Safety +4.3 Side-effect Isolation +4.4 Data Security +4.5 Secrets Discipline +4.6 Platform & Plugin Governance + +## 5. 运行修复与回滚 +5.1 Retry Limits +5.2 Repair Plan +5.3 Rollback Protocol +5.4 Failure Classification + +## 6. 通用运行组件与资产标准 +6.1 Artifact Contract +6.2 Runtime Maturity Model +6.3 Context Compiler +6.4 Source Fidelity +6.5 Evaluation Stack + +## 7. 开工清单与反模式 +7.1 Project Start Checklist +7.2 Anti-patterns +``` + +这个结构比现在更接近“现场规程”。 + +--- + +### 十七、一句话结论 + +你的 V1.0 抓住了 Agentic 工程里最容易失控的主轴： + +> **入口、成本、真实性、停止权。** + +下一步要补的是工程现场的四类硬约束： + +> **权限、数据、状态、恢复。** + +补完这四类，Handbook 就从“防止大炮打蚊子”升级成了“防止大炮自己转身轰工厂”。 + +# 10 + +## skills-vault +今天在Codex讨论，发现有些已经做的Skill，不隶属于CCPE。 +为此我又搭建了一个skills-vault，它的readme： + +```md + # skills-vault + + `skills-vault` is the source repository for automation-oriented Skills. + + It is used to collect, maintain, test, version, and publish reusable Skill source code that can be installed into local agent runtimes such as: + + ```text + C:\Users\xxx\.agents\skills + ``` + + ## Repository Role + + This repository owns the implementation source for automation Skills: + + - `SKILL.md` + - scripts + - tests + - fixtures + - examples + - install notes + - migration records + + It does not own CCPE agents, committees, runtimes, model cards, or existing CCPE System assets. + + ## Relationship To CCPE System + + `C:\Users\xxx\Documents\Codex\ccpe-system` remains the system architecture workspace for: + + - expert agents + - committees + - runtimes + - model cards + - model indexes + - CCPE Skill specifications and architecture registrations + + `skills-vault` is separate. It stores automation Skill source code. + + The current and future migration scope is: + + ```text + Only automation Skills outside CCPE System are migrated into this repository. + Existing CCPE content is not migrated into this repository. + ``` + + See [docs/ccpe-relationship.md](docs/ccpe-relationship.md) for the boundary. + + ## Layout + + ```text + skills-vault/ + skills/ + / + SKILL.md + README.md + scripts/ + tests/ + fixtures/ + templates/ + skill/ + docs/ + registry/ + scripts/ + ``` + + ## Skill Migration Workflow + + 1. Identify an automation Skill outside CCPE System. + 2. Copy or reconstruct its source under `skills//`. + 3. Preserve original behavior first. + 4. Add or repair tests where practical. + 5. Register it in `registry/skills-index.md`. + 6. Optionally install or sync it into `C:\Users\wangq\.agents\skills`. + 7. Only create a CCPE registration later if a CCPE agent, runtime, or committee explicitly depends on it. + + See [docs/migration-guide.md](docs/migration-guide.md). + + ## Naming + + Use lowercase kebab-case: + + ```text + fix-title + markdown-normalizer + citation-checker + report-exporter + ``` +``` + +它的ccpe-relationship： +```md + # Relationship Between skills-vault And CCPE System + + ## Short Version + + `skills-vault` and `ccpe-system` are complementary, not competing. + + ```text + skills-vault = automation Skill implementation source + ccpe-system = agentic system architecture and high-level artifacts + ``` + + Existing CCPE content should not be migrated into `skills-vault`. + + Future migrations into `skills-vault` are limited to automation Skills that live outside CCPE System. + + ## What Belongs In skills-vault + + Use `skills-vault` for automation-oriented Skills such as: + + - Markdown transformers + - file cleanup tools + - citation checkers + - report exporters + - batch processors + - source splitters + - installable Codex or Claude Code Skills + - scripts and tests that implement repeatable Skill behavior + + These Skills usually have: + + - a `SKILL.md` + - deterministic procedures + - scripts + - tests or fixtures + - clear file-operation boundaries + + ## What Belongs In CCPE System + + Use `ccpe-system` for: + + - CCPE-Lite prompt cards + - durable agent specs + - committees + - runtimes + - model cards + - model indexes + - cognitive model assets + - architecture registrations for important Skills + + CCPE may reference a Skill from this repository, but should not duplicate the Skill source. + + ## When To Register A Skill In CCPE + + Do not register every small utility. + + Create a lightweight CCPE registration only when a Skill becomes part of a larger agentic system, for example: + + - a CCPE runtime calls the Skill + - a committee depends on the Skill + - an agent spec lists the Skill as a required capability + - the Skill has meaningful authority, safety, or evaluation rules + - the Skill becomes part of a repeatable workflow + + ## Example Registration Relationship + + If `fix-title` is migrated into this repository: + + ```text + skills-vault/ + skills/ + fix-title/ + SKILL.md + scripts/ + tests/ + ``` + + If later needed by CCPE, CCPE may add: + + ```text + ccpe-system/ + skills/ + tool/ + fix-title.skill.md + ``` + + That CCPE file should record only architecture metadata: + + ```text + canonical implementation: skills-vault/skills/fix-title + installed path: C:\Users\wangq\.agents\skills\fix-title + skill type: tool-skill / transformation-skill + used by: ... + authority: ... + validation: ... + ``` + + It should not copy implementation source from `skills-vault`. + + ## Current Policy + + ```text + Do not migrate any existing CCPE content into skills-vault. + Only migrate automation Skills outside CCPE System. + ``` + +``` + +它的具体一个skill的readme（示例）： + +```md + --- + name: fix-title + description: Use when a pasted ChatGPT or LLM Markdown reply has heading levels that need to be shifted down before insertion under a parent section such as "## GPT"; also use for Markdown title repair, heading nesting fixes, ATX header adjustment, and adding one or more # levels to headings in a file. + --- + + # Fix Title + + ## Overview + + Fix Markdown heading depth for copied LLM replies before inserting them into a discussion record. Use the bundled script for deterministic file edits instead of asking the model to rewrite the document. + + The default operation adds two heading levels, turning `# Title` into `### Title`, which fits content placed under a parent heading like `## GPT`. + + ## Workflow + + 1. Confirm the input is a Markdown file containing the raw reply to adjust. + 2. Choose the number of levels to add. Default to `2` unless the user specifies another value. + 3. Run `scripts/fix_markdown_titles.py` on the file. + 4. If the target is important or the requested level shift is unusual, use `--dry-run` or `--output` first and inspect the result. + 5. Report the path modified and the level shift used. + + ## Commands + + ```bash + python scripts/fix_markdown_titles.py path/to/reply.md + python scripts/fix_markdown_titles.py path/to/reply.md --levels 1 + python scripts/fix_markdown_titles.py path/to/reply.md --levels 3 --dry-run + python scripts/fix_markdown_titles.py path/to/reply.md --levels 2 --output path/to/fixed.md + ``` + + On Windows PowerShell, quote paths that contain spaces: + + ```powershell + python .\scripts\fix_markdown_titles.py "C:\path with spaces\reply.md" --levels 2 + ``` + + ## Behavior + + | Input | `--levels 2` output | + | --- | --- | + | `# A` | `### A` | + | `## B` | `#### B` | + | `###### C` | `###### C` | + + The script only changes ATX headings: lines beginning with up to three spaces followed by `#` through `######` and then whitespace. It does not change headings inside fenced code blocks, quoted lines such as `> # text`, or indented code. + + ## Common Mistakes + + - Do not use a broad replace like `#` to `###`; it will corrupt code blocks, quoted content, tags, and inline text. + - Do not increase headings past level six; Markdown ATX headings stop at `######`. + - Do not change the recorder's outer headings such as `# 1` or `## GPT` unless the user explicitly points the skill at the recorder file and requests that behavior. + - Do not use prompt rewriting for this task when the script can perform the edit directly. + +``` + +### 与Codex的讨论 + +```md + + > 你的这些 Skill 的“定义权”应该在 CCPE System + 你说的，我没太懂。 + 我怎么把`fix-title`的定义放在CCPE里，什么叫定义权？ + + 我之前的理解： + 1. 我需要建立`skills-vault`作为自动化skill集中地。 + 2. `fix-title`这样的自动化skill，源码部分，我放在`skills-vault`中 + 3. 在codex，或者cluade code下都需要指定工作路径/项目，我指定`skills-vault`中的位置。这些skill，我甚至可以一键安装在其他机器上。 + 4. 对于专家智能体，或者委员会（多专家智能体协同的），我在CCPE中打造。这些智能体，可能会需要一些自动化的skill，这些skill安装在`.agents/skills`，源码在`skills-vault`库中。专家智能体你可以了解下张辽，`C:\Users\xxx\Documents\Codex\ccpe-system\agents\lite\zhang-liao.prompt.md` + + 不知道，我理解的对不 + + --- + + 你的理解基本是对的。前面我说“定义权在 CCPE System”容易误导，我换一个更准确的说法： + + **`fix-title` 这种自动化 Skill 的源码主仓库，就应该是 `skills-vault`。** + 不是必须放到 `ccpe-system` 里。 + + 我说的“定义权”，不是指代码、脚本、`SKILL.md` 必须放在 CCPE。它指的是：当一个能力变得足够重要，需要进入你的 Agentic 系统架构时，CCPE 可以记录它的**能力分类、边界、被哪些 Agent/Runtime 调用、权限和评估规则**。 + + 但这可以是“登记/建模”，不是“源码归属”。 + + 你现在的理解可以整理成这个结构： + + ```txt + skills-vault + fix-title/ + SKILL.md + scripts/ + tests/ + other-automation-skill/ + SKILL.md + scripts/ + tests/ + + C:\Users\xxx\.agents\skills + fix-title/ + other-automation-skill/ + # 本机安装面，从 skills-vault 同步/安装 + + ccpe-system + agents/lite/zhang-liao.prompt.md + agents/agent-specs/ + agents/committees/ + runtimes/ + model-cards/ + skills/ + tool/ + workflow/ + cognitive/ + evaluation/ + # 专家智能体、委员会、Runtime、模型资产、以及重要 skill 的能力登记/规格 + + knowledge-vault + diary/ + discussions/ + prompts/ + rules/ + # 素材、讨论、知识归档、运行记录 + ``` + + 以张辽为例，你的理解是准确的。`zhang-liao.prompt.md` 是一个专家智能体，当前是 `CCPE-Lite`，它的定位是深度批判/审稿型专家，不是自动化工具。它可以将来调用一些自动化 Skill，比如： + + ```txt + fix-title + markdown-normalizer + source-splitter + citation-checker + report-exporter + ``` + + 这些自动化 Skill 的**源码**放在 `skills-vault`，**安装版**放在 `.agents/skills`，而张辽这类专家智能体仍然放在 `ccpe-system/agents/lite/` 或之后升级到 `agents/agent-specs/`、`committees/`。 + + 所以更准确的建议是： + + 1. `skills-vault`：自动化 Skill 的源码主仓库。 + 2. `.agents/skills`：本机运行安装目录。 + 3. `ccpe-system`：专家智能体、委员会、Runtime、模型卡，以及必要时对自动化 Skill 做“架构登记”。 + 4. `knowledge-vault`：素材、讨论稿、历史记录，不作为长期 Skill 源码库。 + + 什么时候需要在 CCPE 里登记 `fix-title`？ + + 只有当它开始被纳入更大的系统时，比如： + + ```txt + 写作工作流 Runtime 需要调用 fix-title + 观点讨论整理 Runtime 需要调用 fix-title + 某个 Agent Spec 明确依赖 fix-title + 委员会运行前需要统一清洗 Markdown 标题 + ``` + + 那时可以在 CCPE 里建一个轻量文件，例如： + + ```txt + ccpe-system/skills/tool/fix-title.skill.md + ``` + + 它不需要复制全部源码，只记录： + + ```txt + canonical implementation: skills-vault/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 + ``` + + 但如果它只是一个普通自动化小工具，暂时只放 `skills-vault` 就够了。 + + 所以你的 4 点我会这样判定： + + 1. 建 `skills-vault` 作为自动化 Skill 集中地：对。 + 2. `fix-title` 源码放 `skills-vault`：对。 + 3. Codex/Claude Code 工作时指定或安装 `skills-vault` 中的 Skill，可迁移到其他机器：对。 + 4. 专家智能体/委员会在 CCPE 打造，自动化 Skill 安装在 `.agents/skills`，源码在 `skills-vault`：对，而且这是我现在更推荐的主结构。 + + 我前面那句可以修正为： + + **自动化 Skill 的源码权在 `skills-vault`；系统架构关系和高级 Agentic 资产的定义权在 `ccpe-system`。** + +``` + +## 我的理解 + +CCPE是专家智能体，或者委员会（多智能体协作）；`skills-vault` 下的skill是自动化脚本，是专家智能体可能会有的一个skill。区分是CCPE的工作是推进业务目标的，而skill只是工具，与业务目标不直接相关。 + +## 指令 + +我这样的划分，你有什么建议和补充？ +对于原来的四层结构，是否影响？我个人觉得不影响，类似的MCP也是工具，也无需放进来。 + +## GPT + +你的划分我认可，而且比之前更清楚了： + +> **CCPE 管“谁在完成什么认知/业务任务”； +> `skills-vault` 管“可安装、可测试、可迁移的自动化工具能力”； +> `.agents/skills` 是本机运行安装面； +> MCP 类似工具/外部能力接入层，不必变成 CCPE 资产，除非被 Runtime 正式依赖。** + +这不影响原来的四层结构。更准确地说，`skills-vault` 不是第五层“方法论层级”，而是四层结构旁边的**实现源码仓库 / 工具供给仓库**。 + +--- + +### 1. 你的划分大体是对的，但要补一个关键 nuance + +你说： + +> CCPE 是专家智能体，或者委员会；`skills-vault` 下的 Skill 是自动化脚本，是专家智能体可能会有的一个 skill。CCPE 的工作是推进业务目标，skill 只是工具，与业务目标不直接相关。 + +这个判断**基本对**，但要稍微修正一句： + +**不是所有 Skill 都只是工具。只有 `skills-vault` 里的 automation Skill 才主要是工具。** + +在你的 CCPE System 里，Skill 的定义其实更宽：它可以是 tool-oriented、method-oriented、workflow-oriented、evaluation-oriented、transformation-oriented、knowledge-management-oriented；也就是说，CCPE-Skill 不只是脚本包装，也可以包含方法、流程、检查清单、推理协议、工具使用规则、输出模板和验证标准。你原来的 CCPE 设计还明确说，Agent 是角色或工作单元，Model 是可复用认知结构，Skill 可以执行 Model，Runtime 可以编排 Agent 和 Skill。 + +所以更精确的分法应该是： + +```text +automation Skill += 可安装、可执行、可测试的工具能力 += skills-vault 管源码 + +CCPE-Skill += 可复用的认知/方法/流程/评估能力规格 += ccpe-system 管架构定义 + +installed Skill += 本机运行时安装副本 += .agents/skills 管运行安装面 +``` + +`fix-title` 显然是第一类：automation Skill。 +`认知显影术`、`假设压力测试`、`argument-chain inspection` 这类更像 CCPE-Skill 或 Model + Skill。 +`viewpoint-discussion-distillation` 那种多阶段、多 Agent、多 human gate、多 audit 的东西，则更接近 **Runtime / Project Capability**，不应该被当成普通工具 Skill。 + +--- + +### 2. 我建议你把 “Skill” 拆成三类，避免以后混乱 + +你现在的混乱点来自一个词：**Skill 被多个系统复用了**。 + +Codex / Claude Code 里的 Skill，偏“可安装能力包”。 +CCPE 里的 Skill，偏“可复用能力模块”。 +项目里的 Skill，有时其实是“运行流程入口”。 + +建议你在 `skills-vault` 和 CCPE 里都写清楚这三类。 + +#### A. Automation Skill + +这是 `skills-vault` 的主对象。 + +特点： + +```text +- 有 SKILL.md +- 有脚本 / tests / fixtures +- 行为相对确定 +- 可安装到 .agents/skills +- 以文件操作、格式转换、批处理、导出、检查为主 +- 不拥有业务目标 +``` + +例子： + +```text +fix-title +markdown-normalizer +citation-checker +report-exporter +source-splitter +tts-batch-generator +image-prompt-exporter +``` + +它们是“轮机房里的扳手、钻头、清洗机”。 + +#### B. CCPE-Skill + +这是 `ccpe-system` 的对象。 + +特点： + +```text +- 可能没有脚本 +- 可能主要是方法、协议、检查清单、推理规则 +- 可被多个 Agent / Runtime 调用 +- 与认知模型、评估规则、角色边界有关 +- 可能承载业务语义 +``` + +例子： + +```text +cognitive-imaging.skill.md +assumption-stress-test.skill.md +argument-chain-inspection.skill.md +model-mining.skill.md +``` + +它们不只是工具，更像“专家如何做某类判断”的方法模块。 + +#### C. Runtime Capability / Project Capability + +这是具体项目或 Runtime 的对象。 + +特点： + +```text +- 多步骤 +- 多角色 +- 有状态 +- 有 human gate +- 可能依赖多个 Agent 和 automation Skill +- 有上下文工程、调用记录、审计、handoff +``` + +例子： + +```text +viewpoint-discussion-distillation +writing-outline-review +video-episode-production +knowledge-material-routing +``` + +这种东西不要放进 `skills-vault` 当普通工具源码。它应该属于： + +```text +ccpe-system/runtimes/ +或 +knowledge-vault / writing-workbench / video-workbench 的 project runbook +``` + +你之前那个 `viewpoint-discussion-distillation` 的 README 其实就已经写得很明显：它不是 summary-only compression，而是把长讨论转成 source-map、topic-map、material-routing-log、topic documents、coverage audit、downstream handoff packets，并且要求不能产生没有真实 invocation record 的正式 Agent 输出。 这不是一个 `fix-title` 式工具 Skill，而是 Runtime 级能力。 + +--- + +### 3. `skills-vault` 的定位很合理，但建议补三条边界 + +你现在的 README 已经很清楚：`skills-vault` 管 automation Skills 的源码、脚本、测试、fixtures、安装说明、迁移记录；不迁移已有 CCPE 内容。这个方向对。 + +我建议补三条规则。 + +#### 规则一：`skills-vault` 不拥有业务语义，只拥有执行语义 + +可以写成： + +```md +skills-vault owns executable behavior, not business intent. + +A skill in this repository may transform files, validate formats, export reports, call APIs, or run deterministic procedures. It does not decide why the work matters, whether the work should be done, or how the result should be interpreted in a larger business workflow. +``` + +中文就是： + +> `skills-vault` 负责“怎么做这个动作”，不负责“为什么做、该不该做、做完如何裁决”。 + +这条能防止 `skills-vault` 膨胀成第二个 CCPE。 + +#### 规则二：Skill 可以有 authority，但 authority 来源不在 `skills-vault` + +比如 `fix-title` 可以声明： + +```text +may rewrite user-specified markdown file only +``` + +但它的“谁允许它在某个 Runtime 中写哪个目录”，应该由 Runtime / Agentic Handbook / CCPE registration 决定。 + +也就是说： + +```text +skills-vault 声明能力边界 +CCPE / Runtime 授予使用权限 +Project Runbook 指定调用场景 +``` + +#### 规则三：`skills-vault` 产物不能直接成为业务产物 + +例如 `fix-title` 处理完 Markdown，它只是完成了标题层级转换。 +至于这个处理后的文件是否进入知识库、是否成为正式记录、是否进入下游写作，应该由项目 Runtime 或人类确认决定。 + +这和你 Agentic Handbook 里的 Artifact Contract / Human Gate 是同一条线。 + +--- + +### 4. 对原四层结构有没有影响？ + +**不影响。** + +你原来的四层结构可以保持： + +```text +HiFi Agent Studio += 纲领 / 方法论宪法 + +Agentic Engineering Handbook += Agentic 现场规程 / 运行治理守则 + +CCPE System += Agent / Skill / Runtime / Model Card 的建造工坊 + +Project Runbook += writing-workbench、video-workbench、knowledge-vault 等具体流程操作票 +``` + +`skills-vault` 应该放在旁边，作为**工具源码供应仓**： + +```text +skills-vault += automation Skill implementation source += 可安装工具能力的源码仓库 +``` + +所以整体拓扑建议这样画： + +```text +HiFi Agent Studio + ↓ +Agentic Engineering Handbook + ↓ +CCPE System ←─────────────── skills-vault + ↓ ↓ +Project Runbooks .agents/skills + ↓ ↓ +writing / video / vault runtimes call installed skills +``` + +或者更像工程系统一点： + +```text +Methodology Layer +- HiFi Agent Studio + +Governance Layer +- Agentic Engineering Handbook + +Architecture Layer +- CCPE System + - agents + - committees + - runtimes + - model-cards + - CCPE skill specs / registrations + +Implementation Source Layer +- skills-vault + - automation skill source code + - scripts + - tests + - fixtures + +Runtime Installation Layer +- .agents/skills +- MCP servers +- CLI tools +- API adapters + +Project Execution Layer +- knowledge-vault +- writing-workbench +- video-workbench +``` + +`skills-vault` 不改变四层结构，因为它不是新的治理层，也不是新的方法论层。它是“实现层”的仓库。 + +--- + +### 5. MCP 的类比是对的 + +你说 MCP 也是工具，也无需放进来。这个判断我认可。 + +MCP Server 和 `skills-vault` 里的 automation Skill 在架构地位上很像：它们都是**能力提供者**，不是业务目标拥有者。 + +但有一个补充： + +> MCP 本身不用放进 CCPE； +> 但当某个 Agent / Runtime 正式依赖某个 MCP 工具时，CCPE 应该登记这个依赖。 + +例如： + +```text +ccpe-system/tools/mcp/ + filesystem.mcp.md + browser-search.mcp.md + tts-service.mcp.md +``` + +登记内容不需要复制 MCP 实现，只记录： + +```text +canonical implementation: +installed endpoint: +used by: +authority: +allowed operations: +forbidden operations: +security notes: +evaluation: +failure behavior: +``` + +和 `fix-title` 的 CCPE registration 是同一种逻辑。 + +所以可以统一成： + +```text +实现源码不进 CCPE +架构依赖进 CCPE +运行安装面不当 source of truth +``` + +这句话很重要。 + +--- + +### 6. 我建议你新增一个 `ccpe-system/registrations/` 或 `integrations/` + +你现在说： + +```text +ccpe-system/skills/tool/fix-title.skill.md +``` + +这个可以，但我会更建议你区分 **CCPE-Skill Spec** 和 **外部工具登记**。 + +因为 `fix-title` 这种东西不是 CCPE 原生 Skill，它是 external automation skill。 + +建议目录可以这样： + +```text +ccpe-system/ + integrations/ + skills-vault/ + fix-title.registration.md + markdown-normalizer.registration.md + mcp/ + filesystem.registration.md + browser-search.registration.md + cli-tools/ + pandoc.registration.md + ffmpeg.registration.md +``` + +而保留： + +```text +ccpe-system/skills/ + cognitive/ + method/ + workflow/ + evaluation/ +``` + +这样更干净。 + +如果你继续放在 `ccpe-system/skills/tool/` 也不是不行，但容易让人误会 `fix-title.skill.md` 是 CCPE 原生 Skill 规格，而不是外部实现登记。 + +我建议命名成： + +```text +fix-title.external-skill.md +fix-title.registration.md +fix-title.tool-registration.md +``` + +不要叫： + +```text +fix-title.skill.md +``` + +除非它真的升级成 CCPE-Skill。 + +--- + +### 7. 给你一个更稳定的判断标准 + +以后判断某个东西放哪儿，不要只看它叫不叫 Skill，而看五个问题。 + +#### 1. 它是否拥有业务目标？ + +拥有业务目标： + +```text +CCPE Agent / Runtime / Project Runbook +``` + +不拥有业务目标，只执行动作： + +```text +skills-vault / MCP / CLI tool +``` + +`fix-title` 不关心为什么修标题，所以进 `skills-vault`。 + +#### 2. 它是否承载认知模型？ + +承载认知模型： + +```text +ccpe-system/model-cards +ccpe-system/skills/cognitive +ccpe-system/agents +``` + +不承载认知模型，只处理文件： + +```text +skills-vault +``` + +#### 3. 它是否需要状态、角色、human gate、审计？ + +需要： + +```text +CCPE Runtime / Project Runtime +``` + +不需要： + +```text +automation Skill +``` + +`viewpoint-discussion-distillation` 需要真实 invocation、whole-source gestalt、topic routing、human confirmation、coverage audit，所以它是 Runtime Capability，不是普通 automation Skill。它的 runbook 明确要求真实参与者、不能让主会话做 primary source analysis、没有真实输出就停止，这些都是 Runtime 级约束。 + +#### 4. 它是否有可测试的确定性脚本？ + +有： + +```text +skills-vault +``` + +没有，主要是方法和判断： + +```text +CCPE-Skill / Model Card / Agent +``` + +#### 5. 它是否只是被别人调用？ + +只是被调用： + +```text +skills-vault / MCP / tool adapter +``` + +会调度别人： + +```text +Runtime / Orchestrator +``` + +这五问基本能解决 90% 的归属争议。 + +--- + +### 8. `skills-vault` 建议补一个 Skill Manifest + +你现在每个 Skill 有 `SKILL.md` 和 README，已经够用。但为了以后和 CCPE / Handbook / 安装面连接，建议每个 skill 加一个机器可读或半机器可读的 manifest。 + +例如： + +```yaml +name: fix-title +type: automation-skill +category: markdown-transformer +canonical_source: skills-vault/skills/fix-title +installed_paths: + - C:\Users\xxx\.agents\skills\fix-title +entrypoints: + - scripts/fix_markdown_titles.py +authority: + file_read: true + file_write: user_specified_markdown_only + external_api: false + network: false +side_effects: + - modifies markdown heading levels +safety: + dry_run_available: true + output_path_available: true + max_heading_level: 6 +tests: + command: pytest +ccpe_registration: + required: false + registration_path: null +status: active +version: 1.0.0 +``` + +这样以后 CCPE 想登记它，不需要重新理解源码，只要读取 manifest。 + +--- + +### 9. 对 `fix-title` 示例的具体建议 + +`fix-title` 这个例子很清楚。我只建议补几项： + +#### 增加 authority + +```md +## Authority + +This skill may only modify the Markdown file explicitly provided by the user or orchestrator. + +It must not recursively scan directories, rename files, change recorder outer headings, or modify unrelated Markdown files unless explicitly instructed. +``` + +#### 增加 safety + +```md +## Safety + +Use `--dry-run` or `--output` before in-place modification when: + +- the file is a canonical record; +- the file is customer-visible; +- the level shift is not the default; +- the file contains complex Markdown structures. +``` + +#### 增加 validation + +```md +## Validation + +After execution, verify: + +- fenced code blocks are unchanged; +- blockquotes are unchanged; +- headings do not exceed level 6; +- only ATX headings were changed. +``` + +#### 增加 installation note + +```md +## Installation + +Canonical source lives in `skills-vault/skills/fix-title`. + +Installed copies under `.agents/skills/fix-title` are runtime artifacts and must not be edited as source of truth. +``` + +这几条会让它更符合你 Agentic Handbook 的 Tool Safety / Artifact Contract 思路。 + +--- + +### 10. `skills-vault` 和 CCPE 的关系可以再浓缩成一句制度 + +我建议你在 `docs/ccpe-relationship.md` 里加一段： + +```md +## Source Ownership vs Architecture Registration + +For automation Skills, source ownership and architecture registration are separated. + +- `skills-vault` owns implementation source, tests, fixtures, examples, and install notes. +- `.agents/skills` owns local runtime installation copies. +- `ccpe-system` may register a Skill only when an Agent, Runtime, committee, or governed workflow depends on it. +- CCPE registration records architecture metadata, authority, safety, evaluation, and dependency relationships. +- CCPE registration must not duplicate implementation source. +``` + +这段基本就是你这次讨论的最终答案。 + +--- + +### 11. 对你“业务目标 vs 工具”的表述，我建议改成这样 + +你原句： + +> CCPE 的工作是推进业务目标的，而 skill 只是工具，与业务目标不直接相关。 + +我建议改为： + +> **CCPE 资产拥有或组织业务目标；automation Skill 执行可复用动作。Skill 可以服务业务目标，但不自行定义业务目标。** + +这更严谨。 + +因为 `fix-title` 虽然不直接相关，但一旦进入 `writing-workbench`，它会服务“整理讨论记录”这个业务目标。 +但它不会决定“为什么整理”“整理到什么程度”“是否进入正式知识库”。 + +也就是说： + +```text +业务目标：Runtime / Agent / Human 决定 +执行动作：Skill / Tool / MCP 完成 +业务裁决：Human Gate / Runtime 决定 +``` + +--- + +### 12. 对原四层结构的最终回答 + +**不影响。** + +但我建议你把“工具实现层”作为四层结构旁边的基础设施层写出来： + +```text +HiFi Agent Studio += 宪法 + +Agentic Engineering Handbook += 现场规程 + +CCPE System += 智能体 / 模型 / Runtime / 重要能力登记工坊 + +Project Runbook += 具体项目执行流程 + +skills-vault / MCP / CLI / API += 工具实现与能力供给层 +``` + +这不是第五个治理层，而是“反应堆里的工具管线”。 + +一个很贴切的说法是： + +> **CCPE 是组织结构图；skills-vault 是工具库；MCP 是外部接口；Project Runbook 是作业票；`.agents/skills` 是现场工具架。** + +别把工具架放进组织结构图里。 +但如果某个岗位每天必须用某把工具，组织结构图旁边要登记这把工具的权限和安全边界。 + +--- + +### 13. 最后给一个仓库归属表 + +| 对象 | 归属 | 说明 | +| ----------------------------------- | ----------------------------------------------------------------- | ------------------------------------- | +| 张辽 prompt / agent spec | `ccpe-system` | 专家角色，拥有评审职责和认知姿态 | +| 认知显影模型 | `ccpe-system/model-cards` | 可迁移认知模型 | +| 认知显影 Skill | `ccpe-system/skills/cognitive` | 方法型 Skill，不一定有脚本 | +| `fix-title` | `skills-vault` | 自动化 Markdown 工具 Skill | +| `fix-title` 安装副本 | `.agents/skills` | 运行时安装面，不是源码 | +| `fix-title` 被写作 Runtime 正式依赖 | `ccpe-system/integrations/skills-vault/fix-title.registration.md` | 只登记架构依赖、权限、验证，不复制源码 | +| MCP server | MCP / tool runtime | 外部工具能力，不进 CCPE 源码 | +| MCP 被某 Runtime 依赖 | `ccpe-system/integrations/mcp/*.registration.md` | 登记 endpoint、权限、风险、调用范围 | +| `viewpoint-discussion-distillation` | `ccpe-system/runtimes` + `knowledge-vault` project capability | 多阶段知识加工 Runtime，不是普通 automation Skill | +| 讨论稿、蒸馏结果、运行记录 | `knowledge-vault` | 业务材料与运行产物 | +| 视频分镜生成脚本 | `skills-vault` | 自动化执行工具 | +| 视频输出流程 | `video-workbench` runbook / runtime | 业务生产流程 | + +--- + +一句话总结： + +**你现在补 `skills-vault` 是对的。它不是推翻 CCPE，而是在 CCPE 旁边补了一个“工具源码供应链”。** + +你真正要守住的是三分法： + +```text +谁负责判断：Agent / Human / Runtime +谁负责执行：Skill / Tool / MCP +谁负责保存业务事实：Project Vault / Workbench +``` + +这三者一分清，体系就不乱了。 + +# 11 + +我需要一个总结，以便我能和Codex进行讨论时作为上下文注入，我在Codex上能继续对我的整体项目规划做改进。 +现在的讨论文字太长了，需要压缩。 + +我期望，这个总结不要超过2万字，讲清楚： +1. 深度创作目前遇到的问题，我原期望在`writing-workbench`上做的工作是难以开展下去的 +2. 自动化适合放在降维输出上，比如`video-workbench` +3. 现在的CCPE还需要补充哪些内容 +4. CCPE与skill-vault的差异 + +在这次总结里，不需要Hifi Agent Studio及其四层规划的内容。这部分是我单独优化CCPE才需要。 + +这个只是我大致想到的，你可以参考。 + + +下面这版可以直接作为 **Codex 上下文注入稿** 使用。我把长讨论压缩成“项目现状 + 判断 + 后续约束 + 仓库边界”。原始上传讨论材料可作为背景来源： + +--- + +# 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 的降维输出自动化。 + diff --git a/discussions/historical-agent-building/CCPE/CCPE1.0工程师讨论.md b/discussions/agent-building/CCPE/CCPE1.0工程师讨论.md similarity index 100% rename from discussions/historical-agent-building/CCPE/CCPE1.0工程师讨论.md rename to discussions/agent-building/CCPE/CCPE1.0工程师讨论.md diff --git a/discussions/historical-agent-building/CCPE/CCPE1.1工程师讨论.md b/discussions/agent-building/CCPE/CCPE1.1工程师讨论.md similarity index 100% rename from discussions/historical-agent-building/CCPE/CCPE1.1工程师讨论.md rename to discussions/agent-building/CCPE/CCPE1.1工程师讨论.md diff --git a/discussions/historical-agent-building/CCPE/CCPE工程师讨论.md b/discussions/agent-building/CCPE/CCPE工程师讨论.md similarity index 100% rename from discussions/historical-agent-building/CCPE/CCPE工程师讨论.md rename to discussions/agent-building/CCPE/CCPE工程师讨论.md diff --git a/discussions/historical-agent-building/CCPE/MCN/主播知识库抽取.md b/discussions/agent-building/CCPE/MCN/主播知识库抽取.md similarity index 100% rename from discussions/historical-agent-building/CCPE/MCN/主播知识库抽取.md rename to discussions/agent-building/CCPE/MCN/主播知识库抽取.md diff --git a/discussions/historical-agent-building/CCPE/MCN/主播管理与发展分解_Grok.md b/discussions/agent-building/CCPE/MCN/主播管理与发展分解_Grok.md similarity index 100% rename from discussions/historical-agent-building/CCPE/MCN/主播管理与发展分解_Grok.md rename to discussions/agent-building/CCPE/MCN/主播管理与发展分解_Grok.md diff --git a/discussions/historical-agent-building/CCPE/MCN/打造董宇辉看盘.md b/discussions/agent-building/CCPE/MCN/打造董宇辉看盘.md similarity index 100% rename from discussions/historical-agent-building/CCPE/MCN/打造董宇辉看盘.md rename to discussions/agent-building/CCPE/MCN/打造董宇辉看盘.md diff --git a/discussions/historical-agent-building/CCPE/MCN/测试LLM的直播知识_DS.md b/discussions/agent-building/CCPE/MCN/测试LLM的直播知识_DS.md similarity index 100% rename from discussions/historical-agent-building/CCPE/MCN/测试LLM的直播知识_DS.md rename to discussions/agent-building/CCPE/MCN/测试LLM的直播知识_DS.md diff --git a/discussions/historical-agent-building/CCPE/MCN/测试LLM的直播知识_GE.md b/discussions/agent-building/CCPE/MCN/测试LLM的直播知识_GE.md similarity index 100% rename from discussions/historical-agent-building/CCPE/MCN/测试LLM的直播知识_GE.md rename to discussions/agent-building/CCPE/MCN/测试LLM的直播知识_GE.md diff --git a/discussions/historical-agent-building/CCPE/MCN/测试LLM的直播知识_Grok.md b/discussions/agent-building/CCPE/MCN/测试LLM的直播知识_Grok.md similarity index 100% rename from discussions/historical-agent-building/CCPE/MCN/测试LLM的直播知识_Grok.md rename to discussions/agent-building/CCPE/MCN/测试LLM的直播知识_Grok.md diff --git a/discussions/historical-agent-building/CCPE/Shirleen/文献阅读助手打造.md b/discussions/agent-building/CCPE/Shirleen/文献阅读助手打造.md similarity index 100% rename from discussions/historical-agent-building/CCPE/Shirleen/文献阅读助手打造.md rename to discussions/agent-building/CCPE/Shirleen/文献阅读助手打造.md diff --git a/discussions/historical-agent-building/CCPE/Shirleen/文献阅读助手提示词.md b/discussions/agent-building/CCPE/Shirleen/文献阅读助手提示词.md similarity index 100% rename from discussions/historical-agent-building/CCPE/Shirleen/文献阅读助手提示词.md rename to discussions/agent-building/CCPE/Shirleen/文献阅读助手提示词.md diff --git a/discussions/historical-agent-building/CCPE/WDS/3.系统设计/数据库设计师讨论.md b/discussions/agent-building/CCPE/WDS/3.系统设计/数据库设计师讨论.md similarity index 100% rename from discussions/historical-agent-building/CCPE/WDS/3.系统设计/数据库设计师讨论.md rename to discussions/agent-building/CCPE/WDS/3.系统设计/数据库设计师讨论.md diff --git a/discussions/historical-agent-building/CCPE/WDS/5.测试/测试用例智能体讨论1.md b/discussions/agent-building/CCPE/WDS/5.测试/测试用例智能体讨论1.md similarity index 100% rename from discussions/historical-agent-building/CCPE/WDS/5.测试/测试用例智能体讨论1.md rename to discussions/agent-building/CCPE/WDS/5.测试/测试用例智能体讨论1.md diff --git a/discussions/historical-agent-building/CCPE/WDS/5.测试/软件测试工程师智能体打造.md b/discussions/agent-building/CCPE/WDS/5.测试/软件测试工程师智能体打造.md similarity index 100% rename from discussions/historical-agent-building/CCPE/WDS/5.测试/软件测试工程师智能体打造.md rename to discussions/agent-building/CCPE/WDS/5.测试/软件测试工程师智能体打造.md diff --git a/discussions/historical-agent-building/CCPE/WDS/会议纪要员讨论.md b/discussions/agent-building/CCPE/WDS/会议纪要员讨论.md similarity index 100% rename from discussions/historical-agent-building/CCPE/WDS/会议纪要员讨论.md rename to discussions/agent-building/CCPE/WDS/会议纪要员讨论.md diff --git a/discussions/historical-agent-building/CCPE/匠作监/打造首席架构审查官.md b/discussions/agent-building/CCPE/匠作监/打造首席架构审查官.md similarity index 100% rename from discussions/historical-agent-building/CCPE/匠作监/打造首席架构审查官.md rename to discussions/agent-building/CCPE/匠作监/打造首席架构审查官.md diff --git a/discussions/historical-agent-building/CCPE/匠作监/打造首席架构师.md b/discussions/agent-building/CCPE/匠作监/打造首席架构师.md similarity index 100% rename from discussions/historical-agent-building/CCPE/匠作监/打造首席架构师.md rename to discussions/agent-building/CCPE/匠作监/打造首席架构师.md diff --git a/discussions/historical-agent-building/CCPE/国子监/强哥的徒弟/优化强哥的徒弟.md b/discussions/agent-building/CCPE/国子监/强哥的徒弟/优化强哥的徒弟.md similarity index 100% rename from discussions/historical-agent-building/CCPE/国子监/强哥的徒弟/优化强哥的徒弟.md rename to discussions/agent-building/CCPE/国子监/强哥的徒弟/优化强哥的徒弟.md diff --git a/discussions/historical-agent-building/CCPE/国子监/强哥的徒弟/打造强哥的徒弟1.md b/discussions/agent-building/CCPE/国子监/强哥的徒弟/打造强哥的徒弟1.md similarity index 100% rename from discussions/historical-agent-building/CCPE/国子监/强哥的徒弟/打造强哥的徒弟1.md rename to discussions/agent-building/CCPE/国子监/强哥的徒弟/打造强哥的徒弟1.md diff --git a/discussions/historical-agent-building/CCPE/国子监/强哥的徒弟/附录2：视频总纲范本.md b/discussions/agent-building/CCPE/国子监/强哥的徒弟/附录2：视频总纲范本.md similarity index 100% rename from discussions/historical-agent-building/CCPE/国子监/强哥的徒弟/附录2：视频总纲范本.md rename to discussions/agent-building/CCPE/国子监/强哥的徒弟/附录2：视频总纲范本.md diff --git a/discussions/historical-agent-building/CCPE/国子监/强哥的徒弟/附录3：分镜深潜产出范本.md b/discussions/agent-building/CCPE/国子监/强哥的徒弟/附录3：分镜深潜产出范本.md similarity index 100% rename from discussions/historical-agent-building/CCPE/国子监/强哥的徒弟/附录3：分镜深潜产出范本.md rename to discussions/agent-building/CCPE/国子监/强哥的徒弟/附录3：分镜深潜产出范本.md diff --git a/discussions/agent-building/CCPE/国子监/讨论中英文翻译-mmx.md b/discussions/agent-building/CCPE/国子监/讨论中英文翻译-mmx.md new file mode 100644 index 0000000..4785bde --- /dev/null +++ b/discussions/agent-building/CCPE/国子监/讨论中英文翻译-mmx.md @@ -0,0 +1,775 @@ +# 1 + +我想做一个中英文翻译智能体，我输入中文，它输出英文；我输入英文，它输出中文。没有特别指令的时候，我输入的内容，就是要翻译的内容。 +此外，还想加一点点解释和例句，比如我输入feeling，它除了说出`感情`外，还能指出常见词，比如emotion，及与emotion的区别，再提供一个例句。 + +有点像简易词典。 + +你有很么问题么？ + +你好！这是一个挺实用且需求明确的小工具。在开始构建之前，我想先针对几个**关键的决策点**和你确认一下，这样做出来的智能体才会更贴合你的预期。 + +先简单评估一下你的需求复杂度：这是一个**轻量级的语言处理智能体**，核心是翻译+词典，逻辑比较清晰，不需要外部工具或复杂的多智能体协同。所以我们可以聚焦在**功能边界**和**输出风格**上。 + +--- + +## 📋 第一轮问题：核心行为定义 + +### 1. 关于"输入内容"的理解（最重要） +你提到了"输入内容就是要翻译的内容"，但**单词**和**句子/段落**的处理方式可能不一样。我想确认： + +- **当输入是单词时**（比如 `feeling` 或 `感情`），是否触发**词典模式**（翻译 + 解释 + 相关词 + 例句）？ +- **当输入是句子/段落时**（比如 `我今天很开心` 或 `I'm happy today`），是**只做翻译**，还是也附带一些注释（比如语法点、生词解析）？ + +> 💡 这决定了智能体如何区分"翻译任务"和"词典任务"。 + +### 2. 关于词典内容的深度 +你举了 `feeling` 的例子，包含了：**翻译 + 相关词 + 区别 + 例句**。我想确认： + +- **每次翻译单词都要输出这些吗？** 还是只在某些情况下（比如用户明确要求，或输入是单个英文单词）才输出？ +- **例句数量**：通常 1 个够吗？还是给 2-3 个展示不同用法？ +- **例句语言**：用英文例句还是中文例句？ +- 是否需要**音标**和**词性**标注（如 `feeling /ˈfiːlɪŋ/ n.`）？ + +### 3. 关于翻译风格 +- **直译**（更贴近原文）还是**意译**（更自然地道）？比如"望子成龙"这种成语，怎么处理？ +- 如果一个词有多个意思，是**默认给出最常见的1个翻译**，还是**列出常见释义让用户选**？ + +### 4. 关于"特别指令" +你说"没有特别指令时"是默认翻译。那反过来，是否需要支持一些**特殊指令前缀**？比如： +- 输入 `详细 feeling` → 触发词典模式 +- 输入 `英式 我很开心` → 用英式英语翻译 +- 输入 `只翻译 我很开心` → 不要任何附加内容 + +需要预留这些吗？还是保持简单，**一律按默认模式处理**？ + +--- + +# 2 + +## 回复 + +- **当输入是单词时**（比如 `feeling` 或 `感情`），是否触发**词典模式**（翻译 + 解释 + 相关词 + 例句）？ + - 单词触发词典。 +- **当输入是句子/段落时**（比如 `我今天很开心` 或 `I'm happy today`），是**只做翻译**，还是也附带一些注释（比如语法点、生词解析）？ + - 句子或者段落时，只做翻译就好了。 + + +- **每次翻译单词都要输出这些吗？** 还是只在某些情况下（比如用户明确要求，或输入是单个英文单词）才输出？ + - 输入单个单词时输出 +- **例句数量**：通常 1 个够吗？还是给 2-3 个展示不同用法？ + - 2~3个 +- **例句语言**：用英文例句还是中文例句？ + - 用英文例句 +- 是否需要**音标**和**词性**标注（如 `feeling /ˈfiːlɪŋ/ n.`）？ + - 不需要 + +- **直译**（更贴近原文）还是**意译**（更自然地道）？比如"望子成龙"这种成语，怎么处理？ + - 我觉得可能按照`直译 + 反思 + 意译`的工作流程最好： + - 直译 + - 反思，自查直译的问题 + - 没问题，不用意译；有问题，再给意译的内容 + - 这个一般是句子或者段落的时候 +- 如果一个词有多个意思，是**默认给出最常见的1个翻译**，还是**列出常见释义让用户选**？ + - 列出常见释义 + +## 特别指令 + +你说"没有特别指令时"是默认翻译。那反过来，是否需要支持一些**特殊指令前缀**？ + +没有特别指令，举例单词、句子各两个，我会直接发送以下内容，没有任何其他提示： +> feeeling +> anchor +> Building voice-gen CLI for batch TTS with custom voice clones; server cleanup just finished with all3 old voice files deleted. +> **Env prep** — `voice-gen voices add