693 lines
35 KiB
Markdown
693 lines
35 KiB
Markdown
# 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 个：
|
||
|
||
```text
|
||
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：提纲对齐上下文包**
|
||
```text
|
||
【提纲点 1】
|
||
- 我的核心观点：
|
||
- 相关讨论摘要：
|
||
- 可用论据：
|
||
- 可用例子：
|
||
- 可引用材料：
|
||
- 禁止展开/不作为主线的内容：
|
||
|
||
【提纲点 2】
|
||
- 我的核心观点：
|
||
- 相关讨论摘要：
|
||
- 可用论据：
|
||
- 可用例子：
|
||
- 可引用材料：
|
||
- 禁止展开/不作为主线的内容：
|
||
```
|
||
2. 可以对我的原始材料进行与文章立意、使用相关的**无损信息压缩：**
|
||
* 我的观点、思路有时候会很口语化，就是我想到哪儿，写到哪儿
|
||
* 我放入的过往文章，往往都是整篇放入，（以前单智能体下，不然我就得手工做相关信息提炼）；我的过往文章又是学术性散文，很多内容都是做“异常处理”——防止反方观点的。
|
||
|
||
我们在这里打造智能体，会约定它的工作目录，将来需要有一份文档，让`writing-workbench`去看着调整。
|
||
|
||
3. 提纲评审阶段，评审员也都需要这些上下文；这些上下文就是文章观点的支撑。现在的韩愈输出的提纲，没有对齐包。我们是改造韩愈，还是再做一个韩愈的助手，或者专门的助手。因为学术性散文是韩愈，我还有其他文章风格的主笔智能体。
|
||
4. Context限制。过往都是一股脑扔到Gemini的Context中，因为它支持100万字；而我们现在的Codex，只支持258k。
|
||
5. 韩愈修改提纲，其他评审员评审，都需要保持各自的会话，除非Context限制/或者我要求重启，需要交接。
|
||
6.
|
||
|
||
下面是之前的**深度创作流程**，供参考：
|
||
|
||
```md
|
||
这里涉及到写文章的工作流程，每个环节的产物。我将之前的从灵感到发布的全部过程梳理一下。
|
||
由于`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/` 分散在每个阶段里当作独立实体。上下文应该是一套，但可以有多个“视图”。
|
||
|
||
**核心目录调整**
|
||
把项目级上下文集中到根目录，例如：
|
||
|
||
```text
|
||
context/
|
||
context-manifest.md
|
||
global-context-pack.md
|
||
source-digests/
|
||
outline-aligned/
|
||
dispatch-packs/
|
||
```
|
||
|
||
各阶段目录里的 `context-packs/` 不再保存主上下文，只保存“本阶段使用的上下文视图”或链接说明。也就是说：
|
||
|
||
```text
|
||
02-outline/context-packs/
|
||
```
|
||
|
||
可以保留，但它应当指向或派生自项目根目录的 `context/`，不再各自维护一套散乱材料。
|
||
|
||
**上下文分层**
|
||
你现在需要的不是简单压缩，而是“面向文章用途的结构化压缩”。我建议分四层：
|
||
|
||
```text
|
||
L0 Raw Sources
|
||
原始材料仍在 knowledge-vault 或项目 source-map 指向的位置，不复制全文。
|
||
|
||
L1 Source Digest
|
||
每份材料生成一份面向当前文章的摘要：核心观点、可用段落、反方处理、不可用内容、读者可见性。
|
||
|
||
L2 Outline-Aligned Context Pack
|
||
按提纲点对齐材料，就是你写的那个结构。
|
||
|
||
L3 Agent Dispatch Pack
|
||
给韩愈、张辽、认知显影、巨人认知分别裁剪的上下文包。
|
||
```
|
||
|
||
这样能解决 258k context 限制：Codex 不再吃整批原文，而是调度文件化上下文。大模型长上下文能力可以作为“原始材料压缩器”，但不应成为整个工作流的唯一承载方式。
|
||
|
||
**是否改造韩愈**
|
||
我不建议把“提纲对齐上下文包”塞进韩愈本体。原因是你未来还有其他主笔风格，如果让韩愈承担上下文架构职责，这个能力就不通用了。
|
||
|
||
更合理的是新增一个独立角色或 Skill：
|
||
|
||
```text
|
||
Outline Context Architect
|
||
= 提纲对齐上下文包构建者
|
||
```
|
||
|
||
韩愈只需要轻量改造：输出提纲时给每个提纲点稳定编号、核心命题、材料需求提示。真正把材料对齐到提纲点的工作交给专门助手。
|
||
|
||
**评审会话保存**
|
||
每个评审员应保持自己的会话，不混在一个总会话里。推荐结构：
|
||
|
||
```text
|
||
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 工件：
|
||
|
||
```text
|
||
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 种的折中：
|
||
|
||
```text
|
||
直接用 CCPE System Creator Mode 创建
|
||
但不要写成重型专家
|
||
而是尽量沿用旧 CCPE 的清晰层次感和约束密度
|
||
```
|
||
|
||
也就是说，不注入“专家人格”，但保留旧 CCPE 里有效的东西：任务边界、输入输出、工作步骤、禁止事项、质量标准、冲突处理、人类决策点。
|
||
|
||
三个工件可以这样定位：
|
||
|
||
```text
|
||
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 可测试工件**：
|
||
|
||
```text
|
||
先创建
|
||
再用一个真实提纲项目试跑
|
||
看它是否能产出可用的 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架构的。这种操作太繁琐，在单智能体环境下，全部是我手工传递，这三个我用不起来。
|
||
|
||
好了，我们对齐了思路，你现在创建这三个，然后告诉我下一步我做什么。什么时候去`writing`project开启试验，怎么开启。
|
||
|
||
已创建三份 CCPE 草案，都是 Agentic 架构用的，不是 Lite：
|
||
|
||
- [outline-review-runtime-creation-brief.md](C:/Users/wangq/Documents/Codex/ccpe-system/workbench/analysis/outline-review-runtime-creation-brief.md)
|
||
- [outline-context-architect.agent.md](C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/outline-context-architect.agent.md)
|
||
- [outline-review.runtime.md](C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/outline-review.runtime.md)
|
||
|
||
我也做了验证：三个文件都存在，front matter、Human Decision Gates、Outline-Aligned Context Pack、`review-rounds/round-01` 等关键结构都在。当前只新增草案，未改 `writing-workbench` 模板。
|
||
|
||
下一步你可以**现在就去 `writing-workbench` 开启试验**，但前提是手上已经有一份初稿提纲。试验不必先改全局模板，先开一个真实或半真实项目跑通：
|
||
|
||
```text
|
||
C:/Users/wangq/Documents/Codex/writing-workbench/projects/active/YYYY-MM-DD-aNNN-temp-slug/
|
||
```
|
||
|
||
试验启动条件：
|
||
|
||
```text
|
||
project.md
|
||
source-map.md
|
||
status.md
|
||
00-creation-plan/creative-brief.md
|
||
02-outline/outlines/outline-v1.md
|
||
```
|
||
|
||
然后在 `writing-workbench` 新线程里给 Codex 的启动指令可以是：
|
||
|
||
```text
|
||
请先阅读 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`中，它做了一轮评审报告给我，我发现和以前报告的形式截然不同，它的意思是模拟，然后说：
|
||
|
||
```md
|
||
|
||
是的，问题本质就是这个：当前环境还没有“真正把某个 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](C:/Users/wangq/Documents/Codex/ccpe-system/workbench/analysis/outline-review-runtime-creation-brief.md)
|
||
- [outline-context-architect.agent.md](C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/outline-context-architect.agent.md)
|
||
- [outline-review.runtime.md](C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/outline-review.runtime.md)
|
||
|
||
补的核心是 `Agent Invocation Packet Protocol`：
|
||
|
||
```text
|
||
dispatch-pack.md
|
||
= 本轮任务与上下文分发包，不一定能独立启动 agent。
|
||
|
||
agent-invocation-packet.md
|
||
= 明确 canonical prompt 路径、启动模式、输出契约、连续性要求。
|
||
|
||
prompt-to-send.md
|
||
= 如果要去 Gemini/GPT/Claude 外部平台运行，就必须生成这个完整可复制启动包。
|
||
```
|
||
|
||
并写入了 canonical prompt 路径：
|
||
|
||
```text
|
||
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` 后，下一步不要让它继续“模拟评审”。让它先重做本轮三个评审员的调用包：
|
||
|
||
```text
|
||
请重新读取：
|
||
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](C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/agent-invocation-packet.protocol.md)
|
||
- [outline-review.runtime.md](C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/outline-review.runtime.md)
|
||
- [outline-context-architect.agent.md](C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/outline-context-architect.agent.md)
|
||
- [outline-review-runtime-creation-brief.md](C:/Users/wangq/Documents/Codex/ccpe-system/workbench/analysis/outline-review-runtime-creation-brief.md)
|
||
|
||
现在覆盖的 participant 是：
|
||
|
||
```text
|
||
outline-context-architect
|
||
han-yu-main-writer
|
||
zhang-liao
|
||
cognitive-imaging
|
||
giant-cognition
|
||
```
|
||
|
||
并且写入了硬规则：
|
||
|
||
```text
|
||
不能真实调用 canonical agent 时：
|
||
1. 生成 agent-invocation-packet.md
|
||
2. 生成 prompt-to-send.md
|
||
3. 标记 blocked_waiting_for_external_agent_output
|
||
4. 停止，不得模拟正式输出
|
||
```
|
||
|
||
如果 `writing-workbench` 已经模拟了素材压缩、上下文拆分、三位评审、韩愈修复提纲，那些都不能当正式成果。建议统一标记为：
|
||
|
||
```text
|
||
simulation-only
|
||
excluded-from-synthesis
|
||
not-a-formal-report
|
||
```
|
||
|
||
你回到 `writing-workbench` 后，让它重新读取这个文件：
|
||
|
||
```text
|
||
C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/agent-invocation-packet.protocol.md
|
||
```
|
||
|
||
然后要求它先不要继续评审或修提纲，而是补齐当前项目里所有 participant 的启动包：
|
||
|
||
```text
|
||
请不要模拟任何 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 侧调整为这个流程：
|
||
|
||
```text
|
||
观点素材文件
|
||
-> Outline Context Architect 压缩/拆分
|
||
-> premise-context-pack.md
|
||
-> 韩愈看立意和切入
|
||
-> 用户确认立意
|
||
-> 韩愈输出 outline-v1.md
|
||
-> Outline Context Architect 生成 outline-aligned context pack
|
||
-> 三位评审员真实调用
|
||
-> synthesis / repair-request
|
||
```
|
||
|
||
已修改这几份：
|
||
|
||
- [outline-review.runtime.md](C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/outline-review.runtime.md)
|
||
- [outline-context-architect.agent.md](C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/outline-context-architect.agent.md)
|
||
- [outline-review-runtime-creation-brief.md](C:/Users/wangq/Documents/Codex/ccpe-system/workbench/analysis/outline-review-runtime-creation-brief.md)
|
||
- [agent-invocation-packet.protocol.md](C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/agent-invocation-packet.protocol.md)
|
||
|
||
也补了“补充素材”规则：任何阶段新增素材，都先由 Outline Context Architect 判断影响范围：
|
||
|
||
```text
|
||
positioning_impact
|
||
outline_impact
|
||
review_impact
|
||
repair_impact
|
||
drafting_impact
|
||
```
|
||
|
||
只刷新受影响的 source digest / premise pack / outline pack / dispatch pack，不整套推倒重来。
|
||
|
||
你去 `writing-workbench` 再测时，可以这样下指令：
|
||
|
||
```text
|
||
请重新读取：
|
||
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`的，供参考：
|
||
|
||
```md
|
||
|
||
## 我之前（单智能体环境）在评审阶段的工作流程
|
||
|
||
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](C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/outline-review.runtime.md)
|
||
- [outline-context-architect.agent.md](C:/Users/wangq/Documents/Codex/ccpe-system/workbench/upgraded/outline-context-architect.agent.md)
|
||
- [outline-review-runtime-creation-brief.md](C:/Users/wangq/Documents/Codex/ccpe-system/workbench/analysis/outline-review-runtime-creation-brief.md)
|
||
|
||
关于 `Outline Context Architect`：它**接管上下文工程层**，但不是总项目经理。总项目经理应该是主会话里的 `Runtime Operator / Article Production Orchestrator`。它负责推进轮次、问你决策、调度韩愈/评审员、汇总报告、生成修复请求。`Outline Context Architect` 负责素材压缩、拆分、premise-context-pack、outline-aligned context、补充素材影响判断。
|
||
|
||
我也补了会话拓扑：
|
||
|
||
```text
|
||
主会话：
|
||
Runtime Operator / Article Production Orchestrator
|
||
负责项目控制、状态、决策门、调度、综合、repair-request。
|
||
|
||
上下文子会话：
|
||
Outline Context Architect
|
||
负责 source digest、premise pack、outline pack、补充素材刷新。
|
||
|
||
主笔子会话：
|
||
韩愈
|
||
建议贯穿立意、提纲生成、提纲修复，除非你要求重启或出现漂移。
|
||
|
||
评审子会话：
|
||
张辽：建议跨轮保持，因为你常和它继续对话。
|
||
认知显影 / 巨人认知：默认 report-only，可跨轮保持，但不必频繁对话。
|
||
```
|
||
|
||
CCPE 那几个工件不是会话本身：
|
||
|
||
```text
|
||
outline-review.runtime.md = 主会话操作协议
|
||
outline-context-architect.agent.md = 上下文子会话的角色规范
|
||
agent-invocation-packet.protocol.md = 所有子会话启动/交接协议
|
||
creation-brief = 设计依据和验收标准
|
||
```
|
||
|
||
你回 `writing-workbench` 可以这样启动新测试：
|
||
|
||
```text
|
||
请重新读取 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`，将来测试跑通是新建，还是改名字？
|
||
|