Current State │ ├── User Intent ├── Validated Input ├── Tool Result ├── Environment ├── Permission └── Previous Step Status │ ▼ Evaluate Condition │ ┌───┼───────────────┐ ▼ ▼ ▼ Path A Path B Ask / Stop │ │ │ ▼ ▼ ▼ Action + Validation + State Update │ ▼ Next Decision Point
这里有两个关键要求：
条件必须基于已经观察或验证的状态；
分支执行后必须更新状态并验证结果。
因此，分支不是孤立的 if，而是状态机中的转移。
4. 一个完整分支的六个组成部分
一条工程化分支至少应包含：
4.1 Condition：命中条件
1
检测到 block I/O latency 的 P99 超过阈值
4.2 Evidence Source：条件来源
1
由 scripts/calc_io_metrics.py 的已验证输出提供
4.3 Action：执行动作
1
读取 references/io-analysis.md，并运行 I/O 专项分析
4.4 Postcondition：分支完成标准
1
输出必须包含设备、队列延迟、服务时间和样本数
4.5 Exit / Next State：后续去向
1
进入 evidence-correlation 阶段
4.6 Failure Behavior：条件无法评估或执行失败时怎么办
1
如果单位不明，标记为 unknown，不得与阈值比较；先修复单位问题
可以写成：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
### I/O branch
Enter this branch only when validated I/O metrics show either: - P99 queue latency above the configured threshold; or - sustained queue depth above the device baseline.
Read `references/io-analysis.md`, then run the I/O analysis workflow.
Postconditions: - device identity, sample count, queue latency, and service time are present; - each finding cites a metric or trace event; - uncertainty is recorded when coverage is incomplete.
If units or device identity are unknown, do not enter this branch. Resolve the missing state or report that I/O analysis cannot be completed.
5. 条件必须可观察、可判定
差的条件：
1
If the result looks suspicious, investigate further.
问题在于：
“可疑”没有定义；
没有证据来源；
不知道调查什么；
无法编写测试。
更好的条件：
1 2
If at least 5% of requests exceed the service SLO in a validated five-minute window, enter the latency-regression branch.
一个可判定条件通常需要：
字段或信号；
比较方式；
阈值或枚举；
时间范围；
单位；
数据完整性要求；
unknown 的处理方式。
6. 条件的六种常见来源
6.1 用户意图
1 2
if user asks only for explanation: do not perform external writes
6.2 输入特征
1 2 3 4
if input is a PDF: use the PDF extraction path elif input is DOCX: use the DOCX extraction path
6.3 工具或脚本结果
1 2 3 4
if parser.status == "ok" and event_count > 0: continue else: stop analysis
6.4 环境能力
1 2 3 4
if validator is available: run machine validation else: use the documented fallback or report the limitation
6.5 权限与授权
1 2 3 4
if user explicitly authorized publishing and permission check passed: publish else: keep the artifact local
6.6 工作流状态
1 2 3 4
if plan_validated: execute changes else: remain in planning
不要把这些来源混成一句模糊的“如果合适”。
7. True、False、Unknown：不要把未知当成否
许多 Skill 实际需要三值逻辑：
1 2 3 4 5 6 7 8
TRUE → 有足够证据确认条件成立
FALSE → 有足够证据确认条件不成立
UNKNOWN → 数据缺失、无权限、解析失败或覆盖不足
例如：
1
“没有检测到 I/O 异常”
可能表示：
I/O 数据完整，指标正常：FALSE；
没有采集 I/O 数据：UNKNOWN；
工具失败：UNKNOWN；
查询了错误设备：结果无效。
如果把 unknown 当成 false，Agent 会错误排除某个根因。
推荐显式建模：
1 2 3 4 5
{ "condition":"io_anomaly", "state":"unknown", "reason":"No block events were captured in the requested range." }
8. if / else if：互斥分支
当同一任务只能选择一条路径时，使用互斥分支。
1 2 3 4 5 6 7 8
if input_format == "perfetto": use Perfetto parser else if input_format == "ftrace": use ftrace parser else if input_format == "perf": use perf parser else: stop with unsupported format
Exit conditions: - every finding references an event or computed metric; - missing coverage is disclosed; - results are ready for evidence correlation.
{ "input_valid":true, "coverage":0.94, "signals":{ "scheduler":true, "memory":"unknown", "io":true }, "warnings":[ "Memory reclaim events are not available in this capture." ] }
22.2 分支规则
1 2 3 4 5 6 7 8 9 10 11
## Analysis routing
1. If `input_valid` is not true, stop before domain analysis. 2. If coverage is below 0.80, label all absence-of-signal conclusions as unknown and disclose limited coverage. 3. For every domain whose signal is true, run its analysis branch. 4. For a false signal with sufficient coverage, skip the branch and record `skipped_no_signal`. 5. For an unknown signal, do not claim the domain is normal. Record the reason and request additional data only when it is necessary to answer the user. 6. After all selected branches finish, run evidence correlation.
22.3 路由结果
1 2 3 4 5 6 7 8
scheduler = true → 执行 scheduler branch
memory = unknown → 不执行深度分析；记录数据缺失
io = true → 执行 I/O branch
22.4 汇合
1 2 3 4 5 6 7
Scheduler: high run-queue delay during 01:12–01:18 I/O: device queue latency normal until 01:17, then increases Deployment: new worker count applied at 01:10
if scheduler_signal == true: selected_branches += scheduler
if memory_signal == true: selected_branches += memory
if io_signal == true: selected_branches += io
if selected_branches is empty: if all signals == false and coverage sufficient: report no supported anomaly in observed domains else: report insufficient evidence
run selected branches validate each branch result correlate results
### Inputs - [validated state or field] - [evidence source]
### Priority 1. Safety and authorization gates 2. Input validity 3. User intent 4. Task-specific branches 5. Safe default
### Rules
- If [blocking condition]: stop and report [reason]. - If [missing user choice]: ask [specific question]. - If [condition A is true]: enter [branch A]. - If [condition B is true]: enter [branch B]. - If [condition is false]: record [skip state]. - If [condition is unknown]: do not treat it as false; record [reason].