yuqei/ai-exchange
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b74c124254922c6ee1f0ff3f0b5dd354d888b2ef
ai-exchange/docs/archive/AI_ICT_自动化流程使用教程_v1.md
T

12 KiB
Raw Blame History

AI ICT 自动化流程使用教程 v1

0. Current Default After P0-P6 Freeze

As of 2026-05-11, the default automation entrypoint for this project is:

scripts/run_until_blocked.py

When SESSION.md / TASKS.md contain automation_flow_p0_p6_review_closed, this script does not use the older monitoring rollout phase queue. It first runs the Research Council P6 governance tick and applies the frozen P0-P6 policy:

  • no_op_healthy: record health, stop Research Council phase expansion, and do not create P7.
  • cycle_required: run an optimization cycle only when the automation policy explicitly authorizes it.
  • bounded_slice_required: open only the smallest bounded implementation slice, then return to P6.

After the analysis/decision-only monitor reaches a stable quality window, the default loop no longer stays on continue_periodic_analysis_decision_monitoring. It advances to:

automation_execution_layer_p7_monitor_maturity_rollup

This is automation execution-layer P7, not Research Council P7. It must keep the P0-P6 Research Council freeze, preserve observe-only semantics, and keep execution/live/risk/trust/operator confirmation gates unchanged.

The older scripts/run_monitoring_alert_rollout.py repair bridge remains historical/supporting tooling. It is not the default entrypoint for the current automation execution-layer flow.

The first execution-layer bootstrap slices are:

P0: P6 governance tick routing
P1: anchor-driven smallest-slice selector
P2: validation and quality-gate router
P3: deploy/smoke router
P4: state writeback renderer
P7: monitor maturity rollup and bounded next-slice routing

0.1 Default Kickoff Prompt

Going forward, the default operator kickoff prompt for this repository is:

启动 D:\ai-exchange 自动化流程。
请先读取并以这些锚点为准：
1. docs/AI_ICT_实盘交易分析决策助手下一阶段开发方案_v1.md
2. SESSION.md
3. TASKS.md
全程按自动化闭环执行：读取锚点 -> 选择最小切片 -> 实现 -> focused validation -> 必要质量门 -> 必要时远端 deploy/smoke -> 回写 SESSION.md / TASKS.md。
遇到真实外部阻塞再停下来说明，run-until-blocked。

docs/AI_ICT_全自动开发执行流程_v1.md remains the protocol specification, but it is no longer required in the user-facing kickoff prompt. docs/AI_ICT_TradingAgents_P0-P6合理性审查与优化结论_v1.md remains as a historical governance-freeze reference and is not part of the default kickoff anchors anymore.

1. 文档目标

本文档用于说明当前项目内自动化编排工具的用途、使用方式、运行模式、repair bridge 协议、常见命令和实践建议，作为后续学习和日常使用手册。

当前这套工具仍然是 ai-exchange 项目专用版本。

不建议现在就抽成通用模板，因为它还需要继续通过实际项目推进来检验和修正。

2. 工具概览

当前主脚本：

scripts/run_monitoring_alert_rollout.py

相关配套文档：

  • docs/archive/AI_ICT_下一阶段开发任务清单_v1.md
  • docs/AI_ICT_repair_bridge_protocol_v1.md

这个脚本的目标不是直接替你完成所有业务开发，而是把当前项目的阶段推进流程固化为：

阶段执行
-> 验证
-> 发现失败
-> 生成修复上下文
-> 桥接外部修复代理
-> 智能复验
-> 推进下一阶段

3. 当前支持的阶段

当前脚本内置四个阶段：

  • N1 Launch Readiness 收尾
  • N2 最小主动消息告警闭环
  • N3 告警质量与 runtime 硬化
  • N4 视觉盯盘增强预埋

这些阶段定义在脚本的 PHASES 中，包括：

  • code
  • title
  • goal
  • tasks
  • files
  • validation_commands
  • deliverables

4. 运行模式一览

通过环境变量控制：

MONITORING_ALERT_ROLLOUT_MODE

当前支持：

  • plan
  • status
  • start
  • advance
  • block
  • complete
  • run-until-blocked
  • repair-loop
  • repair-bridge

5. 最常用命令

5.1 查看计划

.venv/bin/python scripts/run_monitoring_alert_rollout.py

作用：

  • 查看当前有哪些阶段
  • 查看自动化策略说明

5.2 初始化状态

MONITORING_ALERT_ROLLOUT_MODE=start .venv/bin/python scripts/run_monitoring_alert_rollout.py

作用：

  • 初始化 .claude/monitoring_alert_rollout_status.json
  • 标记当前 phase 为首个阶段

5.3 查看状态

MONITORING_ALERT_ROLLOUT_MODE=status .venv/bin/python scripts/run_monitoring_alert_rollout.py

作用：

  • 查看当前 phase
  • 已完成阶段
  • 上次运行结果
  • repair loop 状态

5.4 跑当前阶段直到卡住

MONITORING_ALERT_ROLLOUT_MODE=run-until-blocked .venv/bin/python scripts/run_monitoring_alert_rollout.py

作用：

  • 执行当前阶段的验证命令
  • 自动判断：
    • passed
    • needs_work
    • blocked
  • 如果通过，会自动推进 phase

这是日常最核心的命令。

5.5 生成修复循环上下文

当 run-until-blocked 返回 needs_work 时：

MONITORING_ALERT_ROLLOUT_MODE=repair-loop .venv/bin/python scripts/run_monitoring_alert_rollout.py

作用：

  • 从上次失败结果生成 repair loop payload
  • 生成：
    • failure_class
    • recommended_focus
    • phase_patch_targets
    • repair_prompt_context

5.6 桥接外部修复代理

MONITORING_ALERT_AUTO_REPAIR_ENABLED=1 \
MONITORING_ALERT_REPAIR_BRIDGE_COMMAND="python your_repair_agent.py" \
MONITORING_ALERT_ROLLOUT_MODE=repair-bridge \
.venv/bin/python scripts/run_monitoring_alert_rollout.py

作用：

  • 把 repair prompt/context 通过 JSON stdin 发给外部修复代理
  • 解析外部修复代理 stdout JSON
  • 决定是否自动复验

5.7 启用桥接后自动复验

MONITORING_ALERT_AUTO_REPAIR_ENABLED=1 \
MONITORING_ALERT_AUTO_RERUN_ENABLED=1 \
MONITORING_ALERT_REPAIR_BRIDGE_COMMAND="python your_repair_agent.py" \
MONITORING_ALERT_ROLLOUT_MODE=repair-bridge \
.venv/bin/python scripts/run_monitoring_alert_rollout.py

作用：

  • 调 repair agent
  • 解析返回 JSON
  • 智能选择复验命令
  • 自动回跑 run-until-blocked
  • 自动判断是否 phase advance

5.8 JSON 输出模式

MONITORING_ALERT_ROLLOUT_OUTPUT_JSON=1 \
MONITORING_ALERT_ROLLOUT_MODE=status \
.venv/bin/python scripts/run_monitoring_alert_rollout.py

作用：

  • 返回 machine-readable 输出
  • 适合给别的脚本、代理或 IDE 工具消费

6. 重要环境变量

6.1 基础模式

  • MONITORING_ALERT_ROLLOUT_MODE
  • MONITORING_ALERT_ROLLOUT_OUTPUT_JSON=1

6.2 运行控制

  • MONITORING_ALERT_ROLLOUT_MAX_ROUNDS
  • MONITORING_ALERT_COMMAND_TIMEOUT_SECONDS

6.3 repair bridge

  • MONITORING_ALERT_AUTO_REPAIR_ENABLED=1
  • MONITORING_ALERT_REPAIR_BRIDGE_COMMAND="..."
  • MONITORING_ALERT_AUTO_RERUN_ENABLED=1

6.4 手动 blocker

  • MONITORING_ALERT_BLOCKER
  • MONITORING_ALERT_BLOCKER_NOTE

7. 状态文件与锚点文件

7.1 状态文件

.claude/monitoring_alert_rollout_status.json

记录内容包括：

  • 当前 phase
  • 已完成 phase
  • last run
  • repair loop 状态
  • patch rounds
  • history

7.2 锚点文件

脚本还会维护：

  • SESSION.md
  • TASKS.md

当前通过固定区块：

## Automation Status

做结构化更新，而不是简单重复追加。

8. repair loop 的意义

当阶段验证失败时，脚本会生成两层信息：

8.1 next-step guidance

给人类直接看：

  • priority tasks
  • suggested files
  • suggested commands
  • reasoning

8.2 repair metadata

给后续自动修复代理使用：

  • failure_class
  • recommended_focus
  • phase_patch_targets
  • phase_validation_entrypoint
  • repair_prompt_context

9. repair-bridge JSON 协议

详见：

docs/AI_ICT_repair_bridge_protocol_v1.md

9.1 stdin 输入

脚本会给 repair agent 发一段 JSON，例如：

{
  "protocol_version": "repair-bridge/v1",
  "mode": "repair_loop",
  "phase": "N2",
  "phase_title": "最小主动消息告警闭环",
  "failure_class": "alert_dispatch_gap",
  "recommended_focus": "alert_delivery_and_dispatch",
  "phase_patch_targets": [
    "src/services/alerts/alert_dispatcher_service.py"
  ],
  "validation_entrypoint": ".venv/bin/python scripts/run_alert_dispatcher.py",
  "repair_prompt_context": {
    "prompt_text": "..."
  }
}

9.2 stdout 输出

repair agent 应返回 JSON，例如：

{
  "protocol_version": "repair-bridge/v1",
  "status": "applied",
  "summary": "Implemented missing alert dispatcher module and updated runtime hook.",
  "changed_files": [
    "src/services/alerts/alert_dispatcher_service.py",
    "src/services/runtime/trading_runtime_service.py"
  ],
  "notes": ["Focused on N2 alert delivery gap"],
  "success_guess": true,
  "tests_run": [
    ".venv/bin/python scripts/run_alert_dispatcher.py"
  ]
}

10. 当前自动复验规则

repair agent 返回值会参与决策。

自动复验前提

必须满足：

  1. MONITORING_ALERT_AUTO_RERUN_ENABLED=1
  2. stdout JSON 可解析
  3. schema 合法
  4. status in {applied, success, fixed}
  5. success_guess != false
  6. changed_files 非空

11. 智能复验调度

脚本当前优先级：

优先级 1：有 tests_run

如果 repair agent 已经给出 tests_run，优先执行这些命令。

优先级 2：没有 tests_run

根据 changed_files 自动选 focused rerun：

  • 改动 src/services/alerts/ 或 src/api/alerts.py
    • 运行 scripts/run_alert_dispatcher.py
  • 改动 src/services/runtime/ 或 src/api/trading_runtime.py
    • 运行 scripts/run_trading_runtime.py
  • 改动 src/services/readiness/ / src/web/ / src/config/settings.py
    • 运行 scripts/run_launch_readiness.py
  • 改动 src/services/decision/ / src/services/operator/
    • 运行 scripts/run_review_packet.py
  • 如果改动全在 docs/
    • 跳过 focused rerun

然后再回到 run-until-blocked 做阶段判断。

12. patch round 历史

每次 repair bridge 现在都会记录 patch round，内容包括：

  • 第几轮 repair
  • 本轮 changed_files
  • 本轮 tests_run
  • 本轮 success_guess
  • 本轮 rerun_state
  • 是否 phase_advanced

这些历史会写在状态文件的 repair_loop.patch_rounds 中。

13. 当前工具的实际定位

这套工具现在还不是完全通用的跨项目平台，它是：

为 ai-exchange 项目定制演化出来的自动化 orchestrator

特点：

  • 阶段定义写在脚本里
  • 验证命令写在脚本里
  • rerun 规则写在脚本里
  • 锚点文件是当前项目结构

所以目前最适合：

  • 继续在本项目里使用
  • 一边推进，一边发现 bug 再修
  • 等经过更多实践验证后，再考虑抽通用模板

14. 实践建议

14.1 推荐日常顺序

1. run-until-blocked
2. 如果 needs_work -> repair-loop
3. 如果有 repair agent -> repair-bridge
4. 自动复验
5. 再看 status

14.2 推荐先人工观察几轮

虽然现在已经有自动修复桥接、自动复验，但仍建议：

  • 先人工观察几轮
  • 看 repair agent 返回 JSON 是否稳定
  • 看 focused rerun 选择是否合理
  • 看 phase advance 是否符合预期

14.3 外部 repair agent 最好把调试日志写到 stderr

这样 stdout 可以保持纯 JSON，更容易被脚本可靠解析。

15. 后续维护建议

如果后面发现 bug，优先检查：

  1. repair-bridge stdout 是否是合法 JSON
  2. changed_files 是否真实反映改动
  3. tests_run 是否写成了脚本真实执行的命令
  4. 自动 focused rerun 是否选对了命令
  5. SESSION.md / TASKS.md 的 anchor block 是否被错误修改

16. 总结

这套工具当前已经具备：

  • 阶段推进
  • 自动验证
  • run-until-blocked
  • repair loop
  • repair bridge
  • JSON 协议桥接
  • 智能复验
  • patch round 历史
  • 状态锚点写回

它已经足够作为：

当前项目内自动化流程的学习与实操工具

后续先继续在本项目里实践，遇到 bug 再逐步修正，比现在就做通用模板更稳。

Reference in New Issue View Git Blame Copy Permalink