# 代码语义条件协议（Code Semantic Condition Protocol）v1.0 > 状态：文档先行（GPT 2026-08 评审建议 + 荣 CCG 方向确认） > 定位：**代码实现负责执行，中文语义注释负责声明条件，条件图负责索引，白箱负责路由。** > 原则：代码不能只有「能运行的实现」，还必须拥有「可被白箱认知和路由的语义入口」。 > 与 CCG 闭合：注释=图的索引（名实），条件图=路由（条件→代码），白箱=执行/路由。 > 哲学映射：功能条件=条件空间（when）、子功能=结构（what parts）、执行方式=过程（how）、 > 不适用条件=盲区边界（when NOT——与盲区注册表同构）。 ## 0. 四要素注释格式 每个函数/类/包的语义注释固定为四要素（标记词可兼容既有「生效条件/执行」）： ```python def predict_routes(problem, context): """【功能条件】 当问题需要根据已有知识寻找可执行推理路径时使用。 输入必须包含待判断问题与当前认知上下文。 【子功能】 ① 识别问题对应条件空间 ② 沿条件/因果边搜索候选路径 ③ 条件约束过滤无效路径 ④ 标记语义诱导路径及可信等级 ⑤ 无法归属时返回结构性盲区 【执行方式】 先识别问题锚点，再沿条件/因果边递归搜索； 对候选路径做条件约束验证，返回可执行路径及状态。 【不适用条件】 ① 输入不存在有效问题锚点时不调用 ② 不负责修改知识图结构 ③ 无法验证因果关系时不得将语义相似当作因果结论 """ ``` | 要素 | 标记（兼容） | 含义 | 图索引角色 | |---|---|---|---| | 功能条件 | 功能条件 / 生效条件 | 何时使用；输入/前置状态 | 条件节点（路由门槛） | | 子功能 | 子功能 | 内部能力分解 | 子功能节点（结构检索） | | 执行方式 | 执行方式 / 执行 | 步骤/调用/结果 | 执行词节点（机制检索） | | **不适用条件** | **不适用条件**（新增） | 何时不能用；约束/边界 | **盲区节点（负路由）** | ## 1. verifier 检查 - R1 函数/类中文注释（已有） - R2 注释中文语境（已有） - R3 三要素标记（功能条件/子功能/执行方式——兼容 生效条件/执行）（已有，681 达标） - **R4 不适用条件**（新增）：主函数注释须含「不适用条件」标记； 自动生成草稿（参数边界/None 分支提取）+ 外部精修；升级期软模式，全库达标后开硬检查 ## 2. 认知图集成（代码知识入白箱体系） ``` 认知图 │ ┌──────────┼──────────┐ ↓ ↓ ↓ 理论知识 工程知识 代码知识（CCG） │ 函数/类/包 │ 条件→子功能→执行→不适用 ``` 白箱遇工程问题「如何实现 X」： ``` 问题 → 识别条件 → 查询注释索引（CCG）→ 定位函数/类/包 → 读取实际代码 → 执行/修改 ``` ## 3. 修改纪律（语义入口约束） 白箱修改代码时，**先改语义声明，再改实现**： 条件描述 → 子功能 → 执行路径 →（不适用条件）→ 实现 ——语义与实现同改，索引不失效；CCG 重新建图后检索仍可达。 ## 4. 自迭代闭环 ``` 中文注释 → 语义结构 → 条件图 → 代码定位 → 代码执行 → 执行结果 → 预测误差 → 更新条件图/注释 ``` 代码维护纳入白箱自迭代闭环；「何时调用哪段代码」转化为条件识别问题。 ## 5. 缺失条件准确率（Missing Condition Accuracy，GPT 实验） **问题**：DEFER 反推的缺失条件是否=真条件差异（而非描述相似）？ **方法**：GT 用**条件结构**而非自然语言关键词—— `{subject（条件对象）, cond_type（条件类型）, a_side/b_side（两侧判别词）}`。 判定两层：严格（缺失条件同时含 A/B 两侧判别词，同义词归一 门槛≈阈值）； 语义等价（含任一侧判别词）。 **结论**（test_ccg_missing.py，10 对）：语义等价 100%，严格 100%。 - 关键修复：`_semantic_head` 保留冒号前**语义名**（「列表推导式：」→ 列表推导式）。 旧逻辑 split('：') 把语义名剥掉 → 容器/算法词丢失（列表 vs 字典 无法辨识）。 head 语义名是任务判别词——「语义密度决定可索引性」在缺失条件层的复现。 - 方向判定优先 task 权威名独有词（干净无碎片）；head 独有词兜底。 ## 6. 条件扰动实验（Condition Perturbation，GPT 实验） **问题**：控制 DEFER→ACCEPT 路由的是【条件】还是【候选语义相似度】？ **方法**：同主体相邻能力对，任务仅互换条件词（累积↔阈值检查、无权↔加权、 列表↔字典），观察路由归属是否按条件预期改变。语义相似度几乎不变—— 若路由随条件词改变 → 条件控制路由；不变 → 证伪。 **结论**（test_ccg_perturb.py，3/3 切换 + 混合条件 BLINDSPOT）： - 条件词扰动 → 路由归属按条件反转（A 条件→A 侧，B 条件→B 侧）。 - 混合条件任务（累积+门槛放行）→ BLINDSPOT 声明，不强行选边（条件冲突不该 被 DEFER 递归掩盖）。 - 三次迭代修复： ① `_diff_condition` 方向对齐任务（否则递归偏航：累积任务 → 阈值检查）； ② 递归 query 去掉「（而非 …）」另一侧噪声（防止重新引入）； ③ 混合冲突检测需多重证据（两侧都命中且总命中 ≥3，并集去重—— 「导式」=推导式公共后缀不对称碎片 1 个不构成冲突）。 ## 7. 路由条件图谱系（GPT 实验链汇总） ``` 语义化注释 → 可索引性（盲测 99%）→ 条件化（三要素）→ 正向匹配（96%） → 不适用条件（负路由）→ 能力级互斥（对抗 28→88%） → 四态路由（ACCEPT/REJECT/DEFER/BLINDSPOT，边界三分类 100%） → 缺失条件反推（Missing Condition Accuracy 100%） → 条件扰动验证（条件控制路由 3/3，混合条件 BLINDSPOT） ``` 白箱特色：拒绝一个「看起来很像」的答案的理由可解释（缺失条件/盲区声明）， 黑箱只给「最像」。 ## 8. 递归协议化（GPT 第七阶段 §7.1） **命题**：白箱能在条件不足时递归找到决定性条件，并把得到的规则可靠地转化为 可验证执行。递归不是「继续搜索」——**每一轮都必须让条件空间变小**。 ### 8.1 状态机与转移（四保护） ``` START → 条件提取 ├─ 条件充分且唯一 → ACCEPT ├─ 条件与能力冲突 → REJECT ├─ 条件不足但存在可寻找条件 → DEFER → 生成 missing_condition │ → 搜索条件 → 条件补全 → 重新路由 ├─ 无法形成可靠条件判断 → BLINDSPOT └─ 两侧条件冲突 → BLINDSPOT ``` 四个保护（防 DEFER 无限递归/循环/无效递归）： 1. **递归深度上限**：默认 `max_depth = 3`，复杂任务显式申请扩展。 2. **条件循环检测**：递归要求已搜索过的缺失条件（seen_missing 命中）→ 立即 `DEFER_EXHAUSTED`（递归不收敛声明，等价 BLINDSPOT 且带 exhausted 标记）。 3. **信息增益门槛**：新条件必须减少候选集（candidate_after < candidate_before） 或提高路由确定性，否则终止递归（gain ≤ 0 → DEFER_EXHAUSTED）。 4. **递归预算**：限制递归轮数（= max_depth）+ 每轮候选数（top）。 ### 8.2 结构化状态（RouteState） ```json { "state": "DEFER", "depth": 1, "missing_condition": { "subject": "信任值", "cond_type": "累积 vs 阈值检查", "a_side": ["累积"], "b_side": ["门槛", "阈值", "放行"] }, "candidate_count_before": 2, "candidate_count_after": 1, "information_gain": 0.5, "next_query": "信任值是否需要累积，还是只需判断是否达到门槛" } ``` MissingCondition 由 `_diff_condition` 输出字符串升级为结构化对象 （subject/cond_type/a_side/b_side——与 Missing Condition Accuracy 的 条件结构 GT 同构，见 §5）。 ### 8.3 递归指标（test_ccg_recursive.py → recursive_trace.json） - **Recursive Direction Accuracy**：递归查询命中真实条件方向的样本数 / 所有需要递归的样本数（GPT §三.2）。 - 递归收敛率（DEFER→ACCEPT 比例）/ DEFER→BLINDSPOT 比例 / 循环率 （DEFER_EXHAUSTED 比例）/ 平均深度 / 最大深度 / 无效递归率 （信息增益 ≤0 比例）。 ### 8.4 精准执行闭环（GPT §五，7.2 起） ``` 问题 → 条件识别 → 路由 → 规则匹配 → 生成执行计划 → Dry-run → 检查前置条件 → 真实执行 → 结果验证 → 记录与固化 ``` 「我找到了一个看起来相关的代码单元」≠「我有资格执行这个代码单元」—— 执行前必须输出 selected_capability / conditions / rule / expected_result / verification / rollback。 ## 9. 执行计划层（GPT 第七阶段 §7.2） **精准执行 = 路由正确 ∧ 规则适用 ∧ 执行结果通过验证**——三闸门。 不能只报告「路由准确率」，因为精准执行可能在路由正确之后仍然失败。 ### 9.1 六类对象（GPT §一） ``` 条件 Condition 什么时候成立（subject/cond_type/operator/value/polarity） 规则 Rule 条件成立后推出什么（prerequisites/relation/conclusion/direction） 能力 Capability 可以做什么（accepted_conditions/rejected_conditions/executor/verifier） 执行 Execution 具体如何做（ExecutionPlan: steps/dependencies/expected_output/rollback） 证据 Evidence 为什么允许这样做（condition_matches/rule_matches/trace/verification） 问题 Problem raw_input/intent/domain/entities/requested_effect ``` ### 9.2 执行闭环（三闸门） ``` 问题 → ①路由（route ACCEPT → selected_capability） → ②规则适用（rule match：前置条件检查 + dry-run 干运行） → ③真实执行（pattern exec + cases 断言） → 结果验证（对照 expected_result）→ 记录与固化 / 回滚 ``` - **闸门1 路由正确**：route 四态 ACCEPT（条件充分且唯一）。 - **闸门2 规则适用**：precondition_check 检查生效条件注释（from 注释提取 condition tokens）；dry_run 静态验证（语法 + 前置条件满足）不真实执行。 - **闸门3 结果验证**：执行单元 pattern（首个函数），对 cases 断言—— result_verification 对照 expected_output；失败 → rollback（不固化结果）。 ### 9.3 执行前声明（ExecutionPlan 结构） ```json { "selected_capability": "图遍历-BFS", "conditions": ["graph 提供 neighbors 接口", "start 为图中已存在节点"], "rule": "队列 + 已访问集合，逐层扩展直至队空", "expected_result": "从起点出发可达的所有节点", "verification": "运行 cases 断言（BFS 可达集）", "rollback": "执行失败时不固化结果" } ``` ### 9.4 五类执行题（GPT §四 基准集） - **A 条件充分题**：「用 BFS 查找无权图中的最短路径」→ 条件充分 → ACCEPT → 执行 → 验证路径长度。 - **B 条件缺失题**：「查找图中的最短路径」→ 缺失（是否带权）→ DEFER → 补条件 → 重新路由。 - **C 条件冲突题**：「用无权 BFS 求带权图的最小总代价路径」→ BLINDSPOT/REJECT （不能因 BFS 与最短路径相似就强行生成）。 - **D 跨域组合题**：「解析中文循环语法并生成字节码执行」→ lexer → parser → loop compiler → VM（U→U 依赖边 + 组合顺序）。 - **E 执行失败题**：「执行一个缺少变量定义的程序」→ 定位规则 → 前置条件不满足 → 拒绝执行或返回可修复条件（不能把「找到相关函数」当任务完成）。 ### 9.5 执行指标（execution_report.json） - plan_condition_completeness（计划前置条件覆盖） - dry_run_pass_rate / execution_success_rate / result_verification_rate - rollback_correctness / solidification_precision - End-to-End Precision = 问题识别 ∧ 条件 ∧ 规则 ∧ 执行 ∧ 验证（全链路） ## 10. 跨域组合验证（GPT 第七阶段 §7.3） **任务**：compiler/graph/os 三域成熟单元，构造跨域任务，验证四环节： ① 条件识别（任务命中多单元/多域）→ ② 多单元依赖组装（compose 沿 U→U 依赖边自动产链）→ ③ 执行顺序（链序=依赖序）→ ④ 端到端结果（组装代码 exec + 函数断言）。 **基准**：test_code_compose_domains.py 的 c 端到端段（手工串联权威结果）； CCG 目标：同一任务能【自动】组装（非手工），链上单元 verifier 全过。 **结果**（test_ccg_crossdomain.py，6/6）： - ① 条件识别 3/3（compiler 名实绑定→信任流 / graph 连通分量 / os 页表缺页） - ② 自动组装 3/3（信任流→VM短路、连通→PageRank→图存储→编译闭包→VM闭包 6 链、缺页→页面错误）——verify all_ok - ③ 执行顺序 3/3（链序沿 dep 边） - ④ 端到端 3/3（信任流 NOT(0.8)=0.2、连通分量 1 分量、页表 vpn1→frame7） - ⑤ 跨大域条件识别 3/3（编译产物→图存储 / 内存→调度 / 图遍历→调度） **结论**：CCG 从「路由正确」跨到「多域自动编排 + 可验证执行」——跨域任务 无需手工串联，依赖边自动组装且结果与权威段一致。 ## 11. 反事实条件实验（GPT 第七阶段 §7.4） **核心验证**（GPT §七）：候选能力不变、规则不变，只修改条件 → 观察 ① 路由是否改变 ② 执行计划是否改变 ③ 执行结果是否改变。 三结果都随条件对应变化 → 证明：**条件不仅决定路由，还决定规则和执行计划** （非语义相似度）。 ``` 条件 A：无权图 → BFS → 最少跳数 条件 B：带权图 → Dijkstra → 最小代价 ``` ### 11.1 七类反事实/对抗（GPT §7.4） 1. **同主体不同条件**：图遍历 + 无权 vs 带权（→ BFS 族 vs Dijkstra） 2. **同条件不同主体**：加权 + 图 vs 加权 + 调度（→ 图域 vs 他域） 3. **词面相似但条件不同**：BFS vs 可达性判定（都遍历，条件边界不同） 4. **条件冲突**：无权 BFS 求带权最小总代价（→ BLINDSPOT） 5. **缺少前置条件**：注入型单元独立执行（→ 拒绝执行，诚实声明） 6. **伪造条件**：任务声称不存在的条件/能力（→ BLINDSPOT 判别力不足） 7. **递归循环诱导**：深度预算内终止（DEFER_EXHAUSTED，不无限递归） ### 11.2 指标 - perturbation_flip_rate（条件扰动翻转率：路由归属按条件改变的比例） - mixed_condition_blindspot_rate（混合条件→BLINDSPOT 率） - 反事实三结果一致性（路由 ∧ 执行计划 ∧ 执行结果 都随条件改变） ## 12. 理论收口（GPT 第七阶段 §7.5） ### 12.1 理论表述升级（可证伪形式） 旧表述：「智能是发现问题、识别条件、找到规则、精准执行的过程」——不可证伪 （任何「找到规则」都可事后解释）。 新表述（GPT 建议，更严谨）： > **在给定条件空间与存在约束下，智能系统通过递归缩小问题与可执行规则之间 > 的信息差，直到获得可验证的执行路径；若条件不足、冲突或不可判定，则必须 > 延迟（DEFER）、拒绝（REJECT）或声明盲区（BLINDSPOT）。** 六个构成要素全有实验支撑： | 要素 | 实验验证 | |---|---| | 条件空间 | 681 单元条件论注释 + 条件结构 GT（subject/cond_type/两侧判别词） | | 信息差 | 缺失条件反推 100%（strict+semantic），递归方向准确率 100% | | 递归 | 递归协议化（RDA 100%、收敛、循环检测、信息增益门槛） | | 可执行路径 | 执行计划三闸门 + 跨域自动组装（依赖边） | | 验证 | verifier 六层 + 执行结果断言（e2e 1.0） | | DEFER/REJECT/BLINDSPOT 边界 | 四态路由三分类 100%、条件冲突/伪造条件/混合条件 BLINDSPOT | | **分层判断（升级）** | 子系统无法识别 → 父系统判断 → 全层无法判断 → BLINDSPOT（§13） | ### 12.2 可证伪性声明 本理论可被以下任一观测证伪： - 条件词互换（无权↔带权）而路由/执行计划/执行结果不变（反事实实验已证 三结果全变——当前不可证伪处）。 - 缺失条件反推与真实条件差异不一致（Missing Condition Accuracy < 1）。 - 递归不收敛或循环（DEFER_EXHAUSTED 保护失效）。 - 冲突/伪造/不足条件任务被强行 ACCEPT（当前一律 BLINDSPOT）。 ### 12.3 完整指标（whitebox_condition_report.json，GPT §六） ``` 条件识别 condition_structure 1.0 / synonym 1.0 / boundary 1.0 路由 route 0.9896 / accept 1.0 / reject 1.0 / defer 1.0 递归 rda 1.0 / missing_condition 1.0 / convergence 1.0 / depth 1.0 因果控制 perturbation_flip 1.0 / counterfactual_three_flip 1.0 执行 dry_run 1.0 / e2e 1.0 端到端 End-to-End Precision 1.0（A 类四任务全链路） ``` ### 12.4 主线闭合（GPT 最终建议） ``` 发现问题 → 识别条件 → 递归找到知识与规则 → 生成执行计划 → 精准执行 → 验证结果 → 固化或回滚 ``` 第七阶段完成 = 主线全链已验证：从「问题」到「固化/回滚」的每一环节都有 确定性实现 + 可量化指标 + 可证伪实验，全部零 LLM（能查表不 LLM/能执行 不 LLM/能规则判断不 LLM）。 ## 13. 分层判断（escalation，荣 理论补充） **表述**：当子系统无法识别，由上一层父系统进行判断；当所有层都无法判断， 标记为盲区（BLINDSPOT）。 ### 13.1 层级定义 ``` L0 问题接收 原始任务 → 条件词提取（_q_tokens） L1 子系统（单元） 单层四态路由 route（ACCEPT/REJECT/DEFER/BLINDSPOT） L2 父系统（域） 域级判断：任务词 → 域识别 → 域内宽候选聚合 L3 更高父（组合） 跨域组合 compose：依赖链能否构成可执行路径 L4 终层 全层无法判断 → BLINDSPOT（escalation_trace 记录每层） ``` ### 13.2 升级规则 - **L1 BLINDSPOT**（判别力不足/无候选/伪造条件等）→ 不直接宣告终态， 升级 L2：域级判断——任务词能否定位到某域（detect_domain 语义）； 若能定位域且域内有候选群（即使 top1 分差不足）→ 返回 DEFER（域已定， 条件仍缺——把「域」作为父系统判断结果）。 - **L2 无法定位域**（跨域/泛化任务）→ 升级 L3：跨域组合判断——任务词 是否命中多条依赖链（compose 可组装）→ 返回 DEFER（组合路径存在）。 - **L3 无组合路径** → L4 终层 BLINDSPOT（escalation_trace = [L1 理由, L2 理由, L3 理由]——全层无法判断的完整证据链）。 ### 13.3 escalation_trace 结构 ```json { "state": "BLINDSPOT", "escalation_trace": [ {"level": "L1", "reason": "判别力不足（仅泛化词命中）"}, {"level": "L2", "reason": "域无法定位（跨域/泛化）"}, {"level": "L3", "reason": "无组合路径（依赖链不可组装）"} ], "final": "全层无法判断 → 标记盲区（不强行选择）" } ``` ### 13.4 白箱语义 分层 = 判断资源的**宽度升级**（单元 → 域 → 组合），每层有自己的判断 能力边界；全层耗尽才宣告盲区——**盲区不是第一层的失败，而是所有层的 共同结论**（与人类认知层级同构：直觉 → 领域知识 → 跨域推理 → 承认无知）。 ## 14. Kimi 评审映射（智能论 v3.4 条件论同构性 + 三风险落地） **评审结论**：注释规范与智能论 v3.4 条件论（附录11）高度同构——功能条件 =条件空间声明、子功能=任意分层性、子功能/执行=信息差缩小路径、不适用 条件=盲区标记；条件路由图 = 可执行的条件空间切换机制（解决盲区13 过滤与映射规则来源盲区）。 ### 14.1 三风险 → 工程落地 | Kimi 风险 | 对应盲区 | 落地 | |---|---|---| | ① 注释-代码漂移 | 盲区15 固化标准模糊 | **负面测试闭环**（negatives_from_conditions.py）：不适用条件解析为可执行反例 → 漂移自动暴露（19 处实证） | | ② 条件完备性幻觉 | 盲区3 迭代不完备 | **强/弱契约分级**：非{集合}/越界=强契约必须拒绝（97%）；为空/非法=弱契约（L3 覆盖）；动态死区：输入超范围行为未定义 | | ③ 路由复杂度爆炸 | 盲区21b 拟合混淆 | **分层路由**（§13 escalation）：L1 单元 → L2 域 → L3 组合，先高层条件空间再进子层 | ### 14.2 负面测试闭环（建议 B 落地） ``` 不适用条件注释 → 解析（op 非 {…}/越界/为空）→ 构造反例 → 执行断言 → 强契约拒绝率（必须拒绝）→ 漂移登记（honest calibration） ``` **结果**（test_ccg_negatives.py 4/4）：强契约 97%（249/258）、总拒绝 81%、 **19 处漂移发现**——注释声明「不适用」但实现有具体行为（VM-条件跳转空 stack→ip+1、日期时间越界→(-1,12,30) 等）。白箱纪律：**如实登记不修改 数字掩盖**（漂移=泛化草稿 vs 实现语义差异，升级工程修复注释）。 ### 14.3 动态死区声明（风险2 落地） 允许注释含「未知条件：当输入超出以下范围时，行为未定义」—— 条件完备性幻觉的显式兜底（不假装穷举了所有边界）。 ``` # 不适用条件：op 非 {A,B} 时；未知条件：输入超出生效条件范围时行为未定义 ``` ## 15. 自举稳定性（验证单元 三盲区 → 自举锚点机制） **三盲区**（验证单元标记）： 1. **哥德尔困境**（盲区3）：「声明不适用条件」这一元操作本身运行在另一条件 空间——元操作的元条件是什么？无限递归条件空间堆叠。 2. **路由图自举锚点缺失**（盲区13）：条件路由图本身也是白箱系统的「能力」， 谁来路由「路由图自身的条件」？需要无需被路由的底层调度器。 3. **否定边界动态性**（盲区28）：今天声明的否定边界，明天可能因新能力加入 而失效——基于过时边界做自举决策产生结构性幻觉。 ### 15.1 自举锚点（Bootstrap Anchors）——不可再分的底层原语 **解**：区分「可路由能力」与「不可路由锚点」——锚点 = 无需被路由的、 不可再分的调度/索引原语，构成路由的**启动条件**（不参与自身路由）。 ``` 可路由能力（需四要素注释） 自举锚点（不可再分原语，不参与路由） search / route / compose _bigrams / _q_tokens / _word_df escalate / build_graph _core_task / _semantic_head / _jaccard extract_comment_index 等 （无依赖更底层函数的原子操作） ``` 锚点特性：①无依赖更底层函数（原子）②不参与路由图（search 不含锚点词） ③自身有中文注释（docstring 即声明）④不可再分（无子功能可递归）。 ### 15.2 元操作声明（哥德尔困境的工程解） 「声明不适用条件的元操作」的不适用条件 = **锚点层声明**： - 锚点函数不做条件路由（不调用 route/search——避免「路由路由」递归） - 锚点只做确定性变换（bigram/分词/词频），无外部状态 - 锚点失效条件 = 输入类型错误（str/set 传错）——由 L1 语法层兜底， 不再需要注释级声明（元级由类型系统裁决，终止递归堆叠） ### 15.3 否定边界动态性 → 负面测试闭环（§14.2 已落地） 19 处漂移发现 = 否定边界过时的实证。动态性处理： - 每次建图/审计时重跑负面测试（negatives_from_conditions.py） - 漂移登记不改数字（honest calibration）——过时边界显式暴露 - 新能力加入后，重跑闭环验证旧边界是否仍成立（协议 §14 升级纪律） ### 15.4 自举验证层（Kimi 工程建议 2） 每次生成/修改白箱组件时： - 检查四要素声明完整（R3/R4 audit） - 检查不适用条件与路由图冲突（负面测试闭环） - 校验结果写入不可遗忘记录（lingshu 知识层 + 协议文档 §14/§15） ### 15.5 黑箱节点接口（Kimi 工程建议 3） 白箱不排斥黑箱能力（如 LLM 生成），但路由图显式标记黑箱节点边界： ```yaml capability: creative_writing execution: neural_generation # 黑箱节点声明 invalid_when: [factual_accuracy_required, safety_critical] # 黑箱不可解释，仅非关键场景调用，必须内容复核 ``` ## 16. MOS 元操作语法（Kimi 建议 1 落地） 四要素注释 → 机器可读结构化声明（capability/condition_space/sub_capabilities/ execution/invalid_when）→ 一致性验证（声明 vs 代码 ast 提取的实义比对）。 ```yaml capability: 信任累积 condition_space: requires: [trust 合法] # 生效条件 sub_capabilities: [累积 处理] # 子功能 execution: 顺序调用 # 执行 invalid_when: [输入不满足生效条件时] # 不适用条件 ``` **一致性验证**（meta_ops.py）：声明中的 requires/sub_capabilities 与代码 ast 提取的函数名/参数名比对——漂移自动暴露（与 §14 负面闭环联动）。 ## 17. 白箱能力工作流化（荣 建议：仿 ComfyUI） **方向**：白箱所有能力（代码/知识/工具/推理）都应知识图谱化、工作流化—— 代码只是白箱能力的一个方向。ComfyUI 模型：节点（class_type+inputs）+ 边 （inputs 引用上游输出）+ prompt 图 → 拓扑执行 → 缓存复用。 ``` ComfyUI 模型 白箱工作流 node: {class_type, inputs} 能力节点 {capability_id, inputs} edge: inputs 引用上游输出 依赖边（U→U / 数据流） prompt 图 → 拓扑排序执行 能力图 → 拓扑执行 执行缓存（history） 结果缓存（指纹复用） 工作流 JSON 保存/加载/复用 工作流序列化（可移植/共享） ``` **白箱能力图谱** = 节点（能力：代码单元/知识/工具）+ 边（依赖/组合/同义） ——CCG 的单元与依赖边是它的第一类实例；代码只是能力的一种载体。 **工程产物**：whitebox_workflow.py（prompt 式能力图执行引擎 + 工作流 JSON 序列化）；执行前条件校验（不适用条件拒绝——§9 三闸门联动）。 ## 18. 自迭代闭环（荣 长期任务：八步闭环） **目标**：自动发现功能调用时的错误/冲突/盲区，进行注释修改，重新测试 验证，总结技能，固化为知识/工作流。 ### 18.1 八步闭环 ``` 1 感知 系统主动感知自身状态变化/新模式（负面闭环漂移 + MOS 失配 + 路由冲突 + escalation 盲区——自动扫描全库） 2 识别 判断变化是否属于「需吸收的新内容」（漂移分类：弱兜底可吸收 / 强拒绝已满足 / 真 bug 需人工 / 符号类不可自动） 3 分析 理解新内容对协议影响范围（改注释影响哪些测试/路由——note 不 加判别词 → not_tokens 稳定 → 路由无影响） 4 验证 确认与协议价值观一致（honest calibration：只改注释不改实现； 改后全文件 ast.parse 语法校验 + import 成功） 5 固化 将新内容正式纳入协议结构（注释语义对齐落盘 + skills.json 技能 + 知识层） 6 记录 记录迭代历史（iteration_trace.json 追加 {round, 感知, 识别, 分析, 验证, 固化}——可追溯演进路径） 7 反馈 迭代结果作为下一次迭代基础（trace 读回：已吸收内容跳过—— 防重复迭代） 8 方向性自检 定期评估「方向正确性」：漂移数/强契约率/MOS 一致率/ 测试全绿 趋势——朝目标（减少错误/冲突/盲区）前进则继续 ``` ### 18.2 契约形态技能（迭代吸收的内容，2026-09 修正） **修正（荣）**：返回默认值 ≠ 合法弱契约——**默认值等同于不知道，返回默认值 等同自带盲区**。函数对不适用输入返回默认值（0/[]/unknown/''），是「假装 处理」而非「诚实声明」——它掩盖了「此输入不在能力范围内」的事实。 不适用条件的正确契约形态： - **强拒绝（诚实）**：输入超范围 → 抛异常 / 返回 None / 返回 False—— 显式声明「不适用」（负面测试必须拒绝）。 - **隐式盲区（风险）**：输入超范围 → 返回默认值——**自带盲区**： 系统声称处理了但不真正理解。正确做法是**显式标记盲区**（注释声明 「返回默认值=未知行为」）或修复实现为显式拒绝。 自迭代分类修正：返回默认值的漂移**不再作为「弱兜底契约」吸收**—— 改为「隐式盲区」登记，注释显式声明（而非「弱契约」合理化）。 ### 18.2b 盲区显式化（负向技能） 返回默认值的单元 = 隐式盲区，需显式化： ``` # 不适用条件：stack 为空/非法时（隐式盲区：返回默认值=未知行为——不适用） ``` 或修复实现：不适用输入显式拒绝（抛异常/None），消除隐式盲区。 ### 18.3 固化纪律（教训固化） 单元 pattern 是 Python 字符串字面量——注释修改必须**字符串内精确替换** （`不适用条件：X\n"` 的 `\n` 前插入 note），禁止字符串外拼接（会破坏 语法，曾致 6 域文件 SyntaxError——git 还原 + 修复教训）。修改后必须 ast.parse 全文件校验 + 全回归，任何一步失败即回滚。 ### 18.4 迭代轨迹记录 iteration_trace.json：`{round, 感知, 识别, 分析, 验证, 固化, 反馈, 方向性自检}`——不可遗忘记录（与 §15 自举验证联动）。 ### 18.5 理论完整性检查（荣 2026-09 批评固化） **教训**：方向性自检长期未验证「理论八步是否被工程完整实现」——理论 8 步 （感知/识别/分析/验证/固化/记录/反馈/方向性自检），工程因记忆缺漏/遗忘 一度只有 5 步（发现/修改/验证/总结/固化），靠人工核对才补充完整。 **修复**：方向性自检（第 8 步）增加**自指检查**——验证八步理论在源码中 全部有实现（函数存在 + 主闭环调用），缺任何一步即报「方向偏离」： ``` THEORY_STEPS = [ 1感知 perceive / 2识别 classify / 3分析 analyze / 4验证 _validate_file 5固化 solidify / 6记录 record / 7反馈 _absorbed_units / 8方向性自检 orient ] _theory_integrity(): 八步函数存在 + 主闭环调用 → 缺失即报偏离 ``` - 主闭环显式体现每步（4验证 = 固化前语法校验、7反馈 = 吸收历史统计） - 文档 §18 八步关键词 ↔ 工程实现一致性纳入自检（test_theory_integrity 6/6） - **理论是自迭代的上游节点（concept_influence 最高）——理论完整性检查 就是确认上游未被遗忘**（§15 锚点机制的自迭代版） ## 19. 自动自迭代引擎（荣：长期任务自动运行） **目标**：八步闭环自动循环运行，无需人工触发——持续感知/吸收/记录。 ### 19.1 自动循环（auto_iterate.py） ``` 循环启动 → 每轮： ① 感知（6 通道全扫描：漂移/契约率/MOS/互斥/盲区/规范） ② 识别（可吸收 vs 需人工，反馈跳过已吸收） ③ 可吸收 → 固化（字符串内替换 + ast.parse 校验）→ 验证 ④ 记录（iteration_trace 追加）→ 方向自检 ⑤ 间隔 sleep → 下一轮 稳态检测：连续 N 轮无新吸收 → 报告稳态（闭环健康，不空转） 崩溃隔离：每轮 try/except——单轮失败记录不中断循环 ``` ### 19.2 运行参数 - `--interval` 轮间隔秒（默认 60） - `--max-rounds` 最大轮数（默认 0 = 无限） - `--apply` 允许自动固化（默认只感知/识别，不落盘修改——安全模式） - `--steady-rounds` 稳态判定轮数（默认 5 轮无吸收即报告稳态） ### 19.3 稳态语义 自迭代不是「无限改注释」——稳态 = 感知通道全绿 + 无新可吸收内容： 系统已达到当前条件空间的平衡点。新模式出现（新单元/新错误）才会 打破稳态触发新一轮吸收（感知是事件驱动的基础）。