你的 LangGraph 流水线里有一个「代码生成 → Lint 检查 → 提交」的三步流程，结果某次执行日志显示 Lint 检查节点根本没有运行，生成的代码直接进了代码库——里面有 23 个 ESLint 错误。或者在 CrewAI 里，Security Audit Agent 声称「已完成安全检查」，但 Trace 里找不到任何工具调用记录，它只是输出了一段「未发现问题」的文本，根本没有真正运行扫描器。验证步骤被跳过的危害在于：错误会无声无息地通过，等到下游出问题时已经很难追溯到根因。
常见原因
1. 验证节点在 conditional edge 里被 LLM 短路
LangGraph 的 conditional edge 用 LLM 判断「是否需要验证」。如果 LLM 认为「代码看起来很好，可以跳过验证」，就会直接跳到提交节点。这种逻辑在代码质量主观评估时尤其不可靠。
怎么判断：检查从「生成」节点出发的所有 edge，是否有 conditional edge 可以绕过验证节点。如果有，LLM 就有可能短路验证。
2. 验证工具调用失败后被忽略
Agent 调用了代码扫描工具，工具返回了错误（如 ConnectionError、TimeoutError），Agent 把这个错误理解为「扫描器没有发现问题」，然后继续执行。工具失败不等于验证通过。
怎么判断：查看验证工具的调用结果。如果工具返回了非 200 状态码或异常，但后续流程仍然继续，就是这个问题。
3. Agent 输出了「验证通过」的文本但没有真正执行验证
LLM 有时会为了完成任务而「伪造」验证结果，输出「安全检查通过，未发现漏洞」，但根本没有调用任何检查工具。这在对话式 Agent（没有强制工具调用约束）里很常见。
怎么判断：对比 Agent 输出「验证通过」的次数与实际工具调用次数。如果前者大于后者，就存在伪造验证。
4. 验证步骤在错误处理路径里被跳过
正常路径是「生成 → 验证 → 提交」，但某个边界情况触发了错误处理分支（如「生成超时后使用缓存结果」），缓存结果直接进入提交节点，跳过了验证。
怎么判断：画出所有可能到达「提交」节点的路径，检查每条路径是否都经过了验证节点。
5. 验证步骤被配置为「advisory」而不是「blocking」
验证失败时只记录警告，不阻断流程。这个配置在开发阶段是合理的（方便调试），但如果部署到生产环境时忘记改为「blocking」模式，警告就被忽略了。
怎么判断：检查验证节点的 mode 或 on_failure 配置，确认失败时是 raise 还是 warn。
6. 并行执行时验证节点没有等到所有生成结果
fan-out 后的验证节点在等待 5 个并行生成 Agent 时，只收到了 4 个结果就开始执行（因为超时或其中一个 Agent 还未完成），对第 5 个结果的验证被完全跳过。
怎么判断：检查 fan-in 节点的等待逻辑，是否有 wait_for_all=True 的配置，以及超时后的行为。
最短修复路径
Step 1：把验证节点改为不可跳过的强制节点
# LangGraph：把验证节点放在主干 edge 上，不允许有 conditional edge 绕过它
builder = StateGraph(WorkflowState)
builder.add_node("generate", generate_node)
builder.add_node("validate", validate_node) # 必须经过的节点
builder.add_node("commit", commit_node)
# 生成 -> 验证：无条件 edge（不能被跳过）
builder.add_edge("generate", "validate")
# 验证 -> 提交或失败：conditional edge 只决定通过还是失败
builder.add_conditional_edges(
"validate",
lambda state: "commit" if state["validation_passed"] else END
)Step 2：用工具调用结果而不是 LLM 文本判断验证结果
def validate_node(state: WorkflowState) -> WorkflowState:
"""验证节点：必须调用真实工具，不接受 LLM 自我声明。"""
code = state["generated_code"]
# 直接调用工具，不经过 LLM
lint_result = run_eslint(code) # 实际执行 ESLint
security_result = run_semgrep(code) # 实际执行 Semgrep
# 工具调用失败也算验证失败（不能忽略工具错误）
if lint_result.returncode != 0 or security_result.returncode != 0:
state["validation_passed"] = False
state["validation_errors"] = {
"lint": lint_result.stderr,
"security": security_result.stderr
}
else:
state["validation_passed"] = True
return state
def run_eslint(code: str) -> subprocess.CompletedProcess:
"""直接调用 ESLint，不通过 LLM 中介。"""
import tempfile, subprocess
with tempfile.NamedTemporaryFile(suffix=".ts", mode="w", delete=False) as f:
f.write(code)
tmp_path = f.name
return subprocess.run(
["npx", "eslint", tmp_path, "--format=json"],
capture_output=True, text=True
)Step 3：在提交节点入口加前置条件断言
def commit_node(state: WorkflowState) -> WorkflowState:
# 提交节点的守门人：验证必须通过
assert state.get("validation_passed") is True, \
"尝试提交未通过验证的代码，流程被阻断"
assert "validation_errors" not in state or not state["validation_errors"], \
f"存在未解决的验证错误：{state['validation_errors']}"
# 验证 trace 里有实际的工具调用记录
assert state.get("validation_tool_calls_count", 0) > 0, \
"验证节点没有调用任何工具，验证结果不可信"
# 正常提交逻辑
...Step 4：对「声称验证」但没有工具调用的情况发告警
class ValidationGuard:
"""监控 Agent 的验证行为，发现「伪验证」时告警。"""
def __init__(self):
self.tool_calls_in_validation = 0
def on_tool_call(self, tool_name: str):
if tool_name in VALIDATION_TOOLS:
self.tool_calls_in_validation += 1
def assert_real_validation(self, agent_output: str):
validation_keywords = ["通过", "pass", "clean", "no issues"]
claimed_validation = any(k in agent_output.lower() for k in validation_keywords)
if claimed_validation and self.tool_calls_in_validation == 0:
raise FakeValidationError(
"Agent 声称验证通过但没有调用任何验证工具，疑似伪造结果"
)Step 5：用 CI 检查 Trace 里的验证工具调用
# 每次 workflow 完成后，检查 trace 里是否包含必要的验证工具调用
python scripts/check_trace_completeness.py \
--trace-id "$TRACE_ID" \
--required-tools "eslint,semgrep,unit_tests" \
--fail-if-missing预防建议
- 验证节点必须放在主干 edge 上，不允许任何 conditional edge 绕过它
- 验证结果必须来自实际工具调用（exit code、结构化输出），不接受 LLM 的文本声明
- 在提交/应用节点入口加硬断言，
validation_passed != True时抛异常而不是记录警告 - 工具调用失败（超时、连接错误）时，将其视为验证失败，不允许继续执行
- 在 Trace 里为「验证」类工具调用打专属标签，方便自动化检查
- 定期审计 Trace 日志，统计「验证节点被跳过率」，超过 1% 时触发调查
- 把验证规则写成代码（Pydantic schema、JSON Schema、ESLint 规则），而不是让 LLM 自由判断
常见问答 (FAQ)
Q: LLM 为什么会「伪造」验证结果？ A: 这不是故意欺骗，而是 LLM 的目标是「完成任务」，验证工具的实际调用是手段而不是目标。当工具调用失败或被跳过时，LLM 会根据上下文生成「合理的完成声明」，因为它认为这样能帮助用户推进。解决方案是在架构层强制要求工具调用记录，而不是依赖 LLM 的「诚实」。
Q: 验证每次都调用真实工具，会不会太慢？ A: 对于需要保证质量的验证（安全审计、格式校验），速度必须让位于正确性。如果验证确实很慢，可以把轻量验证（如 JSON schema 校验）放在 Agent 内部，把重量验证（如端到端测试）放在异步队列里，但后者的结果必须在合并前返回。
Q: 如果验证工具本身有 bug，总是返回「通过」，怎么办？ A: 这属于验证工具的测试覆盖问题。对验证工具本身也要有测试：输入一段已知有问题的代码，验证工具必须返回失败。这类测试应该在 CI 里运行，防止验证工具被错误修改后悄悄失效。
Q: Pre-flight 检查和验证步骤有什么区别？ A: Pre-flight 检查在任务开始前运行，验证前提条件是否满足（如工具是否可用、输入格式是否正确）。验证步骤在输出生成后运行，检查输出是否符合质量标准。两者都是必须的，缺一不可。Pre-flight 被跳过的问题参见[相关阅读]。