knowledge-vault/work/internal/强哥的思想宇宙/讨论/Local-Agent/0.1本地的CCRA放在哪儿.md

1

我之前在WEB的ChatGPT上打造了一个GPT：“认知科学产品规划架构师--CCRA”，它主要协助我从模糊产品想法中挖掘本质需求，打磨产品形态，规划 MVP，分析关键技术可行性，并输出可交接给 Codex 的产品计划书。 在Codex开了一个项目，C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong，负责具体的模型提炼、回归测试等等。 目前已经进展了4轮，我发现我的工作主要是传递，将评审材料上传到GPT的交流窗口里，将GPT的意见转达给Codex，评审材料的路径：C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\ccra_review_bundle；少部分是与GPT讨论规划，对Codex的工作进行评价。

对我来说，有价值的是少部分的这个工作，而转递工作是繁琐且价值低下的。于是我与GPT交流，是否可以在本地打造一个Agent。 它的回复参见对话记录C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\讨论\2026-06-18产品交流-GPT.md 338行 至 文档末尾。

我本地有一个打造Agent的CCPE System，C:\Users\wangq\Documents\Codex\ccpe-system\；还有完成自动化的C:\Users\wangq\Documents\Codex\skills-vault。这两个都是做工具打造的。

那么我现在的Agent应该怎么做？我的思路如下：

环境初始化: C:\Users\wangq\Documents\Codex\work-projects是我的项目总路径，我在其下建立一个the-mindscape-of-bro-tsong-ccra-reviewer，这个作为一个新项目来做本地CCRA Review工作。 我在the-mindscape-of-bro-tsong-ccra-reviewer项目中，与Codex交流，初始化后，生成对Agent或者Skill的需求单： 类似C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\requirements这样。 然后到CCPE或者skills-vault中去打造。 然后回来搭建CCPE的Agent调用环境。

本地评审工作： 将每轮的评审资料先发给（本地链接，引用即可）the-mindscape-of-bro-tsong-ccra-reviewer。

---

我的问题：

1. 在the-mindscape-of-bro-tsong-ccra-reviewer中，Codex是否会调用Agent，在主会话还是子会话中？
2. 你对这个有什么建议么？

建议做，但不要把它做成“复制网页版 GPT 的本地人格”。更稳的定位是：

the-mindscape-of-bro-tsong-ccra-reviewer = 本地 CCRA Review 控制台项目
它负责收束评审材料、生成调用包、记录本地评审报告、沉淀需求单；真正的 Reviewer Agent 和自动化 Skills 分别去 ccpe-system / skills-vault 打造。

1. Codex 会在主会话还是子会话调用 Agent？

默认不会自动调用独立 Agent。你在 reviewer 项目里和 Codex 对话时，当前 Codex 主会话只是“操作者 / 调度者”。如果只是写一个 AGENTS.md 或安装 Skill，通常还是当前主会话加载这些规则来工作。

如果你要保留 CCRA 的“正交审查”价值，就应该明确规定：

• 主会话：只做调度、整理材料、生成 invocation packet、归档结果。
• 子会话 / 新线程 / subagent：执行 ccra-reviewer 的只读评审。
• Skills：做确定性检查，比如 bundle audit、routing diff、lifecycle scan。
• 原项目 Codex 执行会话：根据 reviewer findings 回到 the-mindscape-of-bro-tsong 修文件。

也就是说，机械检查可以在主会话跑；带判断性的 CCRA Review 应该在子会话或新线程跑。如果在同一个主会话里让 Codex“扮演 CCRA”，那只能算 preliminary self-review，不应该当成正式 CCRA 评审。

2. 我的建议

我建议你按三层做：

第一层：新建 C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong-ccra-reviewer
这个项目只做评审工作台，不复制原项目。建议目录：

requirements/
review-runs/
invocation-packets/
reports/
scripts/
AGENTS.md
README.md

每轮只引用原项目 bundle 路径，比如：

C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\ccra_review_bundle\round-04.1_2026-06-18_selector-rule-patch

第二层：在 ccpe-system 打造 ccra-local-reviewer 的 Agent 规格
放角色契约、评审 rubric、报告格式、禁止事项、调用边界。重点写清楚：

• 只读审查，不直接改业务文件；
• 优先读 source files、diff、reports、tests，不优先读 Codex 总结；
• 必须指出反证、非目标行为变化、测试未证明的产品判断；
• 不自动决定模型升级；
• 输出 findings / risk / next actions。

第三层：在 skills-vault 做少量高价值 Skill
不要一开始做五六个。先做两个最值钱的：

routing-diff-audit
round-init-context-builder

然后再补：

review-bundle-audit
lifecycle-guard
regression-gate-check

最终工作流可以是：

原项目 Codex 生成 review bundle
-> reviewer 项目生成 invocation packet
-> 子会话运行 ccra-local-reviewer
-> 输出 LOCAL_CCRA_REVIEW_REPORT.md
-> 主会话归档并提炼给执行 Codex
-> 原项目 Codex 修复
-> Skill 跑 diff / regression / lifecycle gate
-> Owner 决定是否关闭 round

最重要的边界是：reviewer 项目是控制台，CCPE 是 Agent 规格工厂，skills-vault 是自动化工具源码仓，.agents\skills 是安装运行面。
你这个方向是对的，但第一版要克制：先把“少搬运 + 真隔离 + 可归档”跑通，再扩大自动化。

2

问题：

1. 那如果主会话都是模拟，只能是子会话调用，我还有必要将本地审核单独成项目么，我不如在原项目the-mindscape-of-bro-tsong中直接打造审核者？
2. 按我的理解，CCRA推荐Agent的那些Skill，应该不全是skill-vault的职责，有些应该是CCPE为Agent配套打造的。因为skills-vault的skill，一是自动化，二是有通用性。

你的理解更准确，我会修正上一版建议。

1. 不一定需要单独建 the-mindscape-of-bro-tsong-ccra-reviewer

如果目标只是让 CCRA 评审在子会话中真实发生，目录隔离不是关键，调用隔离才是关键。正交性来自：

• 子会话 / 新线程独立读取材料；
• reviewer 只读，不直接修；
• reviewer 优先读 bundle、diff、reports、tests；
• 输出固定评审报告；
• 主会话只做调度和归档。

所以对当前项目，我更建议先不要新建独立项目，而是在原项目里加一个评审运行区，例如：

C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\
  ccra_review_bundle\
  local_ccra_reviews\
    round-05\
      invocation-packet.md
      prompt-to-send.md
      LOCAL_CCRA_REVIEW_REPORT.md
      owner-decision.md
  requirements\
    ccra-local-reviewer-requirements.md

这样证据、bundle、报告、执行修复都在同一个项目历史里，路径最短，也最不容易产生“评审工作台和真实项目脱节”。

但我不建议把“审核者本体”直接做成这个项目里的私有规则。原项目里可以放调用包、需求单、评审记录；Agent 规格本体仍应进入 ccpe-system。否则它会变成这个项目的临时 prompt，而不是可复用的 CCRA 审查能力。

独立 reviewer 项目只有在这几种情况下才值得建：

• 你想让它跨多个 work-projects 统一管理评审；
• 你想把本地 CCRA 当成长期运营台，有自己的报告索引、模板、批处理脚本；
• 原项目不希望混入任何评审过程文件；
• 你需要集中对比多个项目的 CCRA 评审质量。

当前阶段，我建议：先原项目内运行，成熟后再抽出 review workspace。

2. 你对 Skill 归属的判断是对的

CCRA 提到的那些 “Skill” 不应该全放 skills-vault。应该按性质分层：

ccpe-system
  Agent / reviewer spec
  cognitive review rubric
  lifecycle gate policy
  round governance workflow
  evaluation method spec

skills-vault
  deterministic automation
  reusable scripts
  file/package audit
  routing diff checker
  manifest validator
  report generator

更具体地说：

• routing-diff-audit：偏自动化、可复用，适合 skills-vault。
• review-bundle-audit：偏文件结构检查，也适合 skills-vault。
• round-init-context-builder：如果只是生成上下文文件，适合 skills-vault；如果包含 CCRA 判断框架，则 CCPE 里定义规则，skills-vault 只执行模板生成。
• lifecycle-guard：分两层。生命周期守门原则属于 ccpe-system；扫描文件里是否错误升级 status/stability/regression_status 的脚本属于 skills-vault。
• regression-gate-check：运行测试、校验结果属于 skills-vault；判断测试是否足以支撑模型升级属于 CCRA Agent / CCPE 评审规则。

所以我会把方案调整成：

原项目 the-mindscape-of-bro-tsong
  存放每轮本地 CCRA 调用包、评审报告、Owner 决策

ccpe-system
  打造 ccra-local-reviewer Agent 规格和评审协议

skills-vault
  打造通用自动化 Skill 和脚本

子会话 / 新线程
  真正执行 CCRA review

一句话：不要为“正交性”单独建项目；为“长期运营多个项目的 CCRA 审查台”才单独建项目。当前先在原项目内做 review run，更务实。