321 lines
20 KiB
Markdown
321 lines
20 KiB
Markdown
# 1
|
||
|
||
`C:\Users\wangq\Documents\Codex\work-projects\Cognitive-OS-Wantsong\requirements\ccpe\2026-06-20-m2-cognitive-runtime-prompt-contracts.md`
|
||
|
||
这是Cognitive-OS（COS）提供的需求单。
|
||
|
||
你看完后，先提出你的问题，我确认或者提供相应的素材。
|
||
|
||
我已读完需求单。先做轻量判定：这是一个 **CCPE 供应请求**，目标是为 COS M2 提供 **canonical Prompt Cards + Runtime Spec + model-call protocol + evaluation rubric + Local CCRA readiness boundary**。它属于 CCPE，不应落成产品仓库里的 canonical prompt 真源。
|
||
|
||
我需要你确认这些问题后再动手：
|
||
|
||
1. **七个 Prompt Card 是“具体可用卡”还是“合同模板”？**
|
||
需求里写“templates or concrete cards”。我倾向于先做 **concrete canonical contracts**，但避免写成产品本地 prompt 实现。
|
||
|
||
2. **M2 Runtime 的最小闭环是否固定为这 7 步？**
|
||
Intake / QPI / Lens Orchestration / IA / Synthesis / Reader Translation / Feedback Decision 是否都必须进入 M2a-M2b，还是可以定义“必需链路 + 可选链路”？
|
||
|
||
3. **QPI 与 Intellectual Archaeology 的当前权威来源是哪几个文件？**
|
||
需求列了 `models/qpi.md`、`models/intellectual-archaeology.md`、`model-registry.json`。是否以这三个为准，还是还要同步读取产品仓库的 workflow/orchestration docs？
|
||
|
||
4. **Reader Translation 的目标读者是谁？**
|
||
是面向你自己做认知加工后的“可读报告”，还是面向外部读者/客户/公开内容？这会影响 Prompt Card 的语气、证据边界和行动建议边界。
|
||
|
||
5. **Lens Orchestration 允许调度哪些 lens？**
|
||
目前只允许 QPI + Intellectual Archaeology，还是可以为后续 lens 预留插槽但标记为 forbidden/unregistered？
|
||
|
||
6. **M2 的运行方式要定义到什么粒度？**
|
||
我建议 Runtime Spec 先定义为 **manual-first / semi-automated-ready**：人手动推进、文件记录清楚、未来可接 adapter。你是否接受这个定位？
|
||
|
||
7. **model-call protocol 是否需要绑定具体模型/平台？**
|
||
例如 GPT、Gemini、Claude、Codex，还是只定义抽象调用协议：model registry lookup、primary/support role、prompt contract reference、trace capture、handoff payload？
|
||
|
||
8. **Local CCRA readiness 是“规则边界”还是要产出一个正式 protocol 文件？**
|
||
需求写 boundary rule。我倾向于做成 Runtime Spec 内的 readiness section，再单独产出一个短文件也可以。
|
||
|
||
9. **是否允许 CCPE 创建 product-facing integration registration？**
|
||
例如记录 `Cognitive-OS-Wantsong` 是 consumer repo，CCPE artifacts 是 canonical supplier，产品仓库只能持有 adapters/sample runs。
|
||
|
||
10. **请确认本批输出路径。**
|
||
我建议先放在 CCPE 草稿区：
|
||
`workbench/upgraded/cognitive-os-m2/`
|
||
等你确认后再决定是否提升到 `agents/lite/`、`runtimes/hybrid/`、`skills/evaluation/`、`integrations/` 等 canonical 目录。
|
||
|
||
如果你确认，我下一步会先读取需求单列出的 COS 产品文件，产出一份 **Creation Brief + proposed file list**，不会直接生成全部 artifact。
|
||
|
||
# 2
|
||
|
||
1. **七个 Prompt Card 是“具体可用卡”还是“合同模板”？**
|
||
这个问题我没有看懂，“具体可用卡”、“合同模板”的区别是什么，了解了这个，我才能判断。
|
||
|
||
2. **M2 Runtime 的最小闭环是否固定为这 7 步？**
|
||
它的链路来自于我的文章，`C:\Users\wangq\Documents\Codex\knowledge-vault\rules\cognitive-science\综合认知模型\Wantsong认知操作系统.md`，文章里其实有定义必需，可选这些。
|
||
MVP 2阶段是先打造雏形；后续会增加核心10个模型左右；再后续会扩展到100个模型。但后续扩充的，基本上都是《Wantsong认知操作系统》中的第3阶、第4阶及之后的。不排除有第二阶的，我有一个“知行合一”也比较底层，可能会和思想考古并列。
|
||
|
||
3. **QPI 与 Intellectual Archaeology 的当前权威来源是哪几个文件？**
|
||
`models/qpi.md`、`models/intellectual-archaeology.md`、`model-registry.json`，以这三个为准。
|
||
将来你的`model-cards`将链接到COS的`models`，以COS的为准。
|
||
COS的现在还在打造过程中，它这边模型更新后，我会回来重新改造对应的Skill/Agent。
|
||
|
||
4. **Reader Translation 的目标读者是谁？**
|
||
M2只是我自己，后面还会加转译层。
|
||
|
||
5. **Lens Orchestration 允许调度哪些 lens？**
|
||
目前只有QPI + Intellectual Archaeology，可以为后续 lens 预留插槽但标记为 forbidden/unregistered。
|
||
|
||
6. **M2 的运行方式要定义到什么粒度？**
|
||
运行方式：COS独立子线程调用，记录调用过程和结果。
|
||
|
||
7. **model-call protocol 是否需要绑定具体模型/平台？**
|
||
不用绑定具体模型/平台
|
||
|
||
8. **Local CCRA readiness 是“规则边界”还是要产出一个正式 protocol 文件？**
|
||
这个我没看懂问题。
|
||
|
||
9. **是否允许 CCPE 创建 product-facing integration registration？**
|
||
这部分，可能还需要你提供一些思路，允许与不允许的优劣。
|
||
|
||
10. **请确认本批输出路径。**
|
||
同意先放在 CCPE 草稿区`workbench/upgraded/cognitive-os-m2/`
|
||
|
||
---
|
||
|
||
现在还是讨论阶段，有些问题我回复了，有些还需要进一步解释。
|
||
我回复，你不清楚的，或者新问题，可以继续提问。
|
||
|
||
|
||
这几个问题可以先这样拆开：
|
||
|
||
**1. “具体可用卡” vs “合同模板”**
|
||
|
||
“合同模板”是写给未来制卡人的元模板，比如规定一张 COS Prompt Card 必须有哪些字段：输入、输出、权限、停止条件、trace 要求、失败处理等。它本身不能直接跑 QPI 或思想考古。
|
||
|
||
“具体可用卡”是已经针对某一步写好的 canonical contract，比如 `qpi-routing.prompt.md`：它明确接收什么输入、如何做 QPI 定性、输出什么结构、哪些判断不能做、什么时候停止。产品仓库的 adapter 或独立子线程可以引用它来运行。
|
||
|
||
我建议本批做 **具体可用的 canonical prompt contracts**，但不要写成产品本地实现。也就是：CCPE 提供权威合同，COS 以后只写 adapter / invocation packet / run record。
|
||
|
||
**8. Local CCRA readiness：规则边界 vs 正式 protocol**
|
||
|
||
“规则边界”就是一句或一节明确门槛：什么时候不能启动 Local CCRA，什么时候可以启动。例如：M2 在没有最小手动样本、调用记录、trace、reader output、反馈决策前，不允许进入 Local CCRA。
|
||
|
||
“正式 protocol 文件”则是一个完整流程文件：谁发起、读哪些文件、怎么调用 reviewer、输出什么报告、如何记录、失败怎么处理。
|
||
|
||
我建议 M2 先只做 **readiness boundary**，放进 Runtime Spec 和 Evaluation Rubric 里。等第一次 minimal manual sample 跑完，再决定是否需要独立 `local-ccra-readiness.protocol.md`。
|
||
|
||
**9. product-facing integration registration 的取舍**
|
||
|
||
允许它的好处：CCPE 可以清楚登记 COS 是 consumer repo，COS 的 `models/` 是模型权威源，CCPE 只供应 prompt/runtime/evaluation contract；这能防止产品仓库里的 adapter 被误当 canonical prompt。
|
||
|
||
代价：多一个维护文件，而且 COS 还在快速变化，登记太早可能显得过重。
|
||
|
||
我的建议是：本批先做一个 **轻量 integration note / draft registration**，只记录边界，不把它提升成复杂治理文件。
|
||
|
||
当前我会把 M2 先理解为：
|
||
|
||
- Runtime：COS 独立子线程调用，必须记录调用过程和结果。
|
||
- 模型权威：以 COS 的 `models/qpi.md`、`models/intellectual-archaeology.md`、`model-registry.json` 为准。
|
||
- 当前 lens：只允许 QPI + 思想考古；未来 lens 只预留 `forbidden/unregistered` 插槽。
|
||
- Reader Translation：M2 面向你自己，不面向外部读者。
|
||
- 输出位置：先放 `workbench/upgraded/cognitive-os-m2/`。
|
||
|
||
我下一步只需要你确认一个关键选择：
|
||
|
||
七个 Prompt Card，本批是否按 **“具体可用的 canonical contract”** 来写，而不是只写元模板？
|
||
|
||
# 3
|
||
|
||
**1. “具体可用卡” vs “合同模板”**
|
||
|
||
是的，本批做 **具体可用的 canonical prompt contracts**。产品定义在CCPE，调用在业务Projects（COS，knowledge-vault……）。这个符合规划。
|
||
|
||
**8. Local CCRA readiness：规则边界 vs 正式 protocol**
|
||
|
||
`Local CCRA`是前面为`the-mindscape-of-bro-tsong`打造的，但是这个项目失败了偏离了方向，基于它的重构衍生出了现在的`Cognitive-OS-Wantsong`项目，Local CCRA还能为`Cognitive-OS-Wantsong`服务，但是作用变轻了。
|
||
`Local CCRA`现在是一个可用的Agent，且还包括了5个它的skill。这些skill都是环境里实装的，实际是你提出需求单，由skills-vault打造。
|
||
|
||
> 什么时候不能启动 Local CCRA
|
||
就具体这个问题来说，这个判断在`业务Projects`，你这里应该只提供工具。
|
||
类似的，你这里还有建成的张辽、显影等Agent，这些什么时候调用，调用谁，都是`业务Projects`决定，你这里只做agent/skill的定义。
|
||
|
||
我不知道我理解你的问题了没，但是我的规划是这样的。
|
||
|
||
**9. product-facing integration registration 的取舍**
|
||
|
||
确认以下理解：
|
||
|
||
- Runtime：COS 独立子线程调用，必须记录调用过程和结果。
|
||
- 模型权威：以 COS 的 `models/qpi.md`、`models/intellectual-archaeology.md`、`model-registry.json` 为准。
|
||
- 当前 lens：只允许 QPI + 思想考古；未来 lens 只预留 `forbidden/unregistered` 插槽。
|
||
- Reader Translation：M2 面向你自己，不面向外部读者。
|
||
- 输出位置：先放 `workbench/upgraded/cognitive-os-m2/`。
|
||
|
||
> 七个 Prompt Card，本批是否按 **“具体可用的 canonical contract”** 来写，而不是只写元模板？
|
||
|
||
按 **“具体可用的 canonical contract”** 来写。
|
||
|
||
---
|
||
|
||
**关于COS的Model在变化**
|
||
|
||
之前的`the-mindscape-of-bro-tsong`把注意力全部放在QPI上，且只考虑边界，不考虑实际推进的效果。花了4~5天，4、5亿Tokens在模型库的治理，而不是作用或者效果。这是作废掉的主因。
|
||
现在重建COS，会更加关注模型本身。
|
||
每一次迭代，可能都会对model文件进行变更。
|
||
这里涉及到我们用什么方式来构造`canonical contract`。你可以看下我之前的单智能体的`房玄龄`：
|
||
`C:\Users\wangq\Documents\Codex\knowledge-vault\prompts\ccpe\ccpe\强哥的虎贲卫\房玄龄2.0.md`
|
||
|
||
房玄龄对model的引用实际上放在了附录里，当然正文中也有一些，但是正文中变化都是不大的那部分。
|
||
|
||
如果借鉴这样的引用方式是否可行，将附录变成知识库文件，要求Agent使用时再加载对应的Model文件，这样可以减少CCPE重构Agent的过程。
|
||
|
||
可以，房玄龄这个模式值得借鉴，但 COS 这里要比房玄龄再前进一步。
|
||
|
||
房玄龄是：
|
||
|
||
- 正文：稳定角色、能力、流程、边界。
|
||
- 附录：内嵌模型本体，也就是 QPI 规则。
|
||
- 使用时：Agent 直接读自身附录，不需要外部模型加载。
|
||
|
||
COS M2 我建议改成：
|
||
|
||
- 正文：稳定的 canonical prompt contract，定义这一步要做什么、输入输出、权限、trace、停止条件、失败处理。
|
||
- 模型依赖：不内嵌完整模型，只声明必须加载哪些 COS 模型文件。
|
||
- 运行时：由业务 Project 的独立子线程 / adapter 在调用时把当前模型文件加载进上下文，并在 run record 里记录模型路径、版本/commit/hash、调用结果。
|
||
|
||
也就是说，CCPE 产出的不是“携带模型全文的老式单体 Agent”，而是 **外部模型绑定型 Prompt Contract**。
|
||
|
||
这能解决你说的高频模型迭代问题：COS 的 `models/qpi.md`、`models/intellectual-archaeology.md` 变化后，CCPE 的 contract 不需要每次重构；除非模型的输入输出结构、权限边界、运行流程发生变化，才需要回来改 CCPE contract。
|
||
|
||
我建议本批采用这个设计原则：
|
||
|
||
```text
|
||
Prompt Contract = stable execution contract
|
||
COS model files = current cognitive model authority
|
||
Adapter / subthread = loads model + records run
|
||
Run record = proves which model version was actually used
|
||
```
|
||
|
||
Local CCRA 这里，你的理解我认为是对的。CCPE 不应该替业务 Project 判断“现在是否启动 Local CCRA”。CCPE 只提供：
|
||
|
||
- Local CCRA 作为可调用能力的定义 / 引用边界；
|
||
- 如果某个 Runtime 会交给 Local CCRA，就定义调用包需要什么；
|
||
- 不把 Local CCRA 的启动时机写死成 CCPE 决策。
|
||
|
||
所以需求单里的“Boundary rule for when Local CCRA can review the milestone”，我会改写成更准确的：**Local CCRA invocation readiness contract**。它不是替 COS 决策，而是规定：如果 COS 决定调用 Local CCRA，至少应该供应哪些输入、调用记录、模型版本、样本输出和边界声明。
|
||
|
||
下一步我只问一个问题：
|
||
|
||
COS M2 的七个 Prompt Contract 是否都采用这个统一模式：**不内嵌完整模型正文，只声明 required model context，并要求调用方在独立子线程中加载 COS 当前模型文件、记录模型版本和运行结果？**
|
||
|
||
# 4
|
||
|
||
**关于七个 Prompt Contract 是否都采用这个统一模式**
|
||
|
||
这个问题，本质是CCPE的定位问题。
|
||
|
||
为什么加了一道CCPE的手续，使事情变得复杂？
|
||
我是这样考虑的。专家智能体交给CCPE，非专家智能体的可以驳回，由业务Project自己构造。
|
||
专家智能体：拥有一套自己的人设或者认知模型，往往需要提炼专家的隐形经验来完成。
|
||
|
||
CCPE System前身是我的CCPE，一套构造提示词的方法论。只需要做专家智能体，才需要这种重型的工程方式。
|
||
|
||
假设我们把这7个都排除在外，然后看哪些能吸收：
|
||
1. QPI，原始的模型是一套方法，还有自己的一些组件，可以考虑吸收
|
||
2. IA（思想考古），一套挖掘方法，方法本身比较简单，但是想要获得一份完整的考古报告，报告样例参见`C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\agents\虎贲卫&龙骧营\思想考古\人类通用认知的七层架构-思想考古报告.md`，考古过程参见`C:\Users\wangq\Documents\Codex\knowledge-vault\discussions\agents\虎贲卫&龙骧营\思想考古\人类通用认知的七层架构-思想考古过程.md`。这个挖掘不是那么简单的。
|
||
……
|
||
|
||
这样来考虑的话，这7个你觉得哪些你可以拒绝呢？
|
||
|
||
或者你觉得CCPE System的定位是什么？
|
||
|
||
我同意你这个修正：**不是 COS 提了 7 个 prompt，CCPE 就应该照单全收 7 个 canonical Prompt Cards。**
|
||
CCPE 的定位不应是“所有 prompt 的中央仓库”，而应是 **专家智能体 / 认知模型 / 可复用方法 / 调用契约的锻造层**。
|
||
|
||
我会这样划线：
|
||
|
||
**CCPE 应该吸收的东西**：带有专家判断、认知模型、隐性经验、复杂方法、跨项目复用价值，或者一旦写错会扭曲认知结果的 artifact。
|
||
|
||
**CCPE 应该驳回的东西**：产品本地编排、胶水 prompt、一次性输出格式、运行记录、业务项目自己决定的调用时机、具体 adapter、Local CCRA 是否启动这类项目决策。
|
||
|
||
我看了你给的思想考古报告和过程文件。IA 不是一个“七层填表 prompt”，它有地图生成、用户校正、逐层下潜、理论融合、最终报告重构这些动作。因此 IA 明显属于 CCPE 可以吸收的专家能力。
|
||
|
||
对 7 个 M2 步骤，我建议这样分层：
|
||
|
||
| 步骤 | CCPE 处理建议 | 理由 |
|
||
|---|---|---|
|
||
| Intake / Value Assessment | 吸收，但轻量 | 它是认知加工强度分流器，有方法论，但不是重型专家 Agent。可做 Prompt Contract / Skill Spec。 |
|
||
| QPI Routing | 吸收，重点 | 有独立模型、组件、误判风险高，是 front-routing / misframing diagnosis，不是普通分类器。 |
|
||
| Lens Orchestration | 不做独立专家 Prompt Card | M2 只有 QPI + IA，本质更像 Runtime 边界和产品编排。可写进 Runtime Spec，不必做成专家智能体。 |
|
||
| Intellectual Archaeology Runner | 吸收，重点 | 这是专家方法，且报告质量依赖隐性经验、逐层追问、结构重构。应成为 CCPE 核心 contract。 |
|
||
| Synthesis and Calibration | 部分吸收 | 如果只是合并报告，交给项目；如果是校准置信度、证据边界、行动边界，则 CCPE 应提供 contract/rubric。 |
|
||
| Reader Translation | M2 先驳回 | 当前只给你自己看，属于产品本地表达层。以后面向外部读者、客户、公开内容时再升级为 CCPE translation agent/skill。 |
|
||
| Feedback and Asset Decision | 不做独立 Prompt Card | 资产是否沉淀、模型是否更新、是否启动 Local CCRA，是业务 Project 的 owner gate。CCPE 可提供评估 rubric，但不替它决策。 |
|
||
|
||
所以我推荐的方案是第三种，不是“全收 7 个”，也不是“只收 QPI/IA”：
|
||
|
||
```text
|
||
CCPE full absorb:
|
||
- QPI Routing
|
||
- Intellectual Archaeology Runner
|
||
|
||
CCPE light contract / rubric:
|
||
- Intake / Value Assessment
|
||
- Synthesis and Calibration
|
||
|
||
Runtime-level boundary only:
|
||
- Lens Orchestration
|
||
|
||
Project-local for M2:
|
||
- Reader Translation
|
||
- Feedback and Asset Decision
|
||
```
|
||
|
||
这也会改变本批产物设计：七个里不是都写成同等级 Prompt Card，而是写成 **2 个核心专家 contract + 2 个轻量认知 contract + 1 个 Runtime 编排边界 + 2 个项目本地适配建议**。
|
||
|
||
我下一步的问题：你是否接受这个“分级吸收”原则？如果接受，我后面就不会强行给 7 个都做 canonical Prompt Card。
|
||
|
||
# 5
|
||
|
||
1. 规则
|
||
我们这一次讨论出来了CCPE System的核心标准：**专家智能体 / 认知模型 / 可复用方法 / 调用契约的锻造层**
|
||
这个应该作为你的核心指导原则，不论是外部项目，甚至是我，要求你打造Agent时，你都需要用这个标准比对一下，其是否符合CCPE价值。
|
||
没有价值的应该退回。
|
||
|
||
2. 全部退回
|
||
|
||
讨论自此，我觉得有几个点：
|
||
1. 你可以把这次讨论的内容，帮我总结一下。它可以对齐思路，CCPE是做什么的。
|
||
2. 我觉得COS应该先做一份相对稳定的模型出来，再提需求单。不论是QPI还是思想考古，它继承的是`the-mindscape-of-bro-tsong`，但是原来这个项目就没有在模型质量上做处理，全部做的是边角料。
|
||
3. 如果模型达到了1.0，完全可以让它启动子线程（去掉污染），跑出来试行效果后，我再来打造。所以我觉得现在这个过程有问题。
|
||
|
||
这次结论可以收束成一句话：
|
||
|
||
**CCPE System 不是“所有 Prompt 的加工厂”，而是专家智能体、认知模型、可复用方法、调用契约的锻造层。**
|
||
|
||
这应该成为以后 CCPE 的前置筛选标准。外部 Project 或你本人提出“做 Agent / Prompt / Runtime”时，CCPE 先判断它是否具备 CCPE 价值：是否有专家隐性经验、稳定认知模型、可复用方法、跨项目调用契约，或高风险认知边界。没有这些，就退回业务 Project 自建。
|
||
|
||
对 COS 这份 M2 需求单，我同意现在应 **全部退回**。理由是：当前问题不在 prompt contract，而在 QPI、思想考古等模型本身还没有达到足够稳定、可验证、可复用的 1.0 状态。现在让 CCPE 做七个 contract，会提前把不成熟模型固化，重复 `the-mindscape-of-bro-tsong` 的偏航：大量精力花在治理、边界、selector、审查周边，而不是模型质量和实际加工效果。
|
||
|
||
更合理的顺序是：
|
||
|
||
1. COS 先在业务 Project 内把核心模型打磨到相对稳定的 `1.0`。
|
||
2. 用干净独立子线程试跑，记录输入、模型版本、过程、输出和效果。
|
||
3. 确认 QPI / 思想考古确实有专家能力和复用价值后，再向 CCPE 提需求。
|
||
4. CCPE 再决定吸收为 Prompt Card、Agent Spec、Skill、Runtime，还是只给调用契约。
|
||
|
||
本轮没有生成文件，也不应继续推进 `workbench/upgraded/cognitive-os-m2/`。当前供应结论是：
|
||
|
||
```text
|
||
supplier_decision: returned
|
||
reason: source models are not stable enough for CCPE canonical contract forging
|
||
next_owner: Cognitive-OS-Wantsong
|
||
next_task: stabilize and trial-run model 1.0 before resubmitting CCPE request
|
||
```
|
||
# 6
|
||
|
||
> CCPE System 不是“所有 Prompt 的加工厂”，而是专家智能体、认知模型、可复用方法、调用契约的锻造层。
|
||
|
||
我们这些讨论的，对你的规则应该有影响吧。你需要调整这些规则，然后提交同步。
|
||
这次工作就结束了。
|
||
|