wantsong
/
knowledge-vault
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
knowledge-vault/discussions/technology/Codex/1.重构CCPE/配合COS1.md

20 KiB
Raw Blame History

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。

我建议本批采用这个设计原则：

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”：

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/。当前供应结论是：

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 的加工厂”，而是专家智能体、认知模型、可复用方法、调用契约的锻造层。

我们这些讨论的，对你的规则应该有影响吧。你需要调整这些规则，然后提交同步。 这次工作就结束了。