从 Archon 看 AI 工程化落地：为什么"确定性编排+AI 弹性智能"是终局？
用 AI Coding 工具修 bug，跑三次可能得到三个不同的结果。这种"抛硬币"式的不可控，正是 AI 工程化落地最大的痛点。
Archon 的爆火不是偶然。它把开发流程编码成 YAML 工作流，确定性步骤和 AI 智能环节混合编排。每次工作流在独立的 git worktree 中运行，5 个修复任务并行执行互不冲突。内置 17 个默认工作流，覆盖修 issue、从想法到 PR、代码审查、安全重构等场景。
但更值得关注的是它背后的架构哲学： "AI 只在需要智能的环节介入。"
我们在垂直测试领域自研的 AI测试系统，恰好走了同一条路。本文将从 11 个维度对比两种实践，探讨"确定性编排+AI 弹性智能"为何成为 AI 工程化的行业共识。
一、两种场景，同一种活法
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 个字段。
为什么死磕 TypedDict？ LangGraph 的节点函数签名必须匹配状态字段。如果用普通 dict，拼错字段名只能在运行时发现，调试能把你逼疯。TypedDict 让 IDE 能自动补全和检查，省掉大量调试时间。
二、在测试场景里的三个额外尝试
测试场景与通用编码场景存在本质差异。我们在 Archon 的思路基础上，多做了三个方向的死磕：
1. 自愈能力（Healing）------ 测试失败不直接摆烂
Archon 的流程是线性的"生成 → 执行 → 审查"，遇到阻碍会报错或等待人工审查。我们的测试流程在此基础上多了一个自愈子图，测试失败后不是直接报错，而是先尝试自动修复。
自愈流程是一个 3 节点子图（诊断 → 规划 → 执行），支持自动重试。核心设计是正则匹配优先 + LLM 兜底：
- 正则匹配覆盖 4 类常见错误（network/element/authentication/assertion），置信度 0.9，毫秒级响应
- LLM 兜底诊断只在正则匹配失败（unknown）、置信度低于 0.8、或遇到复杂断言/业务错误时触发
- 每次修复结果写入自愈知识库，供后续分析
踩坑心得： 第一次搞自愈时，所有错误都走 LLM 诊断。问题很明显：每次诊断都要等几秒到十几秒，而且对于 connection refused、401 unauthorized 这种明确错误，LLM 给出的结论跟正则一样，白花钱白等时间。后来改成正则优先 + LLM 兜底------正则覆盖 4 类常见错误（置信度 0.9），只有 unknown、低置信度（<0.8）、或复杂断言才走 LLM。正则命中时诊断几乎瞬间完成，LLM 调用量大幅减少。别迷信 LLM，正则才是爹。
工具白名单机制： 自愈子图需要调用 MCP 工具，但 LLM 不能自由决定。我们在 healing_mcp_orchestrator.py 里做了 3 层工具优先级白名单（P0 紧急恢复 4 个工具、P1 环境修复 3 个工具、P2 事后处理 2 个工具），ALLOWED_HEALING_TOOLS 集合在模块加载时就固定了。安全第一，别给 AI 乱开权限。
2. 变量注入（VariablePool）------ 跨步骤的数据传递
Archon 侧重于代码逻辑的生成。我们的 VariablePool 解决的是测试执行中的另一个痛点：跨步骤的数据传递。
VariablePool 的 inject 方法用正则匹配 {{变量名}}，替换为实际值。支持递归解析（最多 5 层嵌套），每层替换后检查字符串是否变化，没变化就提前退出。配合 extract 方法（支持 regex/jsonpath 两种提取器），实现了完整的"提取 → 存储 → 注入"闭环。
实际场景： API 测试中，登录 → 提取 Token → 下单，Token 自动传递。处理的是有状态的业务链路（注册 → 提取 Token → 登录 → 下单 → 退款）。
踩坑心得： VariablePool 的 inject 方法用正则替换 {{变量}}，但如果变量值本身也包含 {{变量}}（比如 A = "{{B}}"，B = "{{A}}"），就会无限循环。解决办法是递归深度限制 ------最多 5 层，每层替换后检查字符串是否变化，没变化就提前退出。这个 for _ in range(5) 看起来简单，但如果没有这层保护，循环引用会让 inject 方法永远不返回，线程直接卡死。
3. RAG 知识增强 ------ 检索历史知识辅助生成
Archon 依赖通用大模型能力。我们的系统在分析和生成阶段引入了 RAG 检索，用历史用例和业务知识来辅助生成，这是我们在测试场景中的做法。
RAG 服务支持两种检索模式：ChromaDB 向量检索（重量级，>10 万条数据）和 MySQL 全文搜索（轻量级，<10 万条数据）。生成用例时，系统会检索历史用例和已知缺陷，确保生成的用例基于实际业务知识。
4. 实时 WebSocket 双向通信
我们的系统实现了 WebSocket 双向通信，除了推送进度和日志，还支持前端提交审核结果、手动触发重试等交互操作。Archon 走 SSE（单向推送），实现更简单；WebSocket 交互能力更强。
三、说实话，Archon 这三点确实做得好
客观说，Archon 有三个我们目前做不到的：
- 可视化工作流编辑：Web UI 拖拽编辑 YAML 工作流
- 远程触发：支持 Slack/Telegram/Discord/GitHub 直接触发
- 生态更丰富：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 走"低代码工作流"路线，覆盖通用编码场景；我们走"硬编码但深度定制"路线，深耕测试领域。两条路各有适合的场景。
🤔 讨论
如果你的测试系统也要支持"可视化拖拽配置测试流程"，你会选择 Archon 的 YAML 方案，还是 LangGraph 的 StateGraph 方案？为什么？
欢迎在评论区讨论。