|
|
## 结论
这次不是旧的“模型文本复读/无法发出工具调用”，而是 **NeCode 0.0.21 内置 OMN 调度器的超时、重试和任务拆分策略共同导致的失败**。
截图中的“Orion 运行中、其余全部阻塞”在 23:23:18 当时是依赖链的正常表现；但该运行随后于 **23:28:42** 确认失败：
```text
Run ID: omn-d645bca6b399b58595b34765
最终状态: failed
错误: Tasks exhausted recovery attempts: gate0a-core
```
如果界面现在仍显示“运行中”，则还叠加了 UI 状态没有及时刷新的问题。
## 实际证据
Orion 并非没有响应。三次尝试都在持续推理、读文件和执行工具，但每次恰好在固定两分钟被宿主中断：
| 尝试 | 时间 | 输入 Token | 结果 |
|---|---|---:|---|
| 1 | 23:22:41–23:24:41 | 61,508 | `timed out after 120000ms` |
| 2 | 23:24:41–23:26:41 | 54,552 | 同上 |
| 3 | 23:26:42–23:28:42 | 50,480 | 同上 |
第一次尝试结束时，正在执行的 bash 被标记为：
```text
Tool execution aborted
metadata.interrupted = true
```
所以不是 bash 自身失败、网络断线或权限等待，而是调度器主动终止。
Echo、Sage、Raven、Bolt、Iris 均为：
```text
消息数 = 0
输入/输出 Token = 0
```
它们只是等待上游，根本没有启动。
仓库也没有产生新的实现变更；当前仍只有原来未跟踪的 v1.8 规格文档。
## 根因链
1. **硬编码的两分钟墙钟超时**
内置插件默认配置为：
```text
recovery.timeoutMs = 120000
recovery.maxAttempts = 3
```
本机和项目都没有找到覆盖配置，因此这次确实使用默认值。该计时不会因为模型仍在输出、工具仍在执行而续期。
2. **任务粒度远大于两分钟**
`gate0a-core` 同时要求处理身份授权、Route Registry、RevealEvent、侧信道、四轴状态、静态目录安全、导出、数据库和测试，还要阅读约 219KB 的规格。它实际上是数个开发任务的组合，不可能在 120 秒内完整实现和验证。
3. **重试从零开始**
第 2、3 次尝试都创建了新的 Orion 子会话，没有接续上一轮上下文。每轮都会重新“探索仓库→读规格→读核心文件”，造成约 16.6 万输入 Token 的重复消耗，却一直没进入稳定修改阶段。
4. **整个任务图被规划成纯串行链**
```text
baseline
→ gate0a
→ TS-0/TS-1
→ domain
→ workbench
→ export/package
→ final review
```
`maxParallel=4` 实际完全没有发挥作用。Orion 一旦失败，后面五个任务全部无法启动。
5. **模型路由也在放大问题**
尽管任务被标为 `deep`，实际所有子会话都继承了主会话的：
```text
deepseek-v4-flash / low
```
当前实现中，继承主模型会覆盖按任务类别选择模型的逻辑，使 `deep` 分类近似失效。它不是两分钟中断的直接原因，但会显著增加大型架构任务反复侦察的概率。
## 改进建议
优先级最高：
- 把 `timeoutMs` 拆成“无活动超时”和“最大总时长”：
- 无活动超时：120 秒；
- 深度开发任务总时长：15–30 分钟；
- reasoning、工具调用、文件读取等活动应刷新无活动计时器。
- 重试必须继续原子会话和已有工作，不再创建空白子会话；保存最后消息、工具结果、已完成步骤和工作区差异。
- 将 `gate0a-core` 拆成至少四个小任务：身份/授权、揭盲与投影、安全基础设施、测试与运行记录。
- 修复模型路由：协调器可以继承主模型，但 `deep/ultrabrain` 子任务默认应走对应模型，除非用户明确要求所有任务使用同一模型。
- 调整 DAG，让身份基础设施和 TS 类型基础可以在写入范围不冲突时并行；不要让整个任务依赖单一巨型节点。
- 上游最终失败后，将下游标为：
`skipped — blocked by gate0a-core timeout`
并停止累计计时，界面显示 attempt、最后活动时间和明确阻塞原因。
- 增加回归测试：活跃任务超过 120 秒不应被当成失联、重试必须续跑、上游失败后下游状态正确传播、UI 不得继续显示运行中。
临时缓解可以把项目配置提高到 15 分钟，并减少无效重试：
```json
{
"recovery": {
"timeoutMs": 900000,
"maxAttempts": 1
}
}
```
但仅调大超时并不能根治；真正需要修复的是“固定墙钟超时 + 全新会话重试 + 巨型串行任务”这三个机制。 |
-
|
发表于 
