9.4 KiB
1
我先搭建的ccpe-system，即本项目，帮我打造智能体。
之后，我决定把我的知识管理体系，工作流程搬进来。现在知识库knowledge-vault打造完毕，写作工作台writing-workbench初始架构搭建完毕。
请先阅读C:/Users/wangq/Documents/Codex/writing-workbench/docs/context-handoff.md，了解上下文。
按照写作流程的试错阶段工作：
1. 升级并验证关键单智能体 Lite。
2. 对每个 Lite 做场景探查：
- 只是专家评审者：保留 Lite / Agent Spec 可选
- 有稳定职责和输入输出：升级 Agent Spec
- 有可复用动作方法：升级 Skill
- 有稳定内嵌模型：抽 Model Card
3. 构造提纲评审 Runtime，并补充主控 Agent。
4. 在 writing-workbench 启动试错项目验证。
5. 根据失败点修复 Runtime、主控、上下文包、评审者或目录结构。
6. 提纲评审稳定后，再扩展到不含审判庭的全流程。
7. 最后再纳入审判庭、建模者委员会。
我们先搭建评审提纲阶段相关的单智能体 Lite。 这部分包括：
- 认知显影，评审员，已经升级
- 巨人认知，评审员，已经升级
- 张辽，评审员，待升级
- 韩愈，主笔之一，待升级
认知显影、巨人认知都是一次性评价，我基本上不做讨论；张辽，输出评审报告后，我可能会与它讨论。 但是这些都要保持会话上下文：我提供提纲1.0完成第一次评审；我再次提供提纲2.0时，它会结合1.0的评审结果，审查我是否修复，然后输出新的评审。 而不是调用一次就结束了。 是否需要开启新的会话，这个主动权在我。考虑到多轮评审可能会有污染，我会开启新会话让它从头看。
我计划先做评审员的升级验证，韩愈是否OK，可能得到writing-workbench中验证。
- 认知显影，我们之前做了A/B测试，已经相对稳定
- 巨人认知，升级完成后没有做A/B测试，我是否在升级巨人认知的会话中，做A/B测试验证？
- 张辽，将在本会话中升级，验证
- 韩愈，本会话中升级
这些完成后，构造提纲评审 Runtime，并补充主控 Agent。
然后我到writing-workbench 启动试错项目验证。
对此，你有什么问题么？我们先对齐思路。
整体思路我认同，而且你的阶段划分是对的：先把单智能体 Lite 稳住，再做 Runtime 和主控 Agent。这里最关键的是不要把“多轮会话”误解成“必须依赖同一个聊天上下文”。更稳的设计应该是：
评审员 Lite 本身支持连续评审，但连续性的输入应显式化：
当前提纲
上一版提纲
上一轮评审报告
用户已做的修复说明（可选）
本轮评审目标
这样你可以选择继续同一会话，也可以开新会话。开新会话时，只要把前一轮 report.md 和必要上下文包给进去，它仍然能做“是否修复”的追踪审查，且污染更少。
我建议下一步顺序是：
-
先补做“巨人认知”A/B 或压力测试
不一定要回到原升级会话做。更干净的方式是在本会话或独立验证会话中，用同一组提纲样本测试旧版/新版/期望输出差异。目标不是追求形式一致，而是确认巨人认知没有丢掉它的判断力和模型锋芒。 -
本会话升级“张辽”评审员 Lite
张辽需要比认知显影、巨人认知多一个能力：评审后可讨论。因此 Lite 里应明确区分：- 首轮评审模式
- 追踪复审模式
- 讨论澄清模式
- 新会话重启模式
但它仍然先保持 Lite，不急着做 Agent Spec。等进入 Outline Review Runtime 后，如果它有稳定 I/O 和调度位置，再补 Agent Spec。
-
本会话升级“韩愈”主笔 Lite
韩愈不是同类评审员，我会先做成写作/改写/文气控制的 Lite。它是否合格，确实更适合放到writing-workbench的试错项目里验证，因为它要面对真实文章上下文，而不是只看孤立提纲。 -
然后构造 Outline Review Runtime + Article Production Orchestrator
Runtime 负责文件化连续性：生成 context pack、分发给评审员、收集 report、综合修复建议、等待你决策。主控 Agent 不替你做最终判断，只负责组织流程和减少复制粘贴。
我现在主要有 4 个需要对齐的问题：
-
张辽、韩愈的原始提示词或材料现在分别在哪个路径？是在
ccpe-system/workbench/raw/，还是knowledge-vault/prompts/或别处？ -
张辽升级后是否只作为“提纲评审员”，还是也会进入正文评审、战略判断、选题判断？
-
韩愈在当前阶段的职责是“根据提纲写初稿”，还是“评审/改造提纲的文气、结构、论证势能”？这会影响 Lite 的核心任务定义。
-
巨人认知 A/B 测试，你希望我先做一个独立验证报告，还是只在升级张辽前快速压力测一下，发现问题再修？
我的建议是：先拿到张辽、韩愈源材料路径，然后我按“审计 → 场景探查 → Lite 升级 → 小样本验证”的顺序推进；巨人认知则先做轻量验证，不先大改。
2
-
路径 由于
ccpe-system在knowledge-vault之前建设，约定了workbench/raw/目录。 现在知识库已经全部建立。所有提示词（你需要升级的）都在knowledge-vault/prompts/。这部分需要更新相应的文档。 每次升级前，我会告诉你具体基于哪个文件来升级（告诉你文件路径），比如张辽有几个版本。 -
张辽 张辽本质上是红队和建设性苏格拉底，所以它不仅能做提纲评审，还会做其他评审，包括但限于你讲的那些方面，还有对我的观点的逻辑漏洞检查等等。 原版位置：
C:\Users\wangq\Documents\Codex\knowledge-vault\prompts\ccpe\legacy-ccpe\强哥的虎贲卫\张辽\张辽1.1.md -
韩愈 在单智能体中，韩愈做了从观点、立意、提纲、正文撰写，附录撰写、会话迁移等一系列工作。 其内部有四个附件，分别是我的文章风格约定、提纲范本、全局论述注意事项、撰写前的CoT脚本模板。它依据这四个附件约束了/强化了能力。 原版位置：
C:\Users\wangq\Documents\Codex\knowledge-vault\prompts\ccpe\legacy-ccpe\强哥的虎贲卫\韩愈\韩愈1.1.md -
巨人 A/B 测试
我已经完成巨人的 A/B测试，现在的升级策略做了重大调整：original-kernel-minimal-lite first, refined-lite later。
以下制度文件都有更新：
同时巨人保持在original-kernel-minimal-lite状态。
建议：
我们不在本会话中，做A/B测试。本会话是打造会话，我可以在其他会话中做A/B测试，做个别Agent的调优。
- 先了解制度文件变更。
- 然后处理张辽至
original-kernel-minimal-lite，这个简单 - 韩愈，可能需要讨论下它的附件怎么处理。
已按你的新策略推进了一步：不做 A/B，不做 refined rewrite，先走 original-kernel-minimal-lite。
我完成了三件事：
-
更新了来源路径规则
README.md 和 AGENTS.md 已改为：维护中的提示词来源默认在knowledge-vault/prompts/，workbench/raw/只作为临时或未分类输入区。 -
生成了张辽的最小内核 Lite 草稿
zhang-liao-original-kernel-minimal-lite.prompt.md保留了原版核心：
- 同行评审员 + 启发式教练
- 结构主义拆解 / 第一性原理 / 反例边界测试
- 智识诚实优先
- 《建设性批判报告》
- 报告后多轮讨论
只做了最小修复：
- 移除“全知模式”口径
- 修复联网检索边界
- 修复 hidden chain-of-thought 风险
- 增加 1.0 / 2.0 版本复审规则
- 修复原提示词中 workflow 重复段落
- 增加输出层级纪律和自检
-
生成了简短升级报告
zhang-liao-original-kernel-minimal-lite-upgrade-report.md
韩愈附件处理，我建议先不直接拆。当前更稳的方案是：
original-kernel-minimal-lite阶段：四个附件继续内嵌或压缩内嵌，保证 Web 单智能体可用。writing-workbench验证阶段：把四个附件转成上下文包资产，由项目运行时注入。- Runtime 稳定后：再判断哪些附件应成为 Skill、模板或 Model Card。
也就是说，韩愈第一版不要为了结构洁癖牺牲可用性。它的附件不是噪音，而是能力来源；先保留，再在实际写作流程里拆分。
验证：我确认张辽文件只写入 workbench/upgraded/，没有推进到 agents/lite/。当前 git 工作区还有多项你之前的制度和模型索引变更，我只新增/修改了上述文件，没有回退其他改动。
3
我看了张辽，和我预想的不一样。