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] 交叉引用 结构化引用外部规则定义 引用映射 无(元数据)

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

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),优先选择 directprocess 模式并强制重新读取(跳过 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_inputcurrent≠null ∧ last=null → 进入 proceed
  • 状态变量更新 :执行完毕后通过 StateManager 更新 last = currentlastFileHash = 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 更新 lastlastFileHash
  • 可选守卫,通过 @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)、excludeConfigcleanTrigger

步骤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
相关推荐
夏贰四1 小时前
数据资产平台如何落地企业数据分级合规管控?数据资产平台怎样满足行业数据监管审查要求?
大数据·数据库·人工智能
工业机器视觉设计和实现1 小时前
动量的好处与困扰(二,摸到pytorch尾灯!)
人工智能·pytorch·cudnn微积分
2401_865261631 小时前
亦唐科技:推动人工智能与行业应用深度融合
人工智能·科技
白驹_过隙1 小时前
【大模型OCR落地终极排坑:OvisOCR2+vLLM从报错到批量稳定部署全过程】
人工智能·ocr·vllm
产品人卫朋1 小时前
从AGI阶梯看AI硬件:具身智能还很远,物理约束就在眼前
人工智能·机器人·产品经理·创业·ai硬件
清泓y1 小时前
AI_Agent工具调用知识点
人工智能·ai
苦猿的大模型日记1 小时前
Day40|Agent 实战模块起手——ReAct + 工具 + 记忆,从 0 写一个不靠 LangChain 的 30 行核心 Agent
人工智能
txg6661 小时前
机器人领域简报(2026年7月20日—27日)
人工智能·microsoft·机器人
AI新角度1 小时前
开源维护自动化:issue 分类与发布管理的机器人实践
人工智能