knowledge-vault/discussions/technology/Codex/1.重构CCPE/写作相关智能体/重构提纲评审流程2.md

1

请先阅读C:/Users/wangq/Documents/Codex/writing-workbench/docs/context-handoff.md，了解上下文。

目前审核提纲阶段核心部分的智能体已经都有Lite或者Kernel版：

• 散文主笔：韩愈，
• 评审：张辽，认知显影，巨人认知

这些都已经进行了相关测试。

你看我们下步怎么开展。

我建议下一步不要急着做“完整文章生产 Runtime”，而是进入一个较小的闭环：

下一阶段目标：先打通“提纲审核 Runtime v0”。

当前核心资产分类可以这样定：

• 韩愈：CCPE-Lite / Kernel，作为散文主笔，不急着转 Agent Spec。
• 张辽、认知显影、巨人认知：CCPE-Lite / Kernel，作为提纲评审专家。
• 下一步新增的不是更多专家，而是一个轻量控制层：
  • Article Production Orchestrator：CCPE-Agent
  • Outline Review Runtime：CCPE-Runtime / Interactive Runtime
  • 少量工作流 Skill 先作为候选，不急着全做。

推荐顺序：

1. 做一份 Scenario Probe / Creation Brief 明确提纲审核阶段到底怎么跑：输入什么、谁先评、谁复核、谁综合、用户在哪些点决策。

2. 先写 Article Production Orchestrator Agent Spec 它不是评审专家，而是调度者：准备 context pack、分发给韩愈/张辽/认知显影/巨人认知、收报告、合成下一步建议、等待用户裁决。

3. 再写 Outline Review Runtime v0 只覆盖“提纲阶段”，不要覆盖全文写作、终审、附录、建模委员会、视频化。Runtime 里定义：

   • 输入：选题、定位、素材、初版提纲
   • 角色：韩愈主笔 + 三个评审
   • 输出：评审报告、冲突点、修订请求、用户决策项
   • 状态：第几轮、哪些意见已采纳、哪些保留
   • 人类 gate：是否进入正文写作

4. 用 Writing Workbench 开一个试验项目 在 projects/active/YYYY-MM-DD-aNNN-temp-slug/ 下跑一次真实提纲审核，把 session.md 和 report.md 留下来。这个试验会告诉我们哪些 Skill 真的需要做。

5. 试验后再抽 Skill 优先可能是：

   • context-pack-builder
   • review-dispatcher
   • review-synthesis
   • repair-request-builder

我建议下一步产出文件先控制在 2-3 个：

workbench/analysis/article-production-orchestrator-creation-brief.md
workbench/upgraded/article-production-orchestrator.agent.md
workbench/upgraded/outline-review.runtime.md

判断：现在已经过了“专家 Lite 准备阶段”，应该进入“控制层 + 提纲审核 Runtime v0”阶段。不要先拆评审专家，也不要先做全流程自动化。先把最贵、最容易失控的提纲审核环节跑通。

2

因为在深度创作阶段，提纲评审是最终的，我们把这部分先抽出来试跑，之后再向前先后延申。 假设我和韩愈交流，已经有了一份初稿提纲。这是进入的环节。 这里有个文件夹的问题，在writing-workbench project中做了初步规划： C:\Users\wangq\Documents\Codex\writing-workbench\templates\article-project\PROJECT_STRUCTURE.md，但是不够细致。

我的问题：

1. 好几个地方都有这个context-packs/，我理解的上下文，应该是一套吧？这个地方拆到不同阶段了，很散。

2. 现在上下文有时候会非常大，在单智能体环境下，我没法/很难做拆分；但是在我们这套架构下，

   1. 可以考虑做个Outline-Aligned Context Pack：提纲对齐上下文包

    【提纲点 1】
    - 我的核心观点：
    - 相关讨论摘要：
    - 可用论据：
    - 可用例子：
    - 可引用材料：
    - 禁止展开/不作为主线的内容：
   
    【提纲点 2】
    - 我的核心观点：
    - 相关讨论摘要：
    - 可用论据：
    - 可用例子：
    - 可引用材料：
    - 禁止展开/不作为主线的内容：
   

   2. 可以对我的原始材料进行与文章立意、使用相关的无损信息压缩：
      • 我的观点、思路有时候会很口语化，就是我想到哪儿，写到哪儿
      • 我放入的过往文章，往往都是整篇放入，（以前单智能体下，不然我就得手工做相关信息提炼）；我的过往文章又是学术性散文，很多内容都是做“异常处理”——防止反方观点的。

   我们在这里打造智能体，会约定它的工作目录，将来需要有一份文档，让writing-workbench去看着调整。

3. 提纲评审阶段，评审员也都需要这些上下文；这些上下文就是文章观点的支撑。现在的韩愈输出的提纲，没有对齐包。我们是改造韩愈，还是再做一个韩愈的助手，或者专门的助手。因为学术性散文是韩愈，我还有其他文章风格的主笔智能体。

4. Context限制。过往都是一股脑扔到Gemini的Context中，因为它支持100万字；而我们现在的Codex，只支持258k。

5. 韩愈修改提纲，其他评审员评审，都需要保持各自的会话，除非Context限制/或者我要求重启，需要交接。

下面是之前的深度创作流程，供参考：

这里涉及到写文章的工作流程，每个环节的产物。我将之前的从灵感到发布的全部过程梳理一下。
由于`knowledge-vault`知识库已经重构完成，我就按照新的知识库来模拟。

1. 产生灵感。我会记录下来。不论是PC还是手机，这个记录一般会进入`knowledge-vault/diary`
2. 确定观点。基于灵感，做深入洞察。这个主要在`knowledge-vault/discussions`中完成，可能会有多个智能体参与，会直接在不同平台上与LLM探讨，甚至会做Deep Research。
3. 确定创作。因为写文章需要一整段时间，且不是所有的观点都会进入写作。确定创作主要包括确定什么题材——用什么主笔智能体/skill，文章思路，选定的素材，是否要作为我已有的系列中后续的一篇等等，相当于项目计划书初稿。我会在`writing-workbench/projects`中建立一个子项目，这时候日期确定，项目标题可能是临时的。
4. 确定文章立意。将确定创作阶段的成果扔给主笔，以前素材都会进提示词，现在我会告诉主笔智能体，引用了哪些素材文件（包括确定观点阶段的讨论结论，过往文章，调研报告等等）；文章思路等内容还是文字描述。这部分放哪儿？
   * 为了避免灯下黑。素材部分，我还会交代，哪些是读者可见的，比如引用的过往文章，读者可以自行去翻阅，论述时可以相对简略些；哪些是读者不可见的内部资料，比如Agent的报告，Deep research 的报告等等，论述的时候要充分些。
5. 确定文章提纲。这个过程，不论是主笔，还是评审员都可能会开启多轮会话，因为确定提纲是整个创作流程中最重的环节，一次会话往往都在十几个回合。
   1. 我与主笔交流，生成初版提纲放在`outlines`中，这个最终参与评审的提纲一个版本就是一个文件，不会有多个文件；提纲生成可能会是多轮对话，这个对话过程存在哪里（以前我都保存在`knowledge-vault/discussions`中）。
   2. 评审提纲。调用其他评审的Skill，来做评审。在搭建评审委员会之前，需要我明确指定谁来参与评审。与提纲生成类似，评审有三部分内容要考虑保存：
      - 参与评审的素材准备，（之前一股脑放在提示词里），如果只放提纲，不放素材（上下文）大概率很多评审不过；
      - 评审过程记录，我的智能体不是只出评审意见报告，还可以进行交流讨论（比如张辽不但是红队，还是建设性苏格拉底）；
      - 评审意见结果。
   3. 我汇总各评审意见，写应对策略，交给主笔修复提纲。然后重复前两个步骤，直到我认为OK。
   4. 文章提纲确定后，对于复杂些的，会再生成一个附录提纲，放在提纲末尾。
6. 撰写正文。一般这时候都会重启会话。包括了正文的每次讨论输出，和最终正文。
   1. 按章或按小节输出，我自行合并，正文初稿。
   2. 进入正文初稿的评审。这个主要是措辞的修复。大多数评审1、2轮就通过了。
7. 撰写正文附录。对于跨学科，概念多的会基于附录提纲生成附录。包括了附录的讨论，附录会合并进正文。
8. 生成Metadata。包括了Metadata的结果，插图，和合并进正文。
   1. 调用Skill生成Metadata，我放到正文的头信息中，包括关键词、摘要等等。
   2. 生成插图，我上传到服务器，将URL放到头信息中。
9. 启动审判庭。以前的文章在提纲阶段下的力气少，所以进入审判庭的多。现在很少了。审判庭是一个由10个左右的智能体协作机制。
10. 基于审判意见修改。
11. 然后是建面向用户的模型阶段。可能直接抽取模型，也可能会调用`建模者委员会`，由6个智能体构成的协作机制。包括了讨论稿，和最终的模型说明正文。

我赞成你的判断：先把“初稿提纲进入评审”这一段抽出来试跑。它是深度创作里成本最高、最决定文章命运的一段，适合先做成一个可验证的小闭环。

我的建议是：不要把 context-packs/ 分散在每个阶段里当作独立实体。上下文应该是一套，但可以有多个“视图”。

核心目录调整 把项目级上下文集中到根目录，例如：

context/
  context-manifest.md
  global-context-pack.md
  source-digests/
  outline-aligned/
  dispatch-packs/

各阶段目录里的 context-packs/ 不再保存主上下文，只保存“本阶段使用的上下文视图”或链接说明。也就是说：

02-outline/context-packs/

可以保留，但它应当指向或派生自项目根目录的 context/，不再各自维护一套散乱材料。

上下文分层 你现在需要的不是简单压缩，而是“面向文章用途的结构化压缩”。我建议分四层：

L0 Raw Sources
原始材料仍在 knowledge-vault 或项目 source-map 指向的位置，不复制全文。

L1 Source Digest
每份材料生成一份面向当前文章的摘要：核心观点、可用段落、反方处理、不可用内容、读者可见性。

L2 Outline-Aligned Context Pack
按提纲点对齐材料，就是你写的那个结构。

L3 Agent Dispatch Pack
给韩愈、张辽、认知显影、巨人认知分别裁剪的上下文包。

这样能解决 258k context 限制：Codex 不再吃整批原文，而是调度文件化上下文。大模型长上下文能力可以作为“原始材料压缩器”，但不应成为整个工作流的唯一承载方式。

是否改造韩愈 我不建议把“提纲对齐上下文包”塞进韩愈本体。原因是你未来还有其他主笔风格，如果让韩愈承担上下文架构职责，这个能力就不通用了。

更合理的是新增一个独立角色或 Skill：

Outline Context Architect
= 提纲对齐上下文包构建者

韩愈只需要轻量改造：输出提纲时给每个提纲点稳定编号、核心命题、材料需求提示。真正把材料对齐到提纲点的工作交给专门助手。

评审会话保存 每个评审员应保持自己的会话，不混在一个总会话里。推荐结构：

02-outline/
  main-writer-sessions/
    han-yu/
      round-01/
        session.md
        report.md

  review-rounds/
    round-01/
      review-brief.md
      shared-outline-context-pack.md
      zhang-liao/
        dispatch-pack.md
        session.md
        report.md
      cognitive-imaging/
        dispatch-pack.md
        session.md
        report.md
      giant-cognition/
        dispatch-pack.md
        session.md
        report.md
      synthesis.md
      repair-request.md

这里 session.md 保存交流过程，report.md 保存可被 Orchestrator 读取的最终结果。Orchestrator 默认读 report，不读所有 session，除非需要追溯。

下一步 CCPE 侧应该做什么 我建议先做 3 个 CCPE 工件：

workbench/analysis/outline-review-runtime-creation-brief.md
workbench/upgraded/outline-context-architect.agent.md
workbench/upgraded/outline-review.runtime.md

其中 Outline Context Architect 可以先做成 Agent Spec，暂不急着做 Skill。等试跑后确认它的步骤稳定，再抽成 context-pack-builder Skill。

结论：现在的关键不是增加评审智能体，而是建立“提纲-材料-评审”之间的上下文中间层。先做 Outline-Aligned Context Pack，再跑一轮提纲评审 Runtime v0，试跑结果会告诉我们 writing-workbench 的项目目录该怎么正式细化。

3

我同意你的先做 3 个 CCPE 工件。 而根据之前的A/B测试，回归测试等等，发现从CCPE框架到Lite版，你的升级工作做的不到位——丢失了原有专家味。所以先包装了original-kernel-minimal-lite作为ROI最高的版本。 那么现在要新创建的，在我原先流程里不存在，是

1. 我用CCPE旧版框架打造，你再包装成original-kernel-minimal-lite
2. 还是你直接打造
3. 还是你尽量沿用旧版CCPE框架打造

我觉得这几个在这里不算专家，只算助手，可能也不需要注入CCPE框架。现在，只做过旧CCPE到System的评审、升级，还没有启用过Create技能。能不能做出效果好的，我也不确定。 这个你怎么看？

我的判断：这次不适合走 original-kernel-minimal-lite 路线。

原因很简单：original-kernel-minimal-lite 的前提是有一个已经验证过、带专家味的旧源提示词。它的价值在于“保护原始工作内核”。但 Outline Context Architect 和 Outline Review Runtime 是你旧流程里没有的中间层，不存在可保护的原始专家核。硬造一个旧版 CCPE，再包装成 kernel，反而会制造伪来源。

我建议采用第 2 种和第 3 种的折中：

直接用 CCPE System Creator Mode 创建
但不要写成重型专家
而是尽量沿用旧 CCPE 的清晰层次感和约束密度

也就是说，不注入“专家人格”，但保留旧 CCPE 里有效的东西：任务边界、输入输出、工作步骤、禁止事项、质量标准、冲突处理、人类决策点。

三个工件可以这样定位：

outline-review-runtime-creation-brief.md
= 先把场景、边界、目录假设、上下文流转说清楚。

outline-context-architect.agent.md
= 助手型 Agent Spec，不追求专家味，追求稳定、可复用、低幻觉、能处理大材料。

outline-review.runtime.md
= 交互式 Runtime，定义韩愈、评审员、上下文包、会话记录、报告、修复请求如何流转。

我不建议现在做成 Lite，因为它不是给 Web/Gemini/Claude 单独聊天用的“人格专家”，而是工作流里的结构化助手。它更像一个 CCPE-Agent + 后续可抽 Skill。试跑后如果发现它经常被单独调用，再补一个 Lite 版本也不迟。

风险确实存在：这是第一次真正启用 Create，而不是迁移旧专家。应对方式不是回到旧 CCPE，而是把第一版当成 v0 可测试工件：

先创建
再用一个真实提纲项目试跑
看它是否能产出可用的 Outline-Aligned Context Pack
再决定是否抽 Skill、修 Runtime、或给它补 Lite 版本

所以我的推荐路线是：

1. 不先让你用旧 CCPE 打造。
2. 不做 original-kernel-minimal-lite，因为没有原始 kernel。
3. 由我直接用 CCPE System Creator Mode 起草，但刻意保持“助手型、流程型、低人格化”。
4. 第一版只追求可试跑，不追求一次成型。
5. 试跑后再升级，而不是凭空过度设计。

这个方向比较符合现在的问题本质：我们缺的不是专家味，而是上下文工程和评审调度的工作骨架。

4

哦，我说错了，新做的三个不需要Lite版，完全是基于Agentic架构的。这种操作太繁琐，在单智能体环境下，全部是我手工传递，这三个我用不起来。

好了，我们对齐了思路，你现在创建这三个，然后告诉我下一步我做什么。什么时候去writingproject开启试验，怎么开启。

已创建三份 CCPE 草案，都是 Agentic 架构用的，不是 Lite：

• outline-review-runtime-creation-brief.md
• outline-context-architect.agent.md
• outline-review.runtime.md

我也做了验证：三个文件都存在，front matter、Human Decision Gates、Outline-Aligned Context Pack、review-rounds/round-01 等关键结构都在。当前只新增草案，未改 writing-workbench 模板。

下一步你可以现在就去 writing-workbench 开启试验，但前提是手上已经有一份初稿提纲。试验不必先改全局模板，先开一个真实或半真实项目跑通：

C:/Users/wangq/Documents/Codex/writing-workbench/projects/active/YYYY-MM-DD-aNNN-temp-slug/

试验启动条件：

project.md
source-map.md
status.md
00-creation-plan/creative-brief.md
02-outline/outlines/outline-v1.md

然后在 writing-workbench 新线程里给 Codex 的启动指令可以是：

请先阅读 docs/context-handoff.md 和 templates/article-project/PROJECT_STRUCTURE.md。
然后参考 ccpe-system 中这三个草案：
- C:/Users/wangq/Documents/Codex/ccpe-system/workbench/analysis/outline-review-runtime-creation-brief.md
- C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/outline-context-architect.agent.md
- C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/outline-review.runtime.md

现在从已有初稿提纲进入提纲评审试跑。不要改全局模板，先在当前 article project 内建立 context/ 和 02-outline/review-rounds/round-01/，准备 outline-aligned context pack 和三位评审员 dispatch pack。

你要先准备的是：初稿提纲路径、参与评审员名单、这轮允许使用的素材范围。素材不需要一次性整理完，但 source-map.md 至少要列清楚“哪些材料可用、在哪里、读者是否可见”。

5

我到writing-workbench中，它做了一轮评审报告给我，我发现和以前报告的形式截然不同，它的意思是模拟，然后说：

    是的，问题本质就是这个：当前环境还没有“真正把某个 CCPE agent 作为独立角色启动”的执行层。

    回答你的几个问题：

    1. **重做三位评审员 dispatch pack 是谁的工作？**

    是我这边 Writing Workbench 运行层的工作，但它暴露出 CCPE-System 还缺一个更明确的接口规范。

    更准确地说：

    - `ccpe-system` 负责提供 canonical agent prompt：张辽、认知显影、巨人认知等。
    - `writing-workbench` 负责在具体项目里生成“可投递给该 agent 的完整 dispatch pack”。
    - 但目前我写的 dispatch pack 只是任务说明，不是完整 agent 启动包。这是我的执行问题。

    合格的 dispatch pack 应该至少包含：

    - canonical prompt 路径
    - 是否需要粘贴完整 prompt
    - 本轮任务指令
    - 输入文件清单
    - 输出格式
    - 会话连续性要求
    - 明确写出：这是发给哪个 agent 的完整启动内容，还是只给 orchestrator 用的索引

    如果要跨平台复制给 Gemini/GPT/Claude 上的张辽，它还应生成一个 `prompt-to-send.md`，里面包含“张辽 prompt + 本轮任务 + 上下文包 + 输出要求”。

    2. **如果是 CCPE-System 的工作，你需要过去准备什么？**

    CCPE-System 需要补的是“Agent Invocation / Dispatch Pack 标准”，也就是 canonical agent 如何被 Writing Workbench 消费。

    建议 CCPE-System 补一个小规范或 Runtime 子协议：

    ```text
    Agent Invocation Packet
    - canonical_agent_prompt_path
    - invocation_mode: full_prompt_paste | prompt_path_reference | native_agent_id
    - role_integrity_requirement
    - task_context
    - input_files
    - output_contract
    - continuity_policy
    ```

    但这不是现在的阻塞条件。我可以先在当前项目里按这个思路重做本轮 dispatch pack。

它说的对么，你的工作没完成？

它说得对。更准确地说：我前面三份草案完成了“提纲评审 Runtime 的结构”，但漏掉了一个关键执行接口：canonical CCPE agent 如何被真正启动。 所以不是整个工作没完成，而是 Runtime v0 暴露出一个必须补的接口层。

我已经补到这三份文件里：

• outline-review-runtime-creation-brief.md
• outline-context-architect.agent.md
• outline-review.runtime.md

补的核心是 Agent Invocation Packet Protocol：

dispatch-pack.md
= 本轮任务与上下文分发包，不一定能独立启动 agent。

agent-invocation-packet.md
= 明确 canonical prompt 路径、启动模式、输出契约、连续性要求。

prompt-to-send.md
= 如果要去 Gemini/GPT/Claude 外部平台运行，就必须生成这个完整可复制启动包。

并写入了 canonical prompt 路径：

han-yu-main-writer: agents/lite/han-yu.prompt.md
zhang-liao: agents/lite/zhang-liao.prompt.md
cognitive-imaging: agents/lite/cognitive-imaging-practitioner.prompt.md
giant-cognition: agents/lite/giant-cognition.prompt.md

你回到 writing-workbench 后，下一步不要让它继续“模拟评审”。让它先重做本轮三个评审员的调用包：

请重新读取：
C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/outline-review.runtime.md

重点执行 7.1.1 Agent Invocation Packet Protocol。

不要模拟张辽、认知显影、巨人认知的评审。
请为 round-01 的每个评审员生成：
- dispatch-pack.md
- agent-invocation-packet.md
- prompt-to-send.md

如果当前环境不能真正启动对应 canonical agent，就停在 prompt-to-send.md，等待我把它投递到对应平台或新会话。

已有那轮“模拟评审报告”建议标记为无效或 simulation-only，不要当作正式评审结果进入 synthesis。正式流程应该是：先生成 prompt-to-send.md，再由真实张辽/认知显影/巨人认知跑出各自 report.md，最后再做 synthesis。

6

不光是这三个评审员，韩愈还有其他三个刚建的，都缺少接口或封装吧？ 我还没顾上问它，除了3个评审员，其他四个是不是模拟了。如果是，那从素材压缩到拆分再到提纲我都白费劲了。 你检查下，缺的都补上。

你这个担心是对的。缺口不只三个评审员。

我检查后确认：前一版协议只把 agent-invocation-packet.md 明确写给了“三位评审员”，但没有封死：

• Outline Context Architect 的真实调用接口
• 韩愈修复提纲时的真实调用接口
• Runtime operator 不能模拟任何 canonical agent 的规则
• 如果不能真实调用，应该停在 prompt-to-send.md 而不是产出正式结果

我已经补上了，并新增了一个独立子协议：

• agent-invocation-packet.protocol.md
• outline-review.runtime.md
• outline-context-architect.agent.md
• outline-review-runtime-creation-brief.md

现在覆盖的 participant 是：

outline-context-architect
han-yu-main-writer
zhang-liao
cognitive-imaging
giant-cognition

并且写入了硬规则：

不能真实调用 canonical agent 时：
1. 生成 agent-invocation-packet.md
2. 生成 prompt-to-send.md
3. 标记 blocked_waiting_for_external_agent_output
4. 停止，不得模拟正式输出

如果 writing-workbench 已经模拟了素材压缩、上下文拆分、三位评审、韩愈修复提纲，那些都不能当正式成果。建议统一标记为：

simulation-only
excluded-from-synthesis
not-a-formal-report

你回到 writing-workbench 后，让它重新读取这个文件：

C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/agent-invocation-packet.protocol.md

然后要求它先不要继续评审或修提纲，而是补齐当前项目里所有 participant 的启动包：

请不要模拟任何 canonical agent 输出。
请为 outline-context-architect、han-yu-main-writer、zhang-liao、cognitive-imaging、giant-cognition 分别检查是否已有真实 invocation record。
没有的话，生成 agent-invocation-packet.md。
如果当前环境不能真实调用该 agent，生成 prompt-to-send.md 并停止。
已有模拟输出全部标记为 simulation-only，不进入 synthesis。

这次补完后，writing-workbench 就不应该再把“运行层自己写的结果”误当成韩愈或评审员的正式输出。

7

我准备再次启动测试，但是需要做个调整，从观点开始，到评审阶段。 由于是测试，观点阶段就两个回合：

1. 我准备好项目文件夹，放入观点素材文件。进入codex，发指令写文章，观点在哪儿，让韩愈看立意和切入
   • 期望韩愈输出立意
2. 我审核韩愈的立意、确认。
   • 期望韩愈输出提纲
3. 接下来就直接进入评审提纲了。

这是真实的流程。

我放的观点素材文件，包括了Mapping的src，需要Agent自己压缩，自己拆分。 这个时机是什么时候，应该是1中的韩愈输出前吧；而不是到了3提纲评审，不然韩愈咋立意，咋输出提纲，对吧。

那么除了韩愈和评审员，你前面做的三个智能体都需要调整吧？

另外不论在生成提纲，还是评审提纲阶段，甚至将来的生成正文时，都可能会面临补充的素材，有补充素材，就需要压缩拆分。

你对此怎么看？ 你判断是对的：压缩拆分不能等到提纲评审阶段才做。真实流程里，它必须发生在韩愈立意之前，否则韩愈只能靠用户一句“观点在哪儿”来判断切入，后面的提纲和评审都会建立在不完整上下文上。

我已经把 CCPE 侧调整为这个流程：

观点素材文件
-> Outline Context Architect 压缩/拆分
-> premise-context-pack.md
-> 韩愈看立意和切入
-> 用户确认立意
-> 韩愈输出 outline-v1.md
-> Outline Context Architect 生成 outline-aligned context pack
-> 三位评审员真实调用
-> synthesis / repair-request

已修改这几份：

• outline-review.runtime.md
• outline-context-architect.agent.md
• outline-review-runtime-creation-brief.md
• agent-invocation-packet.protocol.md

也补了“补充素材”规则：任何阶段新增素材，都先由 Outline Context Architect 判断影响范围：

positioning_impact
outline_impact
review_impact
repair_impact
drafting_impact

只刷新受影响的 source digest / premise pack / outline pack / dispatch pack，不整套推倒重来。

你去 writing-workbench 再测时，可以这样下指令：

请重新读取：
C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/outline-review.runtime.md
C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/outline-context-architect.agent.md
C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/agent-invocation-packet.protocol.md

这次测试从观点素材开始，不从已有提纲开始。
先处理 source-map 指向的观点素材，调用 Outline Context Architect 生成 context/premise/premise-context-pack.md。
不要模拟韩愈。
然后为韩愈 positioning 生成 dispatch-pack.md、agent-invocation-packet.md、prompt-to-send.md。
如果当前环境不能真实调用韩愈，就停在 prompt-to-send.md，等待我投递。

这样测试才是真实链路：先材料工程，再韩愈立意，再韩愈提纲，再评审。

8

1. 真实写作流程 从观点讨论开始是正常写作流程，而非仅仅是测试流程；从提纲评审开始，这个很少。现在这套若成熟了，就会停止从提纲开始。 所以我觉得，可以直接删掉从提纲评审开始。 背景： 从提纲评审开始，是你了解了我的写作流程后建议的，我也没多想；然后刚刚那个作废了的测试，也是从观点开始的，我发现我没法从提纲评审开始。

2. 我理解的Outline Context Architect是项目经理，我启动写作流程，它不接管么？

3. 会话窗口，合理的协作会话窗口是什么，谁在主会话，谁在子会话？除了这些专家智能体外，CCPE那三个工件呢？

下面是之前跑测试时我发给writing的，供参考：

## 我之前（单智能体环境）在评审阶段的工作流程

1. 第一轮
我会同时发给张辽、认知显影和巨人认知，让他们评审。
得到3份评审结果后，我会汇总，可能也会给出我的解题思路，这个阶段也可能会补充素材。
然后让韩愈基于评审意见进行调整。调整有两种：
* 改动小，没有大的逻辑漏洞时：韩愈直接输出新提纲；
* 改动大，涉及立意调整，大的漏洞时：我会让韩愈先出修订计划，修订计划可能还会有讨论的过程，然后一致后再输出新提纲。

这样进入第二轮。

2. 第N轮。
启动阶段：主要是根据上次的评审意见，会对参与的评审员有删减。这个主要我基于上次评审意见，我看看问题大不大，不是所有问题都要修。
结束阶段：修订完提纲后，也是我来判断，是否要进入下一轮评审；还是直接确定提纲，可以进入撰写阶段。

## 之前（单智能体）的会话管理

1. 尽管三个智能体都是出评审报告，之后也都能对话；但是我一般只和张辽除了有评审报告外，还可能会对话。其他智能体只作为评审员。与张辽的交流内容，大多会影响后续修订的方向，可以视作评审报告的补充材料。而韩愈总是在一个会话里。
2. 评审智能体需要保持自己的会话，这样它可以追溯上次的问题，在新提纲中是否得到修复。
3. 是否重启会话，发起人是我，一般取决于两点：
   1. 会话是否比较长，我查觉到了幻觉。
   2. 评审员的会话中，我加入了一些侧重点——比如让它看看是否充分利用素材；但是后续不需要这个侧重。
4. Gemini上是100万Tokens的Context，我不太注重节约。重启的会话也是自己打包素材，指令这些进度管理。

## 现在的会话

1. 我们这个会话，目前刚刚进入第6个回合。Context用到了48%，还剩52%。应该是韩愈之前的工作也全部都是在主会话里。
   1. 好处是：韩愈就是你，Context共享。
   2. 缺点是：我们本次做测试，素材很少，就放了一篇；我之前的学术性散文经常会有20万字的素材，当然那时候也没拆分（像现在专门做压缩的）
2. 需要你考虑下，主会话子会话最合理的形式，以减少不停的交接，做会话之间的转移。

你说得对，我已经按这个判断改了：标准入口现在就是从观点素材开始，不再保留“从已有提纲进入评审”的分支。那个入口是我们前面为了先抽小闭环临时设的，现在看不符合真实写作流程，已经删掉。

已更新：

• outline-review.runtime.md
• outline-context-architect.agent.md
• outline-review-runtime-creation-brief.md

关于 Outline Context Architect：它接管上下文工程层，但不是总项目经理。总项目经理应该是主会话里的 Runtime Operator / Article Production Orchestrator。它负责推进轮次、问你决策、调度韩愈/评审员、汇总报告、生成修复请求。Outline Context Architect 负责素材压缩、拆分、premise-context-pack、outline-aligned context、补充素材影响判断。

我也补了会话拓扑：

主会话：
Runtime Operator / Article Production Orchestrator
负责项目控制、状态、决策门、调度、综合、repair-request。

上下文子会话：
Outline Context Architect
负责 source digest、premise pack、outline pack、补充素材刷新。

主笔子会话：
韩愈
建议贯穿立意、提纲生成、提纲修复，除非你要求重启或出现漂移。

评审子会话：
张辽：建议跨轮保持，因为你常和它继续对话。
认知显影 / 巨人认知：默认 report-only，可跨轮保持，但不必频繁对话。

CCPE 那几个工件不是会话本身：

outline-review.runtime.md = 主会话操作协议
outline-context-architect.agent.md = 上下文子会话的角色规范
agent-invocation-packet.protocol.md = 所有子会话启动/交接协议
creation-brief = 设计依据和验收标准

你回 writing-workbench 可以这样启动新测试：

请重新读取 ccpe-system 的：
C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/outline-review.runtime.md
C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/outline-context-architect.agent.md
C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/agent-invocation-packet.protocol.md

这次按标准写作入口执行：从观点素材开始，不从已有提纲开始。
主会话只做 Runtime Operator / Orchestrator，不模拟任何 canonical agent。
先调用 Outline Context Architect 生成 premise-context-pack。
然后为韩愈 positioning 生成 invocation packet / prompt-to-send。
如果不能真实调用韩愈，就停下等待我投递。

9

如果不能真实调用韩愈，就停下等待我投递。 应该是任一不能调用都暂停吧？

主会话只做 Runtime Operator / Orchestrator，不模拟任何 canonical agent。 有新加的工件，接口有没有漏？ 现在一共四个工件了么

工件名字合理么？现在还是outline-review，将来测试跑通是新建，还是改名字？