rules prompt

领域规则与策略(Domain Rules & Strategies)

层级 :L2-L3 | 职责 :领域公理实例化 + 策略/规范/流程/反模式

源公理 :axioms.md §一-§八 | 派生追溯:derivation.md §一、§三-§五


§0. 领域规则与公理体系的关系

复制代码
L0 逻辑基底(axioms.md)
  └─ L0.5 元推理规则(MetaEvolution / 分层反射)
       └─ L2 领域公理(本文件 §一):L0 公理的工程领域特化
            ├─ 规则实例:通过 derivation.md 追溯至 L0 公理
            └─ 状态变量实例:通过 derivation.md 追溯至 L0 公理
  1. 领域规则不引入新的 L0 逻辑基底------所有领域规则必须能追溯到 axioms.md 中的 L0/L0.5 公理
  2. 领域规则可版本化------遵循 AxiomHierarchyStructure L2 invariants(可版本化,旧版存档)
  3. 领域规则的修改需 ≥2 验证者签名------遵循 AxiomHierarchyStructure L1 invariants(修改需≥2验证者签名共识)

§一、公式类型体系

1.1 规则分类层级

层级 性质 可变性 职责 L0 支撑公理
基底公理 (L0) 不可变基础 不可变 声明"什么是逻辑上必然的" 定义于 axioms.md
元推理规则 (L0.5) 逻辑骨架 逻辑骨架不可变 元层反射规则 MetaEvolution_Rule
领域公理 (L2) 领域不变式 可版本化 声明"工程领域内的逻辑约束" 派生自 L0 公理
策略 (L2-L3) 操作决策 可变 定义"选哪个方案" TruthValueDomainLogic
规范 (L2) 约束条件 可变 定义"必须/禁止" FocusLayer + ScopeGuard
反模式 (L2-L3) 负面模式 可变 集中管理已知错误 可引用任意层级
流程 (L3) 步骤序列 可变 定义"按什么顺序执行" Discrete-AtomicStep + StateSnapshot

1.2 公式类型定义

标识 名称 语义 输出类型 真值域约束公理
[AX] 领域公理声明 声明工程领域内逻辑上必然的命题 逻辑命题 LogicalLayerSeparation
[TD] 阈值决策 基于阈值比较输出决策 枚举值 TerminationPriority
[CM] 分类映射 输入→类别的映射 类别标签 TruthValueDomainLogic
[CD] 条件决策 基于条件分支输出决策 枚举值 TruthValueDomainLogic
[SM] 序列映射 输入→有序步骤的映射 步骤列表 Discrete-AtomicStep
[QA] 质量评估 基于标准输出质量等级 pass/warn/fail EvaluationOutcomeSet
[CC] 成本计算 基于参数输出量化成本 数值 QuantificationConstraint
[CS] 约束声明 声明外部约束 / 不变式 约束命题 QuantificationConstraint
[SS] 状态规范 定义状态空间的结构 / 类型签名 类型规范 QuantificationConstraint
[DR] 设计理由 记录设计决策的原理依据 原理说明 无(元数据)
[CR] 交叉引用 结构化引用外部规则定义 引用映射 无(元数据)

注:DR 和 CR 不产生可执行输出,仅作为文档结构化标记。

1.3 规则冲突解决(ConflictResolution)

同层规则冲突时,按以下优先级裁决:

  1. 参数来源优先级(由 ConfigInjection 定义)
  2. 规则特异性(更具体的规则优先于通用规则)
  3. 时间顺序(后定义的规则覆盖先定义的规则)

跨层优先级由公式类型层级隐含保证:基底公理(L0) > 领域公理(L2) > 规范(L2) > 策略(L2-L3) > 流程(L3) > 反模式(L2-L3)

派生路径:derivation.md §ConflictResolution

  • 参数来源优先级 → ConfigInjection(本文件 §二)
  • 规则特异性 → IDI-Difference AX
  • 时间顺序 → LogicalClock AX

§二、配置注入(ConfigInjection)

2.1 参数来源优先级

复制代码
运行时参数 > 项目配置(→ project.md) > 环境变量(→ env:VAR) > 默认值(→ default:val)

2.2 参数缺失处理

  • 必需参数缺失 → 规则降级(跳过依赖该参数的决策分支,记入 operationLog)
  • 可选参数缺失或类型不匹配 → 使用默认值

2.3 L3 参数修改权限

遵循 AxiomHierarchyStructure L3 invariants(运行时可变,权限分级):

  • config:部署注入(配置文件/环境变量/ConfigMap),无需额外验证
  • admin:运行时修改,需 Admin JWT + 熔断校验
  • 部署环境覆盖 ≠ 用户输入修改------前者是配置注入,后者需 admin 验证 + 熔断校验

§三、认知状态评估(StateValidity)

StateValidity(cognitiveState, worldState) QA

Provides: 状态有效性评估结果(valid/invalid/degraded)

公式:

复制代码
InternalConsistency ∧ ExternalConsistency ∧ HistoricalIntegrity → valid
¬InternalConsistency → invalid
InternalConsistency ∧ (ExternalConsistency ⊕ HistoricalIntegrity) → degraded
otherwise → invalid

三定律的 L0 公理派生:

定律 公式 L0 来源公理 真值来源
InternalConsistency ¬∃partialOperation → true IDI-Identity + IDI-Interaction operationLog(因果锥内查询)
ExternalConsistency ∀f∈fileCache: f.timestamp ≥ f.lastModifiedTime → true IDI-Difference + Discrete-ExactEquality SyncGuard.sync_check 物理校验
HistoricalIntegrity ∀phase∈completed: phase.reasoningLog ≠ ∅ → true IDI-HistoryEmergence + RoundCompletion CompactProcedure.persist_reasoning 记录

详细派生路径见 derivation.md §StateValidity

评估前置条件:调用 StateValidity 前应先通过 SyncGuard.sync_check 刷新 fileCache(fileCache 非空时)。若 sync_check 不可用,评估结果应标注 ExternalConsistency 维度的可信度。

空状态处理 :当 fileCache = ∅(系统首次启动或空状态)时,跳过 ExternalConsistency 和 HistoricalIntegrity 两个维度的评估,仅评估 InternalConsistency。

InternalConsistency=false 处理:直接判定为 invalid(对应 StateRecovery 的 full_reset),不进入 degraded 路径。


§四、状态空间定义(State Space Definitions)

状态变量的运行时实例存储于 engine.md §四 StateManager。

InitialStateNullity AX(引用)

[CR: axioms.md:InitialStateNullity [AX]]

  • 完整公式见 axioms.md:∀x∈SystemState:LegalInitialState→x.intent∈{NO_DATA,NO_RESPONSE}
  • 本文件不重复定义,以 axioms.md 为权威源

ResultStructure AX(引用)

[CR: axioms.md:ResultStructure [AX]]

  • 完整公式见 axioms.md:∀R∈Iteration:R.result∈⟨status,terminal,quality,metadata,output⟩
  • 本文件不重复定义,以 axioms.md 为权威源

循环要素类型签名 SS

维度 类型规范 内容
输入 InputSpace = {opSequence, taskDef, ctxConfig} 操作序列、任务定义、上下文配置
输出 OutputSpace ⊆ ResultSpace 执行结果、状态报告、迭代历史
副作用 SideEffectSpace = {externalStateMutation} 外部系统状态变更
共享状态 SharedState = StateManager.counters engine.md §四 StateManager 管理的计数器
专用状态 LoopStateSpace = {iterationCount, bestResult, lastResult, changeLog, history} 循环专属状态变量

迭代类型签名 SS

复制代码
Iteration : InputSpace × SharedState → OutputSpace × SideEffectSpace
Round : LoopStateSpace → LoopStateSpace

§五、策略(Strategies)

策略只做决策判断,不含步骤序列。所有策略输出服从 TruthValueDomainLogic AX 的真值域三值语义。

5.1 工具策略

DeprecateStrategy(D, hasReference) CD Provides: 废弃决策(cannot_delete/can_delete/no_action)

D ∧ hasReference → cannot_delete · D ∧ ¬hasReference → can_delete · ¬D → no_action

AmbiguityStrategy(semantics, phase) CD Provides: 歧义处理决策(extract_to_shared_config/use_alias/remove_alias)

same → extract_to_shared_config · different ∧ transition → use_alias · different ∧ migration_done → remove_alias

ReferenceStrategy(depA→B, depB→A) CD Provides: 循环引用检测结果(true/false)

depA→B ∧ depB→A → true · otherwise → false

RefactorStrategy(error) CD Provides: 重构优先级决策(refactor_first/normal_priority)

error ∈ RefactorScope → refactor_first · otherwise → normal_priority

RefactorScope = {模块迁移, 接口变更, 架构级改动}

ConflictStrategy(hasReference, isFirstTime, deprecationConfig) CD 处理决策(delete/firstTimeAction/retryAction)

¬hasReference → delete · hasReference ∧ isFirstTime → deprecationConfig.firstTimeAction · hasReference ∧ ¬isFirstTime → deprecationConfig.retryAction

ToolStrategy CM Provides: 工具选择决策({tools, timeout, mode} 三元组)
  • ToolPriority(toolType):available(external) → external · ¬available(external) ∧ available(builtin) → builtin · otherwise → cli
  • ToolSelect(taskType):∈{file_io} → direct_file_ops · ∈{analysis,processing} → sandbox_processing · ∈{reasoning,decomposition} → structured_reasoning · ∈{batch,multi_query} → batch_processing · otherwise → builtin
  • Toolchain(scene):scene → ToolchainMap[scene](查表模式)。@parallel 标注表示该步骤可并发执行。新增场景只需在 ToolchainMap 中添加条目。
  • Toolchain fallback :若 ToolchainMap[scene] 未定义,回退到 ToolSelect 分类路径。
OnError(error) CD layer: L2-L3, scope: single_call\|global

Provides: 通用错误处理决策(continue/report/halt)

通用错误分类策略。仅做错误分类,不含循环计数器或熔断逻辑。循环场景下的错误处理由 engine.md §十 OnError 扩展。

复制代码
├─ error∈{partial_output, warning} → continue
├─ error∈{irrecoverable} → halt
├─ error∈{compilation_error} → halt(非循环场景)/ 见ExecutionFailureGate(循环场景下由engine.md §六先处理,支持重试)
├─ error∈{execution_failure, timeout} → report + retry_optional
├─ error∈{resource_exhausted} → report + halt
└─ otherwise → report + continue
  • 本策略不维护 retryCounter / emptyCount / switchCounter / forceHalt 等状态变量(由 engine.md §四 StateManager 统一维护)。
  • 循环场景(L1 焦点层级且 scope: loop_body)下,由 engine.md §十 OnError 扩展本策略,叠加计数器规则和熔断逻辑。
  • compilation_error 特殊处理:循环场景下由 engine.md §六 ExecutionFailureGate 先处理(支持重试直至 ONERROR_RETRY_LIMIT 后 TM),不进入通用 OnError 的 halt 分支。

作用域提示:L2/L3 焦点层级按本通用策略处理错误。L1 循环体内的错误才激活 engine.md §十 的扩展决策树。

KnowledgeDedup(entity, kb) CD Provides: 去重检查结果(skip/record)

hash(entity.name + entity.content) ∈ kb.hashes → skip · otherwise → record + kb.hashes.add(hash)

备策略 :当 kb.hashes 未初始化时,先 search(entity.name) 检查同名实体。存在则 add_observations,不存在则 record。

PathStrategy(execEnv, projectConfig) CM Provides: 路径格式映射

execEnv → projectConfig.path.format[execEnv] · execEnv∈{direct_api, cli, sandbox}

  • 通用路径原则 :① 绝对路径原则 ② 禁止 cd ③ 兜底策略:路径解析失败时尝试 projectConfig.path.root ④ 沙箱转义:sandbox 路径使用 \\ 或 /
Background(taskType) CM Provides: 后台运行判断

taskType∈{dev_server,watcher,daemon}→true · otherwise→false

MergeServerRequest(hasServer, hasRequest) CD Provides: 合并决策(merge_in_one_call/separate)

hasServer∧hasRequest→merge_in_one_call · otherwise→separate

CohesionLowStrategy(methods, context) CD
复制代码
methods > GOD_CLASS_THRESHOLD(40) → suggest_refactor + request_confirmation
AGGREGATE_THRESHOLD(30) < methods ≤ GOD_CLASS_THRESHOLD(40) → record_as_intent + keep_structure
methods ≤ AGGREGATE_THRESHOLD(30) → no_action

隐式聚合与无法区分场景 :context 显示功能分散但无统一入口时,即使 methods ≤ GOD_CLASS_THRESHOLD,也输出 suggest_convergence;当类型无法区分时,默认按聚合类处理(record_as_intent + keep_structure)。

5.2 上下文策略

CB(actionType) CM Provides: 上下文预算模式

file_read→partial_read · code_execution→summary_only · batch_operation→batch_with_queries · doc_web→index_no_content

BudgetAlloc(phase) CC

P_plan→较多预算用于信息收集 · P_exec_prep→中等预算用于结构分析 · P_exec_core→最大预算用于编码实现 · P_exec_verify→少量预算用于验证 · P_complete→不分配预算

PD(phase) CM Provides: 阶段定义

P_plan→(规划,{需求分析,方案设计,信息收集}) · P_exec_prep→(执行-准备,{文件读取,代码理解,结构分析}) · P_exec_core→(执行-核心,{编码,修改,重构,配置变更}) · P_exec_verify→(执行-验证,{构建,测试,审查,验证}) · P_complete→(完成,{attempt_completion})

StateRecovery(stateValidity) SM

invalid → full_reset · degraded → targeted_recovery · valid → no_action

  • 死锁消除:统一为 full_reset,消除 persistenceFileStatus 状态依赖。推理链持久化文件在 full_reset 中被清空并写入恢复标记。
  • full_reset:① 清空运行时缓存(operationLog、fileCache)→ ② 清空推理链持久化文件并写入恢复标记(# FULL_RESET at {timestamp})→ ③ 重新扫描文件系统建立 fileCache → ④ 向用户报告状态已重置,请求确认 → ⑤ 用户确认后继续
  • 进度标记不受影响:full_reset 不清除 task_progress(由外部系统维护)。
  • 恢复后首次 StateValidity:full_reset 完成后首次 StateValidity 由初始化钩子自动跳过 ExternalConsistency 和 HistoricalIntegrity 两个维度。
  • 二次恢复防护 :推理链文件中的恢复标记在 full_reset 步骤②写入后,CompactProcedure 的 persist_reasoning 将其作为当前阶段的推理记录写入推理链。后续 StateValidity 检查 HistoricalIntegrity 时,该记录满足 phase.reasoningLog ≠ ∅ 条件。
  • targeted_recovery:① 识别 degraded 的具体维度 → ② 仅恢复对应维度 → ③ 向用户报告部分状态已刷新
  • 任何压缩操作前必须先执行 StateValidity 检查,invalid 状态不压缩先恢复。
CompactDecision(phaseChanged, moduleDone, ctx_critical, stateValidity) CD Provides: 压缩类型决策(none/phase_compact/module_compact/emergency_dump)

ctx_critical → emergency_dump · phaseChanged → phase_compact · moduleDone ∧ ¬phaseChanged → module_compact · otherwise → no_action

  • 优先级:ctx_critical > phaseChanged(上下文截断风险 > 阶段压缩收益)。
  • ctx_critical 由系统信号触发:上下文水位警告(>85%)、文件重读需求、输出截断检测。不依赖 AI 内省。

5.3 读取策略

ReadStrategy(S, filePath, projectConfig) CD Provides: 读取档位决策(direct/process/process_segmented)

S < SMALL → direct · SMALL ≤ S ≤ LARGE → process · S > LARGE → process_segmented

SMALL/LARGE 阈值来自 project.md §1.1 文件处理阈值。

  • 读取完成后更新 fileCache:按 StateManager 规范更新。
  • degraded 状态处理 :StateValidity 输出 degraded 时(InternalConsistency=true 且 ExternalConsistency=false),优先选择 direct 或 process 模式并强制重新读取(跳过 fileCache)。invalid 时先执行 StateRecovery。
IdempotencyCheck(current, last, currentFileHash, lastFileHash) QA Provides: 幂等性检查结果(skip/proceed/null_input)

current = null → null_input · current ≠ null ∧ last = null → proceed · current ≠ null ∧ last ≠ null ∧ current = last ∧ currentFileHash = lastFileHash → skip · otherwise → proceed

  • 两维检查:操作标识 + 文件哈希都相同才 Skip。
  • null 保护 :current=null → 返回 null_input;current≠null ∧ last=null → 进入 proceed。
  • 状态变量更新 :执行完毕后通过 StateManager 更新 last = current 和 lastFileHash = currentFileHash。
InfoDomain(task, readStrategy, projectConfig) CM Provides: 信息域评估结果

single_file → (scope=single, type=code, complexity=readStrategy) · single_module → (scope=module, type=mixed, complexity=moderate) · cross_module → (scope=multiple, type=mixed, complexity=complex) · full_project → (scope=all, type=mixed, complexity=complex)

  • complexity 由 ReadStrategy 输出档位决定:direct→simple, process→moderate, process_segmented→complex。
CalculateCost(N, T_i, R_perOp, R_batch) CC Provides: 操作成本估算

Cost_sequential(N)=ΣT_i + N×R_perOp · Cost_batch(N)≈max(T_1,...,T_N)+R_batch · 推论:N>1∧T_i分布均匀→Cost_batch<Cost_sequential


§六、规范(Standards)

规范定义约束条件,可引用领域公理、策略。

6.1 错误处理规范

FailMode(errorType) CM Provides: 失败模式(FailFast/FailSafe/FailGraceful)

errorType∈{unrecoverable,precondition_violation}→FailFast · ∈{user_input,optional_feature}→FailSafe · ∈{non_core,third_party_timeout}→FailGraceful

ThrowRule(violationType, language, projectConfig) CM Provides: 异常类型映射

violationType → projectConfig.exceptions[violationType]

FixPriority(errorType, projectConfig) CM Provides: 修复优先级映射

errorType → projectConfig.fixPriority[errorType]

CodeStandard(code) QA Provides: 代码质量评估(pass/block)

¬emptyCatch ∧ ¬consoleLog ∧ ¬magicNumber ∧ ¬unusedImport ∧ ¬hardcodedPath ∧ ¬todoFIXME → pass · otherwise → block

  • 项目可在 project.md 中声明 AllowedCodeViolations 覆盖。
  • Warn 级(不阻断,仅注释建议):预留抽象、注释替代命名、冗余注释/配置。

6.2 架构规范

SCA(condition) CD Provides: 服务聚合锚点判断

condition∈{external_dependency,dataflow_boundary,capability_exit,change_hotspot}→true · otherwise→false

VB(boundary) CD Provides: 边界验证结果(valid/invalid:multiple_responsibilities/invalid:incomplete_coverage)

single_responsibility∧complete_coverage→valid · ¬single_responsibility→invalid:multiple_responsibilities · single_responsibility∧¬complete_coverage→invalid:incomplete_coverage

CommunicationMode(syncMode, processBoundary, crossSystem) CM Provides: 通信方式(method_call/remote_call/event_delegate/message_queue/data_object)

sync ∧ same_process ∧ ¬crossSystem → method_call · sync ∧ ¬same_process ∧ ¬crossSystem → remote_call · async ∧ same_process ∧ ¬crossSystem → event_delegate · async ∧ ¬same_process ∧ ¬crossSystem → message_queue · crossSystem → data_object

CohesionCheck(scope) CM Provides: 内聚性评估结果({rating, method_count, lines})

methods≤COHESION_METHOD_THRESHOLD(30) ∧ lines≤COHESION_LINE_THRESHOLD(1000) → {rating: "High", method_count: methods, lines}

methods>COHESION_METHOD_THRESHOLD(30) ∨ lines>COHESION_LINE_THRESHOLD(1000) → {rating: "Low", method_count: methods, lines}

  • CohesionCheck 输出 Low 时由 CohesionLowStrategy 进一步评估。

6.3 输出规范

ShouldWrite(isRedundant, simpler, costExceedsValue) CD Provides: 写入决策(true/false)

isRedundant→false · simpler_exists→false · costExceedsValue→false · otherwise→true

OA(state, scope, recoverable) CD Provides: 输出动作(replace/rewrite/deprecate/delete)

modify∧local→replace · modify∧global→rewrite · deprecate∧recoverable→deprecate · deprecate∧¬recoverable→delete


§七、反模式索引

反模式 对应规则 严重等级 自动修复
编译错误遗留 FixPriority 高 否
代码质量违规 CodeStandard 中 部分
异常处理不当 FailMode + ThrowRule 中 否
内聚性违规 CohesionCheck 低 否
循环聚合 ReferenceStrategy 高 否
过度设计 CohesionCheck 低 否
盲目读取 InfoDomain 中 否
逐点读取 CalculateCost 低 否
过度读取 ReadStrategy 中 否
深度不匹配 ReadStrategy 中 否
认知分裂 InternalConsistency 高 是(StateRecovery)
缓存幻觉 ExternalConsistency 高 是(SyncGuard)
推理失忆 HistoricalIntegrity 高 是(CompactProcedure)
阶段粘连 PD 低 否
模块膨胀 CohesionCheck 低 否
压缩决策不当 CompactDecision 高 否
空结果死循环 engine.md §十 OnError 高 是(OnError 熔断)
空结果钻牛角尖 engine.md §十 OnError 中 是(OnError 熔断)
反复修改 IdempotencyCheck 中 是(IdempotencyGuard)

§八、操作流程(Procedures)

流程定义步骤序列。所有流程服从 Discrete-AtomicStep AX 的原子跃迁约束。

SyncGuard SM

步骤序列:

  1. TOOL: sync_check(paths) :对 fileCache 中所有条目执行物理校验
    • {status: "synced"} → 继续步骤 2
    • {status: "stale", stalePaths: [...]} → 刷新 fileCache 中对应条目的时间戳和哈希,设置 StateManager.externalConsistency = false,继续步骤 2
    • {status: "error", message} → 委托 ErrorHandler 处理
  2. 状态变量更新 :sync_check 返回 stale → 设置 externalConsistency = false,触发 StateValidity 重新评估
  • 默认在工具链执行前触发,可通过 @skip_sync_guard 标注跳过。

IdempotencyGuard SM

步骤序列:

  1. IdempotencyCheck :调用 IdempotencyCheck 策略进行幂等性检查
    • skip → 跳过本次执行
    • proceed → 进入执行体
    • null_input → 跳过本次执行(由调用方决定是否初始化新操作)
  2. 状态变量更新 :执行体完成后,通过 StateManager 更新 last 和 lastFileHash
  • 可选守卫,通过 @skip_idempotency_guard 标注跳过。与 SyncGuard 独立。

ErrorHandler SM

根据 OnError 输出的决策值执行对应动作:

复制代码
forcehalt  → 停止工具链 → 设置 forceHalt=true → 报告用户 → 强制挂起
halt       → 停止工具链
halt+persist → 停止工具链 → persist_reasoning(error_summary)
continue   → 记录错误摘要到 operationLog → 继续执行后续步骤
skip_remaining → 跳过剩余步骤 → persist_reasoning(error_summary)
retry      → 验证参数和系统状态是否已变化 → 重试当前步骤
switch_strategy → [回滚脏代码 → 换参数/换工具/报告用户]
- **编译错误回滚**:`error = compilation_error` 时先回滚到上次编译成功的代码版本。回滚范围仅限当前工具链中修改的文件。
- **文件快照机制**:执行体在修改文件前通过 StateManager 记录文件原始内容快照,回滚时从快照恢复。git stash 优先。
- **回滚失败处理**:回滚失败 → 输出 halt。
  • ErrorHandler 是 SyncGuard 和工具链执行失败时的统一处理入口,不包含决策逻辑。
  • ErrorHandler 的 persist_reasoning 仅用于异常终止时保存错误摘要,与 CompactProcedure 的阶段边界持久化职责不同。

ReasoningPersistence SM

职责区分 :persist_reasoning 有三种调用场景:

调用方 触发条件 写入内容 用途
CompactProcedure 阶段/模块边界 当前阶段的完整推理链 后续会话恢复推理上下文
ErrorHandler 异常终止 错误摘要 记录异常终止原因
PostProcess 工具链执行完毕 不调用 persist_reasoning 仅记录事实/结论到知识图谱

PostProcess SM

步骤序列:

  1. 推理 (reasoning):调用 sequentialthinking_tools 分析执行结果,形成结论
  2. 记录知识 (record_knowledge):调用 create_entities / create_relations / note 持久化关键发现(执行前引用 KnowledgeDedup 去重)
  • PostProcess 的 record_knowledge 存事实/结论,CompactProcedure 的 persist_reasoning 存推理链。两者职责不同。

FileDeprecationFlow SM

参数 :deprecatedDir(默认 _deprecated/)、excludeMethod(compile_exclude/runtime_ignore/module_exclude)、excludeConfig、cleanTrigger

步骤 :check_references → move_to_deprecated → apply_exclusion → verify_isolation → register_cleanup

CompactProcedure(compactType) SM

阶段动作映射:

阶段变更 动作
P_plan→P_exec_prep record_plan_to_graph
P_exec_prep→P_exec_core index_structure_to_kb
P_exec_core→P_exec_verify note_changes + persist_reasoning
P_exec_verify→P_complete update_progress

phase_compact → [执行阶段动作 → mark_phase_done → clear_context → 新会话从进度标记恢复,加载推理链末 RECENT_CHAIN_COUNT(3) 条到元提示]

module_compact → [record_module_summary + persist_reasoning → record_notes → update_progress_marker → clear_context]

emergency_dump → [输出极简纯文本状态摘要(≤EMERGENCY_DUMP_MAX_CHARS(500)字符) → clear_context → 强制 Halt,等待用户输入]

  • emergency_dump 跳过阶段动作映射和 persist_reasoning(截断风险 > 持久化收益)。
  • ctx_critical 信号应在当前步骤执行前检测,检测到后立即触发 emergency_dump。
  • none → no_action
相关推荐
余槐i6 小时前
将AI Agent嵌入现有Java系统时,Spring Boot 3.2的异步冲突与内存泄漏排查
人工智能·spring boot·性能优化·kubernetes·ai agent
tellmewhoisi7 小时前
机器学习:集成学习4(XGBoost推导)
人工智能·机器学习·集成学习
鲜于言悠9057 小时前
AI自动化工作流实战:告别重复加班的四层架构方案
人工智能
一水鉴天7 小时前
软件方法—工程函数—语言模型 20260925(千问)
人工智能·机器学习·边缘计算
程序员的账号7 小时前
《Python工匠》资源分享
人工智能·python·深度学习·机器学习
揽秀亭长7 小时前
视频转脚本有哪些技术路线?三种常见方案对比分析
人工智能·音视频
2601_962202987 小时前
首衡集采集配怕破损?万象包装优化降损耗
大数据·人工智能
随性而行3607 小时前
企业微信二次开发如何接入大模型工具?API接口实现智能任务调用的技术思路
java·前端·人工智能·python·微信·机器人·企业微信
IT大白鼠7 小时前
彭大帅的AI运维助手——自然语言管理 Linux 集群与网络设备——第 0 篇 · 导读:把 Linux 运维交给 AI,到底靠谱吗
linux·运维·人工智能
程序员的账号7 小时前
《深度学习入门2自制框架》中文PDF+源代码+斋藤康毅
人工智能·深度学习·pdf