用 AI 修 bug，跑三次出三个结果。有时候跳过测试，有时候忘了代码审查，有时候 PR 描述写得乱七八糟。
每次运行，都像抛硬币。这滋味搞过 AI 工程的都懂。
最近 Archon 火了。它把开发流程写成 YAML 工作流，确定性步骤和 AI 环节混在一起编排。5 个任务并行跑，互不冲突。内置 17 个默认工作流，修 issue、写 PR、代码审查，全都有。
但看到一句话的时候，我翻了一遍自己的代码库：
"AI 只在需要智能的环节介入。"
我心里咯噔一下。这不就是咱们搞测试系统时踩出来的路吗？我们在测试领域干的活，跟 Archon 在编码领域走的，其实是同一条路。
在 AI 工程化落地的深水区，"确定性编排 + AI 弹性智能"已经不是选择题，而是必答题。Archon 在通用编码领域验证了这条路，而我们的 AI测试系统则在垂直测试领域，多做了自愈、变量注入和 RAG 知识增强这几个方向的死磕。
对应代码：
- 主工作流：
backend/app/graphs/test_flow.py（992 行） - WS 推送辅助：
backend/app/graphs/test_flow_ws.py（97 行） - LangGraph API：
backend/app/api/langgraph.py（369 行） - 自愈修复：
backend/app/skills/healer.py（HealerSkill + 4 种修复策略） - 自愈编排：
backend/app/services/healing_mcp_orchestrator.py（520 行，3 层工具优先级） - 变量池：
backend/app/core/test_session.py（VariablePool：提取 + 注入） - RAG 服务：
backend/app/rag/service.py（MySQL 全文搜索 + ChromaDB 向量检索） - 前端：
frontend/src/views/testflow.vue（550 行）
🤝 两种场景，同一种活法
1. 别再把任务扔给 AI 就不管了
早期做 AI测试，我也试过"把需求扔给 LLM 就不管了"。结果呢？质量忽高忽低，漏用例、重复用例、不符合规范，全来了。
Archon 的宣言很直接：
"Dockerfile 规范了基础设施，GitHub Actions 规范了 CI/CD，那 AI 编码流程也需要一个规范。"
咱们测试也一样。不能靠 LLM 一次生成完事，得分步控制、人工干预、失败自愈。黑盒失控的代价，生产环境可不会给你重来的机会。
2. AI 负责"想"，代码负责"干"
这是两个系统最像的地方。
Archon 的流程：规划(AI) → 代码生成(AI) → 跑测试(确定性) → 代码审查(AI) → 提交(确定性)。 我们的流程：需求分析(AI+RAG) → 用例生成(AI+评审) → 执行测试(确定性+自愈) → 报告生成(确定性)。
| 环节 | AI 介入 | 确定性执行 |
|---|---|---|
| 需求分析 | LLM 提取功能点 + RAG 检索历史用例 | 结构化输出为 JSON |
| 用例生成 | LLM 生成测试步骤 + AI 评审回环 | 模板填充 + 变量注入 |
| 人工评审 | AI 评分 + 人工确认 | human_review_required 等待事件 |
| 测试执行 | --- | Playwright/Schemathesis 确定性执行 |
| 自愈修复 | LLM 兜底诊断 | 正则匹配 + 策略工厂 + 重试/降级 |
| 报告生成 | --- | HTML/CSV/JSON 模板渲染 |
关键区别：Archon 用 YAML，我们用 LangGraph 的 StateGraph。YAML 直观，拖拽就能改；StateGraph 灵活，条件分支、并行执行、状态传递，全用 Python 代码精确控制。没有绝对的好坏，只有适不适合。
3. 状态机是地基
Archon 的 YAML 工作流里，每个节点都能读写共享状态。我们的 TestState 也是这思路，用 TypedDict 定义，塞了 15 个字段（消息历史、用例 ID、会话 ID、9 种状态值、需求列表、RAG 上下文、测试步骤、执行结果......）。
为什么死磕 TypedDict？ LangGraph 的节点函数签名必须跟状态字段严丝合缝。用普通 dict，拼错一个字段名，跑起来才报错，调试能把你逼疯。TypedDict 让 IDE 自动补全+检查，省下的时间够喝两杯咖啡。
📐 测试这行，光靠 AI 不行，我们多做了三件事
测试场景跟编码场景不一样。我们在 Archon 的思路基础上，多做了三个方向的死磕：
1. 自愈能力（Healing）------ 测试失败不直接摆烂
Archon 是直来直去的线性流程，撞了南墙就报错，等人工来救。我们不一样，我们给自己留了后路------自愈子图。
测试失败不直接报错，先尝试自动修复。诊断 → 规划 → 执行，3 节点子图跑起来。
核心代码：HealerSkill（策略工厂模式）
# healer.py --- 自愈技能核心：diagnose 方法
class HealerSkill:
def diagnose(self, error_message: str, context: Dict) -> Dict:
"""诊断错误：正则匹配优先，LLM 兜底"""
error_type, confidence = self._classify_error(error_message)
# 正则匹配失败 or 低置信度 → LLM 兜底
need_llm = (
error_type == "unknown"
or confidence < 0.8
or error_type in ["assertion", "business"]
)
if need_llm:
llm_result = self._llm_diagnose(error_message, context)
if llm_result and llm_result["confidence"] >= confidence:
diagnosis.update(llm_result)
diagnosis["diagnosis_source"] = "llm"
# 策略工厂匹配
selected = self._select_strategy(diagnosis)
diagnosis["auto_repairable"] = selected is not None
return diagnosis自愈编排层（healing_mcp_orchestrator.py）定义了 3 层工具优先级白名单：P0（紧急恢复，4 个工具：创建测试数据/刷新 session/重置状态/获取日志）、P1（环境修复，3 个工具：DOM 快照/清浏览器/特性开关）、P2（事后处理，2 个工具：创建 bug/回滚数据）。ALLOWED_HEALING_TOOLS 集合在模块加载时就焊死了，LLM 只能在这个圈子里选。
设计要点 ：正则匹配覆盖 4 类常见错误（网络/元素/鉴权/断言），置信度 0.9；LLM 兜底处理复杂场景。正则命中时诊断几乎瞬间完成，LLM 调用量大幅减少。每次修复结果还会写入自愈知识库（healing_knowledge_base.json），越用越聪明。
踩坑 1：别迷信 LLM，正则才是爹
第一次搞自愈时，所有错误都走 LLM 诊断。问题很明显：每次诊断都要等几秒到十几秒，而且对于 connection refused、401 unauthorized 这种明确错误，LLM 给出的结论跟正则一样，白花钱白等时间。后来改成正则优先 + LLM 兜底------正则覆盖 4 类常见错误（置信度 0.9），只有 unknown、低置信度（<0.8）、或复杂断言才走 LLM。正则命中时诊断几乎瞬间完成，LLM 调用量大幅减少。
踩坑 2：给 AI 戴紧箍咒
自愈子图需要调用 MCP 工具（创建测试数据、刷新 session、截图等）。如果让 LLM 自由决定调用什么工具，它可能脑子一热调用 delete_all_data。我们在 healing_mcp_orchestrator.py 里做了工具白名单 ，分 3 层优先级，总共 9 个工具。ALLOWED_HEALING_TOOLS 集合在模块加载时就固定了，LLM 只能在这个范围内选择。安全第一，别给 AI 乱开权限。
踩坑 3：变量注入的无限套娃
VariablePool 的 inject 方法用正则替换 {``{变量}}，但如果变量值本身也包含 {``{变量}}（比如 A = "{``{B}}"，B = "{``{A}}"），就会无限循环。解决办法是递归深度限制 ------最多 5 层，每层替换后检查字符串是否变化，没变化就提前退出。这个 for _ in range(5) 看起来简单，但如果没有这层保护，循环引用会让 inject 方法永远不返回，线程直接卡死。
2. 变量注入（VariablePool）------ 跨步骤的数据传递
Archon 侧重于代码逻辑的生成。我们的 VariablePool 解决的是测试执行中的另一个痛点：跨步骤的数据传递。
VariablePool 的核心是 inject 方法：用正则匹配 {``{变量名}}，替换为实际值。支持递归解析（最多 5 层嵌套），每层替换后检查字符串是否变化，没变化就提前退出。配合 extract 方法（支持 regex/jsonpath 两种提取器），实现了完整的"提取 → 存储 → 注入"闭环。
实际场景 ：API 测试中，登录 → 提取 Token → 下单，Token 自动传递。步骤 1：POST /api/login 响应 {"token": "***"}，extract 提取为 SESSION.login.token。步骤 2：GET /api/orders 的 headers 中 {``{login.token}} 被 inject 替换为实际值。
Archon 没有这个机制，它侧重于生成独立的代码片段。VariablePool 是我们为测试场景做的尝试，用来处理有状态的业务链路（注册 → 提取 Token → 登录 → 下单 → 退款）。当然，Archon 的定位是通用编码，测试场景的变量传递本来就不是它的目标。
3. RAG 知识增强 ------ 检索历史知识辅助生成
Archon 依赖通用大模型能力。我们的系统在分析和生成阶段引入了 RAG 检索，用历史用例和业务知识来辅助生成，这是我们在测试场景中的做法。
RAG 服务支持两种检索模式：ChromaDB 向量检索（重量级，>10 万条数据）和 MySQL 全文搜索（轻量级，<10 万条数据）。MySQL 全文搜索使用 MATCH ... AGAINST IN BOOLEAN MODE，查询时添加 + 前缀通配符，按 relevance DESC, quality_score DESC 排序。
实际价值：生成用例时，系统会检索历史用例和已知缺陷。比如测试"支付功能"时，RAG 会返回：
- 历史用例：支付超时处理、重复支付拦截
- 已知缺陷：某版本中微信支付回调延迟问题
- 测试规范：支付相关用例必须包含正向 + 逆向场景
生成的用例基于实际业务知识，不再"从零开始"。
4. 实时 WebSocket 双向通信
我们的系统实现了 WebSocket 双向通信：
| 消息类型 | 方向 | 说明 |
|---|---|---|
execution_progress |
服务端 → 前端 | 执行进度推送（progress + status） |
execution_log |
服务端 → 前端 | 实时日志推送（message + level） |
execution_complete |
服务端 → 前端 | 执行完成通知 |
human_review_required |
服务端 → 前端 | 审核卡片（含可修改用例） |
pong |
服务端 → 前端 | 心跳回复（响应前端 ping） |
Archon 走 SSE（Server-Sent Events），是单向推送。我们的 WebSocket 除了推送进度和日志，还支持前端提交审核结果、手动触发重试等交互操作。两种方案各有所长，SSE 实现更简单，WebSocket 交互能力更强。
📊 说实话，Archon 这三点确实做得好
客观说，Archon 有三个我们目前做不到的：
1. 可视化工作流编辑
Archon 有 Web UI，可以拖拽编辑 YAML 工作流。我们的流程是硬编码的 StateGraph，改流程要改代码、重新部署。这块确实得学。
2. 远程触发
Archon 支持 Slack/Telegram/Discord/GitHub 直接触发工作流。我们的系统只有 API 和前端界面，没有集成这些外部渠道。
3. 生态更丰富
17 个默认工作流模板，开箱即用。我们的系统只内置了测试流程，其他场景需要自己扩展。
每个开源项目都有自己的定位。 Archon 覆盖通用编码场景，我们的系统聚焦测试领域，各有各的侧重点。
🎯 总结：两条不同的路
| 对比维度 | Archon | AI Test System |
|---|---|---|
| 核心理念 | AI 编码需要规范 | 测试流程需要规范 |
| 工作流定义 | YAML（可视化编辑） | LangGraph StateGraph（代码定义） |
| 混合编排 | 确定性 + AI | 确定性 + AI + RAG |
| 人工审核 | 审批节点 | 审核卡片（可修改用例） |
| 自愈能力 | --- | 3 节点子图 + 策略工厂 + MCP 编排 |
| 变量注入 | --- | VariablePool（提取 + 注入 + 递归解析） |
| 实时通信 | SSE（单向） | WebSocket（双向） |
| RAG 知识增强 | --- | MySQL 全文搜索 + ChromaDB 向量检索 |
| 远程触发 | Slack/Telegram/Discord | --- |
| 默认模板 | 17 个工作流 | 1 个测试流程 |
| 可视化 | Web UI 拖拽 | --- |
核心结论：
- "确定性编排 + AI 弹性智能"是行业共识 --- Archon 在通用编码领域验证了这条路，我们在垂直测试领域做了同样的事
- 我们的侧重点：自愈（3 节点子图 + 策略工厂 + MCP 工具编排）、变量注入（处理有状态业务链路）、RAG 增强（用历史用例辅助生成）
- Archon 的优势值得学习：可视化编辑、远程触发、丰富模板，这些是我们未来迭代的方向
不是谁取代谁的问题，而是两条不同的路：Archon 走"低代码工作流"路线，覆盖通用编码场景；我们走"硬编码但深度定制"路线，深耕测试领域。两条路各有适合的场景。
🔔 关注"测试员周周"，14 年测试老兵，持续分享 AI测试实战经验。