企业官网建设流程全解析

• 人工智能
• AI 技能
• MCP 服务
• AI 评测

OpenSpace 的 GDPVal 基准评测（benchmarks/gdpval/README.md）通过冷启动与热启动两阶段反复执行 220 个职业技能任务来度量技能积累带来的 token 节省，而每个任务执行后都会产出包含iterations、tool_calls、artifacts等字段的执行记录。当一条执行记录显示迭代数为 0、没有任何工具调用、也没有任何产物时，这通常不是 Agent 推理能力的问题，而是发生在 Agent 正式工作之前的系统级故障——即零迭代失败（Zero-Iteration Failure）。

zero-iteration-failure-analysis 就是一套专门针对这类「执行前故障」的判别与处置工作流：它告诉你在什么条件下可以确认零迭代失败、如何对失败模式分类、如何把问题路由到系统层调查而不是错误地去做 Agent 层调试，以及如何在失败追踪系统中为这类故障打上独立标签。读完本文，你将掌握一套可直接落地的识别清单、分类表、排查步骤与上报规范，避免在基准分析或 Agent 运维中把基础设施问题误判为模型能力问题。

何时应用：读懂执行摘要中的三种「0」

应用该技能的前提是你正在分析 Agent 执行结果，并且观察到以下特征：

• 执行摘要报告 0 次迭代（iterations字段为 0）；
• 对话日志中没有工具调用（tool_calls/tool_executions为空）；
• 没有产生任何产物（没有文件、输出或中间结果）；
• 存在错误信息，但看不到 Agent 的推理过程。

在 OpenSpace 的基准实现中，这些字段正是由执行结果对象直接提供的：ExecutionResult数据类（见 openspace/runtime/execution_request.py）携带status、iterations、tool_executions、execution_time等字段；run_benchmark.py 在_run_single_task中把这些字段连同 token 统计、技能变化、评估结果一起写入phase1_results.jsonl/phase2_results.jsonl，其中iterations取execution_result.iterations（缺省为 0），tool_calls取len(execution_result.tool_executions)。换句话说，零迭代失败可以直接从基准输出 JSONL 的execution段识别出来，无需额外埋点。

识别检查清单：必须「全部」为真

一个零迭代失败只有在所有以下条件同时成立时才能被确认：

[ ] Iteration count = 0 （迭代数 = 0） [ ] Tool usage count = 0 （工具使用数 = 0） [ ] No conversation log beyond initial instruction（除初始指令外无对话日志） [ ] Error/self-report indicates failure before execution began（错误/自报表明执行开始前即失败）

注意这是严格的 AND 关系：只要迭代数 ≥ 1，无论结果多差，都说明 Agent 已经进入了执行阶段，应按普通执行类失败处理。姊妹技能 detect-zero-iteration-failures 给出了一个更便于程序化判断的等价版本——将iterations、工具调用、files_created以及「对话消息数 ≤ 1」四项指标全部纳入检查。

失败模式分类：先分清楚是「没开始」还是「没做好」

这张分类表是整个工作流的判断中枢：只有迭代数为 0 才属于「执行前失败」，才需要上升为系统级调查；迭代数 ≥ 1 的失败无论错误发生在中途还是产出错误，都属于 Agent 级问题，走标准 Agent 失败分析流程即可。

调查步骤：四步走

Step 1：确认零迭代状态

用一段确定性的代码把「执行前失败」从执行结果中分离出来（源自原文档，可直接复用）：

def is_zero_iteration_failure(execution_result): """Check if failure occurred before any agent iterations.""" return ( execution_result.get('iterations', 0) == 0 and execution_result.get('tool_calls', []) == [] and execution_result.get('artifacts', []) == [] )

在 OpenSpace 中，与之对应的是执行结果的实际形态：若execute()阶段抛出异常，_run_single_task会把status置为"error"并把异常信息写入error字段（见 run_benchmark.py）；若执行正常结束但记录显示 0 迭代，则对应ExecutionResult.iterations为 0 且tool_executions为空元组。

Step 2：提取错误上下文

检查任何错误消息或自我报告，重点寻找三类线索：

• 初始化错误（Initialization errors）：环境设置失败、依赖缺失、配置无效；
• 提示词解析错误（Prompt parsing errors）：指令格式错误、必填字段缺失；
• 资源错误（Resource errors）：内存限制、开始前超时、权限被拒绝。

从源码视角看，这些线索与基准脚本的预检逻辑一一对应：run_benchmark.py 的_check_environment会在正式执行前检查 LLM API Key（OPENROUTER_API_KEY/OPENAI_API_KEY等）、litellm 是否安装、openspace 是否可导入、任务数据是否就绪、评估用 API Key 与 meta-prompts 目录是否存在——任何一项失败都会打印 ❌ 并在--dry-run之外的模式下中止运行。这类「运行前检查失败」正是典型的系统级故障来源。

Step 3：路由到正确的调查方向

IF zero-iteration failure detected: → Escalate to SYSTEM investigation （升级为系统调查） → Do NOT attempt agent-level debugging （不要做 Agent 级调试） → Check: environment, dependencies, prompt format, resource limits ELSE: → Proceed with standard agent failure analysis（走标准 Agent 失败分析）

Step 4：记录失败模式

按统一的 YAML 结构归档失败分类，确保后续聚合分析口径一致：

failure_analysis: type: zero-iteration severity: high investigation_level: system agent_debugging_appropriate: false recommended_actions: - Check execution environment health - Verify prompt/input formatting - Review system logs for initialization errors - Validate resource availability

姊妹技能 detect-zero-iteration-failures 还提供了自动化路由的参考实现：categorize_failure在判定为零迭代失败时返回category: PRE_EXECUTION_FAILURE、severity: HIGH、investigation_team: INFRASTRUCTURE、agent_debug_required: False，否则返回EXECUTION_FAILURE并交由AGENT_DEVELOPMENT团队处理——可以直接嵌入你的失败分类管线。

常见原因与处置对照

关于「资源耗尽」还有一层值得注意的基准配置语义：grounding_max_iterations控制的是 Agent 每任务的迭代上限（默认 20，benchmarks/gdpval/config.json 中设为 30），它决定的是「执行阶段最多跑多少轮」，与「执行前是否失败」是两个不同的维度——零迭代失败恰恰发生在迭代配额被使用之前。

升级标准：什么情况要立即上报系统层

满足以下任一条件时，应立即标记为系统级审查：

• 同一会话内零迭代失败反复出现（>2 次）；
• 错误信息指向基础设施问题；
• 多个 Agent 以相同的零迭代模式失败。

最后一条尤其值得重视：如果多个 Agent 以同一模式零迭代失败，几乎可以断定是共享基础设施或共享配置出了问题，而非各 Agent 各自的推理问题。这与基准场景高度相关——两阶段运行会复用同一个 OpenSpace 实例与同一个.openspace/openspace.db技能库，任何一次环境层面的抖动都可能在后续任务中复现。

案例分析：一个完整的判别示范

EXECUTION SUMMARY: - Iterations: 0 - Tools Used: None - Artifacts: None - Status: Failed - Error: "Agent initialization failed: missing required config" ANALYSIS: ✓ Zero-iteration failure detected ✓ Pre-execution failure mode confirmed → Action: Escalate to system investigation → Do NOT debug agent reasoning (no reasoning occurred) → Check: config loading, environment variables, initialization sequence

对照组（来自 detect-zero-iteration-failure）则展示了「看起来失败但其实是执行失败」的情形：

Status: Failed Iterations: 3 Tools Used: [read_file, write_file, shell_agent] Files Created: [output.txt] Error: "Could not complete task due to X" Analysis: EXECUTION_FAILURE — debug agent reasoning and tool usage

两相对比可以清楚看到：区分标准永远先看迭代数。

必须避免的反模式

• ❌不要在迭代数为 0 时尝试调试 Agent 推理（推理根本没有发生）；
• ❌不要假设任务指令不清晰（Agent 从未看到指令）；
• ❌不要在检查系统健康之前就改用修改后的提示词重试；
• ❌不要将其归类为「Agent 性能问题」。

这些反模式的本质是一致的：零迭代失败意味着系统在「把任务交给 Agent」这一步就断了，任何面向提示词或推理链的修复都是无效动作，只会掩盖真实的基础设施问题。

与失败追踪系统的集成

记录失败时，应为零迭代失败打上独立标签，使其在聚合统计中与普通执行失败区分开：

{ "failure_id": "xyz123", "failure_mode": "pre_execution", "iteration_count": 0, "requires_system_review": true, "agent_actionable": false }

在 OpenSpace 的基准产出中，这一标签可以自然落到 JSONL 记录的status/execution.iterations字段上：status == "error"且execution.iterations == 0的记录即等价于failure_mode: pre_execution。配套技能 detect-zero-iteration-failures 还总结了四条要点：零迭代即执行前失败、属于系统级而非 Agent 级、高严重度（可能波及多个任务）、应作为独立失败模式单独处理。若在自动化重试场景中需要重试，务必先重置环境上下文——上一次失败可能已污染上下文状态。

延伸阅读

• 本技能文件：benchmarks/gdpval/skills/zero-iteration-failure-analysis/SKILL.md
• 同主题姊妹技能（判别清单更程序化 / 自动化分类实现）：detect-zero-iteration-failure、detect-zero-iteration-failures
• 两阶段基准的运行与结果结构：benchmarks/gdpval/run_benchmark.py、benchmarks/gdpval/README.md
• 执行结果数据模型与完成事件：openspace/runtime/execution_request.py、openspace/runtime/execution_events.py
• 运行前环境预检逻辑：run_benchmark.py

• 人工智能
• AI 技能
• MCP 服务
• AI 评测